跳转到主要内容
类别: 定律
类型: 开源协作与软件质量启发式
来源: 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 行为。

波斯特尔定律

宽容有助于互通，但也可能隐藏审阅者仍须检查的协议怪癖。

墨菲定律

可能出错的事仍可能出错——审视减少意外，并不消灭失效模式。

盖尔定律

能工作的复杂系统从简单系统长成；早期暴露可在复杂度掩盖缺陷前抓住它们。

​
一句话总结

把工作开放给真正能运行并挑战它的人——没有覆盖的眼睛，只是观众。