ระบบนิเวศซอฟต์แวร์โอเพนซอร์สกำลังเผชิญวิกฤตที่เพิ่มขึ้น ขณะที่ผู้ดูแลต้องดิ้นรนกับการไหลบ่าของรายงานบั๊กที่สร้างด้วย AI ที่เพิ่มมากขึ้น ในขณะที่บริษัทต่างๆ ยังคงได้รับประโยชน์โดยไม่มีการตอบแทนกลับคืน ความท้าทายนี้เห็นได้ชัดเจนในโปรเจกต์ที่ใช้กันอย่างแพร่หลายอย่าง curl ซึ่งขับเคลื่อนอุปกรณ์กว่าหนึ่งพันล้านเครื่องทั่วโลก แต่ดำเนินงานด้วยพนักงานเต็มเวลาเพียงคนเดียว
สถิติโครงการ Curl :
- เริ่มต้น: ปี 1996 ด้วยโค้ด 100 บรรทัด
- ขนาดปัจจุบัน: โค้ด 180,000 บรรทัด
- ผู้มีส่วนร่วม: ผู้เขียนทั้งหมด 1,400 คน
- ผู้มีส่วนร่วมที่ทำงานอย่างต่อเนื่องรายเดือน: นักพัฒนา 20-25 คน
- พนักงานเต็มเวลา: 1 คน ( Daniel Stenberg )
- การใช้งาน: อุปกรณ์มากกว่า 1 พันล้านเครื่อง
- ผู้ผลิตรถยนต์ที่ใช้ curl : 47 บริษัท
- ผู้ผลิตรถยนต์ที่มีส่วนร่วม: 0 บริษัท
เสียงรบกวนจาก AI ทำให้ปัญหาจริงจมหาย
แนวโน้มที่น่าวิตกได้เกิดขึ้นเมื่อผู้คนใช้โมเดลภาษาขนาดใหญ่เพื่อสร้างช่องโหว่ด้านความปลอดภัยและรายงานบั๊กปลอม การส่งข้อมูลที่สร้างด้วย AI เหล่านี้ผิดพลาดอย่างสม่ำเสมอ แต่กินเวลาอย่างมากจากผู้ดูแลที่ต้องตรวจสอบรายงานแต่ละฉบับ ปัญหานี้ขยายไปเกินกว่าความผิดพลาดธรรมดา บางคนตั้งใจใช้ AI เพื่อสร้างปัญหาด้านความปลอดภัยที่ฟังดูน่าประทับใจแต่เป็นเรื่องแต่งขึ้น โดยหวังจะได้เครดิต CVE สำหรับประวัติการทำงานหรือรับเงินรางวัล
ชุมชนได้สังเกตเห็นรูปแบบนี้แพร่กระจายไปยังหลายโปรเจกต์ โดยรายงานต่างๆ รวมถึง API ที่แต่งขึ้นและช่องโหว่ที่ไม่มีอยู่จริง สิ่งที่ทำให้เรื่องนี้น่าหงุดหงิดเป็นพิเศษคือ ผู้คนที่ส่งรายงานเหล่านี้แทบไม่เคยตรวจสอบผลลัพธ์จาก AI ก่อนส่งให้ผู้ดูแล
การพึ่งพิงจากบริษัทโดยไม่มีการสนับสนุน
แม้ว่าผู้ผลิตรถยนต์ 47 รายใช้ curl ในผลิตภัณฑ์ของตน แต่ไม่มีใครมีส่วนร่วมในการพัฒนา รูปแบบนี้สะท้อนการคาดเดาในอุตสาหกรรมที่กว้างขวางว่าจะมีคนอื่นมาให้เงินทุนสำหรับการดูแลโอเพนซอร์ส การขาดการเชื่อมต่อระหว่างการใช้งานและการสนับสนุนสร้างสถานการณ์ที่ไม่ยั่งยืน ซึ่งโครงสร้างพื้นฐานที่สำคัญต้องพึ่งพิงงานอาสาสมัคร
อย่างไรก็ตาม ปัญหานี้ไม่ใช่เพียงความโลภของบริษัท บริษัทและนักพัฒนาหลายรายต้องการสนับสนุนโปรเจกต์โอเพนซอร์สจริงๆ แต่เผชิญอุปสรรคทางกฎหมายและระบบราชการที่สำคัญ ข้อกำหนดการประเมินผู้ขายที่ซับซ้อน ปัญหาการปฏิบัติตามกฎหมายภาษี และกฎระเบียบเงินทุนต่อต้านการก่อการร้ายทำให้การบริจาคเป็นเรื่องยากอย่างน่าแปลกใจสำหรับองค์กรขนาดใหญ่
ความซับซ้อนในการชำระเงินและกฎหมาย
เส้นทางสู่การสนับสนุนโปรเจกต์โอเพนซอร์สเต็มไปด้วยอุปสรรคที่ไม่คาดคิด บริษัทต่างๆ มักต้องการใบแจ้งหนี้อย่างเป็นทางการและการประเมินผู้ขายที่อาจยาวถึง 20 หน้า โดยต้องการใบรับรองและนโยบายความปลอดภัยที่ผู้ดูแลรายบุคคลไม่สามารถให้ได้ หน่วยงานจัดเก็บภาษีอาจถือว่าการบริจาคเป็นการใช้จ่ายส่วนตัว ซึ่งสร้างความซับซ้อนเพิ่มเติมสำหรับทั้งผู้บริจาคและผู้รับ
จากประสบการณ์ของฉัน ธุรกิจส่วนใหญ่จริงๆ แล้วต้องการบริจาคหรือจ่ายเงินเพื่อสนับสนุนโปรเจกต์ OSS ที่พวกเขาพึ่งพิง ปัญหาคือการทำเช่นนั้นเป็นเรื่องยากเนื่องจากกฎหมาย การปฏิบัติตามข้อกำหนด ฯลฯ
วิธีแก้ปัญหาเชิงสร้างสรรค์บางอย่างได้เกิดขึ้น เช่น การจ่ายเงินให้ผู้ดูแลสำหรับการพูดในงานหรือการให้คำปรึกษาแทนการบริจาคโดยตรง วิธีการนี้ทำงานภายในระบบการชำระเงินของบริษัทที่มีอยู่ ในขณะที่ให้รายได้ที่จำเป็นแก่ผู้ดูแลโปรเจกต์
ตัวอย่างการสนับสนุนทางการเงิน:
- German Sovereign Tech Agency : เงินบริจาค 200,000 ยูโร
- แพลตฟอร์มที่มีให้บริการ: GitHub Sponsors , KoFi , Patreon
- วิธีการชำระเงินทางเลือก: ค่าตอบแทนการบรรยาย, สัญญาให้คำปรึกษา
- ผู้สนับสนุนทางการเงิน: Software Freedom Conservancy , Software in the Public Interest ( SPI )
โครงสร้างพื้นฐานถูกโจมตี
นอกเหนือจากปัญหาที่มนุษย์สร้างขึ้น โปรเจกต์โอเพนซอร์สในปัจจุบันยังเผชิญความท้าทายทางเทคนิคจากบริษัท AI ที่มีเว็บสแครปเปอร์สร้างการโจมตีแบบกระจายเพื่อปฏิเสธการให้บริการ ระบบอัตโนมัติเหล่านี้ใช้แบนด์วิดธ์จำนวนมหาศาลโดยไม่มีส่วนร่วมอะไรกับโปรเจกต์ที่พวกเขาสแครป สำหรับเว็บไซต์ของ curl มีเพียง 0.01% ของการใช้แบนด์วิดธ์ที่มาจากการดาวน์โหลดซอร์สโค้ดจริง ส่วนที่เหลือเป็นการจราจรของบอท
การรวมกันของสแปมที่สร้างด้วย AI การพึ่งพิงจากบริษัท และการโจมตีโครงสร้างพื้นฐานสร้างพายุที่สมบูรณ์แบบที่คุกคามความยั่งยืนของโปรเจกต์โอเพนซอร์สที่สำคัญ แม้ว่าความคิดริเริ่มอย่าง GitHub Sponsors และมูลนิธิต่างๆ จะให้การบรรเทาบ้าง แต่ความไม่สมดุลพื้นฐานระหว่างการใช้งานและการมีส่วนร่วมยังคงเพิ่มขึ้น
สถานการณ์นี้เน้นย้ำถึงความจำเป็นที่สำคัญสำหรับระบบที่ดีกว่าในการเชื่อมต่อผู้ใช้งานจากบริษัทกับผู้ดูแลที่พวกเขาพึ่งพิง ในขณะที่พัฒนาวิธีการที่มีประสิทธิภาพมากขึ้นในการกรองเสียงรบกวนที่สร้างด้วย AI ออกจากการมีส่วนร่วมที่แท้จริง
อ้างอิง: The challenge of maintaining curl