GitHub ควรเก็บเงินเพิ่มอีก 1 ดอลลาร์ต่อเดือนจากผู้ใช้ทุกคนเพื่อสนับสนุนโอเพนซอร์ส

 (blog.greg.technology)
1 คะแนน โดย GN⁺ 2026-01-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้ว่าการพึ่งพาโอเพนซอร์สจะกลายเป็นแกนหลักของการดำเนินงานในองค์กร แต่ก็มีการวิจารณ์ธรรมเนียมที่มองว่าสิ่งนี้ควรได้มาใช้ฟรีเป็นเรื่องปกติ
  • โครงสร้างปัจจุบันที่พึ่งพาการบริจาคหรือการสนับสนุนไม่ยั่งยืน และจำเป็นต้องมีวิธีจัดหาเงินทุนแบบใหม่
  • แนวทางที่เสนอคือให้ GitHub เรียกเก็บเพิ่ม 1 ดอลลาร์ต่อผู้ใช้ต่อเดือน แล้วนำเงินไปสะสมไว้ใน กองทุนโอเพนซอร์ส เพื่อกระจายตามการใช้งาน
  • จัดสรรโดยอิงจากโปรเจ็กต์ที่ถูกอ้างถึงใน package.json หรือ requirements.txt และยกตัวอย่างว่าเป็นโครงสร้างคล้ายกับ โมเดลแบ่งรายได้ของ Spotify
  • จากความจริงที่ว่าโอเพนซอร์สกำลังค้ำจุนโครงสร้างพื้นฐานทั่วโลก จึงเน้นย้ำถึง ความจำเป็นของระบบค่าตอบแทนที่ยั่งยืน

การตั้งคำถามต่อการพึ่งพาโอเพนซอร์สฟรี

  • ชี้ว่ามุมมองที่เห็นว่าโอเพนซอร์สฟรีเหมือนกับ ‘เบียร์ฟรี’ นั้น ไม่ปกติ
    • เบื้องหลังโค้ดมีแรงงานจริงอยู่ และการมองว่าเป็นเพียงงานอดิเรกหรือการมีส่วนร่วมโดยสมัครใจเท่านั้น เป็นสมมติฐานที่ผิด
  • ปัจจุบันระบบนิเวศโอเพนซอร์ส พึ่งพาการบริจาคหรือการสนับสนุน ซึ่งเป็นโครงสร้างที่ไม่มั่นคง
    • นักพัฒนาต้อง ร้องขอการสนับสนุนราวกับกำลังขอทาน เพื่อให้ได้รับความสนใจ
    • บางโปรเจ็กต์กำลังเผชิญกับความจริงที่ว่า เลี้ยงชีพได้ยากและต้องมองหา ‘lifeline’

ข้อเสนอรูปแบบระดมทุนใหม่ผ่าน GitHub

  • เสนอแนวทางให้ GitHub เรียกเก็บเพิ่ม 1 ดอลลาร์ต่อผู้ใช้ต่อเดือนจากทุกองค์กร แล้วสะสมเงินไว้ใน กองทุนโอเพนซอร์ส (Open Source Fund)
    • กองทุนจะถูกเก็บในรูปแบบ escrow และบริหารจัดการอย่างโปร่งใส
  • เงินที่สะสมจะถูก จัดสรรตามการใช้งาน กล่าวคือกระจายตามจำนวนครั้งที่แต่ละโปรเจ็กต์ถูกอ้างถึงใน package.json หรือ requirements.txt
    • อาจรวมถึง คำสั่ง FROM ใน Dockerfile ด้วย
  • อธิบายว่าโมเดลนี้คล้ายกับ วิธีแบ่งรายได้ให้ศิลปินของ Spotify
    • แม้โมเดลของ Spotify จะไม่สมบูรณ์แบบ แต่ก็ยังพอใช้อ้างอิงได้ในฐานะระบบจัดสรรเชิงโครงสร้างขั้นต่ำ

วิธีดำเนินการและโครงสร้างการเข้าร่วม

  • กองทุนจะดำเนินการในรูปแบบ เข้าร่วมโดยปริยาย (opt-out)
    • องค์กรสามารถเลือกไม่เข้าร่วมได้หากไม่ต้องการ
  • อาจมอบสิทธิประโยชน์เชิงสัญลักษณ์ให้แก่องค์กรที่เข้าร่วม เช่น ‘ตราสัญลักษณ์วิเศษ’ หรือ สิทธิ์ตั้งค่า CSS พื้นหลังโปรไฟล์
  • ผู้เสนอแนวคิดระบุว่า “ไอเดียนี้ยังไม่สมบูรณ์และยังหยาบอยู่ แต่ก็ไม่อาจบอกได้ว่าสถานะปัจจุบันนั้น ‘ดี’ แล้ว”

มุมมองต่อความยั่งยืนของโอเพนซอร์ส

  • ภายใต้โครงสร้างปัจจุบัน โค้ดและความพยายามที่ค้ำจุนโครงสร้างพื้นฐานสำคัญของโลก กำลังถูกใช้งานโดยไม่มีค่าตอบแทนใด ๆ
  • เน้นย้ำถึง ความจำเป็นของโครงสร้างการหมุนเวียนเงินทุนแบบใหม่ เพื่อการบำรุงรักษาโอเพนซอร์ส
  • แสดงจุดยืนว่า “ยังไม่รู้ว่าจะรวมโปรเจ็กต์ใหญ่ระดับ Linux อย่างไร แต่ต้องเริ่มจากที่ไหนสักแห่ง”

บทสรุป

  • ผู้เสนอหวังว่าคนที่ฉลาดกว่าตนจะสามารถต่อยอดแนวทางที่เป็นรูปธรรมได้
  • สารหลักคือ “โครงสร้างเงินทุนของโอเพนซอร์สในตอนนี้ไม่ยั่งยืน และจำเป็นต้องเปลี่ยนแปลง”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-16
ความคิดเห็นจาก Hacker News

  • ฉันเป็นคนที่สนุกกับการ มีส่วนร่วมในโอเพนซอร์สโดยไม่ได้รับค่าตอบแทน
    ถ้าคนอื่นชอบงานของฉันด้วยก็ยิ่งดี
    ฉันคิดว่าทัศนคติที่คาดหวังค่าตอบแทนจากโค้ดทุกชิ้นไม่ใช่เรื่องสากล
    ถ้าทำโอเพนซอร์สโดยคาดหวังค่าตอบแทน ก็ถือว่าเข้าหาผิดทางแล้ว
    แต่ถ้าต้องพึ่งพางานของใครสักคน ฉันคิดว่าจำเป็นต้องมี ความเอื้อเฟื้อแบบชุมชน

    • ฉันคิดว่าคนที่มองข้ามมุมมองนี้มักเหมารวมว่า UBI (รายได้พื้นฐานถ้วนหน้า) หรือระบบตาข่ายความปลอดภัยทางสังคมเป็นการ “บั่นทอนแรงจูงใจ”
      คนที่มีความคิดสร้างสรรค์และมีน้ำใจจำนวนมาก ขับเคลื่อนด้วยความสุขล้วนๆ จากการสร้างสรรค์ ไม่ใช่ด้วยเงิน
      ถ้าการดำรงชีพขั้นพื้นฐานได้รับการรับประกัน โลกก็คงมีงานศิลปะ ชุมชน และโอเพนซอร์สมากกว่านี้มาก
    • ฉันยอมรับว่าสิ่งที่คุณพูดถูก
      สิ่งที่ฉันอยากจะบอกคือ งานลักษณะนี้ไม่ควรถูกมองเหมือนเป็นของขวัญที่หล่นมาจากฟ้า
      ยิ่งโปรเจ็กต์ใหญ่ขึ้น ความรับผิดชอบก็ยิ่งมากขึ้น และมันไม่ยุติธรรมที่ภาระนั้นจะไปกระจุกอยู่กับคนคนเดียว
      เหมือนกรณี เหตุการณ์ xz backdoor หรือ PocketBase FAQ เราต้องการการสนับสนุนในระดับระบบ
    • ฉันก็สนุกกับโอเพนซอร์สเหมือนกัน แต่บางครั้งโค้ดของฉันก็กลายเป็น โครงสร้างพื้นฐานสำคัญ ไปโดยไม่รู้ตัว
      ในสถานการณ์แบบนี้ โมเดลการเปลี่ยนผ่านจาก “สิ่งที่ทำเพราะสนุก” ไปเป็น “ความรับผิดชอบระดับงาน” ยังมีไม่พอ
      ด้วยเหตุนี้เอง ผู้ดูแลจำนวนมากจึงหมดไฟ
    • ฉันทำโอเพนซอร์สเพราะความสุขจากการเรียนรู้และการสร้างสรรค์
      โปรเจ็กต์ GitHub ของฉันเหมือนเกาะส่วนตัวของฉัน
      ฉันยินดีรับ PR แต่บางครั้งก็รู้สึกเหมือนมีคนมาลงสีทับบนภาพวาดของฉัน
      ฉันไม่ได้หวังค่าตอบแทน แค่ฟอร์กได้อย่างอิสระตามไลเซนส์ของฉันก็พอ
      สำหรับคนสร้างสรรค์อย่างพวกเรา การไม่เข้ามายุ่งและปล่อยให้มีอิสระ คือความเคารพที่ยิ่งใหญ่ที่สุด
    • ฉันก็ทำโอเพนซอร์สด้วยเหตุผลเดียวกัน
      มันคือ ของขวัญ ที่ฉันมอบให้โลก
      แน่นอนว่าถ้ามีค่าตอบแทนเล็กน้อยก็ดี แต่ถ้าต้องมีภาระผูกพันหรือเงื่อนไข ฉันก็ยังชอบวิธีที่เป็นอิสระแบบตอนนี้มากกว่า

  • โอเพนซอร์สโดยเนื้อแท้คือ ของขวัญที่มอบให้โดยสมัครใจ
    สิ่งที่ได้ตอบแทนมีเพียงชื่อเสียงเล็กน้อยหรือความพึงพอใจ

    • ปัญหาคือ ภาระในการดูแลรักษา
      หลายบริษัทโยนการแก้บั๊กหรือปัญหาด้านความปลอดภัยไปให้ผู้ดูแล
      โครงสร้างแบบนี้ไม่ยั่งยืน และสุดท้ายก็นำไปสู่การหมดไฟกับไลบรารีที่ถูกปล่อยทิ้ง
      ถ้าบริษัทขาดทรัพยากรหรือความเชี่ยวชาญ ก็ควรตอบแทนด้วย การสนับสนุนทางการเงิน
    • มีความเห็นว่าการไปตำหนิคนที่ใช้งานตามเงื่อนไขไลเซนส์นั้นน่าเบื่อเต็มที
    • ฉันคิดว่าการเรียกเงินจากของที่ให้ฟรีไปแล้วนั้นไม่สมเหตุสมผล
    • ทางออกตามธรรมชาติของปัญหานี้คือ ระบบเงินอุดหนุนจากภาครัฐหรือเอกชน
      เราต้องมีโครงสร้างที่ให้ค่าตอบแทนอย่างเป็นธรรมกับคนที่ดูแลโครงสร้างพื้นฐานสำคัญ

  • ทางแก้ปัญหาเรื่องเงินทุนของโอเพนซอร์สไม่ใช่ การบังคับจ่ายเงิน
    โครงสร้างแบบนั้นขัดกับจิตวิญญาณของโอเพนซอร์ส
    ผู้ดูแลและผู้ใช้งานต่างก็ไม่มีภาระผูกพันต่อกัน
    ถ้าไม่ชอบก็แค่ ส่ง PR หรือฟอร์ก
    โอเพนซอร์สไม่ใช่ซอฟต์แวร์เชิงพาณิชย์ แต่เป็นพื้นที่แห่งการแบ่งปันอย่างเสรี

    • แต่การตัดสินว่า “ใครควรได้เงิน” ก็เป็นปัญหาเหมือนกัน
      ถ้าใช้ความนิยมเป็นเกณฑ์ เงินส่วนใหญ่ก็คงไหลไปที่ JavaScript
    • จริงๆ แล้วความหมายดั้งเดิมของโอเพนซอร์สไม่ใช่ “ฟรี” แต่คือ เสรีภาพในการเข้าถึงและแก้ไข
      พูดอีกแบบคือ มันใกล้กับ “เสรีภาพในการแสดงออก” มากกว่า “เบียร์ฟรี”

  • สมมติฐานที่ข้อเสนอนี้ตั้งไว้ว่า “FOSS ส่วนใหญ่เป็นผลงานของอาสาสมัคร” นั้นไม่ถูกต้อง
    โอเพนซอร์สจำนวนมากที่ฉันใช้ถูกสร้างโดย บริษัทยักษ์ใหญ่
    ตัวอย่างเช่น React มาจาก Meta, TypeScript มาจาก Microsoft, และ Chrome มาจาก Google

    • แต่ Chrome ก็ไม่ใช่ FOSS แบบสมบูรณ์
      Google Chrome เป็นเบราว์เซอร์เชิงพาณิชย์ที่สร้างบน Chromium
      Chromium ฟอร์กมาจาก WebKit (Apple) และ WebKit ก็ฟอร์กมาจาก KHTML ของ KDE
    • นอกจากนี้ Chrome ยังพึ่งพา โค้ดที่ไม่ได้มาจาก Google อย่าง libxml2 ด้วย
      เมื่อไม่นานมานี้ผู้ดูแล libxml2 ลาออก ทำให้โครงสร้างการพึ่งพาแบบนี้กลับมาได้รับความสนใจอีกครั้ง

  • ถ้าปล่อยซอฟต์แวร์ออกมาด้วยไลเซนส์โอเพนซอร์ส ก็ไม่ควรแปลกใจที่ผู้คนจะใช้มันฟรี
    ถ้าต้องการรายได้ก็ควรเลือกไลเซนส์แบบอื่น

    • ถ้าไม่ชอบที่บริษัทเอา FOSS ไปทำเชิงพาณิชย์ในรูปแบบที่ไม่เข้ากันกับ FOSS ก็ควรใช้ GPL
    • ไลเซนส์เป็นสิ่งที่เจ้าของลิขสิทธิ์เป็นผู้กำหนด
      ยังมีตัวเลือกอย่าง dual licensing หรือแบบ copyleft อีกมากที่สามารถกำหนดให้การใช้งานเชิงพาณิชย์ต้องมีค่าตอบแทนได้

  • ข้อเสนอให้แจกจ่ายเงินทุนโอเพนซอร์สตาม ปริมาณการใช้งาน นั้นไม่มีประสิทธิภาพ
    การที่ดาวน์โหลดเยอะไม่ได้แปลว่ามีคุณค่าหรือใช้แรงดูแลรักษามาก
    ฉันเองก็มีแพ็กเกจ npm ที่มียอดดาวน์โหลดหลายสิบล้านครั้ง แต่ทำเสร็จสมบูรณ์แล้วแทบไม่ต้องแตะอะไร
    เป็นเรื่องยากที่จะมีอัลกอริทึมที่ตอบโจทย์ทั้ง การป้องกันการปั่นระบบและประสิทธิภาพ ได้พร้อมกัน

  • ถ้ามีระบบแบบนี้ โค้ดสแปมที่สร้างโดย AI จะเพิ่มขึ้นมหาศาล
    มีกรณีคล้ายกันเกิดขึ้นแล้วใน คดีโกงเพลง AI บน Spotify

    • ในความเป็นจริง ปัญหาสแปมลักษณะนี้ก็เกิดขึ้นใน Tea.xyz แล้ว
    • แถมยังมีคนพูดกันว่า Spotify เองก็กำลังทำ เพลง AI อยู่ด้วย

  • ฉันใช้ชีวิตอยู่ได้ด้วย เงินอุดหนุนและเงินสนับสนุน มาหลายปีแล้ว
    ตอนนี้ก็มีแพลตฟอร์มด้านเงินทุนโอเพนซอร์สอยู่มากมาย ปัญหาไม่ได้อยู่ที่แพลตฟอร์ม แต่อยู่ที่ ท่าทีของนักพัฒนา
    ถ้าอยากได้เงิน ก็ต้องพูดให้ชัด
    ส่วนใหญ่ลิงก์รับการสนับสนุนมักถูกฝังลึกอยู่ใน FAQ
    แต่ถ้าขอตรงๆ คนก็มักจะให้เงินอย่างน่าประหลาดใจ
    ขนาด สตรีมเมอร์ Twitch ยังหาเงินได้ ก็ไม่มีเหตุผลที่พวกเราซึ่งสร้างซอฟต์แวร์ที่มีประโยชน์จะหาเงินไม่ได้
    ถ้าเป็นผู้ใช้ระดับองค์กร การติดต่อโดยตรงเพื่อ เสนอการสนับสนุนทางการเงิน มักได้ผล

    • ตัวอย่างเช่น Krita ขยายทีมจาก 2 คนเป็น 4 คนได้ หลังจากวางขายแบบเสียเงินบน Steam และ Windows Store
      ลิงก์ที่เกี่ยวข้อง

  • ถ้ามีระบบแบบนี้ สแปม dependency ที่ไร้ความหมาย จะเพิ่มขึ้น
    ตอนนี้ก็มีนักพัฒนาบางคนแอบยัดแพ็กเกจไร้ประโยชน์เข้ามาใน PR เพื่อปั่นยอดดาวน์โหลดอยู่แล้ว
    เพราะยอดดาวน์โหลดสูงถูกใช้เป็น ตัวชี้วัดความสามารถ ในเรซูเม่

    • ถ้าเกิดโครงสร้างแบบนี้ขึ้น ผู้ดูแลก็คงต้องคอยจับตา สแปม dependency มากขึ้น

  • ถ้าอยากสร้างผลิตภัณฑ์ ก็แค่ สร้างผลิตภัณฑ์แล้วขายมัน
    ที่มันได้รับความนิยมก็เพราะแจกฟรี แต่กลับมาขอเงินทีหลังมันขัดแย้งกันเอง
    ถ้าตั้งแต่แรกต้องจ่ายเงิน ผู้คนก็คงทำใช้เองหรือไม่ก็ไปใช้ตัวอื่น