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

[QR] มีตัวอย่างของการพัฒนาแบบโอเพนซอร์สในตลาดสด ที่ประสบความสำเร็จในยุคก่อนอินเทอร์เน็ตบูม และไม่เกี่ยวกับธรรมเนียมของยูนิกซ์และอินเทอร์เน็ตด้วย การพัฒนาของโปรแกรมบีบอัดซึ่งมุ่งใช้สำหรับดอส ชื่อ info-Zip ระหว่างปี 1990–1992 คือตัวอย่างหนึ่งดังกล่าว อีกตัวอย่างหนึ่งคือระบบกระดานข่าว RBBS (สำหรับดอสอีกเหมือนกัน) ซึ่งเริ่มต้นในปี 1983 และได้สร้างชุมชนที่แข็งแกร่งพอที่จะมีการออกรุ่นสม่ำเสมอมาจนถึงปัจจุบัน (กลางปี 1999) ถึงแม้เมลและการใช้แฟ้มร่วมกันในอินเทอร์เน็ตจะมีข้อได้เปรียบทางเทคนิคอย่างมากเหนือ BBS แล้วก็ตาม ในขณะที่ชุมชนของ info-Zip อาศัยเมลในอินเทอร์เน็ตในระดับหนึ่ง แต่วัฒนธรรมของนักพัฒนา RBBS สามารถจะใช้ชุมชนออนไลน์ผ่าน RBBS ซึ่งไม่ขึ้นกับโครงสร้างพื้นฐาน TCP/IP เลยได้

[CV] แนวคิดที่ว่า ความโปร่งใสและการตรวจทานโดยนักพัฒนาอื่น มีประโยชน์ต่อการจัดการความซับซ้อนของการพัฒนาระบบปฏิบัติการ ปรากฏว่าไม่ใช่เรื่องใหม่แต่อย่างใด ในปี 1965 ซึ่งเป็นช่วงแรกๆ ของประวัติศาสตร์ของระบบปฏิบัติการแบบแบ่งเวลาทำงาน (time-sharing) นั้น Corbató และ Vyssotsky ซึ่งเป็นผู้ร่วมออกแบบระบบปฏิบัติการมัลทิกซ์ (Multics) ได้ เขียน ไว้ว่า

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

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

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

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

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

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

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

ผมได้กลับมาสงสัย (ในช่วงต้นปี 2000) ว่าในบทความนี้รุ่นก่อนๆ ผมได้ประเมินความสำคัญของนโยบายต่อต้านเส้นตายที่ว่า "ทำเสร็จแล้วปลุกด้วย" ต่อผลิตภาพและคุณภาพของชุมชนโอเพนซอร์สต่ำเกินไปอย่างร้ายแรง ประสบการณ์ทั่วๆ ไปของการออก GNOME 1.0 อย่างรีบเร่งในปี 1999 ทำให้เราเห็นว่า ความกดดันในการออกรุ่นก่อนที่จะพร้อม สามารถสลายข้อดีด้านคุณภาพหลายข้อที่โอเพนซอร์สเคยให้ตามปกติได้

อาจจะกลายเป็นว่า ความโปร่งใสของกระบวนการ เป็นหนึ่งในแรงขับดันสามเรื่องที่สำคัญพอๆ กันต่อคุณภาพของโอเพนซอร์ส อีกสองเรื่องก็คือกำหนดการแบบ "ทำเสร็จแล้วปลุกด้วย" และการกลั่นกรองตัวเองของนักพัฒนา

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

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

[IN] ประเด็นที่เกี่ยวข้องกับเรื่องที่นักพัฒนาจะสามารถตั้งต้นโครงการจากศูนย์ในแบบตลาดสดได้หรือไม่ ก็คือประเด็นว่า รูปแบบตลาดสดสามารถสนับสนุนงานที่เป็นนวัตกรรมอย่างแท้จริงได้หรือไม่ บางคนอ้างว่า หากปราศจากความเป็นผู้นำที่เข้มแข็งแล้ว ตลาดสดก็สามารถทำได้เพียงจัดการการลอกเลียนและปรับปรุงแนวคิดเดิมที่มีอยู่ที่อยู่ในขั้นประดิษฐ์คิดค้นเท่านั้น คำโต้แย้งที่เป็นที่รู้จักกันมากที่สุด คงเป็น เอกสารวันฮัลโลวีน ซึ่งเป็นบันทึกข้อความสองชิ้นที่น่ากระอักกระอ่วนของไมโครซอฟท์ ที่เขียนเกี่ยวกับปรากฏการณ์โอเพนซอร์ส ผู้เขียนเอกสารได้เปรียบเทียบการพัฒนาระบบปฏิบัติการที่คล้ายยูนิกซ์ของลินุกซ์กับการ ``ไล่กวดไฟท้าย'' และแสดงความเห็นว่า ``(เมื่อโครงการได้ประสบความสำเร็จ "เทียบเคียง" กับแนวคิดใหม่ล่าสุดแล้ว) ระดับของการบริหารที่ต้องใช้ในการผลักดันไปสู่แนวรุกใหม่จะมากมายมหาศาล''

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

ถ้าเราแทน ``ลินุกซ์'' ด้วย ``โอเพนซอร์ส'' เราจะเห็นว่าเรื่องนี้ไม่ใช่เรื่องใหม่อะไรเลย ตามประวัติแล้ว ชุมชนโอเพนซอร์สไม่ได้ประดิษฐ์ Emacs หรือ World Wide Web หรือตัวอินเทอร์เน็ตเองด้วยการไล่กวดไฟท้าย หรือต้องมีการบริหารอย่างมากมายมหาศาลเลย และในปัจจุบัน ก็มีงานนวัตกรรมมากมายที่ยังดำเนินต่อไปในโลกโอเพนซอร์ส จนถึงกับทำให้ผู้ใช้เคยตัวกับการมีทางเลือก โครงการ GNOME (เพื่อเป็นตัวอย่างของอีกหลายโครงการ) ก็ยังคงผลักดัน GUI ใหม่ล่าสุดและเทคโนโลยีออบเจ็กต์อย่างหนัก มากพอที่จะดึงดูดความสนใจจากสื่อมวลชนสาขาคอมพิวเตอร์ที่อยู่นอกชุมชนลินุกซ์ และยังมีตัวอย่างอื่นอีกเป็นกองทัพ ซึ่งการเข้าไปดู Freshmeat สักวันหนึ่ง ก็สามารถพิสูจน์ได้อย่างรวดเร็ว

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

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

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

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

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

อย่างไรก็ดี นั่นเป็นประเด็นเชิงลบ ผู้อ่านควรได้รับประเด็นเชิงบวกบ้าง ผมขอแนะนำให้ทดลองดังนี้:

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

[EGCS] ขณะนี้ เรามีประวัติศาสตร์ของโครงการที่อาจเป็นการทดสอบที่ชี้วัดศักยภาพของรูปแบบตลาดสดได้ดีกว่า fetchmail ในหลายๆ ทาง คือ EGCS (Experimental GNU Compiler System)

โครงการนี้ประกาศตัวเมื่อกลางเดือนสิงหาคม 1997 โดยเป็นความพยายามอย่างจงใจ ที่จะใช้แนวคิดจากบทความ มหาวิหารกับตลาดสด ที่เผยแพร่รุ่นแรก ผู้ก่อตั้งโครงการรู้สึกว่า การพัฒนาของ GCC หรือ GNU C Compiler กำลังติดขัด เป็นเวลายี่สิบเดือนตั้งแต่นั้น ที่ GCC และ EGCS กลายเป็นผลิตภัณฑ์ที่คู่ขนานกัน โดยดึงแรงงานจากนักพัฒนาในอินเทอร์เน็ตกลุ่มเดียวกัน เริ่มต้นจากซอร์สของ GCC เดียวกัน ใช้ชุดเครื่องมือและสภาพแวดล้อมการพัฒนาของยูนิกซ์เหมือนกัน แต่ต่างกันตรงที่ EGCS พยายามใช้เทคนิคของตลาดสดที่ผมได้บรรยายไปแล้ว ในขณะที่ GCC ยังคงใช้โครงสร้างการทำงานที่คล้ายมหาวิหารมากกว่า และทำโดยกลุ่มนักพัฒนาที่ปิด และออกรุ่นไม่บ่อย

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

ในเดือนเมษายน 1999 มูลนิธิซอฟต์แวร์เสรี (ผู้สนับสนุนอย่างเป็นทางการของ GCC) ได้ยุบกลุ่มพัฒนา GCC เดิมเสีย แล้วโอนการควบคุมของโครงการไปให้ทีมหลักของ EGCS แทน

[SP] แน่นอน คำวิจารณ์ของโครพอตกินและกฎของไลนัส ได้สร้างประเด็นกว้างๆ เกี่ยวกับกลไกไซเบอร์สำหรับจัดโครงสร้างสังคม ทฤษฎีชาวบ้านอีกทฤษฎีหนึ่งของวิศวกรรมซอฟต์แวร์ ก็ได้ชี้ให้เห็นอีกประเด็นหนึ่ง คือกฎของคอนเวย์ ซึ่งกล่าวกันโดยทั่วไปว่า ``ถ้าคุณมีทีมงานสี่ทีมร่วมกันทำคอมไพเลอร์ คุณก็จะได้คอมไพเลอร์ที่ทำงานสี่ขั้น'' ข้อความดั้งเดิมอยู่ในรูปทั่วไปกว่านั้น: ``องค์กรต่างๆ ที่ออกแบบระบบ จะถูกบังคับให้สร้างระบบที่สะท้อนโครงสร้างการสื่อสารขององค์กรเหล่านั้น'' เราอาจกล่าวอย่างย่นย่อกว่านั้นได้ว่า ``วิธีการจะกำหนดผลลัพธ์'' หรือแม้แต่ว่า ``กระบวนการจะกลายเป็นผลิตภัณฑ์''

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

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

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