你是否有过这样的经历：在刚买的手机应用里发现了奇怪的错误，向开发商反馈后，几天后得到回复说同样遇到这个问题的数百人早已提交了报告，修复版本也即将推出？一个人连原因都难以猜到的问题，当许多人一起来看时，往往会出乎意料地很快得到解决。像这样体现“聚集的目光越多，漏洞越容易显现”这一想法的说法，正是莱纳斯定律（Linus’s Law）。
简单来说，莱纳斯定律指的是“只要有足够多的眼睛，所有漏洞都是浅显的”这一经验法则。长期以来，它一直被当作解释开源（Open Source）开发方式为何有力量的代表性说法而被引用。开源开发方式会公开源代码，让任何人都能查看。
本文将依次介绍这条定律诞生的背景和准确含义、众多目光发挥作用的原理，以及暴露出定律局限的案例和在现实中加以运用的方法。
众多目光守护软件的原理与局限
什么是莱纳斯定律？
这条定律由美国程序员埃里克·雷蒙德（Eric S. Raymond）在随笔《大教堂与集市（The Cathedral and the Bazaar）》中加以归纳。这篇随笔于1997年首次发表，并于1999年出版成书。定律的名称取自1991年最早开发出Linux内核的芬兰出身开发者林纳斯·托瓦兹（Linus Torvalds）。
雷蒙德把这条定律更准确地表述为：“只要有足够多的测试者和共同开发者，几乎所有问题都会被迅速发现，而且总会有人一眼看出解决办法。”
（1）大教堂模式
由少数专家关起门来精心设计，只有在完成度足够高时才发布成果。这种看法认为，漏洞深藏不露，必须经过长时间的测试才能找到。
（2）集市模式
尽早发布、频繁发布，并向所有人开放，任何人都可以提出意见和修改方案。Linux的开发就是这样，雷蒙德认为，正因为参与者众多，漏洞很快就会暴露出来。
众多目光发现漏洞的原理
莱纳斯定律的核心在于，发现漏洞和修复漏洞可以由不同的人分别承担。即使最先遇到问题的人不知道原因，看到这一症状的另一个人也可能立刻想到解决办法。
- 多样的使用环境（Diverse Environments）：每个人的设备和用法各不相同，问题会在开发者没来得及测试的情况下暴露出来。
- 同行评审（Peer Review）：其他开发者在阅读代码时，会指出作者没有注意到的错误。
- 并行调试（Parallel Debugging）：多人同时追查原因，比一个人单独排查更快找到线索。
（1）报告症状的人
遇到漏洞的用户如果具体留下重现方法，缩小原因范围所需的时间就会大大减少。
（2）认出原因的人
对于处理过类似问题的开发者来说，别人眼中很深的漏洞也只是浅显的问题。定律中“浅显”一词指的正是这一点。参与者越多，遇到这种人的可能性也就越大。
显示定律局限的案例
【案例1】隐藏了两年多的心脏出血
OpenSSL是一款广泛用于互联网加密通信的开源软件，2011年底经过审查后加入其中的代码存在缺陷。这一缺陷从2012年3月的发布版本开始扩散，直到2014年4月才以“心脏出血（Heartbleed）”之名被公开。据估计，公开时使用受信任安全证书的网络服务器中约有17%、大约50万个面临风险。同年9月，人们又在Linux等系统中广泛使用的命令处理程序Bash里发现了“破壳漏洞（Shellshock）”，这是一个从1989年起隐藏了约25年的缺陷。
【案例2】交给少数人的核心软件
心脏出血被发现时，OpenSSL由寥寥几名志愿者维护，其中全职开发者只有一人。这说明，即使是任何人都能看到的代码，如果没有人真正仔细审查，漏洞也可能长期隐藏。事件发生后不久，Linux基金会就与多家大企业一起设立了支持核心开源项目的基金。
在现实中发挥莱纳斯定律作用的方法
软件工程学者罗伯特·格拉斯（Robert Glass）援引研究批评了这条定律，指出增加审查者并不会让发现的漏洞成比例增加，有用的审查者大约在两三人到四人之间。另一方面，也有分析显示越受欢迎的开源项目，漏洞修复比例越高，因此争论至今仍在继续。归根结底，重要的不是眼睛的数量，而是真正审视代码的眼睛有多少。
（1）把代码审查变成流程
如果每一项改动都要由至少一名同事阅读并批准后才能合入，那么无论代码是否公开，都能获得众多目光的效果。
（2）为核心代码汇聚人员和资源
越是众多服务所依赖的核心组件，越需要配备专职维护者并进行定期安全审计。
（3）让漏洞报告变得简单
让用户能够方便地报告问题并查看处理进展，外部的目光就会自然而然地聚集起来。
（4）用自动化工具填补空白
对于人容易忽略的边界值错误，用自动化测试工具反复检查是很有效的。
莱纳斯定律用一句话体现了“开放协作能够提升软件质量”的信念。但正如心脏出血所提醒的那样，仅仅公开代码是不够的，只有当有人真正去阅读和测试这些代码时，这条定律才能发挥应有的力量。
汇聚真正审视公开代码的目光——这正是安全软件的第一步。
