日后，为了应付一些来自动态SLIP[2]的纠葛，我又不得不重新加入了可由用户制定MDA功能。但是做起来简单多了。
这说明了什么？只要不损失效率，就不要对丢弃一些功能而举棋不定。圣-埃克苏佩里[3]（当他不写作经典儿童书籍的时候，是一个飞行员兼飞机设计师）曾说过：
13.“完美（的设计）意味着没有东西可以再被加入，而是没有东西可以移除”
`“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
当代码变得高效又简洁的时候，就可以说是走上正轨了。在这个过程中，fetchmail有了自己的特设，脱离了前代的popclient。
到了该换名字的时候了，新的设计和老的popclient相比，更像是sendmail的搭档。二者都是MTA，不同的是sendmail是向外投寄，而新的popclient是接收转发。所以，开工两个月之后，我把它更名为fetchmail。
在这个将SMTP转发加入fetchmail的故事中，有一则普遍的经验。那就是不仅调试可以平行展开，开发和（也许这很令人吃惊）探索设计空间同样也可以。当采用快速短周期开发模式的时候，开发很可能成为针对原有的冗余设计或开发观念的一个特殊“调试-修补”环节。
即使在更高层次的设计中，能有许多协作开发者围绕着你的产品设计空间随机游走也是很有价值的。试想一下，一滩水是如何找到排水口的，或更贴切一点，一群蚂蚁是如何找到食物的：实际上就是在分散搜索之后，以一个可延伸的通讯机制加以协调。这很管用，就像哈利·豪切斯和我一样，一个同行之人很可能在你身边开启宝藏，而你只不过是太过专著才一叶障目罢了。
译者按：
1.拉里·沃尔 ：Larry Wall，著名黑客，第一届自由软件奖得主。也是Perl语言的发明人，所以作者说“对……也不例外”。
2.SLIP：Serial Line Internet Protocol，即串行线路IP协议，早期的一中IP封包协议，目前基本已不再使用。
3.圣-埃克苏佩里：安托万·玛丽·罗杰·德·圣-埃克苏佩里（Antoine Marie Roger de Saint-Exupéry），法国作家、飞行员。著作颇丰，1943年出版的《小王子》令他誉满全球。
《大教堂与市集》 第八章 Fetchmail成熟了
现在有了一个简洁新颖的设计，我确信代码运行稳定，因为我每天都在用，公测名单也枝繁叶茂。我逐渐发现，我不再只是研发一个可能只有少数人才会用到的琐碎的个人软件了。而是在主持一个所有使用SLIP/PPP邮件接口的Unix用户都切实需要的软件。
凭借SMTP转发功能，fetchmail把竞争对手远远的甩在了后面，成了一个潜在的“领域杀手”。一个在同领域鹤立鸡群的杀手，它让对手们不但被抛弃而且被遗忘。
这种结果是可遇而不可求的。一个卓有建树的设计构想会把你顺理成章，甚至命中注定地推向成功。而找到这类构想的方法无非是拥有很多值得尝试的创意——或者能用工程的眼光把其他人的创意发挥到令原作者都难以想像的境地。
安迪·塔能鲍姆[1]首先为IBM PC机开发了一个简单的原生Unix系统，他的本意是把它作为一个教学工具（他称之为Minix）。李纳斯则把Minix的概念推臻至安迪想像不到的境地，让它成了这个奇妙的玩意。类似的（只是规模小些），我从卡尔·哈里斯和哈利·豪切斯那里借得创意并把它们深化。我们都不是“原创”——那种人们浪漫想像中的天才。话说回来，大多数科学、工程和软件的成果都不是来自原创天才，恰恰相反，是锐意进取铸就了神话。
这两个项目（指Linux和fetchmail——译者按）都成果斐然——事实上，这正是每个黑客毕生求索的成功！这同样意味着我不得不加高要求自己的标准。为了让fetchmail达到预期的目标，我不仅要为自己编程，还要额外地加入别人需要的功能。与此同时，还必须保证程序的简洁和健硕。
意识到这点之后，我加入的第一个也是至关重要的功能就是“集体收发”——从一组用户的邮箱中收取邮件，之后在分发给不同的收件人。
我添加集体收发功能不仅是因为很多用户吵着要用，更主要的是我觉得通过这个方法可以迫使我更全面的处理地址问题，从而摆脱单信投寄中的缺陷。结果得我所愿。正确地完成RFC822[2]地址解析耗费了我很长时间，并不是因为它的某一部分很难，而是它牵扯了一堆相互关联的烦人细节。
添加集体收发成为了一项杰出的设计决策，只因为：
14.任何工具都应该起到预期的作用，而一个真正杰出的工具会带来出乎意料的用途。
Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
加入集体收发的一个出乎意料的用途是让通过网络相连的客户端可以保存邮件列表和别名扩展。也就是说，通过ISP上网的个人用户不需要持续访问ISP的别名文件就可以管理邮件列表了。
我的公测人员要求加入的另一个重要功能是支持8位的MIME（Multipurpose Internet Mail Extensions，多用途的网际邮件扩充协议）操作。这很容易办到，因为我之前就很小心的保留了对代码的8位兼容性（就是，没有强迫ASCII字符集中未曾用到的第8比特位去携带程序信息）。这并不是因为我有先见之明，而是遵循了另一个原则：
15.在写任何网关软件的时候，都该花点功夫尽可能不去干扰数据流——除非用户强迫你，否则永远不要抛弃任何信息！
When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
假设我不曾遵循这个原则，那么加入8位MIME支持就会很困难而且毛病多多。事实上，我现在做的只是读一下MIME标准（RFC1652）[3]，然后加入一条小小的标头生成规则。
一些欧洲用户请求我加入了一个选项，来限制每次连接可下载的邮件数目（这样他们可以节流昂贵的电话上网费）。我曾长时间抵触这种做法，就算现在也不是心甘情愿。但是如果你是在为外界编写程序，那么你就必须听从你的客户——即使他们不付钱也应如此。
译者按：
1.安迪·塔能鲍姆：安德鲁·斯图尔特·塔能鲍姆（Andrew Stuart Tanenbaum）昵称安迪（Andy）美国计算机学家，现定居荷兰。
2.RFC822：Standard for the format of ARPA Internet text messages，标准ARPA 互联网文本消息格式。
3.SMTP Service Extension for 8bit-MIMEtransport，SMTP 8bit-MIME传输服务扩展。
《大教堂与市集》 第九章 源自Fetchmail的更多经验
930个读者 翻译: Angelo 09/06/2007 原文 引用 双语对照及眉批
在我们回到广义的软件工程问题之前，还有几条fetchmail开发中的独特细节需要深思。非技术性的读者可以安心跳过本章。
rc（fetchmail用户配置）文件语法中包含了一些完全不需解析的，可选的“噪音”关键词。与传统“关键词-对应值”匹配关系相比，它们所带来的趋近于英语语法的配置文件更具可读性。
这源自一个深夜的实验，当时我注意到rc文件的配置命令非常像一门微型指令语言。（这也是我把关键字“server”改成“poll”的原因）[1]
在我看来，努力使这个微型指令语言更像英语可以让其更便于使用。现在我虽然支持“让它成为一门语言（make it a language）”的设计流派（诸如Emacs、HTML和很多数据库引擎那样），但是并不热衷于“类英语”的语法。
传统上，程序员们倾向选用简洁紧凑、完全没有冗余的语法。这是计算资源昂贵时期的文化遗留，以致解析过程必须尽可能的简洁廉价。所以如果采用像英语这样有50%冗余的语法建模，在当时显然是很不合时宜的。
这并不是我通常避免使用“类英语”语法的原因。我在这里提及就是为了打破这种观点。有了更廉价的缓存和处理器，简洁就没有必要称为最终的追求了。现在一门语言的人性化远比降低计算成本要重要。
然而，我们仍然有要谨慎为之的原因。其一就是解析过程的复杂度带来的成本——你总不希望这个成本上升到足以滋养错误和迷惑用户吧？另外，让一门语法趋近英语的作法，通常会令其所谓的“英语”走形。以至于对自然语言的表面的模仿会导致如同传统语法一般的混乱。（你可以在很多号称“第四代”的和商业数据库查询语言中看到这种恶果）
Fetchmail的控制语法之所以能避免这些问题，是因为它的语言空间极为有限。它离一门多用途的语言还差得远呢；其所描述的问题也很简单。所以大可不担心穿梭于微小的英语子集和实际控制语言会造成什么迷惑。我觉得这里有一则可以推而广之的经验：
16.当你的语言还远不足以达到图灵完备的时候，不妨为语法蘸上一层“糖衣”。[2]
When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
另一则经验是有关隐藏的安全性的。一些用户要求我改写软件，以便能对rc文件加密。这样入侵者就不会在无意间看到它们。
我没有照做，因为这并不会带来实际的保护。因为只要有人能获得你rc文件的使用权，他就能和你一样运行fetchmail查看邮件——如果真的想要你的密码，他就可以从fetchmail代码中剥离出必要的解码器。
言而总之，在rc文件中注入密码只是给那些没有深入思考的人一种安全的假象。进而，我们得出通用的规则：
17.安全系统的效用只取决于对秘密的保护，谨防伪安全。[3]
A security system is only as secure as its secret. Beware of pseudo-secrets.
译者按：
1.这个关键字后面对应的是邮件服务器名称。计算机中，“Poll”是动词“轮询”的意思，也就是依次向服务器发送报文，收取邮件。而“Server”是名词“服务器”。显然使用“Poll”更符合英语语法。
2.图灵完备：又称图灵完备性。如果一门语言达到“令一切可计算的问题都能计算”的程度就可以说其达到了图灵完备或说具有图灵完备性。
3.“秘密”是指所要隐藏的标的；“安全系统”是指保护这个标的不泄露的手段；“伪安全”是指将标的写入手段的做法。让我们以fetchmail为例，“秘密”就是要保护rc文件，“安全系统”就是密码，把密码写入rc文件显然就是伪安全。
《大教堂与市集》 第十章 市集风格的先决条件
本文的早期审阅人和测试者不断地希望了解成功市集风格的先决条件，这包括项目负责人的资质和着手建立协作开发社区时代码的开放状况。
很明显，市集风格不能帮你从零开始编程。【注】你可以利用市集风格来测试、调试、改进代码，但是用这种风格来孕育一个项目会很困难的。李纳斯没有这样试过，我也没有。你初建的社区至少需要一个可以运行和测试的东西。
一旦你着手组建团队，就需要给出一个可行的承诺。你的程序并非必须运行良好，它可以是粗糙的、遍布瑕疵的、不完善的、也可以是缺少说明文件的。但是必须满足（1）它能运行；（2）能让潜在的协作开发者相信在不久的将来它能变得精良。
Linux和fetchmail都是在有了健硕，诱人的基础设计之后才推向公开的。我所提到的市集模式观察者们认为这是至关重要的。进而得出结论：一个睿智并且具备高超设计才能的领导是必不可少的。
但是李纳斯是从Unix出获得的设计，而我则是从早期的popclient（尽管日后改动很大，但是还无法和Linux相提并论）。那么，一个市集风格的领导者/主持人当真需要天赋异禀吗？或者他们只是四两拨千斤的动用了他人的创见？
在我看来一个项目的主持人是否能够做出足以彪炳的设计并不很关键。而至关重要的是，他是否可以从他人的创意中慧眼识英。
Linux和fetchmail都印证了这个观点。李纳斯（如同前文描述的那样），尽管不是一个惊世的原创设计者，但是却展现了识别优秀设计并整合成为Linux内核的不凡才能。我也曾描述了fetchmail中最强大独到的功能（SMTP转发）是如何源自他人的。
本文的早期读者捧我的场说我之所以容易低估市集项目中原创因素的价值，是因为我本身不缺乏创意灵感，所以就习以为常了。这番评论或许却有见地，因为（与编码和调试相比）设计确实是我的强项。
但是问题是，在软件设计中展现聪明和原创力会养成一种习惯——当你需要保持设计稳健和简洁的时候，会不自知把它们弄得有趣而复杂。我曾经因此搞砸过项目，所以在fetchmail的开发中我要避免重蹈覆辙。
所以我坚信fetchmail项目的成功应部分归因为我克制了自己的自作聪明；这（至少能够）反驳“原创设计制约市集模式成败”的观点。回头看Linux，假设李纳斯在开发操作系统核心时力主原创的话，我们现在还能见到如此稳健成功的内核吗？
一定的设计和编码技能是必须的。但是我想，任何一个深思熟虑准备试水市集项目的人都远远超出了这个底线。开源社区内部的声望机制给人们一种微妙的压力，从而大家不会去发起一些自己无力支撑的项目。目前看来，这行之有效。
我认为还有一种与软件开发无关的技能，却在市集项目中与优秀设计同等重要——甚至更胜一筹。那就是一个市集项目的主持人或领导者必须具备优秀的人际交流技能。
显而易见，要创建一个开发社区，你需要招募人手，让大家对你所做的感兴趣，并让大家对工作乐此不疲。为了达成这个目标，技术上的磨合必不可少，但却远不是故事的全部。与大家的人际融合也至关重要。
李纳斯平易近人，招人喜欢并让大家乐于帮助他——这并非偶然。我活波外向，喜欢群体工作，并且带有一些插科打诨的言谈和性情——这也绝非巧合。为了运营一个市集项目，哪怕是一点点人格魅力都对你大有助益！
注：
有关市集风格是否可以帮你从零开始构建一个项目的另一个争论是——其是否能够促成真正意义上的创新。有人声称，由于缺少强有力的领导。市集风格只能在工程学前沿克隆和演进已有创新，却无法孕育新知。这种垢弊极可能源自“万圣节文件”——两份微软内部旨在发难的开源现象备忘录。其作者认为，Linux不过是个拾人牙慧的类Unix系统，“（一旦这个计划具有了同等的领先水平）管理开销就必然变得异常庞大。”
这个观点和事实大相径庭，乃至文件作者后来自己也指出：“通常……创新首先出现在Linux上，其后才被推广/整合到其他平台。”
对我们而言，即使把上文中的“Linux”换成“开源软件”也算不得什么新鲜事。回顾历史，开源社区并没有拾人牙慧的开发出Emacs、万维网和因特网，同样也未曾担负过庞大的管理成本。现在开源项目的不断创新给我们提供了前所未有的施展空间。比如GNOME项目（信手拈来一例），已经达到了图形用户界面领域的顶尖水品。其复杂程度吸引了Linux社区外为数可观的商业关注。类似的例子不胜枚举，你可以抽空访问一下Freshmeat.net，一看便知。
其论断中还有一个本质的错误，即假定大教堂模式（或市集模式，亦或其他任何管理结构）可以顺理成章的产生革新。这是一派胡言。群体没有洞见创新的眼光——对此，市集模式中志愿组合的团队也往往无济于事。更不用说那些要为自己生计下注的社团委员会成员了。创新源自个体。其周围社会机制的最有效激励就是做出适当的回应——去培养、奖励、鞭策他们，而不是排挤。
一改过去“孤单发明家”的套路，有人会把这种创新方式描述的颇具浪漫色彩，然而事实远非如此；我并非断言团队无法再像过去那样在开发中创造突破；事实上，我们在平行开发中学到，对于高质量的产品，团队协作是必不可少的。但是我必须指出任何团队的组建都是源于某人的创想（这也是必要的火花）。无论大教堂、市集、还是其他模式都可以抓住这稍纵即逝的火花，并将它引燃。不过，它们都不能在有需要的时候就立即擦然火花。
所以说，（软件或其他领域）革新的根本问题是：首先，如何培养那么多能够创新的人才；以及如何避免排挤他们。
假定大教堂风格可以促成创新，而门槛低、流程通畅的市集模式则无能为力，显然是很荒谬的。如果创造源自一个人加一个好主意，那么能吸引成百上千人共同协作的社会环境必然优于一个必须通过政治手腕向上级推销创意的环境（为了避免不被炒鱿鱼，你必须在得到批准之后才能继续研发）。
确实，如果我们检视一下大教堂模式下的软件创新史，不难发现源自其自身的创造凤毛麟角。大企业需要通过大学中的研究获取新知（因此，万圣节文件的作者对Linux对研究成果的快速吸收深表不安）。或者收购一些由于某个创意而组建的小公司。这两种创新均非源自大教堂文化。恰恰相反，很多类似被买断的创见被（万圣节文件作者鼓吹的）“庞大的管理成本”扼杀了。
上面都是一些反证，这里应该把一个正面的例子奉献给读者。我建议大家试试下面的方法：
* 确立一个你能一以贯之的创新判别标准。比如“发现并加以区分（I know it when I see it）”就满足这个判别条件。
* 选择一款能和Linux竞争的闭源操作系统，和一个让你可以了解其开发进展的最佳资讯渠道。
* 在一个月内每天关注Freshmeat和你选择的消息渠道。分别记录下二者中你认为是创新的点子数。
* 三十天后，汇总两组数据。
在我写下这些文字的日子里，Freshmeat出现了22条新消息。其中有三条看似可以在某方面推动技术革新。虽然这几天Freshmeat不很景气，但是假如有读者在一个月内能通过任何闭源渠道发现这样的三条创新，就真的值得大书特书了。
《大教堂与市集》 第十一章 开源的社会语境
1014个读者 翻译: Angelo 09/11/2007 原文 引用 双语对照及眉批
这句话一语中的：好的软件都是源自解决开发者的切身之痛，推而广之则是因为很多人也面临着相同的困扰。这将我们带回了“格言1”，或许换个角度重申能让其更具效用：
18.要解决有趣的问题？那就先找到你感兴趣的吧！
To solve an interesting problem, start by finding aproblem that is interesting to you.
卡尔·哈里斯先前的popclinet如此，我的fetchmail也是如此。这个观点已经久为人知。而更有趣（Linux和fetchmail历史中更值得我们关注的）的话题则是出现在下一阶段——由用户和协作开发者组成的庞大的活跃社区，推动了软件的演进。
《人月神话》中，布鲁克斯指出程序员的编程时间不能简单叠加。为已经延期的项目增派人手会让它拖地更久。像我们之前提到的，他指出：项目的复杂度和沟通成本会以开发者人数为基础呈平方指数增长，而业绩仅能直线上升。布鲁克斯定律早已被广泛认可。但是在本书中，有不少开源软件的开发流程可以将这个假说证伪——从经验上看，如果布鲁克斯定律主宰了一切，Linux就不可能出现了。
杰拉尔德·温伯格在其经典著作《程序开发心理学》中对布鲁克斯定律作出了颇具后见之名的重要修正。在其关于“无私编程”的讨论中，温伯格发现一些程序员不会“自扫门前雪”，而是鼓励他人帮助纠错和改进代码。在这样的工作室里，工作进展要显著的多。（最近，肯特·贝克的“极限编程”技巧，将编码者配对组合，令其相互督促。或许可以看作是对加强这种影响的一种尝试）
可能是温伯格的用词让这个结论没有得到应有的认可——把网络黑客说成“毫无私心”未免让人莞尔。但是我认为，他的结论今天看起来比任何时候都更让人信服。
借助“无私编程”的澎湃动力，市集模式有力削弱了布鲁克斯定律的影响。布鲁克斯定律背后的真理并没有被推翻，不过庞大的开发群体和廉价的通讯带来了非线性增长。正是这种增长湮没了它的影响。这就如同牛顿学说和爱因斯坦学说的关系。旧的体系在低能量领域依旧有效。不过一旦你将质量和速度推至足够的高度，就会惊现核爆或者Linux。
Unix的历史应该使得我们对研究Linux（以及我小规模效法李纳斯的实证【注1】）得出的结论有所准备。也就是说，虽然编程依旧需要单打独斗，但是真正伟大的革新却要借助整个社区的关注和智慧。一个闭门造车的开发者将会输给一个懂得如何营造开放，演进环境的开发者。因为在这样的环境下，他可以从几百（甚至几千）人中汲取反馈从而探索设计空间、得到代码捐赠、错误检测、以及其他改进。
但是有几个因素制约了传统的Unix世界没能把这一效果推向极至。其中之一就是来自不同版本许可证、行业秘密、和商业利益的法律限制。另一个（回头看来）是因为当时的因特网还不够强大。
在廉价网络到来之前，有过一些地域性的协作社团，在那里他们提倡温伯格的“无私”编程。开发者可以很容易的吸引到一批高水平的建言者和协作开发人员。贝尔实验室，麻省理工大学的人工智能和计算机实验室，加州大学伯克利分校——这些都是创新的来源，颇具传奇色彩并且继续着影响力。
Linux是第一个致力于并且成功地将全世界当作其智库的项目。在我看来，Linux和万维网同期产生，以及Linux在1993到1994年（ISP产业起飞和主流网络商机爆发的岁月）脱离婴儿期都不是巧合。李纳斯是在网络普及成为可能之后，读懂游戏规则的第一人。
尽管，廉价的网络是Linux模式发展的必要条件，但是我认为这并不足以成为充分条件。另一个关键环节是开发中的领导风格和协作机制——因为用户可以加入协同开发，才使得网络这个媒介的力量能够尽情展示。
那么这种领导风格是怎样的？协作关系又是如何的呢？它们不可能是基于权力关系的——即使能做到，强权的领导关系也不会带来我们所见的成果。在这个问题上，温伯格很恰当的引述了19世纪俄国无政府主义者，皮奥奇·阿列克谢耶维奇·克鲁泡特金在《我的自传》[1]中的论点：
我成长于一个农奴主的家庭，直到进入社会，同当时所有的年青人一样，我信奉诸如命令、秩序、叱责、惩罚的必要性。但是当我早期必须经手一些重要事务并与（自由）人打交道的时候，发现任何错误的指令都会引发严重的后果。于是我开始理解“命令和纪律”与“达成共识”两种行事原则的不同之处。前者在阅兵中起到的作用令人钦佩，但在实际生活中则一文不值。因为现实生活中的目标只能由众人同心协力完成。
“同心协力”正是像Linux这样的项目所需要的——“命令和纪律”对于无政府主义天堂（我们称之为网络）里的志愿者来说则形同虚设。为了有效的运营和竞争，一个想要领导协作项目的黑客必须学会如何有效的激发社区对（克鲁泡特金暗示的）“达成共识”模式的兴趣。还必须学会如何应用李纳斯定律。【注2】
先前我用“德尔菲效应”解释李纳斯定律，但是它本身更像一个生物学和经济学中的自适应系统。Linux世界在很多方面更像是一个自由市场或者生态圈，其中自私的个体都试图将自己的利益最大化，但是在这个过程中却自发形成了一种自我纠正机制，其周密度和有效性令任何中央计划都无法与之媲美。这就是可以“达成共识”的地方。
Linux黑客试图最大化的“效用”并不是传统经济学价值，而是在黑客圈中无形的声望和自我实现（或许有人会将他们的动机描绘成“利他的”，但却忽略了一个事实——利他主义本身就是对利他主义者的一种自我满足）。这样的志愿文化并不罕见；我热衷科幻小说已经很久了。与黑客圈不同，科幻迷们早就清楚地认识到“自我赏识 ”（自我激励或是赢取同好的赞誉）是志愿者活动背后的基本动力。
李纳斯，成功地在一个大部分由他人完成的项目中扮演了“看门人”的角色，培养利基直到它可以自我维持。可以说他准确的把握了克鲁泡特金“达成共识”的精神。Linux世界里这种类经济学的视角让我们得以看到“共识”是如何应用的。
我们可以把李纳斯的方法，视为一条通过“自我赏识”开创有效市场的路径——用尽可能稳固的方法连接自利的黑客，进而实现必须持续协作才能达成的目标。通过fetchmail项目（虽然规模小点），我证实可以通过效法李纳斯取得成效。或许我做得比他更有意识，更系统。
许多人（特别是不信任自由市场的人）预期（自我主义者的）“自我管理”文化会分崩离析、占山为王、挥霍无度、鬼鬼祟祟、和身怀敌意。但是只需看看丰富、优质、深刻的Linux说明文档就足以将这种预期推翻。程序员讨厌写说明文档似乎是金科玉律，那么这些文档是哪来的？难道Linux黑客都转性了？显然，与自我彰显的Linux自由市场相比，受人支配的商业软件工作室即使有大笔商业资金支持，也生产不出那么优质的文档。
Fetchmail和Linux项目都表明，通过对其他黑客的适当回报，一个优秀的开发者/协调者可以通过因特网网罗众多优秀的协作开发者，进而避免项目在混乱中倾覆。所以，针对布鲁克斯定律我提出反议：
19.倘若开发的协调者拥有不逊于因特网的媒介，又懂得如何避免强权领导，那么群体智慧定要强于单打独斗。
Providedthe development coordinator has a communications medium at least as good as theInternet, and knows how to lead without coercion, many heads are inevitablybetter than one.
我认为开源软件的未来将日益倚重于那些懂得利用李纳斯游戏规则的人，那些告别大教堂投身市集的人。这并不是说个体的远见和才智光辉不再。相反，我认为开源软件的锋芒会属于一种人——他们以独到的远见和才智开始一个项目，之后通过有效的建立志愿者社区来将其扩大。
或许这并不只是开源软件的未来。若论解决难题，没有一个闭源的开发者能与开源社区的智库相提并论。极少有人能雇用超过200人（1999年600人，2000年800人）为fetchmail效力。
或许开源文化会取得最终的胜利，但这并不是因为协作是善，而软件“囤积”是恶（或许你相信后者，不过李纳斯和我却不以为然），而只因开源社区可以为解决一个问题投入数量级的时间，所以闭源世界肯定会在这场进化角逐中落下马来。
注：
1.如今我们有了另一款软件，与fetchmail相比，它对市集模式假设做了更多的测试。这就是EGCS——实验性GNU编译系统（Experimental GNUCompiler System）。
这个项目始于1997年8月中旬，它被视为对早期（《大教堂与市集》公开版本中）观点的有意尝试。GCC项目（GUN C语言编译器，GNU C Compiler）创始人的离开，导致其停滞了许久。大约二十个月之后GCC和EGCS开始了平行的开发——利用相同的因特网开发人员；都以相同的GCC源代码为基础；使用几乎相同的Unix开发工具和开发环境。惟一不同之处在于，对于EGCS我们使用了先前述及的市集策略。而GCC则采用了类似大教堂的开发模式——封闭的开发团队，极少的对外释放。
这是我们能做到的最贴切的核对实验了，其结果颇具戏剧性。几个月里，EGCS就凭借一些特色遥遥领先——更棒的优化设计以及对FORTRAN和C++语言更好的支持。许多人发现与最近的GCC稳定版本相比EGCS发展的更迅速也更可靠。而且主要的Linux发行版都开始改用EGCS了。
1999年4月，自由软件基金会（GCC的官方发起机构）决定解散原始的GCC开发团队，并正式由EGCS接管。
2.当然，克鲁泡特金的批判和李纳斯定律把社会组织控制论抬升到了更广阔的角度。进而联想到软件工程领域的另一则民间法则，康威定律（Conway's Law）：“让四个人开发编译器，你就会得到四个（4-pass）编译器”。原始表述更具有一般性：“产品必然是其组织通讯结构的缩影”。简言之就是“方法决定结果”或是“过程变为产品”。
在很多层面上，开源社区没有必要形成与这适应的组织功能结构。网络无处不在：非独因特网，人们的工作也可以形成一种分布式的松散连接，一种对等网络。正是这种联系提供了恰如其分的冗余和缓解。对于这两种网络而言，一个节点的重要性取决于有多少人愿意与其相连。
其中对等部分对社区惊人的生产力至关重要。SNAFU法则[2]发展了克鲁泡特金对权力观点的阐释：“只有平等才能带来真诚的交流，因为下级更习惯于取悦上级而非告知以诚。”创造性的团队协作需要坦诚的交流，所以权属关系的存在必然形成制约。有效摆脱权力羁绊的开源社区向我们展示了这有多可怕：错误、低产能与错失机会！
进而SNAFU法则预言在独裁组织中，随着谄媚越来越多，决策者和事实的剥离也愈发严重。其在传统软件开发中所扮演的角色显而易见：下级有很多动机去隐匿、漠视、淡化问题。一旦这个过程转化成了产品，就是一场灾难。
译者按：
1.皮奥奇·阿列克谢耶维奇·克鲁泡特金：Пётр Алексе?евичКропо?ткин (1842-1921) 俄国无政府主义者、地理学家、政治哲学家，他认为改善人类现状的方法是合作而不是竞争。他对俄国和英国的无政府主义运动产生了很大的影响。《我的自传》是巴金的译作，也是巴金认为对自己影响最大的一本书。其英文版名为《Memoirs of a Revolutionist》。
2. SNAFU：“snafu”是二战时期军队中使用的一条缩略语。也就是Situationnormal all fucked up（好日子都他妈搞砸了）。后来也写为Situation normal all fouled up（平静的状态被搅乱了）。黑客则借此解释集权模式的恶果。
《大教堂与市集》 第十二章 关于管理和马其诺防线
1997年最初的《大教堂与市集》以这样的预见收束——程序员/无政府主义者快乐的网络部族，战胜并压倒了等级森严的传统闭源世界。
然而，许多人对此持怀疑态度，他们提出的问题应该得到中正的回应。多数对市集模式的异议可以归结为以下观点：开源支持者们低估了传统管理对生产力的提升作用。
传统思维的软件开发经理经常会指责开源项目组的创建-变动-解散太随意了。这种随意性大大抵消了（对于单个闭源开发者来说）开源社区在人数上的优势。他们会指出软件开发取决于长时间的持续投入，和预期的消费者持续购买程度。而不只是取决于有多少人往锅里扔骨头，然后等着它炖熟。
无可否认，这些论调有一定道理。其实我早就在《魔法大锅炉》（The Magic Cauldron）一文中预计增值服务将会是未来软件业的经济命脉。
但是这个论调却回避了一个重要的问题，它暗自假设开源开发不能提供持续的投入。事实上，有些开源项目已经在相当长的周期里保持了一致的发展方向和有效的维护社区，而不需要传统管理中必不可少的激励模式和制度约束。GNU的Emacs编辑器就是一个极端的、发人深思的例子。不管人事变动有多么频繁（实际上一以贯之的只有作者一人），几百位贡献者还是在长达15年的时间里用全心全意的投入建筑了一个统一的架构。没有一个闭源编辑器能问津这个长寿记录。
这到是提供了一个质疑传统软件开发模式（和大教堂与市集模式的争论不相干）的原因。如果GNU的Emacs在15年的岁月里保持了一致的架构；如果一个像Linux这样的操作系统在硬件和平台技术飞速变换的8年里也做到了这一点；如果（事实如此）许多设计精良的开源项目维系了超过5年的时间——那么我们有资格发问，传统开发的巨额管理费用（如果有的话）究竟给我买到了什么？
不管是什么，它显然不包括按期、按预算、按指定功能完成计划的可靠运营手段。如果能满足其中一条，就是一个罕见的“管理好”的项目了，更不用说全部了。它看来也不包括在让项目在开发过程种拥有适应技术和经济环境变化的能力。在这些方面开源社区已经遥遥领先了（比方说，你可以对比一下因特网30年的历史和那些专利网络短命的半衰期，也可以对比一下从16位到32位Linux毫不费力的升级和微软为此消耗的成本。特别要提醒你的是，Linux可不是只围绕英特尔系列打转，而是支持了包括64位Alpha芯片在内的十几家芯片厂商的产品）。
很多人认为从传统模式产品中可以买到法律保障——一旦出现问题会有人站出来负责，并得到补偿。但是这只是个幻觉，大部分软
