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

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

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

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

ไลนัส ปฏิบัติกับผู้ใช้ของเขาเหมือนกับผู้ร่วมงาน ด้วยวิธีที่ได้ผลที่สุด:

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

แต่ว่ามันเป็นไปได้อย่างไร? มันเป็นสิ่งที่ผมจะทำตามได้ไหม? หรือว่านี่เป็นอัจฉริยภาพเฉพาะตัวของ ไลนัส ทอร์วัลด์ เท่านั้น?

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

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

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

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

หรือพูดง่ายๆ คือ ``ขอให้มีสายตาเฝ้ามองมากพอ บั๊กทั้งหมดก็เป็นเรื่องง่าย'' (Given enough eyeballs, all bugs are shallow) ผมขอตั้งคำพูดนี้เป็น ``กฎของไลนัส''

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

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

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

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

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

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

กฎของไลนัสสามารถกล่าวได้อีกแบบว่า ``การแก้บั๊กสามารถทำขนานกันได้'' (Debugging is parallelizable) ถึงแม้การสื่อสารระหว่างผู้แก้บั๊กกับนักพัฒนาที่ทำหน้าที่ประสานงานจะเป็นเรื่องจำเป็น แต่ในระหว่างผู้แก้บั๊กด้วยกันเองนั้น แทบไม่ต้องประสานงานกันเลย ดังนั้น การแก้บั๊กจึงไม่เพิ่มความซับซ้อนและค่าโสหุ้ยในการจัดการเป็นอัตรากำลังสองเหมือนการเพิ่มนักพัฒนา

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

บรูกส์ (ผู้แต่ง The Mythical Man-Month) เคยตั้งข้อสังเกตแบบผ่านๆ เกี่ยวกับเรื่องนี้ไว้ว่า ``ต้นทุนของการดูแลรักษาโปรแกรมที่มีผู้ใช้แพร่หลาย มักมีค่าประมาณร้อยละ 40 ของต้นทุนที่ใช้ในการพัฒนา น่าแปลกใจตรงที่จำนวนผู้ใช้มีผลกระทบอย่างมากต่อต้นทุนนี้ ยิ่งมีผู้ใช้มากก็เจอบั๊กมาก'' [เน้นข้อความเพิ่ม]

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

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

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