跳轉到主要內容
類別: 定律
類型: 開源協作與軟體品質啟發式
來源: Eric S. Raymond，《大教堂與市集》（First Monday，1998；O’Reilly 書，1999）；以 Linus Torvalds 命名
別名: 「眼睛足夠多，所有 bug 都是淺的」
快速回答 — 林納斯定律（Linus’s Law）主張：測試者與共同開發者足夠多時，幾乎每個問題都會很快被刻畫清楚，並且對某人來說修復顯而易見。更多眼睛不會憑空製造能力；它提高「有人正好具備正確視角」的機率。用它設計評審與發布閉環——不要當成熱門程式碼必然安全的保證。

​
什麼是林納斯定律？

林納斯定律（Linus’s Law）是一條軟體工程主張：廣泛而多樣的審視，往往比封閉的「大教堂式」開發，更容易讓缺陷變淺——更容易發現、也更容易修好。
眼睛足夠多，所有 bug 都是淺的。
Eric S. Raymond 更完整的表述是：只要 beta 測試者與共同開發者足夠多，幾乎每個問題都會很快被刻畫清楚，並且對某人來說修復顯而易見。想像公園裡丟了一把鑰匙：一個人可能走好幾天都找不到；上百人反覆經過同一條路，找到的機會就會上升。程式碼裡，「淺」不是說永遠瑣碎——而是說暴露給足夠多認真的人之後，刻畫與修復會加速。

​
林納斯定律的三層理解

  • 入門：許多仔細的讀者，比小小的封閉團隊更快發現 bug。
  • 實務：儘早發布以換回饋，但前提是審閱者真的能執行、閱讀並回報變更。
  • 進階：眼睛有用，當激勵、工具與專長覆蓋了風險面；缺這些覆蓋時，單靠流行度仍會漏掉深缺陷。

​
起源

Eric S. Raymond 在《大教堂與市集》中創造了 Linus’s Law 這一名稱，文章於 1998 年 3 月在 First Monday 廣泛發表，後擴展為 O’Reilly 著作（1999）。他以 Linus Torvalds 命名，因 Linux 的開發風格——儘早並經常發布、對外部貢獻開放——與由小團隊孤立打造的「大教堂」專案形成對照。 Raymond 認為：大教堂建造者把 bug 當作深而陰險的現象，因此很少發布；市集建造者則假定，一旦許多共同開發者猛砸每個版本，bug 大體上會變淺。Torvalds 後來澄清了 Raymond 採納的重要區分：發現 bug 的人，往往不是理解並修復它的人——而發現常常更難。因此該定律依賴許多頭腦的並行搜尋，而不是要求每個回報者都是偵錯大師。

​
核心要點

林納斯定律是關於搜尋與視角多樣性的賭注，不是給儲存庫加星就能施展的魔法。
1

擴大的是審查，不只是人頭

加人只有在他們走不同路徑、平台與威脅模型時才有用。閒逛圍觀者不是 Raymond 意義上的眼睛。
2

把發現與修復分開

發現與修復是不同工作。社群回報能浮現症狀；維護者仍需專長來修補根因——這與布魯克斯定律不同，後者警告加人可能因協調成本拖慢交付。
3

發布閉環創造暴露面

頻繁發布給審閱者反覆發現回歸的機會。沒有可執行產物與清晰回報管道，開放只是表演。
4

覆蓋勝過名氣

廣泛使用的程式碼仍可能藏著很少被走到的路徑。把社群審閱與測試、模糊測試、專項稽核並用——尤其在激勵薄弱處；海勒姆定律也提醒：沉默依賴可能掩蓋破損邊緣。

​
應用場景

只要你能真正擴大「誰看見、誰加壓」的人，就用林納斯定律。

開源維護

公開變更說明，邀請可重現的缺陷回報，並把安全問題路由給能審查密碼學與記憶體安全的人——不只是功能愛好者。

內部程式碼評審

跨團隊輪換審閱者，要求可執行示範，並把「沒跑過就 LGTM」當作失敗的眼睛。

產品公測

招募匹配真實邊界情況的使用者（語言區域、裝置、無障礙），讓回饋覆蓋生產中會斷裂的表面。

學習與寫作

儘早把草稿分享給不同意你的同伴；坎寧安定律是近親——錯誤或不完整的主張，往往比私下打磨更快招來糾正。

​
經典案例

Heartbleed 說明「足夠多眼睛」並非自動發生。OpenSSL 的 TLS Heartbeat 缺陷（CVE-2014-0160）於 2011 年 12 月 31 日引入原始碼樹，隨 OpenSSL 1.0.1 在 2012 年 3 月 14 日廣泛發布，並在 2014 年 4 月 7 日隨 1.0.1g 修復而公開揭露——在支撐大量公共網路的函式庫裡暴露超過兩年。缺失的邊界檢查讓攻擊者每次請求可讀出約 64 KB 行程記憶體，可能包含金鑰與憑證。 OpenSSL 是開源且被重度使用；即便如此，該缺陷仍未被一般流量發現，直到專家級發現（包括與 Google Security、Codenomicon 相關的回報）推動協調揭露。教訓不是開放審查無用——而是林納斯定律需要相關的眼睛落在被走到的程式碼路徑上，並有動機去找沉默的記憶體缺陷。邊界同樣重要：揭露之後，同一開源生態迅速發布修補程式；失敗在於長期未被察覺的深度，而非刻畫之後無法回應。

​
邊界與失效場景

當「許多使用者」並不是「許多審閱者」時，林納斯定律失效。下載量不是稽核。密碼學、並行與硬體相關缺陷，往往需要休閒貢獻者所缺乏的稀缺專長與工具。 社會動力學壓制回報時也會失效：敵意的維護者文化、不清的貢獻路徑，或責任恐懼，都會縮小有效眼睛數量。 常見誤用是聲稱開源自動比閉源更安全。開放是獲得審視的機會，不是正確性證書。另一種誤用是向專案傾倒未經訓練的審閱者並期待品質上升——沒有分流的雜訊，會重現布魯克斯定律式的協調成本。

​
常見誤區

先把口號與使其成立的條件分開。
不對。它預測的是：當足夠多有能力的審閱者在看時，刻畫會更快。沒有審查覆蓋的流行度，仍可能讓深缺陷潛伏數年。
不對。Eric S. Raymond 根據 Torvalds 的 Linux 實務命名並推廣。Torvalds 細化了發現與修復的區分；他並未把它發表為數學定律。
不對。Star 衡量關注，不衡量已執行的審查。從不執行程式碼、從不讀風險模組、從不提 issue 的眼睛，不會讓 bug 變淺。

​
相關概念

這些頁面有助於把林納斯定律放在協作限度、激勵與失敗模式之中理解。

布魯克斯定律

加人可能抬高協調成本——只有溝通仍可工作時，眼睛才有幫助。

坎寧安定律

錯誤主張會招來糾正；與公開暴露與回應的相關動力學。

海勒姆定律

使用者依賴一切可觀察行為——包括「足夠眼睛」從未挑戰過的 buggy 行為。

波斯特爾定律

寬容有助於互通，但也可能隱藏審閱者仍須檢查的協定怪癖。

墨菲定律

可能出錯的事仍可能出錯——審視減少意外，並不消滅失效模式。

蓋爾定律

能工作的複雜系統從簡單系統長成；早期暴露可在複雜度掩蓋缺陷前抓住它們。

​
一句話總結

把工作開放給真正能執行並挑戰它的人——沒有覆蓋的眼睛，只是觀眾。