> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 林納斯定律
> 林納斯定律指出：審閱者足夠多時，幾乎每個缺陷都會更快被發現並修好。了解起源、用法與開放審查失效之處。
**類別**: 定律
**類型**: 開源協作與軟體品質啟發式
**來源**: 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 的人，往往不是*理解並修復*它的人——而發現常常更難。因此該定律依賴許多頭腦的並行搜尋，而不是要求每個回報者都是偵錯大師。
## 核心要點
林納斯定律是關於搜尋與視角多樣性的賭注，不是給儲存庫加星就能施展的魔法。
加人只有在他們走不同路徑、平台與威脅模型時才有用。閒逛圍觀者不是 Raymond 意義上的眼睛。
發現與修復是不同工作。社群回報能浮現症狀；維護者仍需專長來修補根因——這與[布魯克斯定律](/zh-hant/laws/brookss-law)不同，後者警告加人可能因協調成本拖慢交付。
頻繁發布給審閱者反覆發現回歸的機會。沒有可執行產物與清晰回報管道，開放只是表演。
廣泛使用的程式碼仍可能藏著很少被走到的路徑。把社群審閱與測試、模糊測試、專項稽核並用——尤其在激勵薄弱處；[海勒姆定律](/zh-hant/laws/hyrums-law)也提醒：沉默依賴可能掩蓋破損邊緣。
## 應用場景
只要你能真正擴大「誰看見、誰加壓」的人，就用林納斯定律。
公開變更說明，邀請可重現的缺陷回報，並把安全問題路由給能審查密碼學與記憶體安全的人——不只是功能愛好者。
跨團隊輪換審閱者，要求可執行示範，並把「沒跑過就 LGTM」當作失敗的眼睛。
招募匹配真實邊界情況的使用者（語言區域、裝置、無障礙），讓回饋覆蓋生產中會斷裂的表面。
儘早把草稿分享給不同意你的同伴；[坎寧安定律](/zh-hant/laws/cunninghams-law)是近親——錯誤或不完整的主張，往往比私下打磨更快招來糾正。
## 經典案例
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 行為。
寬容有助於互通，但也可能隱藏審閱者仍須檢查的協定怪癖。
可能出錯的事仍可能出錯——審視減少意外，並不消滅失效模式。
能工作的複雜系統從簡單系統長成；早期暴露可在複雜度掩蓋缺陷前抓住它們。
## 一句話總結
把工作開放給真正能執行並挑戰它的人——沒有覆蓋的眼睛，只是觀眾。