การพัฒนาซอฟต์แวร์ GNU มีความยั่งยืนในเชิงเศรษฐกิจอย่างไร

ฉันขอโทษหากคำถามนี้อยู่นอกหัวข้อ แต่เป็นเศรษฐกิจและคำถามการเขียนโปรแกรมพร้อมกัน ถ้าควรไปที่ชุมชน SE อื่นโปรดระบุฉัน

ในทางทฤษฎีซอฟต์แวร์ GNU ได้รับการพัฒนาโดยอาสาสมัครในช่วงเวลาว่างหรือโดย บริษัท ที่โปรแกรมเมอร์กองทุนอาสาสมัครเพื่อพัฒนาซอฟต์แวร์ GNU (โดยใช้รายได้จากกิจกรรมอื่นของภาคส่วน)

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

ปัญหาคือว่าสิ่งนี้มีขนาดเล็กมากสำหรับโปรแกรมขนาดใหญ่ด้วยเหตุผลดังต่อไปนี้:

1. สนุกเหมือนการเขียนโปรแกรมเนื่องจากโครงการที่ต้องดำเนินการมีขนาดใหญ่ขึ้นเวลาที่ใช้ในการใช้งานฟังก์ชั่นที่ต้องการจะเติบโตอย่างรวดเร็ว โปรแกรมขนาดใหญ่ใช้เวลาในการพัฒนาอย่างไม่น่าเชื่อตัวอย่างเช่นอาจใช้เวลาว่าง 15 ปีและวันหยุดพักผ่อนสำหรับแต่ละคนในการเขียนโปรแกรมระบบปฏิบัติการและเมื่อซอฟต์แวร์ของเขาถูกปล่อยออกมามันจะล้าสมัยไปอย่างสมบูรณ์ .
2. ในขณะที่คนอื่นเขียนโปรแกรมในลักษณะที่คุณทำเสร็จการอ่านและทำความเข้าใจโค้ดของคนอื่นต้องใช้เวลามากในกรณีส่วนใหญ่เท่าที่จะเขียนโค้ดของคุณเองตั้งแต่เริ่มต้น การปรับเปลี่ยนรหัสของผู้อื่นและพยายามปรับปรุงตามที่ได้รับการสนับสนุนโดยปรัชญา GNU นั้นใช้เวลานานพอสมควรในการพัฒนาโคลนของโปรแกรมดังกล่าวด้วยฟังก์ชั่นที่คุณต้องการเพิ่ม
3. ทันทีที่มีคน 2 คนหรือมากกว่านั้นจะต้องร่วมมือกันพัฒนาโปรแกรมที่ใหญ่ขึ้นสิ่งนี้จะสร้างปัญหาการตัดสินใจจำนวนมากที่ไม่เคยเกิดขึ้นกับโครงการผู้พัฒนาเดี่ยว ผลลัพธ์คือตัวอย่างเช่นหากกลุ่มของโปรแกรมเมอร์ 2 คนทำงานร่วมกันในโครงการที่ใช้เวลา 10 ปีในการสร้างคนเดียวพวกเขาจะไม่ทำใน 5 ปี แต่อาจเป็น 8 ปี
4. หากคนที่ทำงานร่วมกันในโครงการเดียวกันพบบนอินเทอร์เน็ตเพียงอย่างเดียวมันเป็นเรื่องง่ายสำหรับสมาชิกคนหนึ่งของโครงการที่จะหายไปทันที (เพราะเขาหมดความสนใจหรือเพราะเขาไม่สามารถอยู่บนอินเทอร์เน็ตได้อีกต่อไป) จึงทำให้การทำงานร่วมกันได้ ยาก

ดังนั้นในขณะที่ฉันเข้าใจอย่างสมบูรณ์แบบว่าโปรแกรมง่าย ๆ สามารถพัฒนาด้วยแนวคิด GNU ได้อย่างไรฉันไม่เห็นเลยว่าโปรแกรมขนาดใหญ่เช่น GNU / Linux หรือ gcc เป็นไปได้อย่างไรในรุ่นนี้ gcc มีรหัสประมาณ 7 ล้านบรรทัด ฉันรู้ว่าบรรทัดของโค้ดไม่ได้มีความหมายมากนักเนื่องจากในระยะต่อมาของโปรเจ็กต์โปรแกรมเมอร์ที่มีประสิทธิผลมากขึ้นคือผู้ที่จะลบบรรทัดของโค้ดจริง ๆ (ทำให้ง่ายขึ้นและ / หรือปรับโครงการให้เหมาะสม) โครงการ gcc คือ

ดังนั้นในทางทฤษฎีใคร ๆ ก็สามารถดัดแปลง gcc ได้อย่างอิสระในช่วงเวลาว่าง แต่ในทางปฏิบัติ มันได้รับการพัฒนาโดยคนที่มีความเป็นมืออาชีพมากเป็นงานไม่ใช่งานอดิเรก ทุกคนที่สร้างคอมไพเลอร์เป็นงานอดิเรกในที่สุดจะยอมแพ้เพราะค่าใช้จ่าย / ผลประโยชน์ไม่คุ้มค่า:

• การพัฒนาโปรแกรมขนาดใหญ่เป็นโครงการขนาดใหญ่ในระยะยาวพวกเขาต้องการใช้เวลาว่างเพื่อทำกิจกรรมอื่น ๆ ที่ให้ผลตอบแทนมากกว่าหรือสนุกสนานในระยะสั้น
• หากพวกเขาต้องพัฒนาโปรแกรมขนาดใหญ่อยู่ดีพวกเขาต้องการทำเพื่อ บริษัท ที่จะจ่ายเงินให้พวกเขาแทนที่จะทำโปรแกรมฟรี

เพื่อให้ผู้ที่สนใจพัฒนาโปรแกรมเช่น GNU / Linux, gcc หรือ Open Office ในระยะยาวควรได้รับรางวัล ดังนั้นคำถามของฉันคือ: ทำไมมีคนบริจาคให้กับโครงการ GNU ขนาดใหญ่ถ้าพวกเขาไม่ได้รับเงินเดือน?

ฉันต้องการเริ่มต้นด้วยการบอกว่าฉันไม่ใช่โปรแกรมเมอร์และฉันไม่เคยมีส่วนร่วมในโครงการโอเพ่นซอร์สใด ๆ อย่างไรก็ตามฉันสนใจโอเพนซอร์ซมาเป็นเวลานานและฉันเชื่อว่าฉันเข้าใจแนวคิดทั่วไปของโอเพ่นซอร์สและวิธีการทำงาน

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

แต่ให้พูดคุยเกี่ยวกับคะแนนของคุณเกี่ยวกับความยืดหยุ่น

1. สิ่งที่ยอดเยี่ยมเกี่ยวกับโอเพ่นซอร์สคือคุณไม่จำเป็นต้องพัฒนาทุกอย่างตั้งแต่เริ่มต้น ระบบปฏิบัติการอย่างอูบุนตูยังไม่ได้สร้างโดยบุคคลเดียว แต่ผู้คนจำนวนมากมีส่วนร่วมในส่วนต่าง ๆ ของระบบ (จริง ๆ แล้วฉันคิดว่ามันยากที่จะหาคนที่มีทักษะทั้งหมดเพื่อสร้างและระบบปฏิบัติการที่มีประสิทธิภาพ) ตัวอย่างเช่นคน Ubuntu ไม่ได้พัฒนาเคอร์เนล Linux พวกเขาใช้เพียงหนึ่งที่พัฒนาโดยผู้อื่น ดังนั้นสิ่งที่ไม่มีโอเพนซอร์สอาจเป็นไปไม่ได้ตอนนี้เป็นไปได้เพราะคุณสามารถสร้างงานของคนอื่นได้

2. การอ่านและทำความเข้าใจโค้ดอื่น ๆ นั้นใช้เวลาไม่นานกว่าการเขียนของคุณเอง อย่างน้อยก็ในหลายกรณี นอกเหนือจากนั้นคุณไม่จำเป็นต้องเข้าใจรหัสทั้งหมดที่คุณใช้ ถ้าฉันต้องการเขียนโปรแกรมสำหรับ Linux ฉันไม่ต้องเข้าใจว่าส่วนต่างๆในโปรแกรมนั้นทำงานโดยละเอียดหรือไม่ ฉันแค่ต้องรู้ว่าพวกเขาทำอะไร จากนั้นฉันสามารถนำส่วนเหล่านี้มารวมกับส่วนอื่น ๆ เพื่อสร้างโปรแกรมของฉัน หรือฉันสามารถใช้โปรแกรมที่มีอยู่และปรับเปลี่ยนตามความต้องการของฉัน

3. เครื่องมือเช่น git และ gitub ทำให้ง่ายต่อการทำงานร่วมกันอย่างเหลือเชื่อ คุณเพิ่งได้รับรหัสและทำการแก้ไข จากนั้นคุณส่งให้กับบุคคลที่รับผิดชอบโครงการ หากดีก็จะได้รับการยอมรับ

4. ผู้คนเข้าและออกจากโครงการตลอดเวลา แต่ถ้าโครงการได้รับความนิยมก็จะสามารถทำงานได้

นี่คือสาเหตุบางประการที่ทำให้โอเพ่นซอร์สทำงานได้

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

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

หากคุณยังสนใจฉันขอแนะนำให้คุณอ่าน The Cathedral และ Bazaar

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

สมมติว่าฉันเป็นนักพัฒนาซอฟต์แวร์ (ฉัน) และฉันกำลังทำงานในโครงการซอฟต์แวร์ที่ซับซ้อน (ฉัน) สถาปัตยกรรมที่ดีแบ่งปัญหาออกเป็นชิ้นส่วนอิสระและเมื่อการพัฒนาดำเนินต่อไปนักพัฒนามักจะตระหนักว่าบางชิ้นที่พวกเขาต้องการนั้นเป็นปัญหาที่พบได้บ่อย นี่คือบางเส้นทางทั่วไปไปข้างหน้า:

1. พวกเขาพัฒนาชิ้นนั้นเองและมันจะกลายเป็นทรัพย์สินของ บริษัท หรือพวกเขาซื้อโซลูชันแบบปิดแหล่งที่มาจาก บริษัท อื่น
2. พวกเขาพบว่าเป็นโครงการโอเพนซอร์ซที่แก้ปัญหานี้ได้อย่างสมบูรณ์แบบและมีสิทธิ์ใช้งานที่เหมาะสม พวกเขารวมมันเข้าไปในโครงการของพวกเขาซึ่งอาจหรืออาจไม่จำเป็นต้องเปิดแหล่งที่มาขึ้นอยู่กับใบอนุญาตและวิธีการใช้ พวกเขาไม่สนับสนุนกลับไปที่โครงการ
3. พวกเขาพบโครงการโอเพนซอร์สที่เกือบจะแก้ปัญหานี้ได้ แต่มีข้อบกพร่องหรือข้อบกพร่อง พวกเขาปรับปรุงมันและพวกเขาอาจมีส่วนร่วมในการปรับปรุงเหล่านั้นกลับไปที่โครงการพื้นฐาน
4. พวกเขาไม่พบสิ่งที่พวกเขาชอบมากพอดังนั้นพวกเขาจึงเริ่มโครงการของตัวเองและตัดสินใจที่จะเปิดแหล่งที่มา

ข้อดีของ 2-4 คือผู้คนจำนวนมากมีส่วนร่วมในทั้งการออกแบบและรหัสของโครงการและมันจะเข้าสู่ระบบนิเวศที่ความคิดที่แข็งแกร่งอยู่รอด (โดยการให้กำเนิดถ้าคุณต้องการ) และคนที่อ่อนแอไม่ได้ การแก้ไขข้อผิดพลาดและการเพิ่มคุณสมบัติกลายเป็นความพยายามของชุมชน ในสถานการณ์ # 2 และ 3 ผู้พัฒนาใช้ประโยชน์จากโครงการจากหลักการทางวิศวกรรมเสียงและรหัสที่ครบกำหนด 3 และ 4 มีความสัมพันธ์กัน ในสถานการณ์ # 4 นักพัฒนาได้รับประโยชน์เมื่อผู้อื่นยอมรับและปรับปรุงรหัสและให้กลับ (# 3) มันมีประโยชน์ที่จะมีส่วนร่วมในโครงการเพื่อให้การปรับปรุงของคุณได้รับการยึดติดอยู่กับการแก้ไขและการปรับปรุงอื่น ๆ จากประสบการณ์ของฉันทุกสถานการณ์เหล่านี้เป็นเรื่องธรรมดา

ในโครงการซอฟต์แวร์ปัจจุบันของฉันฉันเป็นหนึ่งในนักพัฒนาประมาณ 12 คนและทำงานบนระบบเป็นเวลาประมาณสองปี เราได้รวมโครงการโอเพนซอร์ซประมาณ 5,000 โครงการ! เราได้วางไข่โครงการ FOSS ใหม่เพียงไม่กี่แห่งและกลับมาสนับสนุนอีกครึ่งโหล เราไม่ได้เป็นพลเมืองที่ดีโดยเฉพาะในกรณีนี้ (บริษัท อื่น ๆ นั้นดีกว่ามาก) แต่นี่แสดงให้คุณเห็นว่าการทำงานทั้งหมดนี้เป็นอย่างไร แม้ในโครงการขนาดเล็กการมีส่วนร่วมจากโอเพนซอร์สก็สามารถทำได้อย่างง่ายดายในจำนวนหลายสิบหรือหลายร้อย หากเราไม่ได้ใช้ซอฟต์แวร์โอเพนซอร์ซค่าใช้จ่ายในการพัฒนาจะเพิ่มขึ้นเป็น 100-10,000 เท่า

ความสามารถในการปรับขยายเกิดขึ้นเนื่องจากการออกแบบที่แยกส่วนและผ่านกระบวนการการเอาชีวิตรอดแบบไม่ จำกัด ซึ่งโค้ดสามารถรับการปรับโครงสร้างใหม่ทางแยกและอื่น ๆ ความสามารถในการเอาตัวรอดมักจะดีกว่าทางเลือกที่เป็นกรรมสิทธิ์เพราะแม้ว่ารหัสจะไม่ได้รับการดูแลรักษาอีกต่อไปมันอยู่ข้างนอกและคนอื่น ๆ ที่พบคุณค่าในตัวมันสามารถคงไว้ซึ่งตัวเองได้ บริษัท มาและไปและพนักงานได้รับการว่าจ้างและเลิกจ้างเร็วยิ่งขึ้น หากคุณเพิ่มการพึ่งพาซอฟต์แวร์ที่คุณไม่มีซอร์สโค้ดสำหรับหรือมีทีมงานขนาดเล็กเพียงคนเดียวในการดูแลคุณมีความเสี่ยงสูง โครงการขนาดใหญ่เช่นเคอร์เนล Linux, gcc, Android และอื่น ๆ มักจะมี บริษัท จำนวนมากที่ให้การสนับสนุน

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

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