การวิเคราะห์ใหม่เกี่ยวกับซอฟต์แวร์ Open Source เผยให้เห็นความจริงที่น่าตกใจ โครงสร้างพื้นฐานดิจิทัลส่วนใหญ่ของโลกขึ้นอยู่กับนักพัฒนาแต่ละคนที่ทำงานคนเดียว แม้ว่าซอฟต์แวร์ Open Source จะมีมูลค่าทางเศรษฐกิจประมาณ 8.8 ล้านล้านดอลลาร์สหรัฐตามการวิจัยของ Harvard แต่โครงการส่วนใหญ่ถูกดูแลโดยคนเพียงคนเดียว
ผลกระทบทางเศรษฐกิจ:
- Harvard ประเมินมูลค่าของซอฟต์แวร์โอเพนซอร์ส: 8.8 ล้านล้านดอลลาร์สหรัฐ
- มूลค่าส่วนใหญ่ถูกสร้างขึ้นโดยผู้ดูแลรายบุคคล
- ผู้ดูแลส่วนใหญ่ได้รับค่าตอบแทนเพียงเล็กน้อยหรือไม่ได้รับเลย
ขนาดของโครงการที่มีคนเดียว
ข้อมูลจาก ecosyste.ms ที่ติดตามโครงการ Open Source 11.8 ล้านโครงการ แสดงให้เห็นว่าโครงการประมาณ 7 ล้านโครงการมีผู้ดูแลเพียงคนเดียว ตัวเลขนี้ยิ่งมีนัยสำคัญมากขึ้นเมื่อพิจารณาว่ามีโครงการ 4 ล้านโครงการที่ไม่ทราบจำนวนผู้ดูแล ซึ่งหลายโครงการน่าจะเป็นความพยายามของคนเดียวเช่นกัน รูปแบบนี้ยังคงเป็นจริงแม้กระทั่งสำหรับแพ็กเกจซอฟต์แวร์ยอดนิยมที่นักพัฒนาหลายล้านคนพึ่งพาในแต่ละวัน
เมื่อมองเฉพาะระบบนิเวศ NPM ซึ่งให้ข้อมูลที่ครบถ้วนที่สุดสำหรับการวิเคราะห์ ตัวเลขที่ได้นั้นน่าตกตะลึง ในบรรดาแพ็กเกจ NPM 13,000 แพ็กเกจที่ดาวน์โหลดมากที่สุด (ที่มีการดาวน์โหลดมากกว่า 1 ล้านครั้งต่อเดือน) เกือบครึ่งหนึ่งถูกดูแลโดยคนเดียว การแบ่งแยก 50-50 ระหว่างโครงการที่มีผู้ดูแลคนเดียวและหลายคนนี้ยังคงอยู่ในระดับการดาวน์โหลดที่แตกต่างกัน และจะเปลี่ยนแปลงเฉพาะเมื่อตรวจสอบแพ็กเกจที่มีการดาวน์โหลดมากกว่า 1 พันล้านครั้ง
สstatisticsโครงการ Open Source:
- โครงการทั้งหมดที่ติดตาม: 11.8 ล้านโครงการ
- โครงการที่มีผู้ดูแลคนเดียว: ~7 ล้าน (59%)
- โครงการที่ไม่ทราบจำนวนผู้ดูแล: 4 ล้าน
- โครงการ NPM ที่มีคนเดียว: 4+ ล้าน
- ผู้ดูแล NPM ที่ไม่ซ้ำกัน: ~900,000 คน
- แพ็คเกจยอดนิยม (ดาวน์โหลด 1 ล้านครั้ง+/เดือน): 13,000 แพ็คเกจ
- สัดส่วนผู้ดูแลคนเดียวต่อหลายคน: ~50/50
ความเป็นจริงของการทำงานหนักเกินไปและค่าตอบแทนต่ำ
การอภิปรายของชุมชนเผยให้เห็นความกังวลอย่างลึกซึ้งเกี่ยวกับความยั่งยืนของโมเดลนี้ นักพัฒนาหลายคนชี้ไปที่ตัวอย่างในอดีตเช่นช่องโหว่ Heartbleed ซึ่งเป็นข้อบกพร่องด้านความปลอดภัยที่สำคัญใน OpenSSL - ซอฟต์แวร์ที่ดูแลโดยทีมที่ขาดแคลนทุนทรัพยากรแต่เป็นพลังขับเคลื่อนการเข้ารหัสของอินเทอร์เน็ตส่วนใหญ่ รูปแบบนี้เกิดขึ้นซ้ำทั่วทั้งระบบนิเวศ โครงสร้างพื้นฐานที่จำเป็นถูกสร้างและดูแลโดยอาสาสมัครที่ได้รับค่าตอบแทนเพียงเล็กน้อยหรือไม่ได้รับเลยสำหรับงานของพวกเขา
Open Source สิ่งที่ขับเคลื่อนโลก สิ่งที่ Harvard กล่าวว่ามีมูลค่าทางเศรษฐกิจ 8.8 ล้านล้านดอลลาร์ ส่วนใหญ่เป็นคนเดียว และฉันสามารถรับประกันได้ว่าไม่มีโครงการคนเดียวใดเลยที่มีทรัพยากรในปริมาณที่เหมาะสมที่พวกเขาต้องการ
ข้อมูลแสดงให้เห็นว่าในขณะที่ NPM มีโครงการคนเดียวมากกว่า 4 ล้านโครงการ แต่ถูกดูแลโดยบุคคลเพียงประมาณ 900,000 คน หมายความว่านักพัฒนาหลายคนกำลังจัดการหลายโครงการพร้อมกัน
ความเสี่ยงของห่วงโซ่อุปทานและความกังวลทางภูมิรัฐศาสตร์
การอภิปรายล่าสุดมุ่งเน้นไปที่สัญชาติของผู้ดูแล โดยเฉพาะหลังจากรายงานเกี่ยวกับการพึ่งพาของกระทรวงกลาโหมต่อซอฟต์แวร์ที่เขียนโดยนักพัฒนาจากประเทศต่างๆ อย่างไรก็ตาม ชุมชนโต้แย้งว่าการมุ่งเน้นไปที่ภูมิศาสตร์นั้นพลาดประเด็นที่แท้จริง ความเสี่ยงหลักไม่ใช่ว่านักพัฒนาอาศัยอยู่ที่ไหน แต่เป็นความเปราะบางโดยธรรมชาติของการมีโครงสร้างพื้นฐานที่สำคัญขึ้นอยู่กับบุคคลที่ทำงานหนักเกินไปและขาดทรัพยากร
Bus factor - สิ่งที่เกิดขึ้นเมื่อผู้ดูแลคนเดียวไม่สามารถใช้งานได้ - นำเสนอความกังวลที่เร่งด่วนกว่าการพิจารณาทางภูมิรัฐศาสตร์ เมื่อผู้ดูแลละทิ้งโครงการ ถูกครอบงำ หรือเพียงแค่เปลี่ยนไปสนใจสิ่งอื่น ซอฟต์แวร์ที่พวกเขาสร้างขึ้นอาจกลายเป็นภาระด้านความปลอดภัยหรือเพียงแค่หยุดทำงานกับระบบใหม่ๆ
สิ่งที่เกิดขึ้นเมื่อผู้ดูแลหายไป
สมาชิกชุมชนแบ่งปันผลลัพธ์ต่างๆ เมื่อผู้ดูแลคนเดียวถอนตัวจากโครงการ บางครั้งนักพัฒนาคนอื่น Fork โครงการและรับช่วงการดูแล บางครั้งโครงการแข่งขันเกิดขึ้นเพื่อเติมเต็มช่องว่าง ในบางกรณี ผู้ดูแลเดิมส่งมอบความรับผิดชอบให้กับคนอื่น อย่างไรก็ตาม หลายโครงการกลับถูกทิ้งร้าง สร้างช่องโหว่ด้านความปลอดภัยและปัญหาความเข้ากันได้ตามกาลเวลา
ความท้าทายขยายไปเกินกว่าการหาผู้ดูแลทดแทน แม้แต่ซอฟต์แวร์ที่เสร็จสมบูรณ์ยังต้องการความสนใจอย่างต่อเนื่องเมื่อ Dependencies เปลี่ยนแปลง ช่องโหว่ด้านความปลอดภัยเกิดขึ้น และระบบพื้นฐานพัฒนาไป แพ็กเกจที่ทำงานได้อย่างสมบูรณ์แบบมาหลายปีอาจพังทันทีเมื่อ Python หรือ Node.js เวอร์ชันใหม่ถูกปล่อยออกมา
กลยุทธ์การลดความเสี่ยง:
- Vendoring: คัดลอกโค้ดของ dependency โดยตรงเข้าไปในโปรเจกต์
- Lock files: ใช้ไฟล์ล็อก dependency พร้อมกับ cryptographic checksums
- Mirroring: เก็บสำเนาท้องถิ่นของ dependencies ที่สำคัญ
- Forking: สร้างสำเนาที่เป็นอิสระเมื่อผู้ดูแลหายไป
- Code review: ใช้กระบวนการตรวจสอบโค้ดอย่างละเอียดสำหรับ dependencies
เส้นทางไปข้างหน้า
แม้ว่าจะไม่มีวิธีแก้ปัญหาที่ง่ายสำหรับความท้าทายพื้นฐานนี้ แต่ชุมชนเน้นแนวทางหลายประการ นักพัฒนาบางคนสนับสนุนการ Vendoring Dependencies - การคัดลอกโค้ดจริงเข้าไปในโครงการแทนที่จะพึ่งพาแพ็กเกจภายนอก คนอื่นๆ แนะนำการจัดการ Dependencies ที่ดีกว่าผ่าน Lock Files และ Content-addressing Checksums เพื่อให้แน่ใจว่าการ Build สามารถทำซ้ำได้
การอภิปรายเน้นให้เห็นความตึงเครียดที่กว้างขึ้นในการพัฒนาซอฟต์แวร์สมัยใหม่ ความสะดวกในการ Import แพ็กเกจและไลบรารีหลายสิบตัวได้สร้างเว็บของ Dependencies ที่ซับซ้อนซึ่งนักพัฒนาเพียงไม่กี่คนเข้าใจอย่างเต็มที่ แนวทางนี้แม้จะช่วยให้การพัฒนาเป็นไปอย่างรวดเร็ว แต่ก็สร้างความเสี่ยงเชิงระบบเมื่อส่วนประกอบที่สำคัญถูกดูแลโดยบุคคลเดียวโดยไม่มีทรัพยากรหรือการสนับสนุนที่เพียงพอ
ชุมชน Open Source ยังคงต่อสู้กับวิธีการสร้างสมดุลระหว่างจิตวิญญาณการทำงานร่วมกันที่ทำให้โครงการเหล่านี้เป็นไปได้กับความจำเป็นในการมีโครงสร้างพื้นฐานซอฟต์แวร์ที่ยั่งยืนและปลอดภัยซึ่งขับเคลื่อนโลกสมัยใหม่
อ้างอิง: Open Source is one person