Linus's Law
มีตามากพอ bug ทุกตัวก็ตื้น
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”Linus’s Law ถูกบัญญัติโดย Eric S. Raymond ในบทความและหนังสือ The Cathedral and the Bazaar (1999) ตั้งชื่อเพื่อเป็นเกียรติแก่ Linus Torvalds ผู้ก่อตั้ง Linux kernel ประโยคต้นฉบับคือ
“Given enough eyeballs, all bugs are shallow” (เมื่อมีสายตามากพอ bug ทุกตัวก็ตื้น)
Raymond ให้นิยามที่เป็นทางการกว่านั้นไว้ด้วยว่า “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone” — กล่าวคือ ถ้ามีฐานผู้ทดสอบและผู้ร่วมพัฒนาใหญ่พอ ปัญหาแทบทุกอย่างจะถูกระบุสาเหตุได้เร็ว และมีใครสักคนมองเห็นทางแก้ได้อย่างชัดเจน นี่คือหลักการที่อธิบายว่าทำไม model การพัฒนาแบบ “bazaar” (เปิดให้ทุกคนช่วยกันตรวจและแก้) ถึงเอาชนะ model แบบ “cathedral” (ปิด ควบคุมโดยผู้เชี่ยวชาญกลุ่มเล็ก) ได้ในหลายกรณีของ Linux kernel และซอฟต์แวร์โอเพนซอร์สยุคแรก
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”หัวใจของกฎนี้คือ ปัญญารวมหมู่ (collective intelligence) ของกลุ่มคนที่หลากหลายและมากพอ มีแนวโน้มเหนือกว่าการพึ่งพาผู้เชี่ยวชาญเพียงไม่กี่คน เพราะแต่ละคนมีพื้นเพ ประสบการณ์ และมุมมองต่างกัน สิ่งที่คนหนึ่งมองข้าม อีกคนอาจสะดุดเจอทันที เมื่อนำแนวคิดนี้มาใช้กับซอฟต์แวร์ ก็หมายความว่ายิ่งมีคนอ่าน code มากเท่าไร โอกาสที่ bug ข้อผิดพลาดเชิงตรรกะ หรือช่องโหว่ด้านความปลอดภัยจะถูกพบเร็วก็ยิ่งสูงขึ้น — เป็นรากฐานที่อธิบายพลังของ open source, collective code ownership และวัฒนธรรม code review
แต่กฎนี้มีข้อจำกัดสำคัญที่มักถูกมองข้าม
- “มี” สายตา ไม่เท่ากับ “ใช้” สายตา — Robert Glass วิจารณ์ไว้ใน Facts and Fallacies of Software Engineering ว่า Linus’s Law เป็นเพียง “mantra” ที่ขาดหลักฐานเชิงประจักษ์ งานวิจัยชี้ว่าอัตราการพบ bug ไม่ได้เพิ่มเป็นเส้นตรงตามจำนวนผู้ตรวจ แต่มีจำนวนผู้ตรวจที่มีประโยชน์สูงสุดอยู่ที่ราว 2-4 คนต่อรอบเท่านั้น เกินกว่านั้นผลตอบแทนจะลดลง (diminishing returns)
- ผู้ใช้ ≠ ผู้ตรวจ code — คนส่วนใหญ่ที่ “ใช้” ซอฟต์แวร์โอเพนซอร์สไม่เคยอ่าน source code เลย พวกเขาเห็นแค่พฤติกรรมภายนอก การนับจำนวนผู้ใช้ทั้งหมดว่าเป็น “eyeballs” จึงเป็นการประเมินสูงเกินจริง
- การเขียน code ง่ายกว่าการตรวจ code — ปริมาณ code ที่ถูกเขียนเพิ่มขึ้นเร็วกว่าจำนวนคนที่มีทั้งเวลาและความเชี่ยวชาญพอจะตรวจสอบมันอย่างจริงจัง โดยเฉพาะการตรวจด้านความปลอดภัยที่ต้องใช้ทักษะเฉพาะทาง
- สายตาที่ไม่ได้มองจริง ๆ ไม่ช่วยอะไร — Jim Zemlin ผู้อำนวยการบริหารของ Linux Foundation ให้ความเห็นหลังเหตุการณ์ช่องโหว่ใหญ่หลายตัวในปี 2014 ว่า “the eyeballs weren’t really looking” (สายตาเหล่านั้นไม่ได้จ้องมองอยู่จริง)
- กฎนี้ไม่ได้ผูกกับ open source โดยตรง — Microsoft Security Blog ชี้ว่าปัจจัยตัดสินคือทรัพยากรคนที่ actively ตรวจและแก้ bug ไม่ใช่ว่า code เปิดหรือปิด project closed-source ที่มี developer 50 คนกับ tester 50 คนอาจพบและแก้ bug ได้มากกว่า project โอเพนซอร์สที่มี core developer แค่ 5 คนกับผู้ร่วมพัฒนาอีก 20 คน — “ความสามารถในการตรวจ code ได้ (can)” ไม่เหมือนกับ “การตรวจ code จริง (does)“
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- Heartbleed (2014) — ช่องโหว่ร้ายแรงใน OpenSSL ซึ่งเป็นโครงสร้างพื้นฐานสำคัญของอินเทอร์เน็ต ส่งผลกระทบต่อเว็บไซต์ HTTPS ราว 18% ทั่วโลก แต่ bug นี้ซ่อนอยู่ใน code ที่ “เปิด” ให้ทุกคนดูได้นานถึงสองปีก่อนถูกค้นพบ Jeff Atwood เขียนบทความ “Given Enough Money, All Bugs Are Shallow” ชี้ว่านี่คือหลักฐานที่หักล้าง Linus’s Law โดยตรง เขาสรุปว่าสิ่งที่ขาดไม่ใช่สายตา แต่คือแรงจูงใจ — และหลังจากเหตุการณ์นี้ อุตสาหกรรมก็เริ่มพึ่งพา bug bounty program และเงินทุนสนับสนุนการตรวจสอบความปลอดภัยของ infrastructure โอเพนซอร์สอย่างจริงจังมากขึ้น (เช่น Core Infrastructure Initiative)
- Linux kernel เอง — ตัวอย่างดั้งเดิมที่ Raymond ใช้อ้างอิง การที่ kernel เปิดให้นักพัฒนาทั่วโลกส่ง patch และรายงาน bug เข้ามาจำนวนมาก ทำให้ปัญหาที่ซับซ้อนถูกวินิจฉัยได้เร็วกว่าการพึ่งพาทีมปิดเล็ก ๆ ในหลายกรณี โดยเฉพาะเมื่อผู้รายงานมาจากบริบทการใช้งาน (hardware, workload) ที่หลากหลาย
- project GitHub ที่มีความนิยมสูง — งานวิจัยพบว่า project ยอดนิยมบน GitHub มีอัตราการแก้ bug สูงกว่า project ที่ไม่ค่อยมีคนสนใจ สอดคล้องกับที่กฎนี้ทำนายไว้ — แต่ก็เป็นการเน้นย้ำว่าสิ่งที่สำคัญคือ “ผู้มีส่วนร่วมที่ active” ไม่ใช่แค่จำนวนดาวหรือผู้ใช้
- Code review ในทีมโคลสซอร์ส — องค์กรจำนวนมากใช้หลักการเดียวกันในสเกลเล็กกว่า ผ่านการทำ pull request review ที่บังคับให้มีผู้ตรวจอย่างน้อย 1-2 คนก่อน merge หรือทำ pair programming ที่มีสองสายตาช่วยกันมอง code ตั้งแต่ตอนเขียน
บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- อย่าตีความว่า “code ถูกเปิดเผย = code ถูกตรวจแล้ว” เปิด repository ให้ public ไม่ได้แปลว่ามีใครอ่านมันจริง ๆ ทีมต้องจงใจสร้างกระบวนการตรวจสอบ ไม่ใช่หวังพึ่งความบังเอิญของ “สายตาที่มากพอ”
- จำนวนผู้ตรวจที่มีประสิทธิผลมีขีดจำกัด งานวิจัยของ Glass ชี้ว่าราว 2-4 คนต่อรอบ review คือจุดที่คุ้มค่าที่สุด — การเพิ่มผู้ตรวจเกินจำเป็นอาจทำให้เกิด diffusion of responsibility (ทุกคนคิดว่าคนอื่นจะเจอ) มากกว่าจะช่วยเพิ่มคุณภาพ
- ลงทุนกับผู้ตรวจที่มีทักษะ ไม่ใช่แค่จำนวนคน สำหรับ code ที่กระทบความปลอดภัยหรือ business-critical ต้องมีผู้เชี่ยวชาญด้านนั้นโดยเฉพาะ (security review, threat modeling) แทนที่จะหวังพึ่งชุมชนทั่วไป
- ใช้แรงจูงใจเสริมสายตา bug bounty, การจ้างงาน security audit และการสนับสนุนทุนให้ maintainer ของ dependency สำคัญ ล้วนเป็นวิธีทำให้ “eyeballs” ที่มีอยู่ actively มองจริง ไม่ใช่แค่มีศักยภาพจะมอง
- ใน closed-source ก็นำหลักการนี้มาใช้ได้ ผ่านการบังคับ code review, collective code ownership และ whole-team activity ที่ทำให้คนหลายบทบาท (dev, QA, ops) ได้เห็น code เดียวกันจากมุมต่างกัน
ที่เกี่ยวข้อง
หัวข้อที่มีชื่อว่า “ที่เกี่ยวข้อง”- Collective Code Ownership
- Pair Programming
- Whole Team Activity
- Conway’s Law
- Cunningham’s Law
- Goodhart’s Law
แหล่งอ้างอิง
หัวข้อที่มีชื่อว่า “แหล่งอ้างอิง”- ที่มา · deviq.com/laws/linus-law
- Linus’s law — Wikipedia
- Given Enough Money, All Bugs Are Shallow — Jeff Atwood, Coding Horror
- Linus’s Law aka “Many Eyes Make All Bugs Shallow” — Microsoft Security Blog
- The Cathedral and the Bazaar — Eric S. Raymond