Question

注释

1.在《Programing Pearls》（编程珠玑）一书中，著名计算机科学家 Jon Bentley 对 Brooks 这个观点的评论是：“如果你计划抛弃一个，你会抛弃第二个。”基本上他说的是对的，Brooks 和 Bentley 不只是说你对第一次尝试失败要有所准备，而且强调“用正确的办法重新来过”往往比整理一堆乱麻要有效得多。

2.在互联网井喷之前，就有开源集市开发模式的成功例子，而且和 UNIX 及互联网传统并无关系。1990 年至 1992 年间 info-Zip（主要用于 DOS 系统的压缩工具，http://www.cdrom.com/pub/infozip/）的开发就是一例；另一例则是诞生于 1983 年的 RBBS 公告板系统（也是用于 DOS 的），它发展出足够强大的社区，尽管互联网邮件和文件分享相比本地 BBS 有着巨大的技术优势，但直到现在（1999 年中后期），RBBS 还在相当有规律地发布。info-Zip 社区在一定程度上依赖互联网邮件，但 RBBS 的开发者文化实际上是建立在一个规模很大的 RBBS 在线社区之上，它完全独立于 TCP/IP 基础设施。

3.透明性和同行评审对控制操作系统开发的复杂性很有价值，这并不是新观点，1965 年，在分时操作系统发展的早期，Multics 操作系统的两位设计者 Corbató和 Vyssotsky 写道(http://www.multicians.org/fjcc1.html)：

Multics 系统将在大规模试用后再发布……这样做出于两点考虑：第一，系统要经得起公众审视和有兴趣读者的批评；第二，在系统日益复杂的时代，现在和未来的系统设计者有义务让操作系统内部尽可能清晰易懂，以便揭示系统的基本问题。

4.关于重复劳动不一定会拖累开源开发，John Hasler 给出了一个有趣的解释，我把它称为“Hasler 定律”：重复劳动的代价通常和团队成员数成“次二次方”（sub-quadratically）关系，也就是说，重复劳动的成本比计划和管理成本增长得慢得多，后者更需要想办法消除。

实际上，这个说法和 Brooks 定律并不矛盾。复杂性成本和 bug 带来的脆弱性和团队成员数成二次方关系大概是对的。但重复劳动的代价比较特殊，它随团队成员数的变化更慢，这并不难解释，因为人们容易认可这样的不争事实：划定不同开发者代码的功能界限可以避免重复劳动；相比之下，人们并不认为这样就能防范整个系统内各种非预期的不良交互（正是它们导致了大多数 bug）。

将 Linus 定律和 Hasler 定律结合起来可以发现，软件项目的规模（可分为三种）很关键。对于小项目（我认为也就一到三个开发人员）而言，没有什么管理结构比好好找一个主力程序员更有效。对于规模稍微大一些但传统管理成本相对还比较低的项目，集市模式虽然能避免重复劳动、易于跟踪错误、容易看到不易监管的细节，但其好处并不明显。

从 Linus 定律和 Hasler 定律可知，当项目规模大到一定程度，传统管理的成本和问题会比重复劳动的成本增长得快得多。集市模式虽然有自身问题，但不会像传统模式那样存在不能利用“多眼球效应”（many-eyeballs effect）的结构缺陷。（正如我们所看到的，）集市模式在确认 bug 和易疏漏细节上比传统模式要管用得多。因此，对于大型项目，这些定律的组合效果，使得传统管理模式的净收益趋近于零。

5.Linux 将实验版和稳定版分开的做法，还有一个与风险对冲相关但又截然不同的作用，那就是解决要命的最后期限问题（the deadliness of deadlines）。程序员在需求列表不能调整和最后期限不能拖延的双重要求下，会完全顾不上质量，整个工作很可能会变成一团乱麻。感谢哈佛商学院的 Marco Iansiti 和 Alan MacCormack，他们向我证明，放宽这两个限制的任意一个，都会使进度变得可行。

一种办法是保持最后期限不变而让需求列表灵活一些，允许某些到最后期限时仍未完成的需求被舍弃，这基本上就是“稳定版”核心采取的策略。Alan Cox（稳定版核心的维护人）以相当规律的时间间隔将核心发布，但并不保证某个特定 bug 何时被修复，也不保证实验版中的某个特性何时会搬到稳定版中。

另一个办法是设定好想要的需求列表，并在其完成时发布，这基本上是“实验版”核心的策略。De Marco 和 Lister 引用研究结果，指出这个进度策略即是“好了告诉我”(wake me up when it's done)，这不仅能够保证最高质量，而且就平均而言，与“保守”或“激进”的进度安排相比，它的交付时间更短。

2000 年初，我开始怀疑本文早期版本中我严重低估了“好了告诉我”这一反最后期限(anti-deadline) 策略对开源社区生产力和产品质量的重要性。GNOME 1.0 在 1999 年的匆忙发布给我们上了一课：不成熟发布带来的负面影响，会抵消开源通常所带来的质量收益。

现在看来，开源提升产品质量的三架马车中，“好了告诉我”和开发者“自我选择”是两架，另一架是“过程透明"。

6.Brooks 关于解决 N 平方复杂性问题给出的建议是建立“手术团队”型组织，有人将开源项目“核心+光环”式组织看做是“手术团队”的互联网版本，这种类比很有意思，也不是完全不对，但有很大区别：Brooks 设想团队首领周围有一群不同角色的专家（如“代码管理员”），事实上这些角色并不真的存在，一个技术较强的开发者，配上些工具（比 Brooks 那个年代的工具要强多了），就可以替代 Brooks 说的这些角色；而开源文化十分倚重的 UNIX 传统——模块化、API 和信息隐藏——都不是 Brooks 处方上的元素。

7.在谈及 bug 定位难度时，有位读者曾向我指出，bug 跟踪路径长短的差异很大，他推测，对于那种多症状 bug，循迹难度将随症状数呈“指数分布”（我认为呈“高斯分布”或“泊松分布”更合理一些）。如果有可能通过实验获得该分布形状的数据，那将会很有价值。由于跟踪的难度远不是一个等概率平均分布，建议即便是单人开发者，也效仿一下集市策略，对每个症状设定一个循迹时间，过了这个时间还找不到，就换另一症状去查。坚持不懈也许并不总是对的……

8.关于能否使用集市模式从零开始一个项目，关键在于集市模式能否支持真正有创新性的工作。有人声称，如果缺少强有力的领导，集市只能克隆和改进已有最高水平的工程创意，但不能将其推向更高的水平。这也许是万圣节文件(http://www.opensource.org/halloween，两篇令微软尴尬的关于开源现象的内部备忘录) 中最臭名昭著的说法，其作者将 Linux 这种 UNIX 类操作系统的开发比作是“追逐尾灯”，并认为“（当项目达到最高水平时，）管理也要走在最前沿，而且要强大有力”。

这种说法隐含着严重的事实性错误，比如万圣节文件的作者们后来自己也承认：“通常……，相比其他平台，新的研究成果总是最先在 Linux 上得到实现和使用。”

Linux 并不是开源世界里的新事物，从历史上看，开源社区并不是通过“追逐尾灯”和“强有力管理”发明的 Emacs 或万维网或互联网本身，而且目前开源方面的创新工作已经多得让开发者都不知道该选哪个好。随手举个例子，GNOME 项目正把 GUI 和对象技术推向最高水平，不仅在 Linux 社区，在计算机行业媒体中它也获得了强烈的关注。其他例子还有很多，随便哪天你访问一下 Freshmeat（http://freshmeat.net/），都会很快证实这点。

有种错误的观点认为教堂模式（或集市模式，或任何其他形式的管理结构）在一定程度上能可靠地产出创意，这完全是无稽之谈。一帮人在一起，不会有什么突破性的创见——即便是集市中那些无政府主义者组成的志愿者团体，通常也不能有真正的创见，更不要说公司委员会中那些为生计着想的还活在过去年代的人了。远见源自个人，其周遭社会机器的最好做法，就是响应这些有突破性的远见——滋养、奖赏并严格测试它们，而不是压制它们。

有人认为这是对发明家特立独行老派做法的浪漫怀旧，其实不然，我并不是断言一群人不能开发和孵化一个突破性创意，事实上，从同行评审过程可知，正是这类团体开发了高质量的产品。我只是想说，每个这样的团体开发，都必然源自于某人头脑中的一个好创意。大教堂、集市和其他社会结构都可以捕捉这个闪光点并使它更完美，但这些闪光点可不是想要就能有的。

因此创新的根本问题（在软件中，或任何其他领域）是：如何不压制创意。但是，更为根本的是，如何先产生出一批有创见的人。

如果有人认为大教堂模式能够做到这点，而集市模式由于进入门槛低和过程流动性强不能做到这点，那就大错特错了。如果我们需要的是一个人和他的创意，那怎样的社会环境会更有利于这个创意的实现？一个能凭借创意迅速吸引成百上千合作者的环境，必然要好过任何这样的环境：这个人在着手实现他的创意前，不得不向领导层推销他的创意，否则就有被炒掉的风险。

事实上，如果查一下有多少软件创新是因为使用大教堂模型导致的，就很快会发现它非常罕见。大公司靠大学研究提供新创意（所以万圣节文件的作者们对 Linux 能更快吸收这些研究感到不安），或者靠收购小公司来收购创意，这些都不是大教堂文化的原生创新。事实上，用这种方式移植的许多创新，都在万圣节文件作者们大力颂扬的“强有力管理”下悄然窒息了。

当然，这是个否定性结论，读者应该看到更具肯定性的结论。我建议：

·选定一个你认为能始终贯彻的对原创性认定的标准。如果你的定义是“看到了我就能判断”，那也没关系。

·选择任何一个和 Linux 竞争的闭源操作系统，然后选一个最佳来源，用于统计该操作系统上的开发工作。

·对此来源和 Freshmeat 进行为期一个月的观察。每天统计 Freshmeat 发布的公告中你认为有‘原创性’的工作，并使用同一标准统计其他操作系统上的公告。

·30 天后，分别对两组数字求和。

我写到这里的当天，Freshmeat 发布了 22 条公告，其中有 3 个可能在某方面达到了最高水平。对 Freshmeat 而言这天的成绩并不算好，但是，如果任何读者能发现在任何闭源渠道里一个月内有 3 条类似的创新，我会十分惊讶。

9.现在，我们有了一个比 fetchmail 能更好的对集市模式进行验证的系统：EGCS，http://egcs.cygnus.com/,即实验性 GNU 编译系统。

1997 年 8 月中旬，EGCS 项目问世了，它是一个对“大教堂与集市”早期版本中的观点进行有意识尝试的项目。项目创始人觉得 GCC（GNU 的 C 编译器）开发已经停滞不前。之后 20 个月内，GCC 和 EGCS 成为并行产品——二者均从互联网上吸纳开发人员，均源于相同的 GCC 源码库，均使用了几乎一样的 UNIX 工具箱和开发环境。二者不同之处仅在于 EGCS 有意识地尝试运用我之前描述的集市策略；而 GCC 则保留一种更类似大教堂模式的组织结构，其开发团队封闭，而且不常发布新版本。

这很像是一个应要求而开展的对照实验，其结果很有戏剧性，数月之内，EGCS 版本在一些特性上已经有了实质性领先，比如更好的优化，以及对 FORTRAN 和 C++的更好支持。很多人发现 EGCS 的开发快照要比 GCC 的最新稳定版本更可靠，而主要的 Linux 发行版已经开始转向 EGCS。

1999 年 4 月，自由软件基金会（GCC 的官方赞助商）解散了原有 GCC 开发小组，并正式将该项目控制权移交给 EGCS 指导小组。

10.当然，Kropotkin 批判和 Linus 定律引发了人们对社会组织控制论的更广范思考。比如软件工程的一个通俗理论（Conway 定律）常常被表述为“如果有四个小组致力于开发一个编译器，那么你将会得到一个四步（4-pass）编译器。”其原始陈述更具一般性：“如果一个系统由多个组织共同设计，那么其设计的系统将不得不成为这些组织间沟通结构的拷贝。”我们可以更简洁地称之为“方法决定结果”，或者乃至“过程变成产品”。

值得注意的是，开源社区的组织形态和功能在很多层面上是匹配的。网络就是一切，而且无处不在；不只是互联网，还包括在其上工作的人，这些人形成了一个分布式、松耦合以及点到点的网络，它很优雅地实现了多重冗余和去等级化。这两个网络中，一个节点只有在其他节点想要和它合作时才显得重要。

点到点结构是开源社区出现惊人生产力的关键。Kropotkin 曾经对权力关系做出的评价被“SNAFU 原则” ^[1] 进一步阐明：“只有平等个体之间才有真正的交流，因为下级向上级讲好听的谎话会比讲真话更能得到持续的奖励。”真正的交流是创造型团队必不可少的，而权力关系将极大制约这点。开源社区有效避免了这种权力关系，并通过对比告诉我们权力关系会带来多么糟糕的代价：大量的 bug、低下的生产力和机会的丧失。

更进一步，“SNAFU 原则”预测在权力组织中，决策者和现实情况会越来越脱节，因为决策者会听到越来越多好听的谎言。在传统软件开发中很容易看到这一点，由于下级有强烈的动机去隐藏、忽略和最小化问题，当这个“过程变成产品”时，软件会成为一个灾难。

参考文献

我引用了 Frederick P.Brooks 经典之作《人月神话》中的一些内容，在很多方面，他的观点还需要改进。真心推荐由 Addison-Wesley 出版社发行的 25 周年纪念版，这版中新增了 Brooks 在 1986 年发表的“No Silver Bullet”。

新版中还有一篇非常有价值的 Brooks 的回顾，他在 20 年后对该书重新思考，并坦率承认原文中有几个观点没有经受住时间的检验。我首次读到这篇回顾文章时（在本文首个公开版本大致完成时），惊讶地发现 Brooks 把集市类（bazaar-like）实践归功于微软！（事实上，这种归功后来被证实是错误的。1998 年，我们从万圣节文件（http://www.opensource.org/halloween/）中了解到微软内部的开发社区是被严重分割的，他们甚至都没有集市模式所需要的共享源码库。）

Gerald M.Weinberg 在《The Psychology of Computer Programming》（New York:Van Nostrand Reinhold,1971）一书中介绍了“无私编程”（egoless programming）的概念，虽然这个命名有点令人遗憾。早在他之前就有人认识到“命令原理”（principle of command）的无用性，但 Weinberg 可能是在软件开发领域最早意识到并提出这点的人。

Richard P.Gabriel 对 UNIX 文化进行了深入的思考（早在 Linux 时代之前），1989 年他在“LISP：好消息，坏消息，如何成为大赢家”一文提出了一个简单的集市类模型，并不太情愿地论证了它的优越性。虽然这篇文章略显过时，但它仍然在 LISP 粉丝中（包括我）受到追捧。一个读者提醒我说“Worse Is Better”那节几乎是对 Linux 的预言。这篇文章可以在 http://www.naggum.no/worse-is-better.html 中找到。

De Marco 和 Lister 的著作《人件》（New York:Dorset House,1987）是一篇被低估了的佳作，我很高兴看到 Fred Brooks 在他的回顾文章中引用了该书论点。尽管该书作者极力主张的观点并不能直接应用于 Linux 或开源社区，但其对创造性工作必要条件的洞见是敏锐的，对任何想要把集市模型优点融入商业环境的人来说，该书都值得一读。

最后，我必须承认我差点把本文命名为“The Cathedral and the Agora”，Agora 在希腊语中是公开市场或公共聚会场所的意思。Mark Miller 和 Eric Drexler 在多篇论文中提出了有开创性意义的“agoric systems”，描述了这种市场类型计算生态的突出特点，这使得在 5 年后 Linux 引起我兴趣时能够让我对开源文化中类似现象进行清晰的思考。这些论文可以在 http://www.agorics.com/agorpapers.html 中找到。

致谢

本文的改善要归功于和很多人的交流以及他们的排错帮助。特别感谢 Jeff Dutky（dutky@wam.umd.edu）提出的关于“排错可以并行”的构想，并帮助沿此构想进一步分析。同样感谢 Nancy Lebovitz（nancyl@universe.digex.net），是她建议我效仿 Weinberg 引用 Kropotkin 的文字。感谢 General Technics 列表中 Joan Eslinger（wombat@kilimanjaro.engr.sgi.com）和 Marty Franz（marty@net-link.net）提出的敏锐批评。Glen Vandenburg（glv@vanderburg.org）指出了贡献者自我选择的重要性，并提出多流程开发可以修复“疏漏型 bug”这个颇具意义的观点。Daniel Upper（upper@peak.org）提出了关于这点的自然类比。非常感谢 PLUG（费城 Linux 用户组）成员，他们提供了本文首发版的读者测试。Paula Matuszek（matusp00@mh.us.sbphrd.com）在软件管理实践方面给予我指导。Phil Hudson（phil.hudson@iname.com）提醒我：黑客文化的社会组织反映了其软件的组织结构，反之亦然。John Buck（johnbuck@sea.ece.umassd.edu）指出了 MATLAB 与 Emacs 之间有启发性的类比。Russell Johnston（russjj@mail.com）使我意识到在“多少眼睛驯服复杂性”中讨论的一些机制。最后，Linus Torvalds 的意见很有帮助，他很早就对本文表示认可，这实在令人鼓舞。