著佐权与许可声明（译文）

本文是埃里克·S·雷蒙德（Eric S. Raymond）《大教堂与集市》（The Cathedral and the Bazaar）的中文翻译，基于作者发布的原始文章版本（OPL v2.0）翻译。

原始作品信息

• 原作者：Eric S. Raymond（ESR）
• 原文版本：v3.0（2000-08-02）
• 原文版权：Copyright © 2000 Eric S. Raymond
• 原文许可：Open Publication License, v2.0

译文信息

• 译者：natsunoyoru97
• 网络域名：https://www.the-cathedral-and-the-bazaar-unofficial.online/
• 仓库地址：https://github.com/natsunoyoru97/the-cathedral-and-the-bazaar
• 翻译日期：2026年2月6日
• 译文版权：Copyright © 2026 natsunoyoru97
• 译文许可：
  • 遵循原始作品的Open Publication License, v2.0 协议全文；
  • 同时适用本声明所列之补充使用条件，尤其是关于署名、来源标识、非商业衍生、商业使用限制、版本区分与协作方式的规定。本补充条件是对OPL v2.0的补充和细化，不与之冲突。若存在冲突，以OPL v2.0为准。

关键补充声明

1. 本译文为译者个人基于ESR官网原始文章的独立重译版本，与O’Reilly出版的图书版及其他商业/非商业译本无关联，未参考或使用任何现有译本内容。
2. 本仓库是此版译文的唯一官方维护与完整更新来源，译者保留对本仓库版本的修订、注释、发布与维护决定权。
3. 本译文为个人成果，非官方译本，不代表原作者Eric S. Raymond的认可或背书。
4. 原文中的引用已按原作者标注的来源注明，相关权利归原权利人所有。若原文存在未标注或标注不充分的第三方内容，该问题原则上源于原文出处而非译者新增内容；译者将在收到权利人通知后及时核查并作必要处理。
5. 本译文将持续更新，修订记录见个人代码仓库版本历史。
6. Fork与衍生规范
   • 欢迎以个人学习、研究、笔记整理、勘误讨论、非商业解读、非商业摘要、非商业可视化或其他不违反本声明的非商业衍生创作为目的 Fork 本仓库。Fork 本仓库不视为获得对本译文进行商业使用或公开再发布完整版本的许可。
   • 出版纸质标准图书需获得原作者Eric S. Raymond的书面许可。
   • 任何基于本译文的非商业和商业衍生作品（如解读、可视化、摘要），必须显著标注原始出处（本仓库链接）及译者署名。若衍生物中包含译文全文的实质性主体（超过 10 小章节的连续文本，如 3.1-3.10），则不视为本条所称之衍生物，适用下一条之规定。
   • 禁止未经许可将本译文全文及其 fork 全文用于商业出版、商业发行、收费转载、付费课程、收费社群、付费资料包、付费电子书、纸质图书出版，或其他以本译文为主要内容的盈利性使用，如需使用务必征得译者同意并显著标明来源；禁止以去除译者署名、弱化来源说明、冒充官方版本、冒充原维护仓库、误导读者认为衍生版本即本仓库版本等方式造成来源混淆。
   • 不得将蒸馏的 skill 冠以译者个人名义（如 natsunoyoru97.skill），译者不反对基于该译本蒸馏的 skill，但不允许在 skill 中明示译者本人：
     • “基于 natsunoyoru97 开源译本蒸馏”✅
     • “natsunoyoru97 风格译文、natsunoyoru97.skill”❌

协作使用许可

1. 欢迎通过 GitHub Issue 提交关于译文、注释的讨论、勘误或建议。
2. 为保持译本风格一致、忠实于译者小记的宗旨，不接受 Pull Request。重大修改请通过Issue讨论。
3. 转载或修改译文时，需保留本声明，标注修改痕迹；如对译文内容作出删节、改写、重排、再注释或其他修改，须明确说明“此版本基于本版译文改编/整理，并非原维护版本”；修改版本仍应遵守 OPL v2.0 及本声明中的相关补充条件。
4. 出版纸质标准图书需获得原作者Eric S. Raymond的书面许可。
5. 若发现译文与原文不符或存在版权问题，请提交issue或邮件联系译者。

前言

自由在商业中并非一个抽象的概念。

任何行业能否取得成功，几乎直接取决于行业供给方与客户所能拥有的自由度。只需比较一下 AT&T 失去对美国消费者的垄断控制之后美国电话业务中的创新，与之前那些客户没有选择自由时缓慢的创新步伐，便可见一斑。

商业领域中，自由能够创造价值，最有力的例证就是对比计算机硬件行业与软件行业。在计算机硬件领域，供应商和消费者在全球范围内都享有自由，这一行业实现了人类前所未有的产品创新速度和客户价值提升速度。而另一方面，在计算机软件行业，行业变革的衡量单位却是以十年计。办公套件作为 20 世纪 80 年代的王牌应用，直到 90 年代网页浏览器与服务器问世之后才受到挑战。

开源软件给计算机软件行业带来的自由，甚至超过了硬件厂商与消费者所拥有的自由。

计算机语言之所以被称为语言，正因为它们就是语言。它让社会中掌握相关知识的群体（在这里指程序员）能够构建和交流思想，造福社会各界人士，其中也包括其他程序员。

通过法律手段限制获取我们社会日益依赖的基础设施知识（通过我们行业历史上惯用的专有二进制软件许可证），最终只会压缩自由空间、拖慢创新速度。

开源将一系列颠覆性理念，抛给了一个自以为底层架构早已尘埃落定的行业。开源把技术的掌控权交还给使用技术的客户，而不是允许厂商依靠封锁底层代码来挟持客户。向市场提供开源工具，需要新的商业模式。而只要能够向市场提供独一无二的价值，探索出这类商业模式的企业，在和那些妄图持续掌控用户的企业竞争时，将取得巨大的成功。

想要让开源软件真正深刻改变世界，长期以来始终需要两件事：第一，开源软件实现大规模普及；第二，必须向用户解释清楚，让人们理解这套开发模式能为使用者带来哪些价值。

埃里克・雷蒙德正是在这一点上做出了卓越贡献，他推动了开源软件革命走向成功，推动基于 Linux 的操作系统广泛落地，同时惠及所有开源使用者与相关服务商。他能够清晰、有力、精准地阐释这套颠覆性开发模式的价值，是这场革命成功的关键所在。

——鲍勃·杨（Bob Young），红帽公司董事长兼首席执行官（Chairman and CEO, Red Hat, Inc.）

第二版修订说明

为方便第一版读者，现将第二版中作出实质性增补或修订的主题概括如下：

• “足够多的眼球”怎么驯服复杂性。
• 截止日期的致命性。
• 对分支（fork）与伪分支更精确的定义。
• 演化上的累赘理论、孔雀与雄鹿在开源开发者动机研究中的相关性。
• 从经济学角度看，为什么开源不会出现供给不足？
• 信息不对称的影响。
• 将开源作为竞争武器。
• “黑客的复仇”中的预言在时隔 1 年后进行了回顾检验，并补充了新的预言。
• 新增了关于 fetchmail 项目成长的附录。

前言：你为什么要关注黑客文化

你手中的这本书，讲的是计算机黑客的行为与文化。书中收录一系列文章，原本写给程序员与技术管理者。作为潜在读者，你心里大概率会冒出一个直白也完全合理的疑问：“我为什么要关心这些？”

回答这个问题，最直观的一点：计算机软件在全球经济、企业战略布局里，正变得越来越关键。既然你翻开了这本书，想必早就听过大量关于信息经济、数字时代、互联世界的很多观点，这里我不再重复。我只想指出，只要我们在打造更高质量、更加稳定的软件这件事上取得实质性突破，带来的影响就会非常深远，而且这种能量会一天比一天大。

本书收录的文章并没有开创这种根本性变革，但它们完整描述了其中一种：开源软件。也就是系统性运用开放式开发、去中心化同行评审，以降低成本、提升软件质量的一套模式。

开源软件算不上新思路（这套传统早在 30 年前互联网诞生之初就已存在），但直到近些年，技术条件与市场风向交汇，才让它走出小众圈子。如今开源运动正强势发力，有望定义下个时代的计算机基础设施。任何依赖计算机的人，都有必要弄懂它。

我刚刚提到了“开源运动”。这也暗示读者还有另一重、或许最终更加值得关注的理由。在过去 30 年间，一个扎根互联网、充满活力的部落，在不断追寻、实践并珍视开源理念。这群人会自豪地称自己为“黑客”——不是现在媒体滥用的“计算机罪犯”的意思，而是回归它原本、纯粹的含义：狂热爱好者、追求尽善尽美的创作者、忍不住想发明创造的人、解决问题的人、行家。

黑客部落在沉寂的几十年里，一边和棘手的技术难题缠斗，一边承受主流社会漠视、排挤带来的巨大压力，直到近些年才终于崭露头角。是他们搭建了互联网，打造了 Unix，构筑了万维网；如今，他们又在开发 Linux 与开源软件。而在着 90 年代中期互联网大爆发之后，外界终于醒悟，早就应该更关注这群人。

黑客文化以及它取得的成就，通过现身说法，提出了一些根本性的问题：人类的内在驱动力、工作组织形式、专业精神的未来走向、企业的形态，还有这一切，将在 21 世纪及以后信息丰富、后稀缺经济中怎么变化与演进。黑客文化或许也预示了：人类与经济环境相处、改造环境的方式，将会迎来一系列深刻变革。正因如此，任何将要在未来生活、工作的人，都值得去了解黑客文化。

本书收录的文章最初都发布在互联网上：“黑客简史”成文于 1992 年，之后持续更新修订；其余篇目写在 1997 年 2 月至 1999 年 5 月。1999 年 10 月推出第一版时，文章经过小幅修订扩充，2001 年 1 月第二版再度更新。但我没有刻意删减技术细节，也没有为迎合普通读者而刻意简化内容、降低难度。在我看来，给读者带来思考、困惑与智识挑战，要比把内容写得浅薄、轻视读者来得尊重很多。如果你被某些技术知识点、历史细节或是陌生的计算机缩写卡住，可以放心跳过。整本书讲述了一条完整的脉络，你或许会发现，读到后面，之前困惑的地方自然就能理顺。

读者也需要明白，这些文章属于持续迭代的文本。我会定期汇总、吸收各位来信读者的评论与指正，把提炼后的观点并入正文。书中所有疏漏与错误，责任由我一人承担；但本书的成型过程，同样经历了和文中描述软件开发十分相似的同行评审，融入了很多人的贡献，这里没法一一列举。这里印刷的版本不是定稿或终稿，更像是一场持续探索的阶段性报告，而文中描绘的社群里的很多人，都深度参与了这场探索。

最后，我至少要尝试表达心中的欣喜、震撼与谢意——感谢许许多多的人，也感谢一路促成这本书诞生、一连串看似偶然的际遇……

在此，我要特别感谢长久以来给予我友谊、支持书中这些研究工作的人们。谢谢你，林纳斯・托瓦兹（Linus Torvalds）。谢谢你，拉里・奥古斯丁（Larry Augustin）。谢谢你，多克・瑟尔斯（Doc Searls）。谢谢你，蒂姆・奥莱利（Tim O’Reilly）。你们都是让我自豪地称为朋友与同事的人。我尤其要感谢凯瑟琳・雷蒙德（Catherine Raymond）——我的爱人、我的妻子，也是陪伴我最久的支持者。

我是一名黑客。我融入本书记述的这套文化已经超过 20 年。这些年间，我有幸和世上一群最有趣、最杰出的人一起工作、一起玩乐，解决迷人的问题，并且（在少数几个珍贵的时刻）创造出一些既真正新颖又有用的东西。许许多多无法在此一一列出，他们教会了我宝贵的经验，既有我们共同的技艺，也包含世间种种道理。本书收录的这些文章，就是我回赠给他们的礼物。

写下这些文章的过程，是我的探索之路，也是一场迷人旅程的报告。在这段旅程里，我学会了用全新、更加深刻的视角，重新看待那些早已熟悉的事物。至今我也感到诧异，仅仅是记录下这段历程，竟然也对开源走向主流起到了催化作用。我希望读到这份“旅途手记”的读者，能够体会到这段探索旅程的振奋，也能看见今天呈现在我们面前的、震撼的前景——在当下，主流商界与普通消费者，才刚刚踏上同一条道路。

译者小记

卫剑钒老师的译本是中文世界引入《大教堂与集市》的开路先锋，曾陪伴一代开发者走近并理解开源精神，是中文开源文化演进过程中一个标志性的里程碑。本译本为独立重译版本，在翻译过程中并未参考或沿用任何现有中译本文本。译者认为本书引用人类学、社会学乃至文化背景知识概念并不只是因为“有趣”，而是因为这些理论概念能够支撑本书的论述链条与理论建构，因此力图在当下开源协作日益成熟、社区治理逐步系统化、开源协作模式也不再只是极客的玩具的背景下，提供一个更具理论深度与跨学科视野的解读视角。

译者认为，当今社会亟需以跨学科视野推动理论建构、并在理论指导下深化实践。本译本采用学术化的翻译方式，正是希望为未来开源生态的理论探索与实践创新奠定基础。本译本对术语选择和注释密度有明确的学术取向，可能偏离ESR（Eric S. Raymond）作为“黑客散文家”的修辞风格，这一选择的风险与收益，留待读者判断。

此外，译者并非为学术而学术。在21世纪20年代的当下，开源正面临双重收编危机：资本逻辑将其降格为“降低研发成本的人力资本池”与“合规性标签”，政治逻辑将其征用为“技术主权”的地缘政治工具。更隐蔽的是认知层面的不对等：开源社区丰富的自我阐释（礼物文化、集市动力学、黑客伦理）在主流学术与政策话语中仍被视为"经验性描述"或"亚文化修辞"，缺乏与主流社会科学对话的概念硬通货（conceptual currency）。译者认为，开源知识成果本不至于陷入如此境地。

这种失语导致开源在严肃公共讨论中丧失定义自身的权力：当经济学家用“公共品困境”解释开源可持续性时，当政治学家用“数字民粹主义”标签开源社区时，当人文社科学人仍停留在开源“游牧民”的浪漫想象，或技术从业者“被剥削/为虎作伥”的道德二元论时，开源实践者往往因缺乏制度化的理论武器而无力反驳。本译本采用的学术化路径，正是试图在被完全收编之前，为开源构建一套不可化约的理论铠甲——通过经济学、人类学与政治经济学的严格概念化，证明开源不是现有秩序的例外或附庸，而是一种需要被认真对待的新社会组织范式。

译者深知，这种“通过学术体制获得承认”的策略存在异化风险（将流动的实践固化为僵化的范畴），但在当前话语权力极度不对称的情境下，以译者的个人能力似乎只能通过这种姿态，让开源进入资本与政治无法忽视的严肃知识场域。这不仅是为了更好地理解开源，更是为了在理解中保卫开源——防止其在被外界“正视”的过程中，被彻底扭曲为它所反对的东西。

ESR不仅描述开源现象，更试图融合工程学、人类学与经济学，建构一套“开源工程经济学”的新方法论体系。为此，本译本着重梳理书中涉及的哲学、人类学及经济学概念，补充详尽的学术背景与注释，力求呈现其理论骨架。无论你是开发者、研究者，还是对技术与社会的交汇点感到好奇的跨学科读者，只要你对书中提出的思想框架感到好奇，喜爱智识挑战，并享受其中的乐趣，那么这份译本就是为你准备的。译者希望它能为你提供更系统的概念梳理，帮助你更深入地把握原文语境，并领略作者跨学科思想的独特魅力。

第一章：黑客国度简史

本文梳理黑客国度的来龙去脉：先追溯早在 “真正的程序员” 时代埋下的文化源头，再讲述麻省理工黑客的黄金岁月，剖析早期阿帕网（ARPAnet）如何催生首个跨地域线上技术社群。文中记述了 Unix 早年兴起、后续发展陷入停滞的历程，芬兰带来的全新转机，以及那位 “最后纯粹的黑客” 何以成为新一代社群的精神奠基人。文末将梳理 Linux 与互联网走入大众视野的全过程，解释原本小众边缘的黑客国度，是如何一步步走到今天，获得广泛影响力的。

1.1 序幕：真正的程序员

一切的开端，是那群 “真正的程序员”。

他们自己并不这么称呼自己，不会自称黑客，也没有统一的名号。“真正的程序员” 这个说法，是 1980 年之后，圈内人回头追溯才定下的叫法。但自 1945 年起，计算技术就吸引了全球一大批头脑聪慧、创造力出众的顶尖人才。从埃克特与莫奇利造出首台 ENIAC 电子计算机开始，一群纯粹出于乐趣搭建软件、玩软件的爱好者，形成了或多或少延续不断且自觉的技术文化。

这群 “真正的程序员” 大多出身工程或物理专业，不少人同时是业余无线电发烧友。他们的标配是白袜子、涤纶衬衫、领带与厚框眼镜，写代码只用机器语言、汇编、FORTRAN，以及好几种如今早已被遗忘的上古编程语言。

二战结束到 20 世纪 70 年代初，是批处理、“大铁块”大型机（big iron）的黄金时代，“真正的程序员” 是计算机领域绝对主流的技术圈层。不少流传至今、受人推崇的黑客圈内典故都出自这个时代：各式各样的墨菲定律段子，还有那张仿德语恶搞的闪烁指示灯（Blinkenlights） 海报，时至今日，许多机房里还贴着它。

不少成长于这套文化下的人，一直活跃到 90 年代。克雷系列超级计算机的设计者西摩・克雷（Seymour Cray），就是其中最顶尖的代表。相传他曾自研计算机面板上的拨动开关，用八进制逐位录入整套自己写的操作系统，全程没有一处差错，系统还顺利跑了起来——这就是 “真正的程序员” 硬核实力的极致写照。

但 “真正的程序员” 文化高度绑定批处理计算，尤其面向科研的批量运算场景。随着交互式计算、高校计算机实验室与计算机网络相继兴起，这套文化逐渐式微。全新的工程传统就此萌芽，并一路演化，最终成为我们今天所见的开源黑客文化。

1.2 早期黑客

现在大家口中的黑客国度，源头基本可以锁定在 1961 年，那年麻省理工买到了第一台 PDP-1 小型机。 MIT 技术模型铁路俱乐部里有个信号动力小组，直接把这台机器当成了头号硬核玩具。他们自己写开发工具、造出一堆圈内黑话，还发展出一整套独有的社群文化，里面很多特质放到今天我们依然能找到影子。史蒂文・利维（Steven Levy）写的《黑客》（Hackers），书的前半段完整讲了这段往事，1984 年由 Anchor/Doubleday 出版，ISBN：0-385-19195-2。

MIT 的计算机圈子，也是最早用上 “黑客” 这个词的。模型铁路俱乐部的爱好者们，后来成了 MIT 人工智能实验室的核心力量，这家实验室直到八十年代初，都是全球 AI 研究的顶尖阵地。1969 年阿帕网正式上线之后，他们的影响力更加广泛了。

阿帕网是史上第一个横跨大陆的高速计算机网络。美国国防部最初搭建它，只是想做数字通信相关实验，没想到后来连上了几百所高校、军工企业和各类科研实验室。有了这张网，各地科研人员能以前所未有的速度和灵活性交换信息，极大地推动了协作工作，极大地加快了技术进步的节奏和强度。

但阿帕网还有其他的作用：这条电子信息高速通道，把全美国散落各处的黑客凑到了一起，形成了临界质量（critical mass）^a。在此之前，大家都分散在各个小圈子里，各自搞短暂的本地小文化圈；有了网络之后，他们终于凝聚起来，变成了一个线上互通的技术部落，找到了属于整个群体的共同身份。

黑客国度最早的有意识的产物，也就是第一批俚语列表、第一批讽刺作品、第一次对黑客伦理的自觉讨论，都在早期的阿帕网上传播开来。特别是《行话文件》的第一个版本，是在1973年至1975年间通过跨网络合作发展起来的。这本俚语词典成为了该文化的标志性文档之一。它最终于1983年作为《黑客词典》出版；该第一版现已绝版，但经过修订和扩展的版本是《新黑客词典》，由麻省理工学院出版社于1996年出版，此为第三版，ISBN号为0-262-68092-0。

黑客国度第一批成型的标志性产出——最早的圈内黑话合集、讽刺段子、还有大家第一次正经探讨黑客伦理的文字，当年全靠早期阿帕网四处传播。其中最有代表性的就是《行话档案》（Jargon File，http://www.tuxedo.org/jargon）^b。这份文档是 1973 到 1975 年间，各地网友跨网协作一点点攒出来的，相当于黑客圈专属词典，也是定义这套文化的核心文献。这本书在 1983 年正式出版，定名《黑客词典》，初版早已绝版；后来扩充修订的第三版《新黑客词典》由麻省理工学院出版社 1996 年发行，ISBN：0-262-68092-0。

所有连上阿帕网的高校，都成了黑客国度蓬勃生长的沃土，计算机系更是核心阵地。六十年代末起，MIT 人工智能实验室与计算机科学实验室稳居行业顶尖；斯坦福人工智能实验室（SAIL）、卡内基梅隆大学（CMU）的实力也与 MIT 不相上下。这几处都是顶尖的计算机与 AI 研究基地，汇聚了大批聪明人，不管是技术成果还是圈内的趣闻典故，他们都给黑客国度留下了大量积淀。

不过想要看懂后续的发展脉络，我们得回头聊聊硬件本身。当年 AI 实验室能崛起、后来又走向衰落，背后根源都是计算机技术带来的变革浪潮。

早在 PDP-1 那台机器问世时，黑客国度的发展就和 DEC（数字设备公司）的 PDP 系列小型机深度绑定。DEC 是商用交互式计算、分时操作系统的开创者，在那个年代，他家设备性能强、拓展性好，价格还相对亲民，几乎所有高校都大批量采购。

平价分时系统，就是黑客国度成长的土壤。在阿帕网的大部分生命周期中，它主要是由 DEC 机器组成的网络，其中地位最高的当属 1967 年推出的 PDP-10。。在将近 15 年的时间里，PDP-10 一直是黑客圈内最喜爱的机器；配套的 TOPS-10 操作系统、MACRO-10 汇编器，至今还在各种圈内黑话和老故事里，让老一辈极客念念不忘。

而 MIT 虽然用的也是同款的 PDP-10，但道路有点差别：他们直接弃用 DEC 官方整套软件，从零自研了一套传奇的操作系统 ITS。

ITS 全称是 “不兼容分时系统”（Incompatible Time-sharing System），光是名字就能看出这群 MIT 黑客的行事风格：凡事都要按自己的一套来。好在他们不光心气高，技术实力也完全撑得起这份傲气。ITS 设计古怪、风格特立独行，还时不时出点小 bug，但也诞生了一大堆开创性技术。直到今天，它可以算作是连续使用时间最长的单一分时系统。

ITS 内核是纯汇编写的，但上面绝大多数开发项目，都是用 AI 专用语言 Lisp 实现的。当年 Lisp 的表现力、灵活度甩开所有编程语言一大截；哪怕以 25 年后的今天来看，它的设计思路依旧比绝大多数现代语言更好。Lisp 释放了 ITS 开发者跳出常规思维、天马行空地创新的潜力，这也是当年他们能持续产出重磅成果的关键，直到今天 Lisp 也是黑客们最喜欢的语言之一。

ITS文化中的许多技术成果至今仍然活跃；EMACS程序编辑器可能是其中最著名的。而ITS的许多传说对于黑客们来说仍然是“鲜活”的，这一点可以在《行话文件》（http://www.tuxedo.org/jargon）中看到。

当年 ITS 生态诞生的很多技术成果，我们现在还在用，最出名的就是文本编辑器 Emacs。而 ITS 的许多传说对于黑客们来说仍然是“鲜活”的，在《行话档案》上就能看到。

斯坦福人工智能实验室 SAIL 和卡内基梅隆 CMU 这边也没闲着。当年一大批在 SAIL 的 PDP-10 机旁成长起来的黑客骨干，后来都成了个人计算机、窗口图标鼠标这套图形交互界面发展路上的核心人物。而另一边，CMU 的开发者也在钻研，促成了专家系统、工业机器人行业内实用技术方案的第一次大规模落地。

黑客国度还有一处关键的发源地，那就是施乐 PARC 帕洛阿尔托研究中心（Palo Alto Research Center）。从 70 年代初到 80 年代中期，这十多年间这里出现了大量划时代的软硬件创新：我们现在熟悉的鼠标、窗口、图标图形界面，全都是这里发明的；激光打印机、局域网技术同样出自这里。他们研发的 D 系列工作站，性能远超同期设备，比 80 年代主流高性能个人电脑整整超前 10 年。可惜的是，这群顶尖研发者在自家公司根本得不到重视，圈内甚至流传一个经典段子：PARC 就是专门给别的公司研发天才创意的地方。但不可否认，这里诞生的成果，对整个黑客国度影响深远。

在整个 70 年代，阿帕网与 PDP-10 小型机文化的规模越来越大，玩法也更加多样。原本用来跨全美串联各领域技术爱好者、协作研究的邮件列表，逐渐也多用于社交和娱乐。美国国防高级研究计划局 DARPA 对此心知肚明，却故意对这些 “不合官方用途” 的线上活动睁一只眼闭一只眼。他们很清楚，这点额外的网络开销不算什么，能吸引整整一代天赋出众的年轻人投身计算机行业，这笔买卖非常划算。

阿帕网上最出名的休闲社群邮件列表，当属科幻爱好者专属的 SF-LOVERS，就算到今天，在阿帕网演化而来的互联网上这个社群也依旧活跃。当年类似的邮件列表还有很多，它们开创了线上社群交流的雏形；后来这套模式被 CompuServe、GEnie、Prodigy 这些分时服务商商业化，再往后美国在线 AOL 又主导了大众线上服务市场。

而我作为这段黑客史的记录者，在 1977 年就通过早期阿帕网、科幻爱好者社群接触到黑客国度。从那以后，文中讲到的很多行业变迁，我都是全程参与其中的亲历者。

1.3 Unix 的崛起

和万众瞩目的阿帕网圈子不同，在新泽西（New Jersey）的荒野中还有一条完全独立的技术线，从 1969 年就一直在发展，最后风头盖过了 PDP-10 那套体系。碰巧的是，在阿帕网诞生的同一年，贝尔实验室（Bell Labs）的黑客肯・汤普森（Ken Thompson）创造了 Unix。

汤普森之前参与过 Multics 分时操作系统的研发，这套系统和 MIT 的 ITS 算是同根同源。Multics 承载了一套很关键的设计思路：把操作系统内部复杂的底层逻辑全部封装隐藏，普通用户、甚至大部分程序员都不用感知底层细节。核心目的就是简化操作与开发门槛，让大家能更高效地完成实际工作。

可后来 Multics 越做越臃肿，体积庞大却很难落地使用，活成了典型的白象工程（white elephant）^a，贝尔实验室直接退出了项目。这套系统后续由霍尼韦尔（Honeywell）推向商用，但始终没能做起来。汤普森很怀念 Multics 的使用体验，就找来一台闲置淘汰的 DEC PDP-7 小型机，在上面融合 Multics 的设计思路和自己的想法，动手写起了新系统。

另一位传奇黑客丹尼斯・里奇（Dennis Ritchie），专门为汤普森这套尚在雏形的 Unix 打造了全新编程语言 C。和 Unix 的设计思路一脉相承，C 的设计理念是上手舒服、没有多余束缚，而且非常灵活。贝尔实验室内部有越来越多的人开始使用这套工具；在 1971 年两人拿下内部项目，要给实验室开发一套我们现在说的办公自动化系统，Unix 和 C 也借着这个项目快速完善。但汤普森和里奇的野心远不止于此。

早年所有操作系统全是纯汇编写死的，只为榨干单台机器的极限性能。汤普森和里奇是最早看清这件事的人：硬件、编译器技术已经成熟，整套操作系统完全能用高级语言 C 来编写。到 1978 年，完整的 Unix 环境已经成功移植到多款完全不同架构的设备上。

这件事在当时史无前例，带来的影响更是颠覆性的。如果 Unix 不管在哪种机器上跑，界面、功能全都是统一的，那它就能成为通用的软件环境。用户不再需要为每台过时的机器为全新的软件设计付费；有了 Unix 之后，开发者能把整套工具库在不同设备间直接迁移，不用每次都钻木取火、重复造轮子，白白浪费精力。

除了可移植性，Unix 与 C 还有一个重要优势：二者都严格遵循“保持简单，直白”的 KISS 极简设计原则。C 语言逻辑简洁干净，降低了程序员的心智负担（不像之前之后的多数其他语言），不用频繁查阅手册；而 Unix 本身由一堆小巧独立的工具程序构成，工具之间能自由拼接组合，灵活实现各类需求。

这套 C+Unix 的组合，适配的业务场景覆盖极广，很多当年设计者完全没预料到的用途它都能搞定。哪怕 AT&T 没有推出官方技术支持服务，这套系统还是在公司内部快速传开。到 1980 年，全美大量高校、科研机房都部署了 Unix，成千上万黑客都把它当成自己的“老家”。

早期 Unix 圈子最常用的中坚机型是 PDP‑11，以及它的后续机型 VAX。Unix 的可移植性好，不用大幅修改代码就能跑在各式各样的硬件上，它的兼容范围比当年整个阿帕网所有机器加起来还要大。大家也不再碰汇编，用 C 写的程序可以轻松在不同设备间迁移。

Unix 还有一套专属的网络通信方案——UUCP。虽然它网速慢、稳定性一般，但好在成本极低。两台 Unix 主机只要接上普通电话线，就能点对点收发邮件，这个能力是系统原生自带的，不用额外加装组件。1980 年，首批 Usenet 站点开始互相推送各类资讯帖子，搭建起一套巨型分布式论坛，规模很快就超越了阿帕网。各地运行 Unix 的服务器，围绕 Usenet 形成了独属于自己的网络国度。

也有一小部分 Unix 节点同时接入了阿帕网。PDP‑10 一派和 Unix/Usenet 两群人开始有了交集，但最开始两边互相看不顺眼。玩 PDP‑10 的老黑客总觉得 Unix 这帮人后来居上却牛气哄哄，和 ITS 和 LISP 那种精巧繁复、设计华丽的体系相比，Unix 的工具简陋得可笑，于是他们在私底下吐槽：“这帮人还在用石刀兽皮过日子呢！”

当时第三股技术浪潮也正在兴起。1975 年首款个人电脑正式发售，1977 年苹果公司成立，之后硬件迭代速度快得超乎想象。微型计算机巨大的潜力吸引了新一代年轻极客。他们主要用 BASIC 编程，语法简陋粗糙，不管是坚守 PDP‑10 的老牌玩家还是深耕 Unix 的开发者，都觉得连鄙视它都多余。

1.4 远古时代^a的终结

1980 年的天下，大抵是三分的局面：有三派文化圈，他们的边缘偶尔有交集，但各自扎根于完全不同的硬件与体系。一派是阿帕网 + PDP‑10 老玩家，全套绑定 LISP、MACRO 汇编、TOPS‑10、ITS，还有斯坦福 SAIL 那套生态；一派是 Unix 和 C 开发者，日常用 PDP‑11、VAX 小型机，靠慢吞吞的电话线拨号联网；还有一群家用微机爱好者组成的安那其主义乌合之众（anarchic horde），一心想给普罗大众传播计算机算力的福音。

三者之中，ITS 社群依旧自认底蕴最足、地位最高，然而风暴的前兆正悄然笼罩着实验室。ITS 赖以生存的 PDP‑10 硬件日渐老旧，再加上有人开始把 AI 技术商业化，实验室内部直接分裂成不同派系。MIT、SAIL、CMU 的一些顶尖技术大牛，都被初创企业开出的高薪挖走了。

到了 1983 年，压垮 ITS 的最后一根稻草来了。DEC 宣布砍掉 PDP‑10 下一代 Jupiter 机型，全力主推 PDP‑11 和 VAX 产品线。这下 ITS 彻底没了出路：它从设计之初就没有跨硬件移植能力，想把整套系统适配新机器，成本和工作量根本没人扛得住。搭载在 VAX 上的伯克利 Unix，顺势成了黑客国度的首选开发系统。明眼人都看得出来，微型计算机性能提升速度一日千里，早晚会席卷整个行业。

大约就在这个时期，利维写完了《黑客》这本书。他的主要线人之一便是理查德·M·斯托曼——也就是 Emacs 编辑器的创造者。斯托曼当时是 MIT 实验室的核心人物，也是圈内抵制技术商业化态度最狂热的人。

大家一般都用他的缩写账号 RMS 称呼他。后来他创办了 FSF （自由软件基金会），全身心投入开发高质量的免费开源软件。利维在书里称他为 “最后一位纯粹的黑客”，现在回头看这个论断落空了，反倒是件好事。

斯托曼最宏大的规划，完美体现了 80 年代初黑客国度的时代转型：1982 年，他着手从零复刻一套完整的 Unix 兼容系统，全部用 C 语言开发，并且完全免费开放。这个项目取名 GNU（Gnu's Not Unix）。很快 GNU 就成了黑客们协作开发的核心阵地，原本 ITS 一脉的理念与传统，也借此融入了以 Unix、VAX 为主流的新一代黑客文化，得以延续下来。

自由软件基金会成立后的十几年间，无疑在很大程度上奠定了大众认知里黑客文化的核心思想，斯托曼也成了整个技术社群公认的、无可替代的精神领袖。

大约在 1982 到 1983 年，芯片和局域网技术开始深刻改变黑客国度的格局。以太网搭配摩托罗拉 68000 处理器，组合起来性能潜力巨大，不少初创公司纷纷成立，打造出我们现在所说的第一代工作站。

在 1982 年，一群来自斯坦福、伯克利的 Unix 开发者合伙创办了 Sun 公司。他们笃信，把 Unix 跑在性价比更高的 68000 架构硬件上，能适配绝大多数业务场景，一定会大获成功。事实证明他们的判断完全正确，这套思路直接定下了后续整个行业的发展路线。虽说工作站的价格普通个人还是负担不起，但对企业、高校而言已经足够便宜；一人一台工作站连成局域网，很快取代了过去共用一台主机的 VAX 和其他分时系统。

1.5 专有 Unix 时代

回看 1984 年，贝尔体系拆分，AT&T 第一次把 Unix 做成官方商用、提供正规技术支持。这一年，黑客国度清晰分成两大截然不同的阵营：一边是以互联网、Usenet 为纽带、联系紧密的网络国度，大家基本都在用跑 Unix 的小型机或工作站；另一边则是人数众多、彼此分散孤立的家用微机爱好者腹地，两边几乎互不连通。

大概也就在这段时期，各类恶意入侵破坏事件第一次登上主流媒体版面。记者们从此开始乱用 “黑客” 这个词，拿它指代搞破坏、入侵系统的人，这种概念混淆直到今天都没能彻底纠正，十分可惜。

Sun 等厂商推出的工作站为黑客开辟了新天地。这种机器是高性能图形渲染、支持局域网数据共享的专用机型，在整个 80 年代，黑客们都在钻研各类工具软件，想方设法把这些硬件能力充分发挥出来。伯克利 Unix 率先内置兼容阿帕网通信协议，解决了早年 UUCP 拨号网速慢、点对点传输受限的问题，也进一步促进了互联网的发展。

当年行业内出现过好几套工作站图形界面方案，最后脱颖而出的是 MIT 主导开发的 X Window 系统，数十家企业、几百位开发者都为此做出了贡献。它能站稳脚跟有一个关键因素：开发团队遵循黑客伦理，完全开放源码，也能直接通过互联网分发。X 系统击败了各家闭源专属图形方案（就连 Sun 自家的图形产品也没能竞争过它），这件事也提前预示了几年后，一场会深刻影响整个 Unix 生态的大变革即将到来。

ITS 阵营和 Unix 阵营之间，偶尔还会爆出派系间的牢骚怨气，主要是 ITS 老玩家在抒发不满。但 1990 年，最后一台运行 ITS 的主机彻底退役，这群执念很深的老黑客没了专属阵地，只能带着或多或少的不甘，慢慢融入 Unix 社群。

而在依托网络联结的黑客国度内部，整个 80 年代最核心的竞争，来自 BSD 伯克利 Unix 拥护者和 AT&T 原版 Unix 支持者。现在偶尔还能淘到当年的复古海报，画的是卡通版《星球大战》X 翼战机飞速飞离正在爆炸的死星，死星表面印着 AT&T 的企业标识。伯克利这边的开发者总把自己视作反抗冰冷商业巨头的叛逆者。虽说 AT&T Unix 的市场热度始终赶不上 BSD/Sun，但它拿下了行业标准话语权。到 1990 年，两大版本互相借鉴了对方大量创新特性，两者的界限已经变得十分模糊。

在 90 年代初，上一代主流工作站技术迎来巨大冲击，搭载 Intel 386 系列芯片的新一代个人电脑，成本更低、性能却突飞猛进。个人黑客第一次能在买到算力、存储容量与 10 年前的小型机设备相当、完整运行 Unix 开发环境的家用机器，这些 Unix 引擎能够支持完整的开发环境，也可以随时接入互联网。

但 MS-DOS 圈子完全置身事外，对这一切一无所知。早年家用微机爱好者群体不断壮大，玩 DOS、Mac 的开发者数量比线上 Unix 社群高出好几个量级，却始终没能形成一种自觉的文化共同体意识。软硬件迭代速度太快，衍生出几十种小众技术圈子，全都如同蜉蝣般转瞬兴衰，根本没有足够稳定的周期沉淀出统一的黑话、圈内典故与发展历史。再加上没有 UUCP、互联网这种全覆盖的互通网络，他们始终无法凝聚成一个网络国度。

CompuServe、GEnie 这类商用线上平台当时也开始普及，但 DOS、Mac 这种非 Unix 系统出厂根本不带开发套件，大家几乎不会在上面互相分享源码，自然也就没法形成协作开发的黑客传统。

当时黑客国度的核心群体全都围绕着互联网组织，主流技术体系也已经是 Unix，他们压根不在意这些商用拨号平台。这群人真正想要的是更完善的开发工具、更普及的互联网接入，而平价 32 位个人电脑，刚好能把这两样东西送到普通人手里。

可配套操作系统却成了难题：商用 Unix 售价动辄几千美元，门槛很高。90 年代初有好几家厂商尝试把 AT&T、BSD Unix 移植到 PC 上售卖，结果全都做不起来，价格也没有大幅下降。最糟糕的是，买了系统也拿不到能自由修改、二次分发的源代码。这套传统商业软件模式，完全满足不了黑客群体的核心需求。

FSF 这边也没能补上缺口。斯托曼承诺多年、专供黑客使用的自由 Unix 内核 HURD 开发进度长期停滞，拖到 1996 年才勉强产出能简单使用的版本；虽说早在 1990 年，FSF 就已经补齐了一套类 Unix 系统除内核以外几乎所有复杂组件。

雪上加霜的是，到了 90 年代初，很明显各家厂商推进闭源商用 Unix 十年努力正以失败告终。市面上六七个互不兼容的商业 Unix 分支互相争吵，Unix 跨平台可移植性的承诺也因此迷失了。一众商用 Unix 厂商行动迟缓、眼光闭塞，市场运营一塌糊涂，才导致微软能抓住机会，靠着技术差距极大的 Windows 系统，硬生生抢走了大片市场份额。

在 1993 年初，若是抱着看衰心态的旁观者，很容易认定 Unix 的故事行将落幕，黑客部落也将日薄西山。彼时计算机行业媒体里都是这类唱衰的人，自打 70 年代末起，不少人几乎每半年就例行发文，预言 Unix 马上就要消亡。

当时业界主流论调都觉得，技术圈个人英雄主义已经行将就木，软件产业与刚萌芽的互联网，迟早会被微软这样的巨头纳入囊中。初代 Unix 黑客渐渐显出疲态、不复当年锐气（伯克利计算机科研小组早已后劲不足，1994 年更是直接断了资金支持），那是一段前景黯淡的低谷期。

好在还有不少事，始终游离在行业媒体乃至绝大多数黑客的视线之外；1993 年末到 1994 年，这些蛰伏已久的暗流催生了翻天覆地的向好变革，彻底引领整个黑客国度走向崭新的方向，取得从前谁都不敢想象的成就。

1.6 早期的自由 Unix 系统

FSF 尚未完成的 HURD 内核项目，给行业留下了空白，赫尔辛基大学（Helsinki University）一名学生林纳斯・托瓦兹（Linus Torvalds）趁势补上了缺口。1991 年，他依托 FSF 提供的全套工具链，为 386 架构 PC 开发一套自由 Unix 内核。项目起步便大获成功，吸引众多互联网黑客一同协作完善 Linux——一个功能完整、源码完全开放、可以自由修改分发的类 Unix 系统。

Linux 并非一枝独秀。在 1991 年，几乎与林纳斯同步，威廉・乔利茨（William Jolitz）、琳恩・乔利茨（Lynne Jolitz）夫妇正着手把 BSD Unix 源码移植到 386 机型。当时绝大多数旁观者在对比成熟 BSD 方案与林纳斯早期简陋粗糙的原型后，都笃定 BSD 移植版会成为 PC 平台最重要的自由 Unix 系统。

可 Linux 最重要的特点不在技术层面，而在社群组织层面。在 Linux 诞生之前，所有人都认为，任何像操作系统这样复杂的软件，都必须由小规模、高度紧密的核心团队统筹规划、按部就班地开发。这套模式过去是、现在依然是商用软件的常态，既是 80 年代 FSF 打造的一座座自由软件大教堂的典型特征，也是由乔利茨夫妇 386BSD 移植版衍生而来的 FreeBSD、NetBSD、OpenBSD 等分支的典型特征。

Linux 的演进方式则完全不同。项目几乎从一开始，就由大量志愿者以随意的方式进行黑客式开发，仅通过互联网进行协调。它不靠严格的标准或者独裁式管理保障代码品质，而是采用一种极其简单的策略：每周发布一个新版本，并在几天内从几百名用户那里获取反馈；开发者提交的每一处改动，都会经历一轮快速的达尔文式优胜劣汰。让几乎所有人惊叹的是，这套松散的模式竟然很有成效。

到了 1993 年底，Linux 在稳定性和可靠性上已经能与许多商业 Unix 系统竞争，配套的软件更是远超对手，甚至开始吸引商业应用软件移植适配这个系统。这种发展趋势间接击溃了多数小型闭源 Unix 厂商——由于失去开发者与黑客这一客户群体，它们纷纷倒闭。仅有少数企业得以存续，BSDI（伯克利系统设计公司）便是其一——它发行的 BSD 系 Unix 附赠完整源码，深耕黑客社群、维系紧密联结，反而蓬勃发展。

这些进展在当时黑客文明内部并没有引起太多讨论，在外界更是完全没人关注。黑客文明顶住了对其消亡的一次次预测，刚刚开始以自己的面貌重塑商业软件世界。然而，这一趋势还要再过 5 年才会变得显而易见。

1.7 万维网的爆炸式发展

Linux 的早期成长与另一现象产生了协同效应：互联网被公众所发现。90 年代初，ISP（互联网服务提供商）产业蓬勃兴起，以每月几美元的价格向公众出售网络接入服务。万维网问世之后，本就增速迅猛的互联网，发展之势更是一日千里。

1994 年，伯克利 Unix 研发团队正式解散，当时的几个自由 Unix 分支（Linux 与 386BSD 衍生各系）已经成为黑客活动的主要焦点。Linux 以 CD-ROM 的形式商业发行，供不应求。到了 1995 年底，各大计算机公司开始刊登精美的广告，宣传自家软件和硬件适配互联网的友好性！

在 20 世纪 90 年代末，黑客国度的核心活动，就是开发 Linux 与推动互联网主流化。万维网最终将互联网塑造成了大众媒体，许多 20 世纪 80 年代和 90 年代初的黑客纷纷创办 ISP，向大众销售或提供网络接入服务。

互联网的主流化，甚至为黑客文明带来了初步的尊重和政治影响力。1994 年至 1995 年间，黑客活动人士成功挫败了 Clipper 芯片提案^a——该提案意图将强加密技术置于政府控制之下。1996 年，黑客们动员起一个广泛联盟，击败了被错误命名的《通信规范法》（Communications Decency Act, CDA）^b，阻止了对互联网的审查制度。

随着 CDA 一役的胜利，我们已从历史跨入了时事领域。我们进入了另一个时期——在这个时期中，我这个黑客史的记录者（这让他自己也很意外）也从旁观者变成了参与者。余下故事，留待《黑客的复仇》再续。

第二章：大教堂与集市

我将剖析一款大获成功的开源项目——fetchmail。打造这个项目本身就是一场精心设计的试验，用来验证 Linux 发展历程所催生的、一套颠覆大众认知的软件工程理论。我将围绕两种根基迥异的开发模式展开讨论：大多数商业世界采用的“大教堂模式”，与 Linux 社群独有的“集市模式”——并指出这两种模式源于对软件调试任务本质的不同假设。紧接着，我将基于 Linux 的经验，层层递进、有理有据地佐证那句至理名言：“眼球足够多，bug 就好捉”，并与其他由自利主体构成的自校正系统做类比，从中挖掘它们相通的逻辑。在文章最后，我还会深入探讨这份独到的见解将给软件行业的未来带来哪些深远影响。

2.1 大教堂与集市

Linux 是颠覆性的。哪怕在五年前（1991年），谁能想到，一款世界级的操作系统，竟能仿佛魔法一般，出自全球数千名兼职黑客的业余代码创作，所有人仅凭互联网这根纤细的纽带彼此联结？

反正我当初是没想到的。1993 年初 Linux 进入我的视野时，我已经投身 Unix 与开源开发十年之久。20 世纪 80 年代中期，我就是 GNU 的首批贡献者之一。我曾在互联网上发布大量开源软件，独立或联合开发了多款至今仍被广泛使用的工具（如 nethack、Emacs 的 VC 和 GUD 模式、xlife 等）。那时的我，自认深谙软件开发的全部门道。

Linux 彻底推翻了我过往固有的认知。多年来，我一直在推崇 Unix “小工具、快速原型、迭代开发”的核心理念。但我也相信，存在某个关键的复杂度阈值，而一旦越过这道门槛，就必须采用高度集中、预先统筹的开发模式。我相信，最重要的软件（操作系统以及像 Emacs 编程编辑器这样真正大型的工具）应当像大教堂那样建造，由几位魔法师闭门潜心打磨，绝不在时机成熟前发布 beta 版。

林纳斯・托瓦兹（Linus Torvalds）的开发风格出乎我的意料：早发布、常迭代，尽可能下放开发权限，项目对所有人开放到近乎“滥交”的程度。这里没有修建大教堂时那种沉静、审慎的封闭氛围；Linux 社区反倒像一座人声鼎沸的大集市，汇集了各路黑客不同的目标和方案——全球的 Linux 代码归档站点任何人都能提交代码，就是这一模式最好的象征。一套逻辑完整、稳定可靠的操作系统，竟能从这样纷乱的环境中诞生，简直像是接连上演的奇迹。

这种集市风格竟然行得通，而且效果很好，这点让我格外震惊。当我逐渐摸清门道后，我不仅在个人项目中采用自己的方式，还努力去理解：为什么 Linux 社区不但没有在混乱中分崩离析，反而越做越强，让大教堂的建造者们难以想象。

到了 1996 年中期，我自认为终于理清了背后的逻辑。通过一次偶然的机会，我拿到了绝佳的理论验证载体：一个开源项目，我可以主动采用集市模式运营。我付诸实践，最终收获了巨大成功。

下文我将讲述这个项目的完整经历，并以此总结出一套能高效推进开源开发的实践准则。这些准则并不都是我在 Linux 社区才开始学到的，但我们将看到 Linux 社区怎样赋予它们独特的深意。如果我说的成立，它们就能帮你准确理解，究竟是什么让 Linux 社区成为优秀软件的源泉——或许还能助你大幅提升个人开发效率。

2.2 使命必达^a

1993 年起，我在宾夕法尼亚州西切斯特运营免费接入互联网服务商切斯特县互联（CCIL），全权负责平台技术板块。我是 CCIL 的联合创始人，并编写了我们自研的多用户 BBS 系统软件——你可以通过 telnet 登录 locke.ccil.org 来查看它。如今，它在30条线路上支持着近 3000 名用户。这份工作让我能够通过 CCIL 的 56K 线路全天候接入互联网——实际上，这份工作几乎要求我这么做！

我早已习惯即时互联网邮件带来的便利了。我得频繁用 Telnet 登录 locke 服务器查邮件，实在十分麻烦。我想要的是我的邮件被投递到 snark（我的家用系统）上，这样我就能在邮件到达时收到通知，能用我本地的所有工具来着手处理。

互联网原生的邮件转发协议 SMTP（简单邮件传输协议）并不适用，因为它在机器全时在线时工作得最好，而我的个人电脑并不总是连着互联网，也没有静态 IP 地址。我需要的是一种程序，它能在我的间歇性拨号连接中主动抓取，把邮件拉取过来并在本地投递。我知道这样的东西是存在的，而且大多数使用一种叫做 POP（邮局协议）的简单应用协议。POP 如今已被大多数常见邮件客户端广泛支持，但当时，我正在使用的邮件阅读器并没有内置这个功能。

我需要一个 POP3 客户端。于是我上网找了一个——实际上，我找到了三四个。我用了其中一个一段时间，但它缺少一个在我看来很明显的功能——能够修改拉取邮件的地址头，以便回复功能正常工作。

问题是这样的：假设 locke 上一个叫 joe 的人给我发了邮件。如果我把邮件拉到 snark 然后试图回复，我的邮件程序会兴高采烈地将邮件发送给 snark 上一个不存在的 joe。每次回信都要手动给地址补上@ccil.org后缀，没过多久就让我不胜其烦。

这显然应该是计算机替我做的事情，但现有的 POP 客户端没有一个知道该怎么做！这就引出了第一课：

1. 所有出色的软件，最初都是为了解决开发者自己遇到的麻烦。

或许这本来就显而易见（“需求是发明之母”早已是格言），但太多软件开发者日复一日地为薪酬而打磨他们既没有需求也没有热爱的程序。但在 Linux 世界里并非如此——这或许可以解释，为什么 Linux 社区出产的软件平均质量如此之高。

那么，我会不会三下五除二，一头扎进新项目开发，去写一个新 POP3 客户端竞品呢？想都别想！我仔细分析了手头的 POP 工具，问自己：“哪个最接近我的需求？”因为：

2. 普通的程序员清楚要从零开发什么，优秀的程序员懂得该改造、复用什么。

虽然我不敢自称顶尖，但是我会努力效仿顶尖程序员的方法论。顶尖人物的一个重要特质就是会偷懒——只在有建设性的地方投入精力。他们知道，得到 A 的评级不是因为有多努力，而是因为成果；更何况从一个能解决部分问题的原型方案出发，基本上总比从零开始要容易得多。

举个例子，林纳斯・托瓦兹（Linus Torvalds）(http://www.tuxedo.org/˜esr/faqs/linus) 实际上并没有从头开始编写 Linux。相反，他先复用了 Minix（一个面向 IBM PC 兼容机的小型类 Unix 操作系统）的代码和思想。最终所有 Minix 代码要么消失、要么完全重写，但趁它还在，它便仍然是幼年 Linux 的脚手架。

本着同样的精神，我开始寻找现有且代码质量尚可的 POP 工具，作为开发的基础原型。

Unix 社区的源代码共享传统，向来十分拥抱代码复用（这正是 GNU 项目选择 Unix 作为基础操作系统的原因，尽管对该系统本身颇有保留）。Linux 世界几乎将这一传统发挥到了技术极限，它有按 TB 计的开源代码可供获取。因此，花时间寻找改一点就能用的他人成果，在 Linux 社区里更可能有所收获。

对我而言确实如此。加上之前找到的那些，我第二次搜索总共找到了 9 个候选项目：fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail 和 upop。我最初选定的是 Seung-Hong Oh（音译：吴承洪，后文采用此译）编写的 fetchpop。我把我的邮件头重写功能加入其中，并做了其他一些改进，作者接受了这些改进，并将其合并到了他的 1.9 版本中。

然而，仅仅几周后，我偶然发现了卡尔·哈里斯（Carl Harris）的 popclient 代码，很快发现自己面临一个两难：尽管 fetchpop 有一些不错的原创想法（比如后台守护进程模式），但它只能处理 POP3，而且代码写得相当业余（承洪当时是一位有天赋但经验不足的程序员，这两点都暴露无遗）。卡尔的代码更好，相当专业扎实，但他的程序缺少 fetchpop 几个重要且实现起来相当棘手的功能（包括我自己编写的那几个）。

是继续用 fetchpop，还是换到 popclient？如果换，那我就舍弃已经完成的代码，换取一个更好的开发基础。

一个让我想换项目的实际原因是 popclient 支持多协议。POP3 是最常用的邮局协议（POP，Post Office Protocol），但不是唯一的一种。Fetchpop 和其他竞品都不支持 POP2、RPOP 和 APOP，而我已经有了模糊的设想：也许可以为了好玩增加对 IMAP（互联网消息访问协议，最新设计、功能最强大的邮局协议，http://www.imap.org）的支持。

但我还有一个更理论性的理由，这是我早在 Linux 之前就学到的：

3. “做好舍弃第一版的准备，无论如何，你最后总会推倒重来。”（弗雷德里克·布鲁克斯（Fred Brooks），《人月神话》第 11 章）

换句话说，你往往在第一次实现某个解决方案之后，才真正理解问题所在。到了第二次，也许你才足够了解，也能把它做对。所以如果你想做对，就要准备好至少重来一次。¹

好吧（我对自己说），对 fetchpop 的修改已经是我的第一次尝试了。于是我就换了。

1996 年 6 月 25 日，我把第一组 popclient 补丁发给卡尔·哈里斯后，我发现他基本上在那之前一阵子就已经对 popclient 没什么兴趣了。代码长期无人维护，还积累了一些遗留的小 bug。我还有很多改动要做，于是我俩很快就达成一致：由我来接手这个程序是顺理成章的事。

在我几乎还没察觉的情况下，这个项目就已经升级了：我不再只琢磨给现有的 POP 客户端打些小补丁，而是接手了整个项目的维护，而且我的脑海中正涌现出一些想法——我知道那些想法很可能会带来大改。

在一个鼓励代码共享的软件文化中，这是项目演化的一种自然的方式。我正是在践行这条原则：

4. 如果你态度端正，有趣的问题自然会找上门来。

但卡尔·哈里斯的态度更为重要。他明白：

5. 当你不再愿意维护一款程序，你最后的责任就是把它交给一个称职的继任者。

这不需要任何多余的讨论，卡尔和我都知道，我们有一个共同的目标：拿出最好的解决方案。对我们俩来说，唯一的问题就是我能不能证明自己是可靠的接手人选。一旦证明了这一点，他便爽快得体地完成了项目移交。我希望轮到我的时候，我也能做得一样好。

2.3 用户群体的重要作用

就这样，我接手了 popclient。更关键的是，我一并接手了它的用户群。拥有用户是件美妙的事：这不单能印证你的产品贴合真实需求，说明你的开发方向没有出错；只要用心培育，这些用户还能成为协作开发者。

Unix 传统还有一大优势，Linux 将其推向了令人欣喜的极致——很多用户本身就是黑客。源代码是公开的，他们能高效参与开发，大幅缩短调试的时间。只要稍加鼓励，你的用户就会主动排查故障、给出修复方案、优化代码，效率远比你孤军奋战要高。

6. 将用户当作协作开发者，是快速改进代码、高效调试最省心的办法。

我们很容易低估这种效应的威力。在林纳斯・托瓦兹用实践给出全新示范之前，开源圈子里开源圈子里几乎所有人都严重低估了这点：用户越多、系统越复杂，这套协作模式能释放的价值会成倍放大。

实际上，我认为林纳斯最聪明、影响也最深远的一招，不是编写了 Linux 内核，而是他创造出的 Linux 开发模式。有一回我当面和他聊起这个看法，他只是笑着轻声复述了那句口头禅："我本质上是个非常懒惰的人，喜欢靠别人实际做的活儿来获得声誉。"这真是像狐狸一般狡猾的"懒惰"啊，正如罗伯特·海因莱因（Robert Heinlein）笔下人物的经典描述：懒到无可失败。

回想起来，GNU Emacs Lisp 函数库与 Lisp 代码仓库的发展，早已为 Linux 的这套开发思路与成功提供了先例。Emacs 的 C 语言内核和多数 GNU 工具都采用大教堂式开发，而 Lisp 代码库迭代灵活，全程以用户为主导。各类创意与功能原型，往往要反复改写三四轮，才能打磨出稳定版本。当时互联网上已经普遍流行这种和 Linux 相仿的松耦合协作方式。

在开发 fetchmail 之前，我做得最成功的个人项目或许是 Emacs VC（版本控制）模式。当年我和另外三位开发者依靠邮件远程协作，模式和 Linux 十分相似；四人之中，直到今天我只见过理查德・斯托曼（Richard Stallman，Emacs 的作者及自由软件基金会（http://www.fsf.org）的创始人）。VC 模式是 Emacs 内部为 SCCS、RCS 以及后来的 CVS 提供的前端界面，支持一键式版本管理操作，它脱胎于他人写的一段简短简陋的 sccs.el 脚本。VC 的开发之所以成功，是因为与 Emacs 本身不同，Emacs Lisp 代码能够快速走完发布/测试/优化整套流程。

Emacs 的故事并不独一无二。不少软件都会搭建双层架构、两级用户社群，内核采用大教堂开发模式，配套工具集则走集市模式，MATLAB 这款商用数据分析可视化软件就是典型。使用这类分层软件的用户都有同一个感受：项目里最有活力、创意迸发、持续产出新功能的地方，永远是对外开放的工具模块，各式各样的社区开发者都能在这部分自由调试修改。

2.4 早发布，常发布

“早发布、常发布”是 Linux 开发模式的关键组成部分。在过去，大多数开发者（包括我）都认为，对于比玩具项目规模更大的项目而言，“早发布、常发布”听起来并不靠谱，因为早期版本按定义几乎就是有很多 bug 的版本，而你不想把用户的耐心耗光。

这种信念让人们更加倾向于大教堂式开发模式。如果首要目标是让用户尽量少遇到 bug，那你就会每隔六个月（或更久）才发布一个版本，并在发布间隔期间拼命 debug。Emacs 的 C 语言核心就是按照这种方式开发的，而 Lisp 库实际上并不这样——因为除了 FSF 控制的版本，还有活跃的 Lisp 代码仓库（archives），你可以不受 Emacs 发布周期的限制，自己去那里找到新代码和开发中的版本。²

其中最重要的一个是俄亥俄州立大学的 Emacs Lisp 代码仓库，它预示了当今大型 Linux 代码仓库的精神和许多特性。但我们中很少有人真正深入思考过我们在做什么，或者这个代码仓库的存在本身，是如何揭示 FSF 大教堂式开发模式的问题的。大约在 1992 年，我曾认真尝试将大量俄亥俄州大学的代码正式合并到官方的 Emacs Lisp 库中。我遇到了人事上的阻力，这件事最后基本没成。

但一年后，Linux 变得广为人知。很明显，那里正在发生一些不一样的事，而且健康得多。林纳斯的开放式开发政策与大教堂式开发截然相反。网上的 Linux 代码仓库越来越多，多个发行版不断涌现。而所有这一切，都是由前所未有的核心系统频繁发布所驱动的。

林纳斯用一种最有效的方式，把他的用户当成协作开发者：

早发布，常发布。倾听你的客户。

林纳斯的创新，与其说是快速迭代发布、吸纳大量用户反馈（这种做法在 Unix 社区已有很长时间的传统），不如说在于将这种模式扩展到与所开发系统的复杂性相匹配的强度。在早期（大约 1991 年），也不是没听过他一天发布好几次新内核！正是因为他比任何人都积极地培养他的协作开发者，并用互联网进行协作，才取得了成功。

但这究竟是怎么运作的呢？这是我可以复制的吗？还是说它依赖于林纳斯·托瓦兹某种独特的才华？

我不这么认为。当然，林纳斯是一位非常优秀的黑客。我们这些黑客当中有多少人能从头构建出一个完整、产品级的操作系统内核？但 Linux 并不代表任何令人敬畏的概念性飞跃。林纳斯并不是（或者至少目前还不是）像理查德·斯托曼或詹姆斯·高斯林（James Gosling，开发了 NeWS 和 Java）那样的设计创新天才。在我看来，林纳斯更像是一位工程和实现方面的天才，他对避免 bug 和开发死胡同有着第六感，并且真正擅长找到从 A 点到 B 付出最少努力的路径。事实上，Linux 的整个设计都散发着这种品质，并反映了林纳斯本质上保守和简化的设计方法。

那么，如果说快速发布和充分利用互联网媒介并不是偶然，而是林纳斯的工程天赋洞察到“付出最少努力路径”的组成部分，那么他当时到底在最大化什么？他从这套机制里榨出了什么？

这样提问，答案就很明显了。林纳斯是在不断地刺激和奖励他的黑客兼用户——通过让他们参与其中、获得自我满足感的前景来刺激，通过看到他们的工作不断（甚至每天）改进来奖励。

林纳斯的直接目标是最大化投入到 debug 和开发上的总工时，即使这可能以代码不稳定、遇到棘手的严重 bug 而损失用户基础为代价。林纳斯的行为表明他相信类似这样的道理：

8. 只要有足够多的测试者和协作开发者，几乎所有问题都能被快速定性，并且对有些人来说，修复方案显而易见。

或者换个更不正式的说法：“眼睛够多，bug 不躲。” 我管它叫“林纳斯定律”。

我最初的表述是每个问题“对某人来说是一目了然的”。林纳斯不同意，认为理解和修复问题的人不一定是（甚至通常不是）最先发现问题的人。“有人发现问题，”他说，“然后其他人理解问题。而且我敢这么说，发现问题才更难。” 这个修正很重要；我们将在下一节更详细地考察 debug 实践时看到这一点。但关键点是，过程的两个部分（发现和修复）都倾向于很快发生。

我认为，林纳斯定律正是大教堂模式和集市模式之间核心差异的基础。大教堂模式认为，bug 和开发过程中的问题是棘手的、难以察觉的、深层次的现象。需要少数专注的人花好几个月审查，才能有信心说已经搞定了所有问题。因此，发布的间隔很漫长，而当大家期待已久的版本发布后并不完美时，就难免让人失望。

另一方面，在集市模式看来，你假定 bug 通常是浅显的现象——或者至少，当成千上万个热切的协作开发者上手折腾每个新版本时，这些 bug 就会很快变得浅显。因此，你频繁发布，获得更多的修正，而好处是，即使偶尔有翻车的版本流出，你的损失也不大。

就这么简单。这就足够了。如果“林纳斯定律”是假的，那么像 Linux 内核这样复杂的系统，被这么多开发者修改过，应该在某个时刻因为无法预见的恶性交互和还没发现的深层 bug 的重压而崩溃。另一方面，如果它是真的，那它就足以解释 Linux 为什么 bug 相对较少，并且能持续运行数月甚至数年。

话说回来，这也许本不该如此令人惊讶。社会学家多年前就发现，一群同样专业（或同样外行）的观察者，他们的平均意见作为预测，可靠性远比随机挑选的单个观察者的意见要高，他们管这叫德尔菲效应（Delphi effect）^a。看起来，林纳斯所展示的是，这甚至适用于 debug 操作系统——即德尔菲效应能够在操作系统内核的复杂度层面上驾驭开发复杂性。³

Linux 情况中一个明显有助于德尔菲效应的特殊之处在于，任何给定项目的贡献者都是自我筛选的。一位早期回应者指出，收到的贡献并非来自随机样本，而是来自那些对软件足够感兴趣的人，他们会使用软件，了解其工作原理，尝试找到自己遇到问题的解决方案，并实际产生一个看似合理的修复。任何通过这些筛选的人，极有可能贡献出有价值的东西。

林纳斯定律换句话说就是“Debug 是可并行化的”。尽管 debug 需要开发者与某位协调者沟通，但它并不要求 debug 的人之间进行大量协调。因此，它不会陷入增加开发复杂度的二次复杂度和管理成本困境。

在实践中，debug 的人重复工作所导致的效率损失——虽然理论上存在——在 Linux 社区中似乎从来都不是问题。“早发布、常发布”策略的一个效果就是通过快速传播反馈的修复来最小化这种重复。⁴

布鲁克斯（《人月神话》（The Mythical Man-Month）的作者）甚至对杰夫^b的观点做了一个即兴评论：“维护一个广泛使用的程序的总成本通常是其开发成本的 40% 或更多。令人惊讶的是，这个成本受用户数量影响很大。更多的用户发现更多的 bug。”[强调为作者所加]

更多的用户会发现更多的 bug，因为增加用户，就增加了更多的方式对程序进行压力测试。当这些用户同时也是协作开发者时，这种效应会被放大。每个人都会以略微不同的感知方式、不同的分析工具集，从不同的角度来处理 bug 定位，德尔菲效应似乎正是由于这种差异性而生效。在 debug 的特定背景下，这种差异性也倾向于减少重复工作。

因此，增加更多测试 Beta 版本^c的用户可能不会降低开发者眼中当前“深层” bug 的复杂性，但它增加了一些人恰好适配该问题的工具集，让这个 bug 对那个人来说变得浅显。

林纳斯也做好了风险对冲。为了防止出现严重 bug，Linux 的内核版本采用特定的编号方式，让潜在用户可以选择最新的稳定版本，或者冒引入 bug 的风险选择最新的实验版本。大多数 Linux 黑客还没有系统性地模仿这种策略，但也许他们应该效仿；因为两种选择都存在，这让两者都更有吸引力。⁵

2.5 足够多的眼睛，就能驯服复杂性

从宏观上说，集市模式能极大加速调试和代码迭代，这好理解。但要准确说清它在开发者、测试者日常行为的微观层面是怎么起作用的、为什么起作用，就是另一码事了。 在本节（写于原论文三年后，参考了许多开发者重读论文、审视自身行为后得出的见解）中，我们将深入考察它实际的机制。没有技术背景的读者大可放心跳到下一节。

要理解这一点，关键是想通一个问题：不懂源码的用户，他们提交的 bug 报告为什么往往没多大用？这类用户通常只报告表面症状，因为他们把自己的环境当作理所当然。于是：（a）会漏掉关键的背景信息；（b）很少能给出一个靠谱的、能重现 bug 的步骤。

这背后的根本问题是，测试者和开发者对程序的心智模型不匹配。测试者是站在外面往里看，开发者则是站在里面往外看。在闭源开发里，双方都被困在自己的角色里，常常鸡同鸭讲，都觉得对方简直不可理喻。

开源开发打破了这种僵局，让测试者和开发者容易得多地建立起一套基于实际源码的“共同语言”，并在此基础上有效沟通。实际上，对开发者来说，一份只描述表面症状的 bug 报告，跟一份能直接对上他基于源码构建的心智模型的报告，利用价值有很大的差别。

大多数时候，绝大多数 bug，只要有人在源码层面给出一个哪怕不完整、但有启发性的描述，就很容易被揪出来。比如，当你的某个测试者能够指出“第 nnn 行有个边界问题”，或者哪怕只是说“在 X、Y、Z 条件下，这个变量的值会溢出”，那么通常瞟一眼出问题的代码，就足以锁定具体的出错模式并给出修复了。

所以说，双方都能看懂源码，这既能大大改善沟通，也能让测试者提交的报告和核心开发者掌握的知识形成强大的合力。这样一来，即便有很多人参与协作，这种合力也能很好地节省核心开发者的时间。

开源模式还有一个能节省开发者时间的特点，体现在它独特的沟通架构上。前面我用过“核心开发者”这个词，它反映了一种区分：一边是项目核心，通常非常小，一般是一个人，典型情况也就 1-3 人；另一边是项目外围，由测试者和潜在贡献者组成，这个圈子常常有几百上千个人。

传统软件开发组织面对的那个根本难题，就是布鲁克斯定律：“向已经延期的项目里加人，只会让它更延期。”更宽泛地讲，这条定律预言，项目的复杂度和沟通成本会随开发者人数呈平方级增长，而干完的活儿只会呈线性增长。

布鲁克斯定律的基础，是这样一条经验：bug 总爱扎堆出现在不同人写的代码的衔接处；而项目的沟通协调开销，又往往随人际接口的增多而增加。这样一来，问题规模就随开发者之间沟通路径的数量一起涨，而沟通路径的数量正是开发者人数的平方（更精确地说，公式是 N * (N – 1) / 2，其中 N 是开发者人数）。

布鲁克斯定律的分析，以及由此产生的对大团队恐惧，其实都基于一个隐含的前提：项目的沟通结构必定是个“完全图”，也就是人人都和其他所有人直接沟通。但在开源项目里，外围开发者干的活儿实际上是互不干扰、可并行的子任务，他们彼此很少打交道。代码变更和 bug 报告都流向核心小组，只有在这个小小的核心圈里，我们才需要付出完整的布鲁克斯式开销。⁶

源码级 bug 报告之所以往往这么高效，还有其他原因。这主要围绕一个事实：一个 bug，往往能表现出多种不同的症状，具体表现取决于用户的使用习惯和环境细节。 这类 bug 恰好就是那种最复杂、最微妙的（比如动态内存管理的 bug，或者中断窗口带来的随机异常），最难靠随机重现或者静态分析锁定，也最容易给软件造成长期隐患。

如果测试者能为这种多症状的 bug 提交一份试探性的源码级特征描述（比如“在我看来，信号处理代码第 1250 行附近存在一处时序窗口问题”，或者“你那缓冲区是在哪儿清零的？”），这或许就能给开发者一个关键线索——要不然，开发者可能离代码太近，反而“当局者迷”。这一条线索，也许就能解释五六种看似八竿子打不着的症状。这种情况下，也许很难甚至不可能分清哪个表面故障是由哪个具体的 bug 引起的——但因为软件版本发布频繁，这根本不重要。其他协作者很快就能知道他们遇到的 bug 有没有修复。很多时候，源码级的 bug 报告会让一些故障悄无声息地消失，甚至从来没定位到某个具体的修复上。

复杂的多症状错误，从表面症状追溯到真正 bug 的路径也往往有好几条。 某位开发者或测试者能追踪到哪条路径，这取决于他自身环境中一些微妙的细节，而且这种关联还可能随时间以一种不是那么确定的方式变化。实际上，每个开发者和测试者在排查 bug 根源的时候，都像是在程序的状态空间里进行半随机的抽样。Bug 越微妙、越复杂，个人技能就越难保证他抽到的那份样本管用。

所以，对于简单且好复现的 bug，重点落在“半”上，而不是“随机”上；此时调试技巧和对代码及架构的熟悉度就至关重要。然而对于复杂的 bug，重点就落在“随机”上了。这种情况下，许多人同时跑追踪，效率远比少数几个高手一个个地接力追踪要高——哪怕那几个高手的平均技能水平高得多。

如果从不同表面症状追溯到同一个 bug 的各条路径，它们的难度差异巨大，而且这种差异无法从表面症状判断出来，那么上述并行追踪的效果就会被极大地放大。如果一个开发者自己一条条地试这些路径，他第一次就撞上一条高难度路径的几率，和撞上简单路径的几率差不多。反过来，假如很多人一边并行尝试，一边快速发布新版本，那很可能其中一个人会立刻发现那条最容易的路径，然后用更短的时间就把 bug 给揪出来。项目维护者会看到这个修复，发布新版本，而其他正在追同一个 bug 的人就能适时停手，不必在难度更高的追踪路径上耗费过多精力。⁷

2.6 玫瑰何时不是玫瑰^a？

研究了林纳斯的习惯，并琢磨出他成功的原因、总结出自己的理论之后，我有意识地在新项目（当然，这个项目远不如他的复杂和宏大）上检验这一理论。

但我做的第一件事，是大幅度地重组和简化 popclient。卡尔·哈里斯的实现非常稳健，但也有许多 C 程序员常见的那种不必要的复杂度。他把代码当作核心，而把数据结构当作代码的辅助。结果代码很优美，但数据结构的设计却很随意、相当丑陋（至少以我这位资深 LISP 黑客的高标准来看是这样的）。

然而，我重写的另一个目的，不只是为了改进代码和数据结构设计，更是为了把它变成我能完全理解的东西。负责修复一个你不理解的程序的 bug，可没什么乐趣可言。

因此，在头一个月左右的时间里，我基本上只是顺着卡尔基础设计的思路把它做下去。我做的第一个重大改动是增加对 IMAP 的支持。我通过将协议处理机重组成 1 个通用驱动器和 3 个方法表（分别对应 POP2、POP3 和 IMAP）来实现这一点。这次改动以及之前的改动，都说明了一条程序员（尤其是使用 C 这类不原生支持动态类型的语言^b的程序员）值得牢记的通用原则：

9. 高明的数据结构和笨拙的代码，比反过来的组合效果要好得多。

布鲁克斯在《人月神话》第 9 章中写道：“给我看你的流程图，却隐藏你的表，我依然会感到困惑。给我看你的表，我通常就不需要你的流程图了；它会显而易见。”考虑到 30 年来的术语/文化变迁，他表达的是同一个要点。

就在这时（1996 年 9 月上旬，从零开始大约 6 周后），我开始考虑或许应该改个名字——毕竟，它已经不仅仅是一个 POP 客户端了。但我犹豫了，因为设计中还没什么真正新颖的东西。我的 popclient 版本还没有发展出自己的特色。

等到 popclient 学会把取来的邮件转发到 SMTP 端口，情况就彻底不一样了。这事儿我一会儿再细说，先回到前面提过的一点：我说过，我决定用这个项目来检验一个理论——关于林纳斯·托瓦兹到底做对了什么。你多半会问，我怎么检验呢？具体是这么做的：

• 做到了早发布、常发布（几乎从不低于每 10 天一次；在密集开发期间，甚至达到每天一次）。

• 不断扩大测试名单，把所有和我联系过 fetchmail 相关事项的人都加了进去。

• 每次发布时，都会向测试名单发送闲聊般的公告，鼓励大家参与。

• 倾听测试者的意见，就设计决策征求他们的看法，并且在每次收到补丁和反馈时，都会给他们一点甜头。

这些简单的措施带来了立竿见影的效果。项目一开始，我就收到了质量高到大多数开发者都求之不得的 bug 报告，而且常常附带好的修复方案。我收到了有见地的批评、粉丝邮件和有洞见的功能建议。这引出了：

10.如果你把测试者当作最宝贵的资源，他们就会真的成为你最宝贵的资源。

要衡量 fetchmail 有多成功，一个很有意思的角度是项目测试邮件列表 fetchmail-friends 的庞大规模。到本文最近一次修订的时候（2000 年 11 月），它拥有 287 名成员，并且以每周增加 2 到 3 人的速度增长。

实际上，在 1997 年 5 月下旬修订时，我发现名单从接近 300 人的高点开始出现成员流失，其中的原因耐人寻味。有几个人要求我取消订阅，因为 fetchmail 对他们来说运行得太好了，以至于他们不再需要查看列表流量！这也许正是一个成熟的集市模式项目，在它正常生命周期中都会遇到的事情吧。

2.7 Popclient 蜕变为 Fetchmail

这个项目真正的转折点，是哈里·霍赫海瑟（Harry Hochheiser）给我发了一段把邮件转发到客户端主机的 SMTP 端口的 demo 代码。我瞬间就反应过来：只要把这个功能稳定实现好，现有的其他所有邮件投递方式基本都可以淘汰了。

在过去的好几周，我一直在小幅迭代优化 fetchmail，虽然它的交互界面勉强能用，但设计却很粗糙：设计一点都不优雅，大量可有可无的零散参数到处堆砌。其中两项配置最让我心里别扭——一是将拉取到的邮件存入本地邮箱文件，二是直接输出到标准输出流，但我却说不上来问题到底出在哪。

（如果你对互联网邮件的技术细节不感兴趣，可以放心跳过下面两段。）

仔细琢磨 SMTP 转发这套方案后我才发现，popclient 之前承担的职责实在太多了。它最初的设计一身二用，同时充当邮件传输代理（MTA）与本地投递代理（MDA）。有了 SMTP 转发功能，它就能彻底和 MDA 相关逻辑解耦，只做纯粹的 MTA，像 sendmail 那样把本地投递工作转交其他程序处理。

几乎所有支持 TCP/IP 的系统都会默认开放 25 端口，既然如此，何必费心折腾复杂的 MDA 配置，还要给邮箱文件做锁机制、处理追加写入逻辑？更重要的是，采用这种转发方式后，拉取到的邮件格式会和普通发件方主动推送的 SMTP 邮件完全一致，这也正是我们想要的效果。

（拔高一层视角来看……）

就算前面一堆技术术语你没完全看懂，这里也有几点重要心得。先说第一点：主动借鉴林纳斯的开发思路，给我带来的最大收获就是这套 SMTP 转发方案。有位用户给了我这个很棒的点子，我只需要理清这套方案背后的深层逻辑就行。

11.自己想出好点子固然厉害，但发掘用户提出的好思路同样重要。很多时候后者反而更可贵。

你很快会发现一件有意思的事：只要你坦荡承认成果离不开他人帮助，他们反倒会认为所有的创新全是你自己摸索出来的，只会觉得你天资出众，只是分寸得当、低调谦逊。林纳斯就是最好的例子，这套做法在他身上非常有效！

（1997 年 8 月，我在第一届 Perl 大会做分享，大牛黑客拉里・沃尔就坐在第一排。等我讲到上面那段收尾的话时，他学着布道大会那种激昂的腔调高声喊：“说得好，就该这么讲，兄弟！” 台下所有人哄堂大笑，大家都清楚，这套处世之道在 Perl 之父身上同样行得通。）

我抱着同样的心态维护这个项目几周后，就收到了源源不断的夸赞，不光来自项目用户，不少听说过这件事的圈外人也纷纷发来好评。我留了一部分这类邮件；要是哪天我怀疑自己做的一切是否有意义，就翻出来看一看 :-)。

但这里还有两条更核心、无关派系立场的经验，适用于所有类型的设计工作。

12.很多时候，最亮眼、最有突破性的方案，都源于意识到自己最初对问题的认知从根上就错了。

我之前一直搞错了解决方向，持续迭代 popclient，让它同时做 MTA 和 MDA，还堆了一堆别扭的本地投递逻辑。Fetchmail 的设计必须彻底推倒重来，只做纯粹的 MTA，融入互联网标准 SMTP 邮件流转链路。

如果你在开发过程中陷入瓶颈，怎么都想不出下一版补丁方案，不必纠结解法对错，而要反思自己提出的问题本身对不对，你或许需要重新定义问题。

好吧，我重新定义了我的问题。显然，正确的方案是：(1) 把 SMTP 转发支持塞到通用驱动里；(2) 将这个模式设置成默认模式；(3) 最终移除其它所有的投递模式，包括投递到文件、投递到标准输出两类选项。

我对第三步纠结了很久，生怕得罪那些依赖原有投递方式的老 popclient 用户。理论上，他们完全可以用 .forward 文件或是其他 sendmail 同类工具实现同样的效果，但在实际的切换过程中大概率会出各种状况。

可真正删掉这些逻辑后，收益远超预期。驱动层里那些最陈旧、最杂乱的祖传代码直接消失了，配置也大幅简化——再也不用窝囊地去翻找系统 MDA、定位用户邮箱，也不必操心底层系统是否支持文件锁。

除此之外，唯一会导致邮件丢失的场景也彻底消失了。原来如果指定投递至本地文件，一旦磁盘写满，邮件就会直接丢失；改用 SMTP 转发后就不会出现这种问题：SMTP 接收端只有确认邮件可成功投递、或至少能存入队列暂存待发的时候，才会返回 OK。

除此之外程序性能也有所提升，只是单次执行很难感知到差别。这次改造还有一个不小的好处：工具手册页精简了非常多。

后来为了适配动态 SLIP 这类少见的特殊场景，我不得不重新加回“由用户指定本地 MDA 投递”的功能，不过这次我找到了简洁得多的实现方案。

这件事给我们什么启示？只要不会削弱程序功能，该舍弃过时的功能时就别犹豫。安托万・德・圣-埃克苏佩里（Antoine de SaintExupéry，这位除了写下经典儿童文学，同时也是飞行员、飞机设计师）曾说过：

13.“（设计的）完美，不在于无物可增，而在于无可再减。”

当代码质量稳步提升、同时逻辑也更加简洁时，就说明你的设计走对路了。也正是在这样一番改造后，fetchmail 形成了独属于自己的设计定位，和前身 popclient 彻底区分开来。

是时候更换项目名称了。全新架构相比旧版 popclient，和 sendmail 更像是一对互补工具：二者同属邮件传输代理 MTA，sendmail 向外推送邮件再完成投递，而重构后的工具则先拉取邮件再投递。项目启动 2 个月后，我就把它重命名为 fetchmail。

从 fetchmail 新增 SMTP 投递功能这件事里，还能总结出一条普适经验：不光程序调试可以并行，开发工作，甚至各类方案探索也都可以并行推进。如果你的开发模式以快速迭代为主，新增功能、优化拓展都可以当作调试的特殊形式：修补软件最初的功能规划、核心思路里存在的 “设计疏漏 bug”。

即便上升到顶层设计层面，多名协作开发者围绕产品，在设计空间里自由发散尝试，价值也格外突出。不妨观察积水自动流向排水口，或是蚂蚁觅食的过程：先依靠扩散式的方式全域探索，再依托一套可扩展的信息传递机制，集中利用已经发现的有效路径。这套模式非常有用，就像当初哈里·霍赫海瑟给我提供思路那样，团队里的前哨成员很可能发现一处价值巨大的优化方向，而你因为过度聚焦手头工作反倒视而不见。

2.8 Fetchmail 长大了

那时我手头有一套精巧新颖的设计，一套我每天使用、运行稳定的代码，Beta 测试用户群体还在持续扩张。我慢慢意识到，我做的早已不再是那种碰巧能给极少数人派上用场、无足轻重的个人项目。我手里的程序是每个有 Unix 机器和 SLIP/PPP 邮件链路的黑客都真正需要的。

有了 SMTP 转发功能，它就大幅领先一众竞品，有望成为一款“品类杀手”。这种经典的程序能完美契合自身的细分定位，好用到同类替代方案不仅会被弃用，甚至几乎被人遗忘。

我认为你没法单纯以这样的结果作为目标、提前规划出来。你只会被强有力的设计理念牵引，事后回望，这份成果看起来理所应当、浑然天成，甚至像是早已注定。想要追求这类设计思路只有两种方式：积累丰富的创意；具备工程判断力，能把别人的优秀构想拓展到原创者预想之外的高度。

安德鲁・塔能鲍姆（Andy Tanenbaum）最初的想法是为 IBM PC 构建一套简易原生 Unix，用作教学工具（他把它命名为 Minix）。林纳斯・托瓦兹把 Minix 的理念推进到安德鲁或许不曾预想的地步，最终发展成了不起的成果。同理（尽管规模更小），我吸收了卡尔・哈里斯、哈里・霍赫海瑟的部分思路并大力拓展。我们二人都算不上大众认知里那种理想化的原创性天才形象，但说到底，大部分科学研究、工程实践与软件开发都并非依靠原创性天才完成，广为流传的黑客迷思恰恰与此相反。

尽管如此，结果依然令人兴奋不已——实际上，这正是每一位黑客毕生追求的成功！想要让 fetchmail 达到如今我所能预见的完善程度，那我就不能只为自己的需求写代码，还要兼容、支持圈子外其他用户所需的各类功能，同时维持程序简洁、稳定。

意识到这一点后，我新增的第一个、也是最关键的功能，就是多投递支持（multidrop support）：这个功能可以从存放多名用户全部邮件的公共邮箱抓取邮件，再将每一封邮件分发到对应的收件人。

我决定新增多投递支持，一部分原因是不少用户反复提出需求，但更主要的是，我认为这套功能会倒逼我完整处理各类地址场景，从而暴露单投递代码里潜藏的缺陷。事实也的确如此。把 RFC 822（http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt）^a地址解析逻辑做完善耗费了我大量时间，并非其中某一块逻辑难以实现，而是整套规则牵扯大量相互关联、繁琐细碎的细节。

但多投递地址处理事后证明也是一项绝佳的设计选择。理由如下：

14.任何工具都能完成预设场景下的工作，而一款真正出色的工具，还能适配各类你从未预想过的使用场景。

开启多投递模式的 fetchmail 有一个意料之外的用法：可以在网络连接的客户端侧管理邮件列表，列表管理与别名解析全都在本地客户端完成。也就是说，使用者通过 ISP 账号运营个人主机时，不必持续调取服务商的别名文件，就能自主管理邮件列表。

测试用户提出的另一项重要的改动需求，是增加 8 位 MIME（多用途互联网邮件扩展）兼容支持。实现这项功能相当简单，因为我一直有意识保证代码 8 位洁净——也就是不占用 ASCII 闲置的第 8 个比特位承载程序内部信息。我当初这么做并不是因为预料到用户会需要该功能，而是恪守另一条准则：

15.开发任何网关类软件时，务必尽量减少对原始数据流的改动——除非接收端硬性要求，否则绝不丢弃任何数据！

如果我当初没有遵循这条准则，实现 8 位 MIME 兼容将会十分棘手，还很容易产生漏洞。实际情况却是，我只需研读 MIME 规范文档 RFC 1652（http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt）^b，再新增一小段生成头部的逻辑即可。

不少欧洲用户反复要求我增加参数选项，限制单次会话拉取的邮件总量，以此控制拨号网络产生的高昂通信费用。这件事我一直都有些抵触，到现在我也不完全认同这种设计。可是如果你的软件面向全球的用户，就必须倾听使用者的需求——哪怕他们没有付费，这条准则也不会失效。

2.9 从 Fetchmail 学到的其他经验

在回到通用软件工程问题前，还有几个从 fetchmail 开发经验的具体经验值得思考。非技术背景的读者可以放心跳过本节。

rc（配置）文件的语法包含一些可选的“噪音”关键词，解析器会直接无视这些词。这些类英语语法的关键词，读起来比去掉修饰词后那种传统精简键值对舒服很多。

这个点子最早是我某天夜里随手试出来的，当时我发现 rc 文件里的配置写法，越来越像一套指令式微型语言。我也正是因此，把旧版 popclient 里的 server 关键字改成了 poll。

在我看来，如果这套微型指令语言写得更贴近日常英文，用起来门槛可能会更低。尽管我本人是“把它做成一种语言”设计学派的坚定拥护者（Emacs、HTML 和许多数据库引擎都是这一学派的典范），但我通常并不热衷于“类英语”语法。

长期以来程序员都偏爱精准、紧凑、不带一点冗余的控制语法。这是早年硬件条件有限时留下的习惯——当时算力、内存成本极高，解析逻辑必须做到极简、极省资源。而英语本身有近一半的冗余内容，在当时完全算不上合适的参考模板。

不过这并不是我平时不爱用类英语语法的真正理由，我在这里提到只是为了驳斥这套陈旧的思路。现在算力和内存成本已经压得很低，代码写得精简不该是唯一追求。放到现在，一套语法对人好不好用，远比省不省机器资源更关键。

但即便如此，我们也不能无脑追捧类自然语言语法，这里有两个实实在在的问题。第一是解析逻辑会变复杂，一旦复杂到一定程度，反而更容易出 bug，还会让用户看不懂配置。第二，强行让语言语法像英语，往往扭曲原本的语句逻辑，看起来贴近自然语言，实际读起来和传统的精简语法一样绕。很多所谓第四代语言、商用数据库查询语言，都存在这个明显缺陷。

fetchmail 的配置语法刚好避开了上面这些坑，因为它能描述的场景范围十分有限。它根本算不上通用编程语言，能表达的逻辑本身就不复杂，使用者在简易英文短句和配置语法之间切换思路时，基本不会产生混淆。我从中总结出一条适用范围更广的经验：

16.如果你的语言和图灵完备性（Turingcomplete）不沾边，语法糖可以是你的朋友^a。

还有一条经验，是关于“靠隐蔽实现安全”的误区的。不少 fetchmail 用户希望我改动程序，把密码加密后存进 rc 配置文件，防止别人随便就能看到密码。

我没有实现这个功能，因为这么做起不到真正的防护作用。只要对方有权限读取你的 rc 文件，就完全可以用你的身份执行 fetchmail；如果对方一心要窃取密码，直接从 fetchmail 源码里找到解密逻辑就能拿到明文。

给.fetchmailrc里的密码加密，只会让不深究底层逻辑的用户产生虚假的安全感。由此得出一条通用准则：：

17.一套安全体系的安全上限，由它的保密信息决定。警惕所有伪保密手段。

2.10 集市模式的必要前提

这篇文章的早期审阅者与试读读者，不断提出疑问：想要成功落地集市模式的开发，需要满足哪些必要前提？这些必要条件既包括项目负责人的个人能力，也包含项目开源、搭建协作开发社区那一刻的代码状态。

有一点毋庸置疑：集市模式无法从零起步开发项目。⁸ 测试、排错、迭代优化可以采用集市模式，但靠这套模式从零孵化新项目难如登天。林纳斯没有这么做，我同样没有。刚刚组建的开发者社区，必须手里有一份可运行、可测试的程序作为基础。

启动社区建设时，你需要能交出一份有说服力的愿景。程序本身不必完善，哪怕粗糙、漏洞百出、功能残缺、文档简陋都没关系。但有两点底线绝对不能破：第一，程序必须能正常运行；第二，要让潜在合作者相信，短期内这款程序可以迭代打磨成优质项目。

Linux 和 fetchmail 开源时，都具备扎实、亮眼的基础架构。不少研读这套集市开发模型的人，知道这点很重要，却得出另一个结论：项目负责人必须拥有极强的设计天赋与架构洞察力。

不过林纳斯的设计脱胎于 Unix，我最初的思路则源自老牌工具 popclient（只是后续改动幅度极大，相对整体体量来说，变更程度远超过 Linux）。那么采用集市开发模式的项目负责人、协调者，是不是非得拥有顶尖的设计天赋？还是说只需要善于吸纳别人的优秀设计思路，一样能把项目做好？

在我看来，协调者自己能不能构思出天才级别的完整设计其实无关紧要，但能辨别他人提出的优质设计方案，是必不可少的核心能力。

Linux 和 fetchmail 两个项目都印证了这个观点。前文也提到过，林纳斯本身算不上天马行空的原创设计者，可他非常擅长甄别出色的设计，并把这些方案整合进 Linux 内核。而我前面也讲过，fetchmail 里最核心、最出彩的设计，也就是 SMTP 转发，灵感完全来自别人。

这篇文章的早期读者曾评价说，我容易低估集市项目里设计原创性的重要性，原因是我自身原创设计能力充足，便觉得这份能力理所应当人人具备。这说法有几分道理；和编码、调试相比，设计确实是我最擅长的技能。

不过在软件设计上富有巧思和原创性会形成一种惯性：本该优先保证程序健壮简洁，却下意识把功能设计得花哨复杂。我曾经因为犯下这个失误搞砸过项目，但开发 fetchmail 时我规避了这个问题。

因此我认为 fetchmail 的成功，一部分是因为我克制住了一味追求精巧设计的倾向；这至少能证明，设计原创能力并非集市项目成功的核心要素。再看 Linux：假如林纳斯・托瓦兹当初开发时执意要在操作系统架构层面做出颠覆性创新，最终产出的内核还能像现在这样稳定、广受认可吗？

当然，开发者必须具备基础的设计与编码能力，但我觉得，但凡真心打算做集市模式开源项目的人，基本都能跨过这条最低门槛。开源社区里依靠声望形成的内在约束，会无形中提醒大家，不要贸然开启自己没能力长期维护的项目。这套机制到目前为止运行得十分顺畅。

还有一项能力，大家平时不会把它和软件开发绑定在一起，但对集市项目来说，它和设计天赋一样关键，甚至更为重要：集市项目的负责人、协调者必须擅长与人打交道，拥有出色的沟通能力。

这点其实很好理解。想要搭建起协作开发社区，你得吸引参与者、勾起他们对项目的兴趣，还要让大家愿意持续投入精力。亮眼的技术设计固然能吸引不少人，但这远远不够，你展现出的处事风格同样举足轻重。

林纳斯为人和善，能让人心生好感、愿意伸出援手，这绝非偶然。我自身精力充沛、性格外向，乐于协同众人协作，还自带一点单口喜剧演员的表达能力与临场直觉，这同样不是巧合。想要跑通集市开发模式，负责人哪怕只具备一点点笼络人心、凝聚他人的能力，都能事半功倍。

2.11 开源软件的社会化协作背景

经上记着说：那些最好的开源小工具，一开始都只是作者用来解决自身日常痛点的自用方案，后来广为流传，是因为大量用户都面临一模一样的问题。这刚好呼应第一条准则，换个更实用的说法总结就是：

18.想要攻克有价值的难题，先找一个你自己真正在意、感兴趣的问题。

卡尔・哈里斯最早写 popclient 是这样，我开发 fetchmail 也是同样的道理，不过这个道理早就有人说过。Linux 和 fetchmail 的发展史真正值得深挖、值得我们重点讨论的，是后面这个阶段：当软件拥有规模庞大、积极性高的用户与协作开发者社群后，项目会如何持续迭代演化。

弗雷德・布鲁克斯在《人月神话》里提出过一个观点：程序员的工时不能简单互相替代；给进度滞后的项目新增人手，只会拖慢整体工期。前文也提到过他的推导逻辑：项目复杂度、沟通开销会随开发者人数呈平方级上涨，但产出的工作量只线性增加。布鲁克斯定律长期以来都被当作行业铁律。但本文分析的开源开发模式，从多个层面推翻了这条定律成立的前提；而且现实摆在眼前，如果布鲁克斯定律适用于所有场景，Linux 根本不可能发展到如今的规模。

如今回头看杰拉尔德・温伯格（Gerald Weinberg）的经典著作《程序开发心理学》（The Psychology of Computer Programming），恰好给布鲁克斯的理论补上了关键修正。书中在讲“无我编程”时提到一种现象：如果团队里开发者不把代码当成自己的专属地盘，主动欢迎别人找漏洞、提优化思路，项目迭代改进的速度会远远超过其他团队。（近些年肯特・贝克（Kent Beck）提出的极限编程，让程序员结对编程、互相审阅代码，本质就是刻意复刻这种效果。）

温伯格起的这个术语，或许让他的观点没能收获本该有的认可——光是把互联网开源开发者形容成 “无我”，就让人觉得好笑。但放到现在，他这套理论的说服力比以往任何时候都强。

集市模式充分发挥无我编程带来的增益，大幅削弱布鲁克斯定律的负面影响。布鲁克斯定律的底层规律并未失效，可当开发者规模庞大、沟通成本低廉时，一些原本不显著的正向非线性效应会盖过它的弊端。这好比牛顿物理与爱因斯坦物理的关系：经典体系在低能量场景下依旧成立，可当质量、规模提升到一定程度，就会产生核爆炸、Linux 这种超乎预料的结果。

其实回看 Unix 的发展历史，我们本该早就预料到 Linux 的这套发展规律（我自己也照搬过林纳斯的开发思路，在小规模项目里实操验证过这套逻辑⁹）。说白了：写代码这件事，本质上依旧是单打独斗的工作，但那些真正亮眼、出彩的项目，靠的是聚拢整个社群的注意力和集体脑力。闭门造车、只靠自己动脑开发的人，迟早会被甩开差距；真正厉害的开发者，会搭建开放、可迭代的协作环境，让成百上千、甚至上万的开发者一起打磨：扩充设计思路、提交代码、排查 bug、迭代优化。

但早年的 Unix 生态受好几项条件限制，没法把这套玩法做到极致。一是各类开源许可证、商业保密条款、商业利益带来的法律约束；二是事后回看，当年互联网基础条件太差。

在低成本互联网普及之前，只有少数地理位置集中的技术圈子，内部风气推崇温伯格的无我编程。开发者随手就能招来一大批资深同行一起协作、评审代码。贝尔实验室、麻省理工 AI 实验室、计算机实验室、伯克利分校，都是这类圈子，诞生了大量经典技术，时至今日依旧影响力十足。

Linux 是历史上第一个主动放眼全球、把全世界当作人才池，并且做成了的开源项目。Linux 的孕育阶段刚好撞上万维网诞生，它在 1993—1994 年走出初创期，与运营商（ISP）行业起飞、互联网彻底走入大众视野同处一个时期，这并不是偶然。全网普及带来了全新协作规则，而林纳斯是第一个吃透这套新规则的人。

便宜的互联网，是 Linux 这套开发模式能够成型的必要条件，但光有网络远远不够。还有一个至关重要的要素：配套的项目管理风格、协作规范。依靠这套规则，项目负责人才能聚拢开发者，最大化发挥互联网协作的价值。

那么这套管理风格、协作规范究竟是什么？首先它绝对不能依靠权力层级管控；就算强行靠权力施压管理，也绝对做不出 Linux 如今的成果。

针对这一问题，温伯格引用了 19 世纪俄国无政府主义者彼得・克鲁泡特金（Pyotr Alexeyvich Kropotkin）的自传《一个革命者的回忆录》（Memoirs of a Revolutionist），里面的观点恰好能精准解释这个议题：

我出身于农奴主家庭，和当年所有年轻人一样，刚踏入社会时深信管理就得靠指挥、下指令、训斥、惩罚这一套。但早年我负责大型事务、和【自由】民众共事，任何一点失误都会立刻引发严重后果，这时我才看清两种管理逻辑的天差地别：一种靠命令与纪律管控，另一种靠彼此共识协作。命令那套在阅兵场上固然好用，放到真实事务里却完全行不通；真正要做成事，得靠无数人同心协力、付出大量心血。

Linux 这类项目，恰恰就需要上文所说的 “众人同心合力深耕一件事”；而互联网这个自由开放的环境里，参与者全是自愿贡献的开发者，根本没法靠 “下达命令” 这套模式管理。想把协作项目做好、具备竞争力，牵头的开发者就得学着按照克鲁泡特金所说的 “共识原则”，聚拢同好、调动整个社群的积极性，也就是活用林纳斯定律。¹⁰

前面我用德尔斐效应简单解释过林纳斯定律，但拿生物、经济学里的自适应系统来类比，会更贴切。Linux 社区很多地方都和自由市场、自然生态十分相似：每个参与者都优先追求自身收益，可在这个过程中，会自发形成一套自我修正的有序体系，它的完备度与效率，远不是顶层统一规划能比得上的。而克鲁泡特金所说的 “共识原则”，答案就藏在这套机制里。

Linux 开发者追求最大化的 “效用函数”，并非传统经济学里的金钱收益，而是看不见的精神满足，以及在同行圈子里积攒的声望。有人会把这种动机称作 “利他”，但忽略了一点：对付出者而言，利他本身也是一种自我价值满足。依靠这套逻辑运转的志愿社群其实并不少见，我自己长期参与的科幻爱好者圈子就是很好的例子。和黑客社群不同，科幻圈很早就直白点明了 egoboo（简单理解就是刷圈内声望、收获他人认可），并将其视作所有人无偿产出内容、参与志愿运营的核心驱动力。

林纳斯把自己放在项目守门人的位置，绝大部分开发工作交由社区完成，同时持续维持项目热度，直到项目能自主运转，这套做法精准践行了克鲁泡特金所说的 “共识协作原则”。用这套近似经济学的视角看待 Linux 社区，我们就能看懂这份共识是如何落地的。

我们可以把林纳斯的这套玩法，理解成搭建了一个高效的 “egoboo 市场”：把每位开发者自我实现的诉求，和只能靠长期协作才能攻克的复杂目标牢牢绑定。我在 fetchmail 项目里已经验证，这套模式完全可以复刻，效果同样不错，只是规模小很多；甚至相比林纳斯，我实施这套思路时目标更清晰、流程更体系化。

不少人（尤其是本身不看好自由市场机制的人）会觉得，一群只在乎自身声望、自主行动、以自我为中心的人凑在一起，圈子必然四分五裂、各自划地盘、重复造轮子、藏私还互相敌视。但只要看一件事就能推翻这个猜想：Linux 配套文档种类之丰富、质量之高、内容之详实，完全超乎想象。

业内谁都清楚，程序员普遍讨厌写文档，那为什么 Linux 社区能产出海量完善文档？答案很明显：这套以声望（egoboo）为核心的自由激励机制，催生出大量利他、正向的贡献行为，效果远胜过财大气粗的商业公司专职文档团队。

fetchmail 和 Linux 内核两个项目都证明了一件事：项目带头人只要能妥善给其他开发者提供声望认可，就能借助互联网吸纳大量协作开发者，享受多人协作带来的红利，同时不让项目彻底乱成一锅粥。针对布鲁克斯定律，我提出一条对立的核心结论：

19.只要项目协调者拥有互联网这种高效沟通渠道，并且擅长用非强制手段统筹团队，那么聚集众人智慧的效果，必然远比单打独斗好。

我相信开源软件的未来，会越来越偏向吃透林纳斯这套协作玩法的人，也就是放下大教堂式封闭开发思路、拥抱集市模式的人。这并不是说个人独到的视野与过人天赋就不再重要；恰恰相反，未来开源领域的前沿创新者，一定是先靠一己之力拿出亮眼构想，再搭建起自愿参与的同好社群，把这份创意的价值无限放大。

这套趋势或许不只适用于开源软件，任何闭源厂商，都不可能调动起像 Linux 社区这般规模的人才力量来攻克同一个难题。就拿 fetchmail 举例，前后贡献代码的开发者峰值达到 800 人（早期 200 人，1999 年 600 人，2000 年 800 人），几乎没有哪家公司承担得起全额雇佣这么多人的成本。

到最后，开源生态之所以会占据优势，根源未必是 “协作在道德上更高尚”，也不是 “私有闭源囤积代码本身就是错的”（我和林纳斯都不认同这套道德评判逻辑）；单纯只是在长期的演化竞争中闭源阵营注定落败——开源社区能投入到同一个问题上的资深开发者工时，比闭源厂商高出好几个数量级，完全不在一个量级。

2.12 论管理与马奇诺防线

1997 年《大教堂与集市》一文的结尾描绘了上述愿景——一群快乐的、互相联结的程序员/安那其主义者“乌合之众”，在竞争中击败并压制了体制森严的传统闭源软件行业。

不过很多质疑者并不认可这套说法，他们提出的问题值得好好讨论。反对集市模式的声音，大多都指向同一个观点：推崇集市模式的人，低估了传统管理对开发效率的提升效果。

思想传统的软件开发经理常会反对说，开源社区的协作小组组建、变动、解散都十分随性，这份不稳定性直接抵消了开源人手充足的优势。在他们看来，软件开发看重长久稳定的投入，以及客户对持续维护更新的稳定期待，而不是大家随便往锅里丢点骨头，就放任项目自己慢慢熬。

这种说法当然有合理的地方。我曾在“魔法锅炉”一文中详细论述过：用户所预期的长期后续维护服务价值，是软件生产经济学的关键。

但这套观点本身藏着一个关键漏洞：它默认开源项目没办法长期稳定投入维护。可现实里有不少开源项目，完全不靠传统企业必备的薪酬激励、层级管控体系，照样长年守住统一开发方向，维护社群稳定高效运转。GNU Emacs 编辑器就是一个很有说服力的极端例子，15 年间开发者来来去去、人员流动极大，全程只有作者一人始终持续跟进，却把好几百个贡献者的代码都整合进了统一完整的架构思路里。市面上没有任何一款闭源编辑器，能维持这么久的持续迭代生命周期。

这就给了我们独立于 “大教堂 vs 集市” 之争的全新视角，去重新审视传统管控式开发的优势。既然 Emacs 能连续 15 年坚守统一架构，Linux 系统也能在硬件、平台技术飞速迭代的八年间保持整体设计连贯；更何况大量架构完善的开源项目，稳定运营周期都超过 5 年，那我们不妨好好想一想，传统开发模式付出高昂的管理成本，到底换来了什么实实在在的收益？

传统管理模式换来的那些东西里，绝对不含按期交付、不超预算、完整落地需求文档全部功能这三样。企业管控项目能达成其中任意一项都算少见，三者同时达标更是几乎没有。它也没法让产品在开发周期内灵活适配技术、市场环境的变动，这一点开源社区的表现要好得多。举两个直观例子：互联网稳定发展 30 年，反观各类私有网络技术生命周期都很短；再看系统位数升级，当年 Windows 从 16 位转到 32 位付出巨大成本，同期 Linux 的升级迁移却几乎没什么阻力，不光适配全系列 Intel 芯片，还顺利移植到十多种硬件平台，64 位 Alpha 架构也包含在内。

不少人觉得传统闭源模式的一大优势是出问题能找到法人主体追责，甚至索要赔偿。但这只是空想。绝大多数软件许可协议都会直接免除商品适销担保，更不会承诺运行效果；真因为软件故障索赔成功的案例少到几乎找不到。就算索赔容易实现，一门心思指望出事去打官司也完全搞错重点。大家的核心诉求从来不是起诉厂商，而是拿到稳定可用的软件。

那这么高昂的管理成本，到底换来了什么？

想弄明白这个问题，得先搞清楚软件项目经理自认的核心价值。我认识一位业内做得很出色的项目管理者，她总结出项目管理一共承担的 5 项职责：

• 明确项目目标，保证所有人发力方向统一

• 全程跟进把控，避免关键细节出现遗漏

• 调动员工积极性，推动大家完成枯燥却必不可少的基础杂活

• 合理调配人手，最大化团队产出效率

• 统筹各类资源，保障项目能够持续推进

这些职责单看确实都很合理，可放到开源模式和对应的社群环境里，就显得没那么必要了。下面我们倒着逐条分析。

我那位做管理的朋友说，资源调配在很大程度上是一场防御性战役。你好不容易争取到人手、设备、办公场地，一边要设防抵御同级经理对这些资源的侧翼进攻，同时还要抵挡上层重新拆分有限资源池的压力。

但开源开发者都是自愿参与的，本身就因为感兴趣、有能力才主动加入项目，就算有人拿工资做开源开发，这个底层逻辑也没变。志愿协作的氛围直接解决了资源调配的“进攻”问题——大家自带电脑、网络等资源参与进来，完全不需要像传统管理者那样“打防守”。

况且现在电脑便宜、网络普及，真正稀缺的资源从来不是硬件，而是资深开发者投入的精力。开源项目很少会因为缺设备、缺网络、缺办公场地做不下去；只有开发者失去热情，项目才会彻底停滞。

既然是这个逻辑，那开源开发者靠自主筛选、自发组队来拉满整体效率这件事就格外关键 —— 整个社群环境会毫不留情地筛掉能力跟不上的人。我那位既熟悉开源、也操盘过大型闭源项目的朋友认为，开源能做成，一部分原因是这套生态只吸纳程序员群体里顶尖那 5% 的高手。而她日常绝大部分工作，就是管理剩下 95% 的普通开发人员，也亲眼印证了业内公认的现状：顶尖程序员和仅仅够用的普通开发者之间，产出效率能差上百倍。

如此悬殊的效率差距，一直抛出来一个很难回避的问题：如果直接筛掉垫底半数能力不足的人，不管是单个项目还是整个行业，会不会运转得更好？有见地的管理者早就想明白一件事：假如传统管理唯一的作用，只是把能力最差的那群人从纯拖后腿变成勉强不亏，那整套管理流程其实根本得不偿失。

而开源社群的成功，把这个疑问摆到了台面上，还给出实打实的佐证：网上自发聚集、自愿参与的贡献者，远比管理一整栋心思根本不在这份工作上的全职员工，成本更低、效果也好得多。

这便自然引出了激励的问题。阐述我朋友观点的一个常见等效说法是，传统开发管理是对积极性不高的程序员的必要补偿，也就是要推着那些本身没什么干劲的程序员好好干活，否则他们无法产出好的工作。

持这套看法的人一般还会附带一个论调：开源开发者只愿意碰有意思、技术酷炫的活儿；枯燥琐碎的工作没人愿意碰，就算做也做得稀烂，这类任务只能靠拿工资的办公室员工，在管理层的督促下硬着头皮完成。我在《垦殖智域》里从心理、社群层面分析过，为什么这个说法站不住脚。不过现在我们不妨先假设这个论调是对的，看看能推出什么结论。

如果传统高度管控的闭源开发模式，唯一能守住的阵地就只有那些没人感兴趣的枯燥工作，那它能存续的时间就十分有限——只要哪天有人觉得这块枯燥业务值得钻研，或是找到了别的实现路径，这套模式就会被攻破，如同形同虚设的马奇诺防线。一旦某种枯燥软件出现开源竞品，用户就能明显感受到差异：开源贡献者是发自内心想解决这个难题才动手开发。不管是写软件还是其他创造性工作，发自内心的热爱，带来的驱动力远不是单纯薪资能比的。

那如果搭建整套传统管理架构仅仅只是为了驱动员工干活，那可能是一种好的战术，却是糟糕的战略——短期或许能赢，但长期来看则必输无疑。

梳理到这里能看出来，传统开发管理对比开源，在两件事上完全落了下风：资源统筹、人员编排；至于员工激励这块，也只是苟延残喘、撑不了多久。而这位可怜的、四面楚歌的传统管理者，在流程监督这一项上同样找不到优势。开源最硬核的优势就是分布式同行评审，想要杜绝细节疏漏，这套机制碾压企业里所有传统管控手段。

那最后只剩 “制定统一目标” 这一点，能不能拿来证明高额管理成本有存在的必要？或许还有一丝可能，但前提是要有足够依据证明：企业管理层、官方产品路线图，定下的目标更有价值、更容易让所有人达成共识，效果胜过开源社群的负责人和部落长老这类角色。

单从表面来看，这套说法很难站得住脚。倒不是开源这边的案例太有说服力——比如 Emacs 长达十几年的生命力，或是林纳斯·托瓦兹召集“乌合之众”发表“统治世界”^a的演讲，就能集结大批开发者。而真正拉垮对比结果的，是传统企业用来定项目目标的流程实际表现惨不忍睹。

软件工程有一条广为熟知的行业结论：60% 至 75% 的传统软件项目，要么无法收尾完工，要么交付后被目标用户舍弃。如果这个比例基本属实（我接触过的所有资深管理者都不曾反驳），那么大多数项目锁定的目标要么 (a) 脱离现实、根本无法落地实现，要么 (b) 根本方向就是错的。

和其他各种问题相比，这也是如今软件行业里，哪怕听者本身就是管理者（甚至管理者感触更深），光是听到 “管理委员会” 这个词也让他们心里发怵的核心理由。过去只有程序员吐槽这套模式的时代早已远去，如今高管的办公桌上，都会贴着讽刺企业管理的《呆伯特》（Dilbert）漫画。

那我们对传统软件开发管理者的回应其实很简单，如果开源社群真的严重低估了传统管理的价值，那为什么你们有这么多人打心底里嫌弃自己这套流程呢？

开源社群的现状再次把这个问题摆得明明白白，我们做开发本身就是乐在其中。这份带着趣味的创造性实践，在技术成果、市场份额、行业认知影响力上都收获了惊人的成绩。我们不只证明自己能产出更优质的软件，更证明发自内心的愉悦本身就是一种宝贵的资产。

距离这篇文章第一版发布已有两年半，我文末想抛出的最有颠覆性的观点，已经不再是畅想一个由开源主导的软件行业；毕竟现在也有不少行事严谨、西装革履的人觉得这个图景具备可行性。

但我想提炼一条适用范围更广的道理，不只针对软件开发，可能所有创意类、专业类工作都通用：人只有身处恰到好处的挑战区间，才能从任务里获得乐趣，它不至于简单枯燥，也不会难到无从下手。一名状态舒展的开发者，自身能力不会被闲置，也不会被模糊混乱的目标、内耗沉重的流程拖累。享受工作，就意味着更高的效率。

如果从业者发自内心抵触、厌恶整套工作流程，哪怕只是通过贴《呆伯特》漫画这种讽刺自嘲的方式表现出来，这本身就说明这套流程已经彻底失效。愉悦、幽默感、轻松的创作氛围，都是实打实的宝贵优势。前文我写下 “快乐的‘乌合之众’”（happy hordes），不只是为了玩文字头韵（alliteration）的修辞；Linux 的吉祥物是软萌幼态的小企鹅，也绝不是随便一个玩笑。

开源取得成功，最重要的启示或许就是：以轻松自在的玩乐心态去创作，才是创意工作里性价比、经济效率最高的模式。

2.13 尾声：网景拥抱集市

意识到自己正在参与创造历史，这是一种奇妙的感觉……

在 1998 年 1 月 22 日，距离我初次发表《大教堂与集市》约 7 个月，网景通信公司对外宣布，计划开放旗下网景通信家（Netscape Communicator）的源代码（公告原文参见：http://www.netscape.com/newsref/pr/newsrelease558.html）。在官方发布这则消息前，我对此毫不知情。

消息发布后不久，网景执行副总裁、首席技术官埃里克・哈恩（Eric Hahn）给我发来一封邮件，内容如下：“我谨代表网景全体同仁，首先向你致谢，是你的理念引领我们走到今天这一步。你的思考与文字，是我们做出开源决策最核心的思想源泉。”

The following week I flew out to Silicon Valley at Netscape’s invitation for a day-long strategy conference (on 4 February 1998) with some of their top executives and technical people. We designed Netscape’s source-release strategy and license together.

一周之后，我受网景邀约飞往硅谷，出席 1998 年 2 月 4 日为期一天的战略研讨会，参会者包含公司一众高管与核心技术负责人。我们一同敲定了网景源代码开放方案，并共同起草配套开源许可证。

几天后，我写下这样一段文字：

网景即将在商业领域开展一场面向集市开发模式的大规模真实落地试验。开源文化此刻正面临一道难关：如果网景这次推进失败，那开源理念将彻底失去公信力，商界或许整整十年都不会再涉足开源。

但换个角度看，这同样是千载难逢的良机。华尔街及各界市场对此举的初步反馈偏向谨慎乐观。我们也迎来了自证价值的机会。如果网景借开源重新夺回可观的市场份额，一场迟到已久的软件行业变革或将就此拉开序幕。

接下来这一年，注定充满借鉴意义，也很有看点。

事实也的确印证了这点。我在 2000 年年中落笔此文时，这个后来被命名为 Mozilla 的项目，只能算是一次不完全成功的尝试。它达成了网景最初的核心目标：打破微软对浏览器市场的垄断格局，同时也交出了几项亮眼的成果，其中最有代表性的就是新一代 Gecko 渲染引擎的问世。

但它并没有像 Mozilla 初代发起人预想的那样，吸引到海量外部开发者参与共建。问题似乎在于，Mozilla 发行版在很长一段时间里，违背了集市模式的一条核心准则：没有提供能让潜在贡献者一键运行、直观看到运行效果的成品。（项目开源一年多之内，任何人想要从源码编译 Mozilla，都必须取得专有 Motif 图形库的商用授权。）

站在外部视角看，最致命的短板在于：项目启动长达两年半，Mozilla 团队始终未能推出一款可投入商用的稳定浏览器。1999 年，一位项目核心成员杰米·扎温斯基（Jamie Zawinski）选择离职，他公开痛陈内部管理混乱、错失大量机遇，这件事在业内掀起了不小的波澜^a。他说得一针见血：“开源并不是灵丹妙药。”

这话不假。时至 2000 年 11 月，Mozilla 的长期发展前景已经远比杰米递交辞职信那会儿明朗：近几周的 nightly 版本^b，终于跨过关键的门槛，达到可供商用的稳定水准。但杰米的观点无可辩驳：如果一个既有项目本身目标模糊、有大量的面条代码（spaghetti code）^c，或是深陷软件工程各类陈年顽疾，仅仅开放源代码并不能力挽狂澜。Mozilla 恰好同时提供了两面参照范本，清晰地展示了开源何以成事，又何以落败。

与此同时，开源理念在其他领域遍地开花，收获了大批拥护者。自从网景开放源码之后，业界对开源开发模式的关注度呈爆炸式增长；这股浪潮与 Linux 操作系统的持续兴盛相辅相成、彼此助推。当年由 Mozilla 掀起的开源风潮，至今仍在加速蔓延。

第三章：垦殖智域

在观察到开源许可证所界定的官方意识形态与黑客实际行为之间存在矛盾后，我梳理了规范开源软件所有权与控制权的实际惯例。本文指出，这些惯例背后暗含一套财产权底层理论，与洛克土地占有理论具有同构性。然后，我会将这一点与对黑客文化作为“礼物文化”的分析联系起来：在这种文化中，参与者通过付出时间、精力和创造力博取声望。最后，本文将探讨该分析对文化内部冲突解决的参考价值，并推导出相应的规范性结论。

3.1 开源圈的言行反差

只要花时间观察互联网开源软件这片活跃、高产的领域，都一定会注意到一个有趣的矛盾：开源黑客们秉持的理念，与他们实际的行为方式之间存在差异——也就是开源文化的官方意识形态与落地实践存在脱节。

文化是一种拥有适应能力的机器。开源文化是对一系列可识别的驱动力与压力所作出的回应。和通常情况一样，文化对其环境的适应既表现为有意识的意识形态，也表现为隐性的、无意识的或半自觉的知识^a。这种无意识的适应与有意识的意识形态之间存在一定分歧，而这种情况并不少见。

在本文中，我将深入挖掘这一矛盾的根源，并借此揭示那些驱动力与压力，进而梳理出关于黑客文化及其习俗的一些有趣的观点。最后，我将提出一些建议，探讨如何更好地利用这种文化中所蕴含的隐性知识。

3.2 黑客圈的理念光谱

互联网开源文化的意识形态（即黑客们自称所信奉的东西）本身就是一个相当复杂的话题。所有成员都同意，开源（即可以自由再分发、能够便捷地演进和修改以适应不断变化需求的软件）是一件好事，值得共同倾力协作。这种共识实际上定义了该文化的成员资格。然而，个人及各种亚文化对这一信念给出的理由却差异很大。

光谱中的一个维度是理念热忱的程度：开源开发究竟仅仅被视为达成目的的一种便捷手段（实用工具、趣味玩具，或是有趣的游戏），还是被视为目的本身。

一个高度理念热忱的人可能会说：“自由软件就是我的生命！我存在的意义就是创造有用、优美的程序和信息资源，然后无偿分享。”一个中度理念热忱的人可能会说：“开源是一件好事，我愿意投入大量时间来促使其实现。”一个低度理念热忱的人可能会说：“是啊，开源有时候还行。我会玩玩它，也尊重那些开发它的人。”

另一个变化维度是对商业软件，或者对被视为主导商业软件市场的那些公司的抵触程度。

一个高度反商业倾向的人可能会说：“商业软件就是盗窃和资源垄断。我写自由软件是为了终结这种邪恶。”一个中度反商业倾向的人可能会说：“商业软件总体上还可以，因为程序员理应获得报酬，但那些靠劣质产品吃老本、横行霸道的公司是邪恶的。”一个无反商业倾向的人可能会说：“商业软件没问题；我只是更喜欢使用或编写开源软件罢了。”（如今，鉴于自本文首次公开版本以来产业中开源部分的增长，你还可能听到：“商业软件挺好的，只要我能拿到源代码，或者它能满足我的需求就行。”）

前文所述各类别的交叉乘积所隐含的 9 种态度，在开源文化中都存在。指出这些区别是有价值的，因为它们暗示了不同的行动取向，以及不同的适应与合作行为。

历史上，黑客文化中最为显眼、组织最为完善的部分，既是高度理念热忱的，也是高度反商业的。由理查德·M·斯托曼（RMS）创立的自由软件基金会（FSF）从20世纪80年代早期开始支持了大量的开源开发，Emacs 和 GCC 等工具至今仍是互联网开源世界的基石，并且在可预见的未来似乎仍将如此。

多年来，FSF 一直是开源黑客行为最重要的核心阵地，产出了大量至今对该文化至关重要的工具。FSF也是长期唯一一个在黑客文化外部观察者眼中具有机构身份认同的开源赞助者。他们实际上定义了“自由软件”这一术语，并有意给它一种对抗性的色彩（而较新的标签“开源”[http://www.opensource.org] 则同样有意地回避了这一点）。

因此，来自黑客文化内外部的看法，都倾向于将该文化与 FSF 的理念热忱态度及其被视为反商业的目标等同起来。RMS 本人否认自己是反商业的，但他的纲领却被大多数人（包括他许多最直言不讳的支持者）如此解读。FSF 那场充满活力且旗帜鲜明的“根除软件资源垄断！”运动，成了最接近黑客意识形态的存在，而 RMS 则成了最接近黑客文化领袖的人。

FSF 的许可条款，即“通用公共许可证”（GPL），表达了FSF的态度。它在开源世界中被极为广泛地使用。北卡罗来纳州的 Metalab（http://metalab.unc.edu/pub/Linux/welcome.html；前身为 Sunsite）是Linux 世界中最大、最受欢迎的软件仓库。1997 年 7 月，在 Sunsite 上那些明确标注了许可条款的软件包中，约有一半使用的是 GPL。

但是，FSF 从来都没有一枝独秀。黑客文化中始终存在着一股更低调、对抗性更弱、对市场更友好的思潮。这些实用主义者所忠诚的，与其说是一种意识形态，不如说是一系列建立在 FSF 之前的早期开源努力基础上的工程传统。这些传统中最重要的是 Unix 和商业化之前的互联网相互交织的技术文化。

典型的实用主义者态度只是中度反商业，他们对企业世界的主要不满并非“软件资源垄断”本身。而是那个世界顽固地拒绝采纳包含 Unix、开放标准和开源软件的更优方法。如果说实用主义者憎恶什么的话，那不太可能是泛泛的“资源垄断者”，而更可能是当前软件体制中的“木头王”（King Log）^a；以前是 IBM，现在是微软。

对实用主义者来说，GPL 的重要性在于它是一种工具，而非目的本身。其主要价值不是作为反对软件资源垄断的武器，而是作为一种鼓励软件共享和促进集市模式开发社区发展的工具。实用主义者看重拥有好用的工具和玩具，这种喜好超过了他对商业主义的反感，他可以在不抵触意识形态的情况下使用高质量的商业软件。同时，他的开源经验教会了他很高的技术质量标准，很少有闭源软件能够达到这一标准。

多年来，实用主义观点在黑客文化中的表达，主要表现为一股顽固的抵制潮流，即拒绝完全接受 GPL，乃至拒绝完全接受 FSF 的整个理念主张。在整个 20 世纪 80 年代到 90 年代早期，这种态度往往与伯克利 Unix 的爱好者、BSD 许可证的用户，以及从 BSD 源代码构建开源 Unix 的早期努力联系在一起。然而，这些努力未能建立起有相当规模的集市模式社区，反而变得严重碎片化且效率低下。

直到 1993 年至 1994 年初的 Linux 大爆发，实用主义才找到了真正的权力基础。尽管林纳斯·托瓦兹（Linus Torvalds）从未刻意反对 RMS，但他以善意的态度看待商业 Linux 产业的发展、公开认可为特定任务使用高质量商业软件、温和地嘲讽文化中那些更原教旨主义的理念热忱分子，为社区树立了榜样。

Linux 快速发展的一个副作用是吸纳了大量新黑客，对他们而言，Linux 才是主要的忠诚对象，FSF 的理念主张更多只是过往历史。尽管较新一波的 Linux 黑客可能将该系统描述为“GNU 一代的选择”，但他们大多更效仿托瓦兹而非斯托曼。

反商业的纯粹主义者日益发现自己成了少数派。情况发生了多大变化，直到 1998 年 2 月网景公司宣布将以源代码形式发布 Navigator 5.0 时才显现出来。这在企业世界内部激发了对“自由软件”更大的兴趣。随后，黑客文化内部呼吁利用这一前所未有的机会，并将其产品从“自由软件”改称为“开源”，这一呼吁得到了即时的赞同，令所有相关方都感到惊讶。

随着行业发展，文化的实用主义部分本身到 20 世纪 90 年代中期也变得多中心化了。其他具有自我意识和魅力型领袖的半独立社区开始从Unix/互联网的根基上萌发。其中，继 Linux 之后最重要的是拉里·沃尔（Larry Wall）领导下的 Perl 文化。规模较小但仍然重要的，是围绕约翰·奥斯特豪特（John Osterhout）的 Tcl 语言和吉多·范罗苏姆（Guido van Rossum）的 Python 语言所形成的传统^b。这三个社区都通过设计自己非GPL的许可方案，表达了它们的意识形态独立性。

3.3 性解放的理论，清教徒的实践^a

尽管历经种种变革，业界对于“自由软件”与“开源”的定义仍形成了广泛共识。而这一共识最直观的体现便是各类开源许可证，所有许可证均包含核心共性条款。

在 1997 年，这些共同要素被提炼为《Debian 自由软件指导方针》，该文件后续演变为开源定义（OSD，http://www.opensource.org）。依据 OSD 的方针，开源许可证必须保障任意一方拥有无条件修改开源软件、并二次分发修改版本的权利。

因此，OSD（以及遵循OSD的许可证，如 GPL、BSD 许可证和 Perl 的艺术许可证（Artistic License）^b）背后隐含的理念是：任何人都可以二次开发任何代码。没有什么能阻止五六个不同的人拿着任一开源产品（例如，FSF 的 gcc C 编译器）、复制源代码，带着它们朝不同的演化方向各自发展，却都宣称自己的版本才是正统。

这种项目分化被称为分支（fork）。分支的核心特征是衍生出多个相互竞争、日后无法代码互通的项目，进而割裂潜在的开发者社区。（有些现象表面上类似分支，但实则不然，例如各种不同 Linux 发行版的涌现便是典型。这类伪分支虽然可能形成独立的项目，但主体代码高度共用，各方能够充分共享开发成果，因此无论从技术还是社区层面看，都不构成浪费，也不被视为分支。）

开源许可证并没有任何限制分支的条款，更不用说伪分支了；甚至可以说，许可证在无形中默许并助长了这两类行为。但在实际场景中，伪分支十分普遍，真正的项目分支却极少出现。大型项目一旦发生分裂，必然伴随项目更名，相关方也会公开展开大量辩解。在诸如 GNU Emacs/XEmacs 分裂、gcc/egcs 分裂，以及 BSD 各派生团体的多次分裂等案例中不难发现：分裂者都感到自己是在违背一个相当强大的社区规范。¹

实际上（并且与“任何人都可以二次改动代码”的一致性理论（consensus theory）^c相矛盾），开源文化有一套体系完备、却大多不成文的权属惯例。

这些惯例规定了谁可以修改软件、在什么情况下可以修改，以及（尤其重要的是）谁有权将修改后的版本二次分发给社区。

文化中的禁忌会让其中的规范格外突出。因此，我们在此总结一些重要的禁忌，对后文将大有裨益：

• 社区对创建项目分支有着强大的舆论压力。除非迫不得已，同时需要大量公开为自己申辩开脱，并为新项目更名，否则分支不会发生。

• 未经项目协调者配合就向外推送代码改动，会遭到社区反感。除非是在一些特殊情况下，例如本质上微不足道的移植修复。

• 未经本人明确同意，不得将某人的名字从项目记录、贡献者名单或维护者名单中删除。

在本文的剩余部分，我们将详细审视这些禁忌和权属惯例。我们不仅要探究它们如何运作，还要分析它们背后揭示了开源社区哪些深层运作逻辑与激励机制。

3.4 产权制度与开源

当财产可以被无限复制、极易修改，且所处环境不存在强制性权力关系，也没有物质稀缺性经济的形态时，产权^a又意味着什么？

实际上，在开源文化的语境下，这个问题很容易回答。一个软件项目的产权人（所有者）^b，就是获得社区公认、独享分发修改版本排他权利的人。

（在本节讨论产权时，我会使用单数形式，会让人感觉每个项目仿佛都由一人所有。然而应当理解，项目也可以由团体所有。我们将在后面探讨这类团体的内部运作机制。）

根据标准的开源许可证，所有参与者在演化博弈中都是平等的。但在实践中，人们非常清楚地区分两种补丁：一种是“官方”补丁，由公开认可的项目维护者批准并集成到正在迭代的软件里；另一种是第三方的“非官方”补丁。非官方补丁并不常见，通常也不被信任。²

不难证明，问题的关键在于公开再分发。权属惯例鼓励人们在必要时为个人使用打补丁。对于在封闭的用户或开发小组内再分发修改版本的人，惯例持无所谓的态度。只有当修改被公开发布给整个开源社区、与原作分庭抗礼时，产权才成为问题。

一般来说，有三种方式可以获得开源项目的产权。第一种，也是最显而易见的，是发起项目。如果一个项目自创立以来只有一个维护者，且该维护者仍然活跃，惯例甚至不允许对谁拥有该项目产生质疑。

第二种方式是从前任产权人那里接过项目的产权（有时称为“交班”）。社区中广为理解的是，当项目产权人不再愿意，或无法投入必要的时间进行开发或维护工作时，他们有责任将项目交接给有能力的继任者。

值得注意的是，对于重大项目，这种控制权的转移通常会高调造势。虽然整个开源社区似乎从未干预产权人选择继任者，但惯例显然包含了一个前提：公共的合法性很重要。

对于小型项目，通常在项目发布包所含的变更记录中，注明产权的变更就足够了。其明确的推定是：如果前任产权人并非自愿转移控制权，他或她可以在合理期限内公开反对，并在社区支持下重新主张控制权。

获得项目产权的第三种方式是，发现项目需要人维护，而产权人已经消失或失去兴趣。如果你打算这样做，你有责任尽力找到原产权人。如果找不到，你可以在相关场所（例如专门讨论该应用领域的 Usenet 新闻组）宣布该项目似乎已无人维护，并且你在考虑接手。

社区惯例要求你预留一段公示期，期满后方可宣告自己成为项目新产权人。在这段时间里，如果有其他人宣布他们实际上已经在为该项目工作，那么他们的主张比你的优先级更高。开源社区认为多次公开表达你的意图是良好的行为。如果你在多个相关论坛（相关的新闻组、邮件列表）上发布公告，会得到更高的评价；如果你表现出耐心等待回复的姿态，则会得到更高的评价。一般情况下，你越是努力让前任产权人或其他主张者有机会回应，在没有回应时你的主张就越有力。

如果你在项目用户社区的见证下完成了这一过程，并且没有反对意见，那么你可以声称拥有了这个无主项目的产权，并在历史文件中注明。然而，这不如“交班”那样稳固，并且只有用户社区见证了你做出了实质性的改进，他们才认为你完全合法。

我观察这些惯例的运作已有 20 年，追溯到自由软件基金会之前的开源软件古代史，而这些惯例有几个非常有趣的特点。最有趣的一点是，大多数黑客遵循这些惯例时，并没有完全意识到自己在这样做。事实上，这可能是第一个有意识、且相当完整地写下来的总结。

另一个特点是，作为无意识的惯例，它们被社区成员以极其（甚至令人惊讶地）一致的方式遵循。我亲眼目睹了数百个开源项目的演化，而我仍然可以用手指头数出我观察到或听说过的重大违规案例。

第三个有趣的特点是，随着这些惯例的长期演化，它们一直朝着一致的方向发展。这个方向就是鼓励更多的公共责任感、更多的公开告知，以及更小心地保存项目的署名信息和变更记录，以此来确立当前产权人的合法性。

这些特点表明，这些惯例并非偶然，而是开源文化中某种隐性议程或生成模式的产物，而这种模式对其运作方式具有根本性的意义。

一位早期回应者指出，将互联网黑客文化与破解者/海盗文化（以游戏破解和海盗公告牌系统为中心的“warez d00dz”^c）进行对比，能很好地阐明这两种文化的生成模式。我们将在本文后面回到“d00dz”进行对比。

3.5 洛克与土地财产权^a

要理解这种生成模式，不妨留意一个与黑客通常关注的领域相去甚远的历史类比。法律史和政治哲学的研究者或许能认出，这些惯例背后的财产权理论，与英美普通法（common law）中的土地保有理论几乎如出一辙！

在该理论中，取得土地财产权的方式有三种：

在尚未有主的边疆地带，可以通过垦殖(homesteading)^b取得财产权——即通过掺进劳动（mixing labour）^c改造无主土地，圈起围栏，并维护自己的财产权。

在已开发地区，财产权转移的常规方式是财产权转让——即从前手^d产权人处受让地契。此理论中，产权链（chain of title）^e概念至关重要。理想的财产权证明，是一条可追溯至最初垦殖时的地契与转让链条。

最后，普通法理论承认土地产权可能丧失或被抛弃（例如产权人无继承人死亡，或证明空地产权链的档案缺失）。对于这样弃置的土地，可通过逆权占有来主张财产权——即迁入、改良，并像垦殖那样维护财产权。

如同黑客惯例，这一理论也是在中央权威薄弱甚至缺失的语境下有机演化的。它由北欧和日耳曼部落法在千余年间发展而来。因在近代早期由英国政治哲学家约翰·洛克（John Locke）系统化与合理化，它有时也被称为洛克财产权理论。

但凡资源具备较高经济或生存刚需价值，且不存在足以强制统一分配稀缺资源的权威主体，当地便会衍生出逻辑相近的财产权规则。即便在被赋予浪漫想象、认为没有财产权概念的狩猎采集文化中也是如此。例如，在卡拉哈里（Kgalagadi，旧称卡拉哈迪（Kalahari））沙漠的昆桑布须曼人（!Kung San bushmen）传统中，狩猎领地没有财产权，但水坑和泉眼有财产权——这个理论明显与洛克的理论相似。

昆桑布须曼人的例子很有启发性，它表明，洛克的财产权惯例仅当资源预期收益大于预期防御成本时才会出现。狩猎领地不是财产权，因为狩猎收益高度不可预测、变化不定，且虽极受珍视却非日常生存必需。而水坑对生存至关重要，且规模小到足以防御。

本文标题中的智域（noosphere）是思想的疆域，即一切可能思想的总体。我们在黑客产权惯例中看到的，正是洛克财产权理论，适用于智域的一个子集——所有程序构成的领域。因此，“垦殖智域”正是每一个新开源项目创始人所做的事情。

法雷·里多（Faré Rideau）正确指出，黑客并非完全在纯粹思想的领域运作。他断言，黑客拥有的是编程项目——物质劳动（开发、服务等）的内涵性聚焦点（intensional focus point）^f，与声誉、可信度等相关联。因此他认为，黑客项目所张成的空间不是智域，而是它的某种对偶——探索智域的程序项目领域。（向天体物理学家们致歉，从词源学上，这个对偶空间应称为“能层（ergosphere）”，即“劳作域”^g。）

在实践中，智域与劳作域的区分对我们当前论证并不重要。法雷坚持的纯粹意义上的智域是否有意义地存在，本身是可疑的；几乎只有信奉柏拉图式理论的哲学家才会相信它。且仅当有人主张思想（智域的元素）不能占有，但思想在项目中的具体实现可以占有时，这一区分才具有实践重要性。这个问题引向知识产权理论中一些超出本文范围的议题⁴。

为避免混淆，需注意：无论是智域还是劳作域，都不同于电子媒介中虚拟位置的总和——后者有时被称为“赛博空间”（这令大多数黑客厌恶）。那里的产权受完全不同的规则支配，更接近物质基底的规则——本质上，谁拥有承载赛博空间某部分的媒介和机器，谁就拥有那部分赛博空间。

洛克财产权惯例逻辑强烈暗示：开源黑客遵循他们现行的惯例，是为了捍卫其努力所带来的某种预期回报。这种回报必须比垦殖项目的努力、维护记录“产权链”的版本历史成本、公开发布通知和等待对废弃（孤儿）项目进行逆权占有（adverse possession）^h所花费的时间成本更为重要。

此外，开源的收益必然不仅仅是软件的使用，而是某种会被 fork 行为损害或稀释的东西。如果使用是唯一诉求，就不会有反对 fork 的禁忌，开源产权也就完全不像土地保有了。实际上，现有开源许可证所隐含的，恰恰是这样一个（只关注使用的）世界。

我们可以先排除某些候选的收益类型。因为无法通过网络连接有效强制他人、寻求权力直接排除。同样，开源文化中没有太多类似货币或内部稀缺经济的东西，因此黑客不可能追求与物质财富非常类似的事物（如积累稀缺代币）。

然而，开源活动确实有一种方式可以帮助人们变得更富有——这种方式提供了理解其真正动机的重要线索。在黑客文化中获得的声誉，偶尔会以具有经济意义的方式溢出到现实世界：可能带来更好的工作机会、咨询合同或图书出版协议。

但这类副作用对大多数黑客而言，充其量是罕见且边缘化的，远不足以作为唯一的解释——即便我们忽略黑客们在反复申明：他们做这些事不是为了钱，而是出于理想主义或热爱。

不过，这些经济副作用的中介机制值得审视。接下来我们会看到，理解开源文化内部的声誉动态，具有相当强的解释力。

3.6 黑客场域^a内的礼物文化

要理解声誉在开源文化中的作用，不妨从历史转向人类学和经济学，考察交换文化与礼物文化之间的差异。

人类天生就有竞争声望地位的驱动力，这是我们的进化史所塑造的。在农业发明之前，占人类历史 90% 的时间里，我们的祖先生活在小型游牧狩猎采集群体中。地位高的个体（那些最擅长组织联盟、说服他人与其合作的人）能获得最健康的配偶和最好的食物。人们对声望地位的渴求会呈现不同表现形式，核心取决于生存资料的稀缺程度。

人类大多数社会组织方式都是对稀缺和匮乏的适应。每种方式都附带着不同的获取声望地位的途径。

最简单的方式是命令等级制。在命令等级制中，稀缺物资由一个中央权威分配，并以强制力为后盾。命令等级制的扩展性很差；⁵ 随着规模扩大，它们会变得越来越残暴和低效。因此，任何命令等级制，只要其规模超越一个大家庭，便几乎总是寄生在另一种类型、规模更大的经济体之上。在命令等级制中，声望地位主要由对强制权力的掌握程度决定。

我们的社会以交换经济为主。这是对稀缺性的一种精妙适应，与命令等级制不同，它的扩展性相当好。稀缺物资的分配通过交易和自愿合作以去中心化的方式进行（事实上，竞争欲望的主导作用恰恰是产生合作行为）。在交换经济中，声望地位主要由对可用于使用或交易之物（不一定是物质之物）的掌控程度决定。

大多数人心中都有这两种模式的隐含模型，并理解它们如何相互作用。例如，政府、军队和有组织犯罪，都是寄生在更广泛的交换经济——我们称之为“自由市场”——之上的命令等级制。然而还有第三种模式，它与前两者截然不同，而且除了人类学家之外，通常不被人们所认知；这就是礼物文化^b。

礼物文化不是对稀缺性的适应，而是对丰裕的适应。它们出现在生存物资不存在严重物质稀缺问题的人群中。我们可以在生活在气候温和、食物充足生态区的原住民文化中观察到礼物文化的运作。我们也可以在自己社会的某些阶层中观察到这些现象，尤其是在演艺界和超级富豪群体中。

丰裕使得命令等级制下的关系难以维系，也使得交换经济下的关系成为一种几乎无意义的博弈。在礼物文化中，声望地位不是由你控制什么决定的，而是由你给予什么决定的。

夸扣特尔人酋长的夸富宴（potlatch）^c就是如此，百万富翁精心策划且通常公开的慈善行为也是如此，黑客为产出高质量开源代码而付出的长时间努力亦是如此。

从这个角度来看，很显然开源黑客社会实际上就是一种礼物文化。在其中，并不存在“生存必需品”——磁盘空间、网络带宽、计算能力——的严重短缺。软件是自由共享的，而这种丰裕创造了一种局面，在其中评判竞争成败的唯一标尺，就是在同侪群体中建立的声誉。

然而，仅凭这个观察并不足以完全解释黑客文化中观察到的所有特征。破解者和“warez d00dz”（d00dz，也即 dudes，指盗版软件圈）也拥有一种礼物文化，在与黑客相同的（电子）媒介中繁荣发展，但他们的行为却大相径庭。他们文化中的群体意识比黑客更强，排他性也更明显。他们保守秘密而非分享秘密；你更可能看到破解者团体分发闭源破解程序，而不是泄露他们如何做到这一点的诀窍。（关于这种行为的内部视角，参见注释 5）。

这表明，如果之前还不够明显的话，那就是运作礼物文化的方式不止一种。历史和价值观很重要，我在“黑客圈简史”（A Brief History of Hackerdom）中总结了黑客文化的历史；它塑造当前行为的方式并不神秘。黑客们通过一系列关于其竞争形式的选择来定义他们的文化。本文余下部分将考察的正是这种形式。

3.7 黑客的创造乐趣

顺便说一句，在做这个“声望博弈”分析时，我并不是要贬低或忽视设计优美的软件、并让它运行所带来的那种纯粹的创作审美满足感。黑客们都体验过这种满足感，并以此获得内心滋养。如果这种满足感不是一个人重要的动力来源，那他根本就不会成为黑客，就像不爱音乐的人永远不会成为作曲家一样。

因此，也许我们应该考虑另一种黑客行为模型，其中纯粹的技艺乐趣是主要动机。这种技艺模型必须能够解释黑客惯例，将其视为一种路径，既能充分拓展手艺创作的空间，也能提升最终成果的品质。这与声望博弈模型相互矛盾，还是说只是得出的结论不同？

其实不然。在考察技艺模型时，我们回到了同样的问题，正是这些客观约束，让黑客社群只能以礼物文化的模式运作。如果没有衡量质量的指标，又该如何实现作品质量最大化？如果稀缺经济学不起作用，除了同行评估之外，还有什么指标可用？看起来，任何由技艺文化形成的社群，最终都要依靠声望体系完成内部秩序构建——实际上，我们可以从中世纪行会以来的许多历史技艺文化中观察到这种动态^a。

在一个重要的方面，技艺模型弱于礼物文化模型；它本身无法解释我们在本文开头提出的那个矛盾。

最后，技艺动机本身在心理学上可能并不像我们愿意假设的那样远离声望博弈。想象一下你优美的程序被锁在抽屉里，再也不会被使用，再想象一下它被许多人顺畅、愉快地使用。哪个梦想能让你感到满足？

尽管如此，我们仍然需要留意这套技艺模型。它对许多黑客有直观的吸引力，并且能很好地解释个人行为的某些方面。⁶

在我将本文的第一版发布到互联网上之后，一位匿名读者留言道：“你可能不是为了获得声望而工作，但声望是一种真实的回报，如果你工作做得好，它会产生相应的正反馈。”这是一个微妙而重要的观点。无论手艺人是否意识到声望激励，它们都在持续运作；因此，归根结底，无论黑客是否将自己的行为理解为声望博弈的一部分，他的行为都会被该博弈所塑造。

其他评论者将同行尊重所带来的奖励，以及黑客的乐趣，与亚伯拉罕·马斯洛（Abraham Maslow）著名的需求层次理论（Hierarchy of Values）中的生存需求以上层次联系起来。⁷ 根据这种观点，黑客的乐趣满足了自我实现或超越的需求，而这种需求只有在较低层次的需求（包括身体安全需求，以及“归属感”或同行尊重需求）得到最低限度的满足后，才能持续表现出来。因此，声望博弈可能在提供社会背景方面至关重要——正是在这种背景下，黑客的乐趣才能真正成为个人的主要动机。

3.8 礼物文化中声望的多重维度

在所有礼物文化中，人们都愿意主动角逐同行声望（名望），背后存在共通根源：

第一，也是最直观的一点：在同行间积累良好声望，是核心回报。前文提到过演化层面的根源，让人类生来就认同这份价值。（不少人会把追逐声望的本能，转化为各类精神升华追求——这些追求和具象的同行社群并无明显关联，比如“荣誉”“道德操守”“虔诚”等，但这并不会改变背后的底层心理机制。）

第二，声望是博取他人关注、促成合作的重要途径（在纯粹的礼物经济体系里，这也是唯一的途径）。如果一个人一向以慷慨、聪慧、处事公允、具备领导力及其他优良特质著称，便更容易让他人确信，与他相交能收获实际的益处。

第三，如果一套礼物经济与交换经济或命令层级体系产生交集甚至深度交融，你的个人声望便会向外辐射，帮助你在另一套体系中获得更高的身份层级。

除了这些普遍性原因之外，黑客文化独有的环境特质，让声望的价值远超世俗现实场景下各类礼物文化里的声望。

最核心的独特之处在于：人们所馈赠的成果（换言之，即其精力与时间投入的可见象征）极其复杂。它们的价值远不如物质礼物或交换经济中的金钱那样显而易见，很难客观区分优良馈赠与拙劣馈赠。因此，馈赠者能不能借此拿到社群地位，很大程度要看同行细致客观的评判。

另一个特殊性在于开源文化所具有的相对纯粹性。大多数礼物文化都并不纯粹——它们要么受交换经济关系影响（如奢侈品贸易），要么受命令经济关系影响（如家族或宗族结构）。在开源文化中，不存在同等影响力的对应体系；因此，除同行声望之外，获取地位的其他途径几乎完全缺失。

3.9 产权如何放大声望激励

现在我们可以将前面的分析整合起来，形成一个关于黑客产权惯例的连贯论述。我们已经理解了垦殖智域的收益——那就是黑客礼物文化中的同行声望，以及由此带来的所有次级收益和附带影响。

基于这一理解，我们可以将黑客社群的洛克式财产权惯例分析为一种最大化声望激励的手段——即确保同行的背书归于应得之人，而不归于不应得之人。

在这一分析下，我们观察到的三条禁忌就完全说得通了。如果他人盗用或糟蹋了自己的工作成果，个人的声望可能会受到不公正的损害；这些禁忌（以及相关的惯例）正是试图防止这种情况发生。（或者，更务实地来说，黑客们通常避免fork 项目或对他人项目进行非官方 fix，以后别人用同样方式动自己的项目，他们就能否定这种行为的正当性。）

• Fork 一个项目是不好的，因为它使 fork 前的贡献者面临声望风险，而他们只有在 fork 后同时活跃于两个衍生项目中才能控制这种风险。（这通常过于混乱或难以操作。）

• 分发非官方补丁（或者更糟，非官方二进制程序包）会使项目所有者面临不公平的声望风险。即使官方代码完美无瑕，项目所有者也会因补丁中的 bug 而挨骂（但参见注释4）。

• 偷偷地将某人的名字从项目中抹去，在文化语境中属于“终极罪行”之一。这样做是窃取受害者的馈赠，并将它作为窃贼自己的成果来展示。

当然，fork 一个项目，或者为其分发非官方补丁也会直接挑战原始开发者团队的声望。如果我 fork 或者通过非官方途径 fix 了你的项目，我就是在说：“你做了一个错误的决定，未能将项目带向我正在引领的方向”；而任何使用我 fork 出的版本的人都是在支持这一挑战。但这本身本应是一个公平的挑战——尽管极端，它仍是同行评审最尖锐的形式。因此，尽管这无疑强化了禁忌，但单凭这一点并不足以解释禁忌的存在。

这三种禁忌行为都会对开源社区造成整体性伤害，同时也会对受害者造成局部伤害。潜在贡献者会降低预期，不再相信无偿创作能换来相应的声望回报，从而间接伤害整个开源社区。

值得注意的是，对于这三条禁忌中的两条，还存在另一套解释。

首先，黑客们常常哀叹 fork 项目会导致衍生项目在未来或多或少平行发展，从而造成重复劳动，以此解释他们对 fork 项目的反感。他们也可能指出，fork 也往往会分裂协作开发者社区，导致两个衍生项目可用的智力资源都比原项目少。

有受访者指出，fork 产生的多个衍生项目中，通常很难有超过一个能长期保持显著的“市场份额”存活下来。这强化了各方合作、避免 fork 的动机，因为很难事先知道谁会落在下风，并眼睁睁看着自己大量的工作要么彻底消失，要么默默无闻。

也有人指出，fork 很可能引发争执和纠纷，这一简单事实本身就足以形成反对 fork 的社会压力。争执和纠纷会破坏团队合作，而团队合作对于每个贡献者实现个人目标都是必不可少的。

对非官方补丁的反感，通常解释为它们可能在不同版本之间造成兼容性问题，极大地增加 bug 追踪的复杂性，并给维护者带来额外的工作负担——捉自己的虫就已经够忙了。

这些解释有相当的真实性，它们确实在一定程度上强化了产权的洛克式逻辑。但是，尽管在理智上很有吸引力，它们却无法解释，为何在禁忌被“通融”或打破的罕见情况下——不仅仅是被侵害方，还包括往往反应相当激烈的旁观者和观察者——会表现出如此多的情绪和领地意识。关于重复劳动和维护麻烦的纯粹功利考量，根本无法充分解释所观察到的行为。

再者，还有第三条禁忌。除了声望博弈分析之外，很难看出还有什么能解释这一点。这一禁忌很少被分析得比“这不公平”更深入，这一事实本身就颇具揭示性，我们将在下一节中看到这点。

3.10 自我的问题

在这篇文章的开头，我提到过：一种文化潜意识层面的适应性知识，往往与其显意识层面的意识形态相左。其中一个重要例证便是：洛克式财产权惯例虽然得到广泛遵循，却明显违背了开源许可标准协议的明文意图。

在与黑客们讨论声誉博弈分析时，我观察到了这一现象的另一个有趣实例。那就是许多黑客抗拒这种分析，并强烈不愿承认他们的行为是受追求同行声望的动机所驱动——或者如我当时不慎所贴的标签那样，是受自我（ego）满足驱动。

这揭示了黑客文化中有趣的一点。它在意识层面上不信任并鄙视自我主义及以自我为基础的动机；自我标榜往往遭到无情批评，即便社群看似可能因此获益。实际上这种态度强烈到，该文化中的“大人物”和部落长老们必须轻言细语、一言一行间都要自嘲，才能维持其地位。这种态度与一套几乎完全靠“自我”运转的激励体系如何兼容，则十分值得探讨。

其中很大一部分当然源于欧美主流文化（Europo-American）^a对“自我”普遍抱有的负面态度。多数黑客所处的文化母体（culture matrix）告诉他们：渴望自我满足是一种不良（或至少是不成熟）的动机；“自我”往好里说只是怪才才可容忍的怪癖，而更多时候则是心理病态的真实标志。唯有升华和伪装的形式——如“同行声望”、“自尊”、“专业操守”或“成就自豪感”——才被普遍接受。

这种文化观念隐含诸多病态根源：人们无视心理学、行为学的全部实证，坚信自身拥有纯粹“无私”的动机，由此产生的自我欺骗造成了极大伤害——单就这个问题，我就完全能另写一篇。也许吧，要不是弗里德里希·威廉·尼采（Friedrich Wilhelm Nietzsche）和安·兰德（Ayn Rand）早就（不管他们还有啥别的毛病）把“利他主义”拆解成没被正视的自利形式，我说不定真会动笔^b。

但我不是想在这里做道德哲学或者心理学研究，因此我只想指出这种“自我即恶”的信念所造成的一点小伤害，即：它让很多黑客在情感上很难清醒地理解自己文化的社交动态！

不过，这条探究路径尚未完成。外部大众文化对明显以自我为驱动的行为的禁忌，在黑客（亚）文化中被大大强化了，让人不得不怀疑这对黑客是不是有什么特别的适应性功能。的确，在许多其他礼物文化中——例如戏剧从业者的同行文化或超级富豪圈子——这种禁忌要弱得多（甚至不存在）。

3.11 低调行事的价值

我们已经在前文点明，声望是黑客文化奖励机制的核心，现在需要理解为什么这一事实保持半遮半掩、心照不宣显得如此重要。

与海盗文化做一番对比，则很有启发性。在那种文化中，追求地位的行为公开而张扬。那些破解者热衷于追逐发布“0day warez”（在原始未破解版本发布当日，即发布破解软件）所带来的声名，却对破解手法三缄其口。这些秘术方士从不轻易亮出自己的底牌。结果便是，破解者文化整体的知识储备只能缓慢积累。

相比之下，在黑客社区中，一个人的作品就是他的宣言。这里奉行非常严格的精英政治（Meritocracy，功绩择优、能者居之），并且有一种强烈的社群品格（ethos），即作品优劣理应、甚至必须由自身成果证明。最好的炫耀资本就是“开箱即用”的优质代码，而且任何合格的程序员都能看出它的水平。因此，黑客文化的知识储备能够快速积累。

因此社群会约束刻意标榜自我的姿态，进而提升协作产出，但这只是次要效应；这套规范真正守护的，是社区同行评价体系内信息的纯度。也就是说，自矜、傲慢会被社群约束，因为这类表达如同信息噪音，会掩盖协作创新实践中的关键信号。

出于相近的逻辑，抨击作者而非代码的行为是不被允许的。这里有一处耐人寻味的细节，能够佐证前述观点：黑客即使会因理念、私人分歧互相争执对线，却绝不会公开质疑他人的专业技术能力（即使是私下批评也很少见，且语气往往趋于缓和）；追踪 bug 、提出批评永远针对项目本身，而不是创作者个人。

此外，开发者不会因过往的 bug 持续遭受苛责；bug 已被修复这件事，远比它曾经存在更重要。有受访者提到，修复“Emacs 的 bug”能够积累声望，但拿“理查德・斯托曼的 bug”说事则适得其反——而且，批评斯托曼那些早已修复的旧 Emacs bug，会被认为是极不礼貌的行为。

这与学术界的许多领域形成了鲜明的反差：在那些领域，贬损他人成果是获取声望的重要方式。在黑客文化中，这种行为被当作相当严重的禁忌——事实上如此严重，以至于这种行为的缺席最初并没有被我当作数据点，直到一位视角独特的受访者在这篇文章首次发表近整整一年后向我指出！

和学界、黑客界共有的排斥张扬姿态的潜规则相比，禁止质疑他人专业能力的特有禁忌更能说明问题，可以归因于学术界与黑客社群的沟通、协作支撑体系截然不同。

黑客文化中礼物馈赠的媒介是无形的，其沟通渠道不擅长表达情感上的细微差别，成员线下接触是例外而非常态。这使得它对噪音的容忍度低于大多数其他礼物文化，也解释了为何同时存在两大禁忌：禁止刻意张扬、禁止攻击他人的技术能力。一旦大量争执围绕专业水平展开，会严重扰乱这套文化的声望记分板。

这种对噪音的脆弱性也解释了黑客社区部落长老所需的、在公众层面低调行事的模式。他们必须表现出杜绝自夸的姿态，这样才能守住对有害噪音的禁忌底线。⁸

如果一个人有志运营成熟的开源项目，低调行事是必备素养；项目维护者必须让社群信服自身判断力，因为维护者的大部分工作是审阅他人的代码。谁会愿意向一个连自身代码优劣都分辨不清、或是企图独占项目声望回报的人贡献成果呢？潜在的贡献者希望项目领导者兼具谦逊与格局，能客观承认：“没错，这个版本确实比我的版本好，我会采用”，并给予创作者应有的赞誉。

低调行事还有一重现实考量：在开源世界中，你很少想给人一种项目已经“完成”的印象，这可能会让潜在的贡献者觉得自己不能发挥作用。最大化你影响力的方式是，对程序的状态保持低调。如果你通过代码来炫耀，然后说：“哎呀，它还不能做 x、y 和 z，所以它没那么好”，那么针对 x、y 和 z 的补丁往往会很快出现。

最后，我个人观察到，一些头号黑客的自嘲行为反映了一种真实（且并非不合理）的恐惧，即担心成为个人崇拜的对象。林纳斯・托瓦兹和拉里・沃尔（Larry Wall）都提供了许多此类规避行为的明确例证。有一次，在和拉里・沃尔一起外出晚餐时，我开玩笑说：“你是这里的头号黑客——你来选餐厅。”他明显畏缩了一下。这是有道理的；无数志愿社群衰败，根源就是大众混淆了社群共同价值与领袖个人特质，拉里与林纳斯对此心知肚明。另一方面，如果他们能让自己承认的话，大多数黑客会乐于拥有拉里的烦恼。

3.12 从声望博弈看开源生态的全局趋势

声望博弈模型还能推导出若干不易一眼察觉的全局规律，背后一大根源在于：创办一个成功项目所获得的声望，高于在现有项目中协作所获得的声望。同样，从具有显著创新性的项目中获得的声望，也高于从那些跟风式的、对已有软件的增量改进中获得的声望。另一方面，除了作者本人之外无人理解或无人需要的软件，在声望博弈中注定失败；而且，通过为现有项目做贡献来吸引良好关注，往往比让人们注意到一个新项目更容易。最后，与一个已经成功的项目竞争，远比填补一个空白细分生态位要困难得多。

因此，存在一个与邻近项目（即最相似的那些竞争项目）之间的最优距离。离得太近，你的产品就会沦为价值有限的跟风式作品，是一份糟糕的礼物（不如去为现有项目做贡献）。离得太远，则没人能使用、理解或看清自身工作的价值关联（同样是一份糟糕的礼物）。这在智域中形成了一种垦殖模式，颇似定居者向物理前沿扩散的过程——并非随机，而像是一种受扩散限制的分形结构。项目往往倾向于在前沿附近填补功能空白而兴起（关于新奇性吸引力的进一步讨论，见注释9）。

一些非常成功的项目成为了“品类杀手”（category killers）；没人愿意在它们附近垦殖，因为要与已建立起来的基础竞争黑客们的注意力，实在太过困难。那些原本可能创办自己独立项目的人，最终转而为这些大型成功项目编写扩展。经典的品类杀手例子是 GNU Emacs；它的变体如此彻底地占据了“完全可编程编辑器”这一生态位，以至于自 1980 年代初以来，没有任何竞争者能超越单人项目的阶段。相反，人们转而编写 Emacs 模式。

从全局来看，这两股趋势（填补空白与品类杀手）在时间维度上勾勒出一条可预判的项目演化路径。20 世纪 70 年代，现有的大部分开源项目不过是玩具和演示程序。80 年代，推动力集中在开发和互联网工具上。90 年代，重心转向了操作系统。每一轮都是当下赛道的发展潜力近乎耗尽，开发者才会转向更前沿、难度更高的领域。

这一趋势对近未来有着有趣的启示。1998 年初，Linux 看起来非常像是“开源操作系统”生态位中的品类杀手——那些原本可能去编写竞争操作系统的人，如今正在编写 Linux 设备驱动和扩展。而且，该文化所能设想的绝大多数底层工具，都已经以开源形式存在了。那还剩下什么？

应用软件。随着新千年的到来，可以颇有把握地预测，开源开发工作将日益转向最后一片空白领域——面向非技术人员的程序。一个清晰的早期指标是 GIMP（http://www.gimp.org）的开发，这个类似 Photoshop 的图像处理工具，是开源首个拥有面向最终用户的友好 GUI 界面的主要应用，而这种界面在过去十年的商业应用中已被视为标配。另一个指标是围绕 KDE（见 http://www.kde.org）和 GNOME（见 http://www.gnome.org）等应用工具包项目的热烈讨论。

本文的一位回应者指出，垦殖的类比也解释了为什么黑客们对微软“拥抱并扩展”（embrace and extend）——即把互联网协议复杂化然后封闭起来——的政策抱有如此本能的排斥。黑客文化能与大多数封闭软件共存；例如，Adobe Photoshop 的存在并不会显著降低 GIMP（其开源对应物）附近领域的吸引力。但是，当微软成功地将一个协议“去商品化”（de-commoditizing），以至于只有微软自己的程序员才能为其编写软件时，这一举动不仅通过扩展垄断损害了客户利益，还会压缩黑客能够开拓、耕耘的智域的数量和质量⁹。难怪黑客们常将微软的策略称为“协议污染”；他们的反应，恰如农民看到有人在他们赖以灌溉作物的河流中下毒一样！

最后，声望博弈分析也解释了那句常被引用的格言：你不是因为自称黑客而成为黑客——而是当其他黑客称你为黑客时，你才成为黑客。¹⁰ 从这个角度来看，黑客是指那些已经（通过贡献礼物）证明自己既具备技术能力、又理解声望博弈如何运作的人。这种判断看重从业者的行业认知与社群文化的习得程度，只能由已经深植于该文化内部的人做出。

3.13 怎样的贡献才够好？

黑客文化评判贡献、给予同行声望自有一套稳定标准，我们可以梳理出如下几条准则：

1. 如果软件的运行效果不如用户被引导产生的预期，那它就不够好——无论设计多精巧、创意多独到。

请注意“用户被引导产生的预期”这个限定。这条规则并非要求完美；测试版和实验性软件可以有bug。它要求的是：用户能够根据项目所处的阶段和开发者的相关陈述，准确地评估风险。

这条规则也能解释一个现象：开源软件常会长期停留在测试阶段，只有开发者完全确定不会爆出大量棘手问题时，才会打上 1.0 版本号。在闭源世界里，版本号1.0意味着：“如果你够谨慎，那就别碰它。”而在开源世界中，它的含义更像是：“开发者愿意拿自身声誉为产品担保。”

2. 扩展智域的工作，优于复制现有功能领域的工作。

很多人会简单认为原创优于单纯复刻现有软件功能，但事情并没有那么简单。如果在复刻闭源软件功能的过程中，能够破解封闭协议或私有格式、把这片领域开放出来，那么这份复刻工作的价值和原创不分高下。

因此，举例来说，当今开源世界中声望最高的项目之一是 Samba——它允许 Unix 机器作为微软专有的 SMB 文件共享协议的客户端或服务器运行。这其中需要做的创造性工作极少；主要问题在于确保逆向工程的细节正确无误。尽管如此，Samba 团队的成员仍被视为英雄，因为他们瓦解了微软锁定整个用户群体、圈占大块智域的垄断布局。

3. 被纳入主要发行版的作品，优于未被纳入的。被所有主要发行版收录的作品声望最高。

主要的发行版不仅包括像 Red Hat、Debian、Caldera 和 SuSE 这样的大型 Linux 发行版，还包括其余同样需要维护口碑、自带质量背书的软件合集——比如 BSD 发行版或自由软件基金会的源码库。

4. 使用是最真诚的赞美——成为品类杀手（category killers）优于做陪跑者。

信任同行的评判是同行评审机制的基础。没人有精力逐一比对所有同类替代方案，因此受众更广的项目会被视作更优质。

因此，完成一项好到没有人再愿意使用替代品的作品，就能赢得巨大的声望。最高程度的同行声望，来自完成了广受欢迎、成为品类杀手、并被所有主要发行版收录的原创作品。那些不止一次做到这一点的人，会被半开玩笑地称为“半神”。

5. 对艰苦、枯燥工作的持续投入（例如调试、编写文档），要比专挑“有趣又简单的开发活”摘樱桃式（cherrypicking）取巧^a更值得称赞。

这条规范，是社区用来奖励必要任务的——那些黑客们并非天生就愿意去做的事。在某种程度上，它与以下规则相矛盾：

6. 具备实质价值的功能扩展，优于零散简易补丁与单纯的 bug 修复。

它的实际运作方式似乎是：就单次行为而言，添加一项功能获得的奖励可能比修复一个 bug 更多——除非这个 bug 异常严重或隐蔽，以至于解决它本身就是一种展示非凡技巧和聪明才智的行为。但如果拉长时间维度，一个长年坚持修复普通 bug 的开发者，地位很可能高于同等精力只做简单功能新增的人。

一位受访者指出，这些规则会以有趣的方式相互作用，也并不总是在所有时候都奖励最高的效用。问一个黑客，他更可能因为自己全新的工具出名，还是因为给他人工具做扩展插件而出名，答案毫无疑问是“新工具”。然而，如果问到：（a）一个全新的工具，它可能每天被操作系统在后台默默使用仅几次，但迅速成为品类杀手；与（b）对一个现有工具的几项扩展，它们既不是特别新颖，也不是品类杀手，但每天被大量用户使用且可见——在黑客最终选择（a）之前，你很可能会看到他有些犹豫。这两种选择的分量大致相当。

上述受访者通过补充以下内容，恰如其分地说明了我的问题：“案例（a）是 fetchmail；案例（b）是你众多的 Emacs 扩展，比如 vc.el 和 gud.el。”他说的确实没错；我更可能被标注为“fetchmail 的作者”，而不是“一大堆 Emacs 扩展的作者”，尽管后者在长期来看可能具有更高的总效用。

这里可能发生的情况仅仅是，拥有全新独立标识的项目，比依附已有成熟项目衍生的拓展功能更容易获得关注。对这些规则的阐释，以及它们对黑客文化声望记分系统的启示，将是一个值得进一步研究的好课题。

3.14 以领地行为学阐释智域产权

要理解洛克财产权惯例的成因与影响，换一个视角分析会更清晰；即从动物行为学，特别是其中的领地行为学的角度来看。

产权是动物领地性的一种抽象，而领地性作为一种进化产物，它的功能是减少种内争斗（intraspecies violence）^a。狼通过划定自身边界、尊重同类边界，减少卷入争斗的概率；这类争斗轻则负伤、重则丧命，都会削弱自身的繁殖竞争力。同样，人类社会中的产权功能，是通过设定边界来明确区分和平行为与攻击行为，从而预防人类群体冲突。

在某些圈子里，将人类产权描述为一种任意的社会惯例颇为流行，但这种说法完全站不住脚。任何养过狗的人都见过，陌生人靠近主人地界时狗会吠叫的情形，这时就能体会到动物领地性与人类产权之间的根本延续性。我们这位狼驯化而来的犬类近亲本能地知道，产权绝非单纯的社会惯例或博弈游戏，而是一种至关重要的、进化而来的避免暴力的机制。（这让它们比许多人类政治理论家更聪明。）

主张产权（如同标记领地）是一种述行行为（performative act）^b，用来宣告自身将要捍卫哪些边界。社群对产权主张的支持，是一种最小化摩擦、最大化合作行为的方式。即使主张产权比一道篱笆或一声狗叫抽象得多，即使它仅仅是 README 文件中标注项目维护者姓名、宣示项目归属，这些道理依然成立。它仍是领地性的抽象表达，和其余各类产权一样，根植于人类演化出、用于化解冲突的领地本能。

这种动物行为学分析起初可能显得非常抽象，难以与实际的黑客行为联系起来。但它有一些重要的推论。其一，它可以解释万维网（World Wide Web）网站为何如此流行，特别是为什么拥有网站的开源项目看起来比没有网站的项目更“真实”、更充实。

从客观角度来说，这件事其实很难说通。从零开发、持续维护一款小型程序需要大量精力，相比之下搭建网页成本极低，因此很难将网页视为实质性内容或非凡努力的证据。

单靠万维网本身的功能，也不足以解释这一现象。网页的沟通功能，完全可以通过 FTP 站点、邮件列表和 Usenet 帖子的组合来实现，甚至效果可能更好。实际上，绝大多数项目的日常合作沟通，都依托邮件列表或新闻组，很少直接通过网页完成。那么，为什么网站作为项目大本营如此受欢迎呢？

“主页”（home page）这个术语所隐含的隐喻提供了重要线索。创建开源项目，本质是在智域内宣示领地主张（行业也普遍认可这一点），但从心理直觉层面看，这种主张缺乏足够的说服力。毕竟，软件没有实体的空间边界，并且可以无限快速复制。人类本能里对“领地、产权”的认知很难直接套用到软件上，还需要一层具象载体（项目主页）才能落地。

项目主页将抽象的数字先占垦殖行为具象化：在具备清晰空间层级的万维网中，把程序世界里无形的领地宣示，转化为看得见的“家园”（home）领地。从智域降维到“赛博空间”，虽然还没有完全把我们带到现实中设有围栏、犬只守界的实体领地，却能把抽象产权主张，和人类先天的领地本能牢牢绑定。这就是为什么拥有网页的项目显得更“真实”的原因。

超链接的存在及优秀的搜索引擎极大地强化了这一点。一个有网页的项目，更有可能被在智域中探索其周边区域的人注意到；其他人会添加外链指向它，搜索引擎也能检索到该项目。因此项目主页既是更高效的宣传载体，也是更有力的述行行为，代表一份更强的领地宣示。

这种动物行为学分析也鼓励我们更仔细地审视开源文化中处理冲突的机制。由此我们可以推出：开源社群的产权惯例，除了能最大化声望激励，还承担着预防、化解社群冲突的功能。

3.15 从产权看冲突的三大根源

在围绕开源软件的冲突中，我们可以归纳出四个主要问题：

• 谁有权对项目做出具有约束力的决策？

• 各项功劳归谁、各类过错由谁承担？

• 如何减少重复劳动，并防止非官方分支版本复杂化 bug 追踪流程？

• 从技术角度而言，什么是“正确之举”？

然而，如果我们重新推敲“什么是正确之举”这一点，它就往往不成问题了。对于任何此类问题，要么有被所有相关方接受的客观判定方式，要么没有。如果有，那就万事大吉，人人受益。如果没有，则问题最终都会落脚到 “谁拥有最终决策权”。

因此，一套项目冲突的化解理论，必须回应三个问题：

（a）设计决策的最终定夺权在谁手上，

（b）如何认定贡献者的功劳以及如何分配功劳，以及

（c）如何防止项目团队与产品分化出多条独立分支。

产权惯例在解决（a）、（c）两类问题时作用十分清晰。惯例确认了项目产权持有者有权做出具有约束力的决策。我们之前也观察到，社群惯例还会形成很强的约束，抵制通过 fork 来稀释产权的行为。

值得注意的是，即使抛开声望博弈，单从黑客文化中纯粹的技艺模型来看，这些惯例也合情合理。在这种观点下，这些惯例与其说是为了防止声望激励被稀释，不如说是为了保障工匠依照自身思路落地设计构想的权利。

然而，技艺模型不足以解释黑客关于（b）问题（即谁因何事获得功劳）的惯例——因为纯粹的工匠不关心声望博弈，也没有动机去关心功劳的归属。为了分析这一点，我们需要将洛克的财产权理论再推进一步，既要分析项目之间的冲突与产权运行规则，也要拆解项目内部的同类问题。

3.16 开源项目结构中的产权分配规则

最简单的情况，就是项目只有一个产权持有者（兼维护者）。这种模式不可能闹矛盾：产权持有者做出所有决策，并承担所有的功劳与骂名。唯一容易出分歧的，只有继任交接这件事——要是初代维护者淡出或者没心思继续做了，该由谁接手项目产权。前文 (c) 点也提到，社群都不想看到项目被 fork，大家对此都有共识。基于社群达成的这类共识，衍生出一套稳定的文化规范：即产权持有者/维护者无法继续维护项目时，应公开将产权移交给他人。

稍微复杂一些的情况，就是一个项目有多个共同维护者，他们在一位仁慈独裁者（benevolent dictator，常缩写为 BDFL）领导下工作，整个项目的产权都归他。根据惯例，团体项目倾向于采用这种模式；它在像 Linux 内核或 Emacs 这样的大型项目上已经证明有效，落到决策权分配这件事上，它的效果并不比任何其他替代方案明显逊色。

BDFL 这套产权管理模式，大多是从单人维护模式慢慢演变出来的：创始人不断吸引外部贡献者加入，团队规模做大，制度也就跟着成型。即使产权持有者依旧是独裁者，社群内部也会因“谁做了项目哪些部分，获得什么功劳”产生新的争议。

在这种情况下，惯例要求产权持有者/独裁者有义务公平给予贡献者功劳（例如，通过在 README 或代码提交记录中适当地提及）。放到洛克产权模型里解释，道理很简单：只要你为项目贡献代码，就能分到一部分声望产权收益，这份收益有赞誉，也免不了背负争议。

顺着这个思路想就能明白：BDFL 并不手握项目完整、排他的全部产权。虽然他有权做出具备约束力的最终决定，但本质上，他是把整体声望产权里的一部分收益份额让出去，换取其他人投入开发。用农场分佃制（sharecropping）来做类比，实在是再贴切不过了，只不过贡献者的名字会永久留在项目贡献名录，就算后来不再参与开发，也能持续拿到一点声望产权收益。

走 BDFL 路线的项目，参与的人一多，自然而然会分出两类贡献者：普通参与者、共同维护者（co-developer）。想成为共同维护者一般有两条路：要么独自扛下某一个核心子系统，接管该区域的产权领地；要么当“首席修复官”（lord high fixer），常年排查、修复各类 bug。不管走哪条路，共同维护者都需要长期、持续投入大量时间，以此换取对应子系统的配套产权权责。

子系统产权负责人这个角色，是我们这套产权分析里的关键，值得好好聊聊。黑客们喜欢说“权威跟着责任走”（authority follows responsibility）。只要共同维护者接下某个子系统的维护工作，那么这块模块的代码实现、对外接口，就全都归他的专属产权领地管，只需接受项目总负责人（兼任架构师）提出的修正。能明显看出来，这套规则依托洛克财产权模型，在项目内部划出多块独立的产权领地；和现实里所有产权分界一样，它能有效避免各方因产权起冲突。

按照惯例，只要项目有共同维护者，手握整体产权的 BDFL 或项目负责人，做关键决定前都得和这群人商量。尤其是决定牵扯到某个人专属产权领地的子系统（也就是他长期投入、全权负责的模块），协商就更有必要。明智的领导者都清楚内部产权领地边界的作用，不会随便插手、推翻各个子系统产权负责人做出的决定。

而有些体量极大的项目，则干脆彻底放弃 BDFL 这套产权管理模式。一种做法是让所有共同维护者组成投票委员会，Apache 就是典型例子；另一种是轮值统筹制，项目整体产权的管控权，在资深共同维护者的圈子里轮流交接，Perl 开发团队就是这么运作的。

大家普遍觉得这种复杂的多元产权组织形式不稳定、难以运作。这一点很好解释，集体委员会设计本身就自带一堆众所周知的问题，黑客文化圈对此早有认知。但我认为开发者本能抵触委员会、轮值统筹这类架构，还有更深一层原因：这种模式很难套进我们分析简单场景时，下意识使用的洛克产权模型。在这类复杂团队里，不管是控制权意义上的产权，还是声望回报收益意义上的产权，都很难理清每个人对应的领地；内部产权领地边界模糊不清，除非整个团队配合默契、互相信任，否则产权矛盾几乎无法避开。

3.17 冲突及其化解

我们已经看到，在项目内部，日益复杂的角色分工体现为设计权威和部分产权的分配。虽然这是一种有效的激励分配方式，但它也稀释了项目负责人的权威——尤其是削弱其压制潜在冲突的能力。

尽管围绕设计的技术争论看似最易引发内部冲突，但它们很少成为交火的真正原因。这类争论通常相对容易通过前文“权威跟着责任走”的领地归属规则（territorial rule）来解决。

解决冲突的另一种方式是依据贡献资历（seniority）——如果两位或两组贡献者之间发生争议，且争议无法客观解决，同时任何一方都不拥有争议所涉领地的产权，那么对项目整体投入最多的一方（即在整个项目中拥有最多产权的一方）获胜。

（等价地，投入最少的一方落败。有趣的是，这与许多关系型数据库引擎用于解决死锁的启发式方法恰好相同。当两个线程因资源发生死锁时，投入当前事务较少的一方会被选为死锁牺牲者并终止执行。这种策略通常让运行时间最长的事务，也就是资历更深的一方胜出。）

这些规则通常足以解决大多数项目争议。当它们不起作用时，项目负责人拍板定夺通常也能够解决。两类规则都无法摆平的争议则十分少见。

通常，冲突不会变得严重，除非以下两个标准（“权威跟随责任”和“资历深厚者胜”）指向不同的方向，并且项目负责人的权威薄弱或缺失。这种情况最可能发生的明显案例，是项目负责人消失后出现的继任权之争。我曾亲身经历过一次这样的争斗。它丑陋、痛苦、旷日持久，直到所有当事方都精疲力竭、同意将控制权交给外部人士才得以解决，我由衷希望自己再也不要卷入类似的事情。

归根结底，所有这些冲突解决机制，都有赖于全体黑客社群执行它们的意愿。可用的执行机制只有两种：公开抨击（flaming）和社群孤立（shunning）——即公开谴责那些破坏惯例的人，并拒绝与其合作。

3.18 文化习得机制^a与学术界的对照

本文的早期版本提出了这样一个研究问题：社群如何让其成员了解并习得惯例？这些惯例是半意识层面上不言自明或自组织的吗？这类规范是靠榜样示范，还是靠直白的条文指导来传递？

明确指导式的传授显然很少见，原因很简单：到现在为止，都很少有成文规范能用于系统性教学。

许多规范是通过榜样来传授的。举一个非常简单的例子，有一条规范是，每个软件发行版都应包含一个名为README或READ.ME的文件，其中包含浏览该发行版的初步指导。这一惯例至少从20世纪80年代初就已确立；甚至偶尔也被记载下来。但人们通常是通过观察众多发行版来了解这一点的。

另一方面，一旦一个人对声望博弈有了基本的（或许是无意识的）理解，一些黑客惯例便会自行组织形成。大多数黑客从不需要别人来教那三条禁忌，或者真被问起来，他们会说这些不言自明，不是谁教的。这种现象值得更深入的分析——也许我们可以在黑客获取关于该文化的知识的过程中找到解释。

许多文化使用隐藏的线索（更确切地说，是宗教/神秘意义上的“奥秘”）作为一种文化习得机制。这些秘密不透露给外人，但社群指望有心入行的新手能自己发现或推断出来。要想被内部接受，一个人必须证明自己既理解了该奥秘，又是以文化上认可的方式习得它的。

黑客文化对这种线索或考验的运用，自觉和广泛程度都非同寻常。我们可以看到这个过程至少在三个层面上运作：

• 密码式的专属圈内秘辛。例如，有一个名为“alt.sysadmin.recovery”的Usenet新闻组就有一个非常明确的此类秘密；你不知道它就无法发帖，而知道它被视为你有资格发帖的证据。常客们有一条强烈的禁忌，禁止泄露这个秘密。

• 需要入门某些技术奥秘的要求。一个人必须吸收相当多的技术知识，才能给出足够有价值的“礼物”（例如，必须至少掌握一种主流计算机语言）。这一宏观筛选机制，和微观层面的隐藏线索作用一致，用来筛选社群所需特质：抽象思维、毅力与思维灵活性。

• 社会情境奥秘。一个人通过参与特定项目而融入该文化。每个项目都是一个由黑客组成的活跃社会语境（social context），有心参与的贡献者必须从社会层面和技术层面去研究和理解它，才能在其中发挥作用。（具体来说，一个常见的做法是阅读该项目的网页和/或邮件列表存档。）正是通过这些项目组，新手才能体验到资深黑客的行为榜样。

在获取这些奥秘的过程中，想入行的黑客会获得情境知识，这些知识（过一段时间后）确实会让那三条禁忌以及其他惯例显得不言自明。

顺便提一句，有人可能会争辩说，黑客礼物文化本身的结构就是其自身的核心奥秘。一个人只有展现出对声望博弈及其隐含的惯例、禁忌和用法的本能理解，才被视为已融入该文化（具体地说：没有人会称你为黑客）。然而这没什么特别的，所有社群都会要求新人领会。此外，黑客文化并未表现出将其内部逻辑和惯例保密的愿望——至少，从来没有人因为我揭示了这些而抨击过我！

本文的受访者众多，他们指出，黑客的产权惯例似乎与学术界的实践密切相关（并且可能直接源于此），尤其是科学学术界。学术界社群在开垦蕴藏潜在创新思路的知识领地时也面临着类似的问题，并且在利用同行评审和声望的方式上，也表现出非常相似的适应性解决方案。

由于许多黑客在成长过程中接触过学术界（在大学期间学习黑客技能很常见），因此学术界与黑客文化在适应性模式上的共通之处，对于理解这些惯例是如何被应用的，就不仅仅是泛泛的兴趣了。

正如我所描述的那样，学术界与黑客“礼物文化”之间存在着大量明显的相似之处。一旦研究人员获得终身教职，就无需再担心生存问题。（事实上，终身教职的概念很可能可以追溯到更早的礼物文化，那时“自然哲学家”主要是拥有充裕时间用于研究的富有的绅士。）在没有生存问题的情况下，提升声望成为驱动目标，这鼓励了通过期刊和其他媒体分享新想法和研究成果。这从功能上讲是合理的，因为科学研究与黑客文化一样，非常依赖于“站在巨人肩膀上”的理念，而不必反复重新发现基本原理。

有些人甚至提出，黑客惯例仅仅是学术界惯例的反映，并且实际上（在大多数情况下）是由个体黑客从学术界习得的。这可能说得有点过了——连聪明的高中生都能轻松学会黑客惯例，这说法根本站不住脚！

3.19 礼物文化为什么优于交换经济

这里存在一种更有趣的可能性。我怀疑学术界与黑客社群会形成相近适配模式，并不是二者存在本源关联；而是在自然规律与人类先天本能的约束下，各自发展出了适配自身目标的最优社会组织形式。历史的结论似乎是，自由市场资本主义是实现经济效率的全球最优合作方式；或许，以类似的方式，基于声望博弈的礼物文化，也是产生（并检验！）高质量创造性工作的全球最优合作方式。

支持这一理论的是大量关于艺术与奖励之间互动的心理学研究。¹¹ 这些研究得到的关注少于它们应得的，部分原因或许是它们的普及者往往倾向于过度解读，借此全盘否定自由市场与知识产权制度。尽管如此，这些研究结果确实表明，某些类型的稀缺经济奖励实际上会降低程序员等创造性工作者的生产力。

布兰迪斯大学（Brandeis University）的心理学家特蕾莎·阿玛比尔（Theresa Amabile）在谨慎总结一项1984年关于动机与奖励的研究结果时指出：“委托创作的作品，一般而言，可能不如纯粹出于兴趣而完成的作品具有创造性。”阿玛贝尔接着指出：“任务复杂度越高，外在物质奖励越会削弱其创造性。”有趣的是，研究表明，固定薪水不会削弱动机，但计件工资和奖金却会削弱动机。

因此，给翻汉堡或挖沟渠的人发放绩效奖金在经济上或许是明智的，但在编程团队中，将薪资与绩效脱钩，让人们自行选择项目，可能更为明智（开源社群把两套逻辑贯彻到了极致）。事实上，这些结果表明，在编程领域，奖励绩效的唯一恰当时机，是当程序员的动机如此强烈，以至于即使没有奖励他也会工作的时候！

该领域的其他研究人员则直言不讳地指向了令黑客们如此关注的那些自主性和创造性控制问题。“当一个人体验到的自我决定程度受限时，”罗切斯特大学（the University of Rochester）心理学副教授理查德·瑞安（Richard Ryan）说，“他的创造力也会随之降低。”

总的来说，将任何任务呈现为一种手段而非目的本身，似乎都会削弱动机。即使是赢得与他人的竞争或获得同行的尊重，如果这种胜利被体验为“为了奖励而工作”，也可能以同样的方式削弱动机（这或许可以解释，为什么黑客文化从文化上忌讳明确寻求或宣称这种尊重）。

让管理问题更加复杂的是，管控式口头评价似乎与计件工资一样具有削弱动机的效果。

瑞安发现，那些被告知“很好，你做得对”的企业员工，“其内在动机显著低于那些只收到客观信息类反馈的员工”。

提供激励措施可能仍然是明智的，但这些激励必须不带附加条件，避免打乱整套协作机制。瑞安指出，“我给你这个奖励是因为我认可你工作的价值”与“你得到这个奖励是因为你达到了我的标准”之间存在着关键的区别。前者不会削弱动机，而后者则会。

基于这些心理学观察，我们可以提出一个论点：一个开源开发团队的效率（尤其是在长期，创造力作为生产力倍增器变得更加关键时）将显著高于一个规模和技能水平相当、但受稀缺性奖励激励（或去激励）的闭源程序员团队。

这从一个略有不同的角度印证了《大教堂与集市》中的一个推测：从根本上说，工业化的工厂式软件生产模式，从资本主义开始创造足够多的财富盈余，使众多程序员能够生活在一个后稀缺的礼物文化中那一刻起，就注定要被淘汰。

实际上，想要软件产出最大化，就会面临一个禅宗式的悖论：如果你想要最高效的生产，就必须不再强行施压要求程序员产出。保障他们的生计，放手让他们去做，并忘记截止日期。对于传统的管理者来说，这听起来像是疯狂放纵、注定失败的做法——但这正是开源文化如今碾压各路竞品的秘诀。

3.20 结论：从惯例到习惯法

前文我们已经梳理过约束开源软件产权与管理权的社群惯例，这套体系背后隐含一套和洛克土地占有财产权理论逻辑同源的框架；前文也结合礼物文化分析过，社群参与者依靠付出时间、精力与创意争夺声望。我们也考察了这种分析对于该文化中冲突解决的意义。

接下来合乎逻辑的问题是：“这为什么重要？”黑客们自发形成这套惯例，且至今都只是凭直觉践行，从未经过系统理论梳理。我们很难看出单纯的理论剖析是否能带来实际落地价值——除非，也许我们能够从描述走向规范，并推导出改进这些惯例运作方式的方法。

我们已经发现，在英美普通法传统下的土地产权理论中，存在着与黑客惯例高度相似的逻辑类比。从历史上看，¹² 发明了这一传统的欧洲部落文化，通过从模糊、靠直觉遵循的不成文惯例，演化成由部落贤者记录、最终成文的正式习惯法体系，改进了其争端解决机制。

也许，随着黑客社群规模持续扩张、新成员适应文化日益困难，黑客文化是时候采取类似的举措了——出台成文行为准则，以解决与开源项目相关的各类争端，并建立仲裁传统，由社群资深成员出面调解各类纠纷。

本文的分析勾勒出这样一部规范可能呈现的轮廓，将先前隐性的内容显性化。此类规范不可能自上而下地强加；它们必须由各个项目的创始人或产权持有者自愿采纳。它们也不可能完全僵化，因为社群所处外部环境会不断变化。最后，要使此类规范的实施行之有效，它们必须反映黑客部落的广泛共识。

我已经开始着手制定这样一部规范，暂定名为《莫尔文协议》，以我居住的小镇命名。如果本文中的总体分析得到足够广泛的认可，我将公开莫尔文协议，作为争端解决的示范性规范。有意评议、完善这套规范，或是单纯对此想法提出看法的读者，欢迎通过电子邮件与我联系：esr@thyrsus.com。

3.21 有待进一步研究的问题

无论是开源社群还是我个人，都对不采用仁慈独裁者治理模式的大型项目缺乏深入理解。大多数此类项目都以失败告终，少数项目却大获成功，拥有举足轻重的行业影响力（如Perl、Apache、KDE），然而没有人真正理解造成这种巨大差距的根本原因。外界普遍存在一种模糊认知，认为每一个此类项目都自成一类，项目的兴衰全系于内部成员的群体互动氛围，但事实果真如此吗？还是说，存在可复用、可供团队参照的运作策略？

第四章：魔法锅炉

本章分析开源现象背后不断演变的经济基础：首先破除软件开发资金来源与软件定价结构的若干普遍迷思；继而以博弈论剖析开源合作稳定与否，提出九种可持续的开源开发资金模式，其中包括两种非营利性模式与七种营利性模式；进而阐释闭源软件具备合理性的经济条件；同时探讨当前市场在开源软件商业化上的创新，包括重构赞助制度与搭建任务市场模式；最后对未来趋势做出初步预判。

4.1 开源社区的成就与魔法无异

在威尔士神话中，女神瑟西德温^a拥有一口神奇的魔法锅炉，只需念诵唯有她知晓的咒语，锅中便会魔法般生出滋养生灵的琼浆玉液。在现代科学界，巴克敏斯特·富勒提出的"简效化"概念^b与这个神话遥相呼应：当早期设计投入的实体资源逐渐被海量信息取代，技术便会在提升效能的同时不断降低成本。阿瑟·克拉克^c将二者联系起来，做出那句经典论断："任何足够先进的技术，皆与魔法无异。"

对许多人来说，开源社区的成就就像某种难以置信的魔法。高品质的免费软件仿佛念动咒语即成，它惠及用户，虽令人一时称羡，却难以在充满竞争与资源稀缺的现实世界长久维系。这究竟有什么玄机？莫非瑟西德温的魔法锅炉只不过是一道障眼戏法？如果这不是戏法，简效化理念在这里又如何显效？女神吟诵的，又是怎样一道咒语？

4.2 超越极客与礼物文化的视角

开源文化的实践，无疑颠覆了许多局外人对软件开发的固有观念。《大教堂与集市》一章讲去中心化的协作式软件开发怎样推翻布鲁克斯定律^a，从而在单个项目上达到前所未有的可靠性与质量水平。《开拓智域》^b一章则审视这种“集市”式开发所处的社会动态，认为最有效的理解不应套用传统的交换经济学术语，而应该参考人类学家所称的 “礼物文化”^c ，在这种文化中，成员通过慷慨馈赠来竞争地位。

本文将先破除软件生产经济学层面的常见迷思^d，再延续此前文本的分析脉络，深入经济学、博弈论和商业模式的领域，发展出新的概念工具，以理解开源开发者的礼物文化是怎样在交换经济中维系的。

沿此分析脉络继续深入，我们需放弃（或至少同意暂时搁置）礼物文化层面的解释。《开拓智域》曾提出，礼物文化行为出现在生存物资已足够丰富、导致交换博弈失去大部分吸引力的情境中。这一解释作为行为的心理学动因足够有力，然而仍不足以解释大多数开源开发者实际上所处的混合经济环境。对大多数人而言，交换博弈虽然已失去吸引力，但是它并没有失去强制性。他们的行为必须在物质稀缺经济学^e中站得住脚，才能让自己维持足以支撑礼物文化的盈余地带。

因此本文将（完全在稀缺经济学的领域内）审视那些维系开源开发的合作与交换模式。下文将通过具体案例，回答那个现实的问题：“我怎么拿它赚钱？”不过在此之前，我有必要指出：这个问题背后的许多张力^f，实际上来自那些流行却违背实际软件生产经济学的通俗认知。

（文末先作申明：本文讨论倡导开源开发，既不是说闭源开发本质上是错误的，也不是简单否定软件知识产权，更不是什么呼吁 “分享” 的利他主义道德说教。尽管这些论点在开源社区中少数嗓门大的人里仍然备受青睐，但自《大教堂与集市》出版以来的经验已清楚表明，它们并非必需。为开源开发辩护的一个完全充分的理由是它带来的工程与经济成果：产出更高质、软件更可靠、价格更低、选择更多。）

4.3 “软件产业属于批量制造业”是错觉

首先必须明确，计算机程序像所有工具或生产资料一样，具有两种不同的经济价值：使用价值与销售价值。程序的使用价值在于它能让工具的生产力倍增；而它的销售价值在于作为一种可销售商品的价值（专业经济学家的说法是，销售价值是指最终产品的价值，使用价值是指中间产品的价值^a）。大多数人往往以为软件生产的经济学是“工厂模式”^b，这种模式基于以下基本前提：

• 大多数开发者的时间报酬，来自程序的销售价值。
• 软件的销售价值与其开发成本（即实现其功能所需的资源成本）及其使用价值成正比。

换言之，人们普遍认为软件具有典型制成品^c的价值特征，但这两个假设都是错误的。

首先，为销售而编写的代码只是编程冰山的一角。在微型计算机普及之前曾有个公认的说法：全球90%的代码都是由银行和保险公司内部开发的。从宏观行业格局看，如今这一情况已发生改变——随着其他行业数字化程度的加深，金融业的相对份额想必已经下降。然而，从微观的企业实践来看，软件开发的基本模式并未改变：我们稍后将用实证数据表明，仍有约95%的代码由企业内部团队自行开发。

很多系统都有这类代码：各类管理信息系统（MIS）、所有大中公司都需定制的财务与数据库软件、设备驱动程序这类技术含量高的代码——几乎无人能靠单独销售驱动赚钱（这一点我们后文再谈），以及各种嵌入在日益依赖芯片/嵌入式系统的机器中的代码，从机床、喷气客机到汽车，乃至微波炉和烤面包机。

这类内部代码大多与应用环境高度耦合，导致它们极难复用或移植。（无论应用环境是商务办公场景的整套业务流程体系还是联合收割机的燃油喷射系统，皆是如此）正因如此，一旦应用环境发生变化，软件就需要持续维护以保持同步。

这就是“维护”，任何软件工程师或系统分析师都会告诉你，维护工作占据了绝大部分程序员超过75%的工作量。因此，大部分程序员的工时都耗费在了编写或维护那些完全没有销售价值的内部代码上。读者若想验证，随便翻看一份报纸的招聘版就能明白。

读者不妨亲自做一个很有启发的实验： 找一份本地报纸，翻到招聘版看看编程、数据处理和软件工程类职位，找出那些涉及软件开发的岗位，然后判断一下这些岗位开发的软件是自用还是用来销售的。

很快你便会发现，即使对“用于销售”作最宽泛的定义，至少95%的岗位薪酬，都完全来自软件的使用价值（即中间产品价值）。这便是我们认为仅有5%的软件行业是由销售价值驱动的理由。不过请注意，本文后续的分析对此具体数字并不敏感；即便该比例是15%甚至20%，其经济学结论依然适用。

我在技术会议上发言通常会先提出两个问题：观众里有多少人从事软件编写工作？又有多少人的薪水与软件的销售价值直接挂钩？对于第一个问题，几乎全场举手；而到了第二个问题，则应者寥寥，而两个问题举手人数的悬殊对比让听众感到惊讶。

其次，“软件的销售价值与其开发或重置成本^d挂钩” 这一观点，只需观察消费者的实际行为便不攻自破。确实有许多商品（如食品、汽车、机床）在折旧前的销售价值在一定程度上符合此比例关系；甚至有许多无形商品^e（例如音乐、地图或数据库的复制权）的销售价值也与开发和重置成本高度相关。

但软件截然不同：一旦软件供应商倒闭或产品停服，无论它理论上的使用价值有多高，或是功能等效产品的开发成本多高，消费者愿意支付的最大价格会迅速降到接近零（要验证这一点，去附近软件商店的清仓区看看就知道了）。

供应商退出市场时，零售商的反应很有启示意义：他们看清了一件供应商常常忽略的事。那就是，消费者的支付意愿，取决于他们对未来服务的预期价值（这里的“服务”包括升级、增强和后续支持）。

因此本质上讲，软件行业在实践中更接近服务业，却误以为自己属于批量制造业。

我们不妨想想，为什么大家通常会有相反的看法。原因可能很简单：软件行业里，真正把软件当作“产品”来制造和销售的那一小部分公司，恰恰也是唯一会在市场上打广告的。同时，人们心里普遍有种偏见，觉得制造业比服务业更“实在”，毕竟造出来的东西看得见、摸得着¹，这种想法可能也在暗中影响我们的判断。另外，那些最显眼、广告打得最凶的软件，往往是像游戏这类短期消费型产品，它们本身就不太需要后续服务（但这只是例外，不是常态）²。

还有一点值得注意，“软件是批量制造业”这个错觉，催生出的价格结构已经病态地偏离了实际成本。如果（正如公认的那样）一个典型软件项目超过75%的生命周期成本都花在维护、调试和功能扩展上，在这种前提下，收取高额一次性买断费、却只提供象征性服务甚至完全不收取服务费的模式，注定是双输局面。

消费者是受损的一方。因为，即便软件业本质是服务业，但在“工厂模式”下，所有激励机制都与提供合格服务的目标背道而驰。如果供应商靠现成的软件产品赚钱，那么他们的大部分精力都会放到量产推销这些产品上；无法创造利润的客服部门，则会沦为最无效员工的“收容所”，他们能获得的资源，也仅够避免流失关键数量的客户而已。

更糟的还在后头。软件一旦投入使用，服务需求便随之而来，除非对服务单独收费，否则利润空间将直接受到侵蚀。在开源模式下，追求的是尽可能庞大的用户基数，以获得最广泛的反馈和最具活力的衍生市场；而在闭源模式下，企业希望买家越多越好、实际用户越少越好。因此，“工厂模式”的内在逻辑，最终会毫不意外地奖赏那些生产 “货架软件” 的厂商，他们的产品营销做得无懈可击，足以畅销一时，实际却几乎毫无用处。

这一模式的另一面在于，从长远来看，采用这种“工厂模式”的大多数厂商也终将失败。想要依靠固定售价来支撑持续的服务成本，只有市场处于高速扩张期才可能实现，这就必须让未来的收入足以覆盖因昨日销售所产生的服务与产品生命周期成本。一旦市场成熟、销量放缓，多数厂商只能被迫停止服务与技术支持，让产品沦为“孤儿软件”来削减开支³。

无论厂商是明确行动（停止产品支持）还是暗中操作（让产品难以获得售后支持），结果都会让消费者转向竞争对手，因为这种做法会破坏产品的预期未来价值，而这种价值恰恰依赖于持续的服务。短期内，厂商可以通过发布看似新版本、实则仅为修复错误的更新来勉强应对，并为它贴上新的价格标签。但消费者很快就会感到厌倦。因此，从长远来看，厮杀中唯一的活路是垄断，使市场只剩下唯一的赢家^f。

实际上，我们已经一再看到，这种因服务支持枯竭而导致的失败模式，足以让市场中实力强劲的亚军也走向消亡。（对于任何曾梳理过专有PC操作系统、文字处理软件、会计程序乃至整个商业软件历史的人来说，这一规律应当尤为清晰。）“工厂模式”所催生的这种扭曲的激励机制，最终必然导向“赢家通吃”的市场格局，即使是最终的赢家，其客户也终将以损失收场。

若不采用“工厂模式”，出路何在？要真正高效地应对软件生命周期的实际成本结构（“高效”在此兼指日常语义与经济学术语中的涵义），我们就必须建立一套基于服务合同、订阅模式、厂商与客户持续价值交换为核心的定价体系。这正是像ERP（企业资源规划）系统这样的大型商业软件产品的已采用的通行模式，这些产品的开发成本极为高昂，任何固定售价都无法覆盖所有成本；像Baan^g和Peoplesoft^h这样的公司实际上是通过售后咨询服务盈利的。在自由市场追求效率的内在驱动下，我们可以预见：这将是成熟软件产业绝大多数领域最终的定价结构。

以上分析让我们初步看清：开源软件之所以对现有秩序构成日益严峻的挑战，不仅在技术层面，更在经济逻辑。软件“自由化”所产生的效应，似乎正在迫使我们进入一个由服务费主导的世界，并由此揭示：闭源软件中那些保密代码的销售价值，作为商业模式支柱是何等脆弱。

这一转变带来的阵痛，或许并不如表面看来那般剧烈。许多消费者发现，盗版软件（尤其是游戏、操作系统和生产力工具）很容易获得，因此，在消费者眼中，为许多专有软件付费的理由只在于它能换取其他东西：厂商支持、纸质手册，或是一种道德上的心安。商业化发行的所谓“自由”软件，其定价理由往往也与此如出一辙，唯一的区别在于，这些厂商不会自欺欺人地以为，软件代码本身就一定对客户有价值。

“自由”一词的误导性还体现在另一方面。降低商品本身的成本，往往会提升而非抑制对其支撑体系（人力与基础设施）的总投入。汽车价格下降，反而会推升对汽车技工的需求。同理，即使在开源世界中，目前那5%依靠软件销售价值获酬的程序员，也不太可能遭受损失。在这场转型中真正受损的，不是程序员，而是押注闭源策略、且该策略在经济上已难以为继的投资者。

4.4 信息渴望“自由”^a之迷思

还有一个与“工厂模式”的错觉对等且相反的迷思，这就是信息应该“自由”的说法，常常误导人们对开源软件经济学的理解。 这种说法的核心主张是：由于复制数字信息的边际成本^b为零，那么它的市场均衡价格^c也应为零（或者说，一个充斥着复制者的市场会将其价格压低至零）。

诚然，某些信息确实有渴望“自由”的一面，但这种“自由”是有前提的。技术标准文档就是一个很好的例子， 因为当更多人能获取这些信息时，它们的价值反而会增加。 然而，认为所有信息都渴望“自由”的观点却站不住脚，我们只需看那些指向竞争性商品^d的排他性信息就明白了，比如藏宝图、瑞士银行账号，或者电脑密码这类服务使用权凭证。 这类指引信息确实可以无限复制，然而它们所指的标的物（宝藏、账户、计算机服务）却无法被复制。 因此，标的物本身的非零成本属性，自然也就转嫁给了这些指引信息。

我们澄清这种迷思，主要是想说明：它与那些从实用角度支持开源的论证，几乎没有关联。 我们稍后就会看到，即使假定软件确实具备制成品那样的非零价值结构， 这些经济学论点依然能够成立。因此，我们无需探讨软件是否应该“自由”的问题。

4.5 反向公地的正向循环

在以怀疑的眼光审视了一种广为流传的模式之后，让我们来看看能否建立另一种模式：可以解释开源合作为何可持续的、实事求是的经济学解释。

我们需要从几个不同层面上考察该问题。一个是为开源项目做出贡献的个体的行为；另一个则是支撑像 Linux 或 Apache 这样的项目持续合作的经济力量。

再次强调，我们必须首先破除一个广为流传、妨碍理解的朴素观念。每当我们试图解释合作行为时，加勒特·哈丁"公地悲剧"的阴影始终笼罩其上。

哈丁让我们假想一片由当地牧民共有的草场，他们在那里放牛。但是，放牧会破坏公地、踩踏草地、留下泥泞的秃斑，而这些秃迹斑斑的植被恢复得又很缓慢。如果没有公认的（且强制执行！）的放牧权分配政策来防止过度放牧，各方利益的激励将驱使他们尽快、尽可能多地放牛，力求在公地退化成泥沼之前攫取最大价值。

大多数人对合作行为的直觉都与此非常相似。公地悲剧实际上源于两个相互关联的问题：一个是过度使用，另一个是供给不足。在需求方面，公地状况鼓励了因过度使用而导致的逐底竞争，经济学家将此称为拥挤性公共物品问题^b。在供给方面，公地奖励了搭便车行为^c，从而削弱甚至消除了个体行动者投资开垦牧场的动机。

公地悲剧只预测了三种可能的结果：草场变成泥沼；某个拥有强制力的行动者代表村庄强制执行分配政策（共产主义式解决方案^d）；公地解体，村民圈出自己能够防守并可持续管理的地块（产权式解决方案）。

当人们不经反思地将此模型应用于开源合作时，他们认为开源合作不稳定、持续时间很短。由于没有切实可行的方法能通过互联网强制执行程序员时间的分配政策，这个模型的直接后果是：公地将会解体，各种软件片段会被封闭源代码，而反馈回公共池的工作量将迅速减少。

事实上，经验清楚地表明，趋势与此相反。开源开发的广度和数量趋势，可以通过Metalab和SourceForge（主要的 Linux 源码站点）的每日提交量，或者 freshmeat.net（一个专门发布新软件广告的站点）的每日公告量来衡量。两者的数量都在稳步快速增长。显然，"公地悲剧"模型在某个关键方面未能捕捉到实际发生的情况。

部分答案在于，使用软件并不会降低其价值。实际上，开源软件得到广泛使用往往会增加其价值，因为用户会修复bug和增加新功能（提交代码补丁）。在这个反向公地里，草地越是有人放牧，它反而长得越旺。

这种公共物品不会因过度使用而退化，这解决了哈丁悲剧的一半，即拥挤的公共物品问题。但它不能解释为什么开源没有供给不足的问题。为什么搭便车行为在开源社区并不普遍，为什么他们不是等着别人来完成自己所需的工作，或者，即使自己做了工作，也不愿把成果回馈给公地呢？

部分答案在于，人们不仅仅需要解决方案，他们还需要及时的解决方案。预测别人什么时候能完成某项所需工作几乎是不可能的。如果修复一个 bug 或添加一个功能对任何潜在的贡献者来说回报足够大，那个人就会投入其中（此时其他人都搭便车的事实就无关紧要了）。

另一部分答案在于，对公共源码库的小补丁，其假定的市场价值是难以捕捉的。假设我写了一个修复某个 难缠的 bug 的补丁，并且假设许多人明白这个补丁可以变现，那我如何向这些用户收费？传统的支付系统的高昂开销，让通常合适的小额支付显得不合时宜。

更关键的一点可能在于，这种价值不仅难以捕捉，它在一般情况下甚至难以评估。我们不妨做一个思想实验：假设互联网配备了理论上理想的小额支付系统：它安全、普遍可访问，而且零成本。现在，假设你写了一个名为"Linux 内核杂项修复"的补丁。你怎么知道它应该要多少价钱？一个潜在买家，在还没看到补丁之前，又怎么知道付多少钱合理呢？

这几乎是F. A. 哈耶克的"计算问题"^e的哈哈镜映像，这个问题需要一个超人，既能够评估补丁的功能价值，又能够得到信任据此定价，才能保证交易顺畅。

不幸的是，存在严重的超人短缺，所以补丁作者 J. Random Hacker^f 只剩下两个选择：把补丁攥在手里，或者把它无偿投进公共代码池里。

把补丁攥在手里毫无益处。实际上，这反而会在未来产生成本，即在每个新版本中将该补丁重新合并到源代码库所需的工作量。因此，这种选择的收益实际上为负（并且会随着开源项目特有的快速发布节奏而倍增）。

更乐观地说，贡献者通过将补丁的维护开销，转移给源代码所有者和项目组的其他成员而获益，他也因其他人将来改进他的工作而获益。最后，因为他不必自行维护这个补丁，他有更多时间做其他规模更大的定制，来满足自己的需求。支持将整个软件包开源的那些论点，同样适用于补丁。

把补丁投进公共代码池可能一无所获，也可能激励他人的互惠成果，这些成果将来会解决 J. Random 的一些问题。这个看似利他的选择，从博弈论意义上讲，实际上是理性自利的最优解。

在分析这种合作时，重要的是要注意到，虽然存在搭便车问题（在没有金钱或金钱等价物补偿的情况下，工作可能供给不足），但是它并不随着最终用户的数量而扩展（详见尾注 1）。一个开源项目的复杂性和通信开销几乎完全取决于参与开发者的数量；拥有更多不看源代码的最终用户实际上不产生任何成本。这可能会增加项目邮件列表上蠢问题的数量，但通过维护一个FAQ（常见问题）列表，并坦然无视那些显然没读过它的提问者，可以相对容易地避免这种情况（实际上，这两种做法都很典型）。

开源软件中真正的搭便车问题，与其说在于其他方面，不如说更在于提交补丁的摩擦成本。一个在文化声誉博弈中没什么既得利益的潜在贡献者，在缺乏金钱补偿的情况下，可能会想："不值得提交这个修复，因为我得清理补丁，写变更日志条目，还要签署 FSF 的授权文件……"。正是因此，项目的贡献者数量（及其二阶效应，项目的成功）与每个项目让贡献用户需要跨过的门槛数量呈强烈的负相关。这些摩擦成本既可能是机械性的，也可能是政治性的。我认为它们共同解释了为什么松散、没有定形的 Linux 文化吸引的合作能量比组织更严密、更集中的 BSD 产出高出几个数量级——以及为什么随着 Linux 的崛起，自由软件基金会的重要性相对有所下降。

就解释范围而言，这些都很好，然而这只是 J. Random Hacker 创建补丁之后如何处理的事后解释。我们需要的另一半解释是，JRH 当初是怎么能写出那个补丁的，而不是被迫从事可能为他带来销售价值的闭源软件开发工作。是哪些商业模式创造了可以让开源开发蓬勃发展的利基市场？

4.6 选择闭源的理由

在给开源商业模式分类之前，我们通常应该先讨论闭源的排他性收益。当我们选择闭源时，我们究竟在保护什么？

假设你雇佣某人为你公司定制开发（比如说）一个会计软件包，这个问题并不会因为源码是闭源而非开源就能更好解决。你希望源码闭源的唯一理性原因，要么是你想把这个软件包卖给其他人，要么就是想阻止竞争对手使用它。

显而易见，你在保护销售价值，然而这点对于95%仅供内部使用的软件并不适用。那么，闭源还有其他什么好处呢？

第二种情况（保护竞争优势）值得稍加审视。假设你把那个会计软件包开源了，它开始有了热度，并从社区的改进中获益。现在你的竞争对手也开始用它，不仅无需开发成本就能获得好处，还在侵蚀你的业务。这是反对开源的理由吗？

也许是，也许不是。真正的问题在于，你通过分摊开发工作量所获得的收益，是否超过了搭便车者激化竞争所造成的损失。许多人对这种权衡的推理往往有失偏颇，原因在于：（a）忽视了招募更多开发人员所带来的功能优势，以及（b）没有将开发成本视为沉没成本。既然假设成立，你无论如何都必须支付开发成本，因此（如果你选择开源）将其视为开源的代价是错误的。

另一个经常被提及的理由是：担心公开某个特定专业会计功能的源码，可能等同于泄露你的商业机密。这实际上不是支持闭源的理由，而是反对劣质设计的理由。在编写得当的会计软件包中，业务知识根本不应该用代码来表达，而应该用由会计引擎实现的模式或规范语言来表达（一个很相近的例子：数据库模式将业务知识从数据库引擎的运行机制中解耦）。这种功能分离将使你能够保护核心资产（模式），同时从开源引擎的行为中获得最大收益。

还有一些闭源的理由是完全不理性的。例如，你可能误以为闭源会使你的业务系统更安全，能抵御骇客和入侵者。如果是这样，我建议你立即去找密码学家谈谈，保管能瞧好你不切实际的幻想。真正的安全业老鸟深知闭源程序并不安全可靠，因为他们从惨痛的经历中吸取了教训。安全性是可靠性的一部分，算法和实现只有经过彻底的同行评审，才可能信任它是安全的。

4.7 基于使用价值的开源资助模式

使用价值和销售价值的区别让我们注意到关键事实：只有销售价值会受到闭源到开源这一转变的威胁，而使用价值则不会。

如果软件开发真正的主要动力是使用价值而非销售价值，并且（正如《大教堂与集市》中所论证的）开源开发确实比闭源开发更有效、更高效，那么我们应该能够找到这样的情景：仅凭预期的使用价值，就能可持续地资助开源开发。

实际上，我们不难识别出至少两种重要的模式。在这些模式下，开源项目全职开发者的薪酬完全来自使用价值。

Apache的案例：分摊成本

假设你在一家公司工作，该公司有个关键业务需求：需要一台能处理海量请求、可靠性高的Web服务器。它可能用来支持电子商务高频交易，也可能用来给高流量媒体做广告营销，又或者用来支持门户网站日常运维。服务必须7x24小时不间断运行、必须速度快、还必须具备可定制性。

为满足你的需求，有三种基本策略可供选择：

• 购买专有Web服务器。 在这种情况下你赌的是：供应商的开发节奏和你的需求能对上，而且供应商的软件质量要过关、能及时响应你的需求。即使假设这两点都成立，产品在可定制性方面可能仍显不足，你只能通过供应商提供的钩子函数进行修改。从每月的Netcraft调查就可以看出，这种专有服务并不吃香，而且越来越不吃香。

• 自行开发。 自己搭建Web服务器并非可以立即排除的选择：Web服务器并不算复杂，肯定比浏览器简单，而且专门的服务器可以非常精简高效。走这条路，你可以获得你想要的精确功能和可定制性，尽管你要用开发时间来兑现。当你退休或者离职时，公司怕是要接手这份祖传代码。

• 加入Apache小组。 Apache服务器是由一群通过互联网协作的网管建立的，他们发现，将他们的成果集中起来共用一个代码库，比各自并行开发大量项目更明智。这么做之后，他们既保留了自行开发的大部分优势，又获得了大规模同行评审的强大调试效果。

选择Apache的优势非常显著，它究竟有多强，我们可以从每月的Netcraft调查中判断。该调查显示自Apache诞生以来，其市场份额相对于所有专有Web服务器稳步增长。截至2000年11月，Apache及其衍生版本占据了60%的市场份额（http://www.netcraft.com/survey/），它背后没有任何公司实体，没有做任何市场推广，也没有签约任何服务机构。

Apache的案例体现了一种模式：互相竞争的软件用户发现，合作起来资助开源开发对他们有利，因为这样做能让他们以更低的成本获得比其他方式更好的产品。

思科的案例：分散风险

几年前，思科（网络设备制造商）的两名程序员接到了一项任务：编写一个用于思科公司内部网络的分布式打印假脱机系统。这是一个相当大的挑战：除了要支持任意用户A在任意打印机B（可能在同一房间，也可能在千里之外）打印外，系统还必须确保在缺纸或墨粉不足的情况下，作业能够被重新路由到目标附近的一台备用打印机。该系统还需要能够向打印机管理员报告这些问题。

这两人想出了一套巧妙的修改方案，对标准的Unix打印假脱机软件做了修改（http://www.tpp.org/CiscoPrint/），还添加了一些包装脚本，顺利完成了任务。然后他们发现，他们自己和思科要面临一个问题。

问题在于，他们两个都不太可能永远留在思科。最终，这两位程序员都会离开，软件将无人维护，沦为祖传代码（即逐渐与现实世界条件脱节）。没有开发者愿意看到自己的作品落得这般下场，而这对勇敢的组合认为，思科付费购买解决方案，是基于一个并非不合理的期望：该方案的使用寿命能超过他们自己在思科的任职期限。

因此他们去找经理，强烈建议他批准将该打印队列软件作为开源软件发布。他们的理由是，思科不会损失任何销售价值，反而会有很多其他收获。思科可以激励一个遍布众多公司的用户和共同开发者社区发展壮大，从而有效地对冲软件原始开发者流失的风险。

思科的案例表明，开源不仅可以降低成本，还可以分散和减轻风险。所有参与方都发现，开放源代码，以及由多个独立收入来源资助的协作社区的存在，共同提供了一种本身具有经济价值的兜底机制，足以吸引资金为其买单。

4.8 销售价值的困境

开源让厂商难以从软件中获取直接销售价值。这种困难并非技术层面的原因，源代码和二进制代码在复制难易程度上并无本质区别，开源产品未必比闭源产品更难通过版权和许可法律保障销售价值。

这种困难的根源在于开源开发的社会契约本质。基于三个互为因果的理由，主流开源许可证禁止了对使用、再分发和修改的大多数限制，而这些活动恰恰是获取直接销售收入的关键手段。要理解这些理由，我们必须审视许可证在演进过程中的社会背景：互联网黑客文化。

尽管外界对黑客文化仍然存在广泛的误解，但这些理由没有一个与敌视市场有关。虽然少数黑客确实对逐利动机持排斥态度，但社区与Red Hat、SuSE、Caldera等盈利性Linux发行商合作的普遍意愿表明，只要合作符合自己的目标，大多数黑客就乐于与企业界合作。黑客们反对直接收入获取许可证的真正理由，其实更为微妙且深刻。

第一个原因涉及互惠性^a。虽然大多数开源开发者并不反对他人从自己的馈赠成果中获利，但他们同样要求任何一方（代码原创者可能例外）都不能处于垄断利润的优越地位。J. Random Hacker接受坑爹^b公司通过销售他本人的软件或补丁盈利，但前提是这种获利机会对他自己也平等开放。

第二个原因涉及意外后果。黑客们观察到，那些包含商业使用限制或销售费用的许可证（这是最常见试图获取直接销售价值的方式，初看似乎合理）会产生严重的寒蝉效应。一个具体表现是，它会为廉价CD-ROM选集的再分发等我们本应鼓励的活动蒙上法律阴影。使用/销售/修改/分发的限制（以及许可条款的其他复杂性）需要人们付出额外开销来追踪合规情况，而且随着人们处理的软件包越来越多，感知到的不确定性和潜在法律风险也将呈组合式爆炸。黑客们认为这种结果是有害的，因此圈内有强大的舆论压力要求许可证简洁、无限制。

最后一个也最关键的原因，在于捍卫《垦殖智域》中提到的同行评审和礼物文化的运作模式。旨在保卫知识产权或获取直接销售价值的许可限制，往往在法律上断绝了fork^c项目的可能性。Sun公司针对Jini和Java的所谓"社区源代码"许可证就属于这种情况。虽然大家普遍对fork行为嗤之以鼻，也认为这种行为是万不得已之举（原因在《垦殖智域》中有详细论述），但是当维护者无能或背刺（例如转向更封闭的许可证）时⁵，保留这个最后的手段至关重要。

黑客社区对互惠性理由有一定弹性，因此能容忍网景通信公司（Netscape，后文简称网景）公共许可证（NPL）这类给予代码原创者某些利润特权的许可证（就NPL而言，原创者拥有在包含闭源代码的衍生作品中独家使用开源Mozilla代码的权利）。然而对于意外后果的理由，社区的弹性较小；而对于保留fork选项的权利，则完全没有妥协余地（这就是社区基本拒绝Sun的Java和Jini社区源代码许可方案的理由）。

（这里有必要重申：黑客社区中没有人希望项目分裂成相互竞争的开发分支；实际上，正如我在《垦殖智域》中所观察到的，出于充分的理由，存在反对fork的非常强大的社会压力。同样也没有人希望被卷进纠察线、法庭或枪战中。但fork权就像罢工权、诉讼权或持枪权，你不必行使其中任何一个权利，然而有人想剥夺这些权利就是严重危险的信号。）

这些理由解释了《开源定义》中的条款，该定义体现了黑客社区对标准许可证（如 GPL、BSD 许可证、MIT 许可证和艺术许可证）核心要素的共识。这些条款客观上（尽管并非主观意图）让厂商极难获取直接销售价值。

4.9 开源软件的间接获利之道

然而，确实存在一些围绕软件相关服务构建市场的模式，能够获取类似间接销售的价值。目前有五种已知模式和两种探索性模式属于此类（未来可能还会发展出更多模式）。

舍卒保车，抢占市场

在这种模式下，你利用开源软件为专有软件创造或维持市场份额，而这些专有软件能带来直接收入流。最常见的形式是，开源客户端软件带动服务器软件销售，或带动与门户网站相关的订阅/广告收入。

网景通信公司在 1998 年初将 Mozilla 浏览器开源时，采用的就是这一策略。当时，他们浏览器业务的收入已降至总收入的 13%，并且还在微软首次发布 IE 浏览器后持续下滑。微软大力营销 IE（以及后来成为反垄断诉讼核心问题的涉嫌不当的捆绑行为），迅速蚕食了网景的浏览器市场份额，这引发了人们的担忧：微软意图垄断浏览器市场，然后利用对 HTML 和 HTTP 的事实控制权将网景挤出服务器市场。

网景通过将旗下仍广受欢迎的浏览器开源这一做法，有效地阻止了微软垄断浏览器市场。他们期望开源协作能加速浏览器的开发和调试，并希望微软的 IE 不得不被动追赶，从而无法垄断 HTML 标准。

这一策略奏效了。1998 年 11 月，网景实际上开始从 IE 手中夺回部分商业市场份额。到 1999 年初美国在线收购网景时，保持 Mozilla 项目活跃的竞争优势已非常明显，以至于美国在线最初的公开承诺之一就是继续支持当时仍处于 Alpha 阶段的 Mozilla 项目。

开源软件，反哺硬件

此模式适用于硬件制造商（这里的硬件包括：从以太网等外围板卡，到完整的计算机系统）。市场压力迫使硬件公司编写和维护软件（从设备驱动程序、配置工具等简单软件，直至整个操作系统层面的复杂软件），但软件本身并非利润中心，它是一项通常不菲的开销。

在这种情况下，开源是显而易见的明智之举。因为不会损失任何收入流，所以没有负面影响。供应商获得的是显著扩大的开发者群体、对客户需求更快速灵活的反应，以及通过同行评审带来的更高可靠性，还能免费获得面向其他环境的移植版本。更重要的是，当客户的技术人员根据需要投入更多时间来改进源代码时，供应商还可能赢得更高的客户忠诚度。

供应商通常会针对开源硬件驱动程序提出一些特定的反对意见。为了避免将这些意见与更通用的问题混在一起，我将另行撰文讨论此话题（见《后记：闭源驱动导致供应商亏损的原因》）。

开源带来的"长效兼容"效应在硬件领域尤为突出。硬件产品的生产和售后支持是有期限的，之后客户就只能靠自己了。然而如果他们能获得驱动源代码，并能根据需要自行修补，他们就更有可能成为满意的回头客。

苹果电脑公司在 1999 年 3 月中旬决定将 Mac OS X 服务器操作系统的内核"Darwin"开源，是采用"开源软件，反哺硬件"模式的、非常引人注目的案例。

共享配方，经营餐馆

在这种模式下，开源软件不是为了像舍卒保车模式那样为封闭软件创造市场地位，而是为了服务。（我曾称之为"羊毛出在羊身上"，但这里面的耦合关系其实不像羊毛和羊那么紧密。）

此模式由 Cygnus Solutions 首创，该公司可算作第一家开源商业公司（1989 年）。当时，GNU 工具为多种机器提供了通用的开发环境，但每种工具都使用不同的配置过程，并且需要一套不同的补丁才能在各个平台上运行。Cygnus 公司整合了 GNU 的工具链，并创建了 configure^a 脚本以统一构建过程（这就是标题说的配方），然后销售与他们的 GNU 工具版本捆绑在一起的二进制文件和支持服务（这就是标题说的餐馆）。根据 GPL 许可证的规定，他们允许客户自由使用、分发和修改其分发的软件，如果站点使用支持服务的用户数量超出合同约定，则可以终止服务合同或要求支付更高费用（就像吃自助餐不能几个人合买一份拼单）。

这也是 Red Hat 和其他 Linux 发行商所做的。他们实际销售的并非软件本身，而是通过组装测试一个可运行的操作系统所增加的价值，而这个系统即便只是默示担保^b，也具备适销性^c，能与其他相同品牌的系统实现即插即用。他们价值主张的其他要素包括免费安装支持和提供持续支持合同的选择。

开源的"市场建设"效应可能极为强大，尤其是对于那些从一开始就必然处于服务位置的公司而言。最近一个非常有启发性的案例是 Digital Creations，这是一家成立于 1998 年的网站设计公司，专门从事复杂的数据库和交易网站建设。他们的主要工具，也就是公司的知识产权的看家本领，是一个对象发布器，曾有过几个名字和版本，现在被称为 Zope。

当 Digital Creations 寻求风险投资时，他们引入的风险投资家仔细评估了他们的潜在市场、团队和工具。然后，这位风险投资家建议 Digital Creations 将 Zope 开源。

按照传统软件行业的标准，这看起来绝对是疯狂的举动。传统的商学院观点认为，像 Zope 这样的核心知识产权是公司的看家本领，无论如何都不能放弃。但这位风险投资家有两个相关的洞察：一是 Zope 真正的核心资产实际上是其团队成员的才智和技能；二是 Zope 作为市场开拓工具可能比作为秘密武器创造更多价值。

要理解这一点，可以比较两种情景。在传统情景下，Zope 仍是 Digital Creations 的秘密武器。假设它非常有效，公司将能够在短时间内交付高质量产品，但问题是没人知道。让现有客户满意很容易，然而在起步阶段建立客户群却更难。

相反，这位风投家看到，将 Zope 开源可能是对 Digital Creations 真正的资产，也就是公司团队，起到关键的宣传作用。他预计，评估 Zope 的客户会认为雇佣 Zope 的专家比自己培养相应的专家更有效率。

此后，Zope 的一位负责人非常公开地证实，他们的开源战略"开启了许多原本无法进入的大门"[原文如此]，潜在客户也确实对这种情况的逻辑做出了回应。因此，Digital Creations 发展得很好。

另一个最新的例子是 e-smith 公司（http://www.esmith.net/）。这家公司销售开源的一体化互联网服务器软件（一种定制的 Linux）的支持合同。该公司的一位负责人就自家软件免费下载分发这一点做出回应："大多数公司会认为那是软件盗版，而我们认为那是免费营销（http://www.globetechnology.com/gam/News/19990625/BAND.html）。"

立足开源，销售周边

在这种模式下，你销售的是开源软件的周边产品，包括低端产品和高端产品：低端产品如马克杯和T恤，高端产品如经过专业制作校对的文档。

O'Reilly & Associates 公司出版了许多优秀的开源软件参考书籍，它是"销售周边"模式的一个绝佳例证。O'Reilly 实际上雇佣并支持著名的开源黑客（如 Larry Wall 和 Brian Behlendorf），以此在目标市场中建立声誉。

限期闭源，永久开源

在这种模式下，你发布的软件以二进制和源代码形式附带一份闭源许可证，然而这个闭源条款是有期限的。举个例子，你可以写一份许可证允许软件免费再分发，但未经付费不得用于商业用途；另外，如果该软件在发布已满一年或供应商倒闭，软件将适用 GPL 条款。

在这种模式下，客户可以根据自身需求进行定制产品，因为他们拥有源代码。产品是"面向未来"的：因为许可证保证如果原公司倒闭，开源社区就可以接手该产品。

销售价格和数量是基于这些客户预期的，因此与纯粹采用闭源许可证发布相比，原公司应该能从其产品中获得更高的收入。此外，随着较旧的代码采用 GPL 许可，它们将得到严格的同行评审、错误修复和次要功能改进，会部分减轻原创者高达 75% 的维护负担。

这一模式已被 Aladdin Enterprises（广受欢迎的 Ghostscript 程序的开发商）成功采用。Ghostscript 是一款 PostScript 解释器，能够将 PostScript 语言转换为多种打印机的原生语言。

此模式的主要缺点是，闭源条款往往会在产品周期的早期（也是最需要同行评审和参与的时候）阻碍同行参与评审代码。

解放软件，销售品牌

这是一种探索性的商业模式。你将一项软件技术开源，并保留相应的测试套件和兼容性标准，再向通过兼容认证的实现方，出售品牌授权。

（这正是 Sun Microsystems 对 Java 和 Jini 理应采用的方式。）

更新：2000 年 7 月，Sun 宣布将旗下的 Star Office 开源，并且他们将向那些通过了 Sun 验证套件的、基于该代码库的开发分支，授权使用 Star Office 品牌。

解放软件，销售内容

这是另一种探索性的商业模式。比如股票行情订阅服务，它的价值既不在于客户端软件，也不在于服务器，而在于提供客观可靠的信息。因此你将所有软件开源，并销售内容的订阅服务。只要黑客将客户端移植到新平台、以各种方式增强它，你的市场会自动扩大。

（这就是AOL理应将自家客户端软件开源的理由。）

4.10 何时开源，何时闭源

在回顾了支持开源软件开发的商业模式之后，我们现在可以探讨一个普遍性问题：什么时候开源具有经济意义，什么时候闭源更合适。首先，我们必须清楚每种策略的收益是什么。

收益何在？

闭源方法允许你从保密的代码中收取垄断收益^a，而另一方面，它排除了真正独立同行评审的可能性。开源方法为独立同行评审创造了条件，但你无法从私有技术中获得垄断收益。

拥有私有技术的垄断收益众所周知，而传统的软件商业模式都是围绕这一点构建的。直到最近，独立同行评审的收益才被人们充分理解。然而，Linux 操作系统的惨痛教训，我们可能早该从互联网核心软件的历史以及其他工程领域学到：开源同行评审是实现高可靠性和高质量的唯一可扩展方法。

因此，在竞争激烈的市场中，寻求高可靠性和高质量的客户会奖励那些走向开源，并学会在软件相关的服务、增值和辅助市场中维持收入流的软件生产者。Linux 的惊人成功背后，正是这一现象。Linux 在 1996 年异军突起，到 2000 年中期已成为商业服务器市场上第二受欢迎的操作系统（而一些调查实际上显示，在 2000 年底它的份额超过了微软）。在 1999 年初，IDC 预测，到 2003 年 Linux 的增长速度将超过所有其他操作系统的总和，而这一预测至今仍然准确。

开源几乎同样重要的一个收益是，它作为推广开放标准和围绕这些标准建立市场的一种工具。互联网的迅猛增长很大程度上归功于没有人拥有 TCP/IP，也没有人对核心互联网协议拥有专有控制权。

TCP/IP 和 Linux 成功背后的网络效应^b相当清晰，最终归结为信任和对称性问题^c：共享基础设施的参与方若能看清其底层运行逻辑，自然会对这套体系更加信赖。而且他们会更倾向于让所有参与者权利对称的基础设施，而不是某一参与者处于特权地位、榨取垄断收益或单方施加控制的基础设施。

然而，对于软件消费者而言，对称性问题的重要性实际上并不需要假设存在网络效应。如果存在质量可接受的开源替代方案，理性的软件消费者不会选择依赖闭源软件，让自己受制于垄断供应商。软件对消费者的业务越关键，这一论点就越有说服力：软件越重要，消费者就越不能容忍它被第三方控制。

这还有另一面。经济学家知道，总的来说，信息不对称^d会使市场运作不良。当从特权信息中收取垄断收益比投资于生产更好的产品更有利可图时，较高质量的商品就会被驱逐出市场。总的来说，不仅在软件领域，即使在别的领域保守技术秘密，也同样不利于产品品质提升。

最后与信任问题相关的是，开源软件的一个重要客户收益是它具有面向未来的特性。如果源代码是开放的，那么即使供应商倒闭，客户也有一定的补救措施。这对于“开源软件，反哺硬件”（指为硬件配套的软件）可能尤其重要，因为硬件的生命周期通常很短，但这种效应更有普遍性，会转化为各种开源软件的附加价值。

它们如何相互作用？

当私有技术的收益高于开源的回报时，闭源在经济上是合理的。当开源的回报高于私有技术的垄断收益时，开源就是有意义的。

这本身是一个显然的论断。然而当我们注意到开源的收益比私有技术的收益更难衡量和预测，而且这种收益被严重低估的频率远高于被高估的频率时，它就变得重要了。事实上，在主流商界因 1998 年初 Mozilla 源代码发布而开始重新思考其基本假设之前，人们错误地、但普遍地假定开源的收益为零。

那么，我们如何评估开源的收益呢？总的来说，这是一个难题，但我们可以像处理任何其他预测问题一样来处理它。我们可以从观察到的开源方法成功或失败的案例开始。我们可以尝试归纳出一个模型，这个模型至少能在定性层面，让我们感受到在哪些情境下，对于试图最大化回报的投资者或企业而言，开源是“净收益”。然后，我们可以回到数据，尝试完善这个模型。

根据《大教堂与市集》中提出的分析，我们可以预期开源在以下情况下具有高收益：(a) 可靠性/稳定性/可扩展性至关重要，并且 (b) 设计和实现的正确性不容易通过独立的同行评审以外的方式验证。（实际上，大多数复杂程序都满足第二个标准。）

消费者出于理性，会希望避免陷入被某一垄断供应商锁定的局面。软件对这位消费者变得越关键，他们越会对开源感兴趣（因此，也增加了供应商开源的竞争市场价值）。因此，另一个标准 (c) 在软件是业务关键型资本品时（例如，在许多企业 MIS 部门中），会推动走向开源。

至于应用领域，我们上面观察到开源基础设施创造了信任和对称效应，随着时间的推移，这些效应往往会吸引更多客户，并胜过闭源基础设施。另外，在一个快速扩张的市场中占据较小的份额，通常比在一个封闭停滞的市场中占据较大的份额更好。因此，对于基础设施软件，以普及为目标的开源策略，其长期收益很可能高于以知识产权收益为目标的闭源策略。

实际上，潜在客户推理供应商策略未来后果的能力，以及他们不愿接受供应商垄断的态度，意味着一个更强的约束条件；在没有已经拥有压倒性市场力量的情况下，你可以选择开源的普及策略，或者选择从闭源软件获得直接收入的策略——但不能两者兼得。（这一原则的类似情况在其他领域也能看到——例如，在电子产品市场中，客户常常拒绝购买单一来源的设计。）这个情况也可以不那么消极地表述：在网络效应（正网络外部性）占主导地位的地方，开源很可能是正确的选择。

我们可以通过观察总结这个逻辑：当软件 (d) 对于基础设施软件，开源的回报往往更高。

最后，我们可能会注意到，独特或高度差异化服务的提供者，比起那些关键算法和知识库已经被充分理解的服务供应商，更担心他们的方法被竞争对手复制。因此，当 (e) 关键方法（或其功能等价物）属于通用工程知识的一部分时，开源更有可能占据主导地位。

互联网核心软件、Apache 和 Linux 对标准 Unix API 的实现，是所有五个标准的主要范例。这些市场演变中走向开源的道路，可以很好地从 20 世纪 90 年代中期数据网络重新统一于 TCP/IP 的过程中看出，此前 15 年间，人们曾尝试使用 DECNET、XNS、IPX 等封闭协议来建立帝国的尝试均告失败。

另一方面，开源对于那些独特拥有价值生成软件技术的公司似乎最没有意义，这些技术（强烈符合标准 (e)），(a) 对失败的容忍度相对较高，(b) 可以很容易地通过独立同行评审以外的方式验证，(c) 不是业务关键型的，并且 (d) 其价值不会因网络效应或普及而大幅增加。

作为这个极端情况的例子，在 1999 年初，一家公司问我：“我们应该开源吗？”该公司编写的软件用于计算锯木厂的切割模式，以便从原木中提取最大数量的板材。我的结论是“不应该”。唯一勉强符合的标准是 (c)；但在紧要关头，经验丰富的操作员可以手工生成切割模式。

请注意，如果这个切割模式计算器是由一家锯木厂设备制造商编写的，我的答案可能会大不相同。在这种情况下，开放代码会增加他们正在销售的相关硬件的价值。还要注意，如果已经存在某种开源的切割模式计算器（也许是锯木厂设备制造商编写的那一个），那么闭源产品将很难和它竞争——这与其说是价格原因，不如说是客户会感知到开源在可定制性和其他特性方面的优势。

重要的一点是，特定产品或技术在这些尺度上的位置可能会随时间变化，我们将在下面的案例研究中看到这点。

总结一下，以下判定因素会推动开源：

1. 可靠性/稳定性/可扩展性至关重要。

2. 设计和实现的正确性不容易通过独立同行评审以外的方式验证。

3. 软件对用户控制其业务至关重要。

4. 软件建立或支持通用的计算和通信基础设施。

5. 关键方法（或其功能等价物）属于通用工程知识的一部分。

毁灭战士：案例研究

id 公司最畅销的游戏《毁灭战士》的历史，说明了市场压力和产品演变如何能够决定性地改变闭源与开源的收益大小。

当《毁灭战士》于 1993 年底首次发布时，它的第一人称实时动画独一无二（与标准 (e) 相反），不但这项技术的视觉效果令人震撼（远远超过其前作《德军总部 3D》的平面世界动画），而且在好几个月里，没人能弄清楚在那个时代性能不足的微处理器上是如何实现的。这些保密的代码值得收取非常可观的垄断收益。此外，开源的潜在收益很低。作为一款单机游戏，该软件 (a) 失败带来的成本容忍度较高，(b) 验证起来不是特别困难，(c) 对任何消费者都不是业务关键型的，并且 (d) 没有从网络效应中受益。从经济角度看，《毁灭战士》闭源是合理的。

然而，《毁灭战士》周边的市场并没有停滞不前。潜在的竞争对手发明了其动画技术的功能等价物，其他“第一人称射击”游戏如《毁灭公爵》开始出现。随着这些游戏蚕食《毁灭战士》的市场份额，私有技术垄断收益的价值下降了。

另一方面，扩大市场份额的努力带来了新的技术挑战——游戏要更可靠、有更多功能、用户群更大以及支持多平台。随着多人“死亡竞赛”游戏和《毁灭战士》游戏服务的出现，市场开始显示出显著的网络效应。所有这些都需要程序员的工作时间，而 id 更愿意将这些时间投入到下一款游戏上。

从游戏首次发布起，id 就一直对 mod 创作持宽容态度：不反对公开创建自定义数据内容的技术规格文档，并偶尔回答特定问题、发布他们自己现有的规格文档，并直接与 mod 作者合作。他们还鼓励在互联网上分发《毁灭战士》新数据的行为。

技术和市场趋势提高了开放源代码的收益；《毁灭战士》开放规格文档、鼓励第三方扩展的做法，不仅增加了游戏的感知价值^e，还为他们创造了一个可以利用的二级市场。在某个点上，收益曲线发生了交叉，id 转向在这个二级市场赚钱（通过诸如游戏场景选集等产品），然后开放《毁灭战士》的源代码，这在经济上变得合理了。在这个时间点之后的某个时候，它真的发生了。《毁灭战士》的完整源代码于 1997 年底发布。

知道何时放手

《毁灭战士》是一个有趣的案例研究，因为它既不是操作系统，也不是通信/网络软件；因此它与通常显而易见的开源成功案例相去甚远。事实上，《毁灭战士》的生命周期，连同其交叉点，可能会开始成为当今代码生态中应用软件的典型——在这个生态中，通信和分布式计算都产生了严重的健壮性/可靠性/可扩展性问题，这些问题只能通过同行评审来解决，并且经常跨越技术环境之间以及竞争参与者之间的边界（这隐含了所有信任和对称性问题）。

《毁灭战士》从单机玩法演变为死亡竞赛玩法，网络效应也正日益成为计算本身的核心。即使在最重量级的商业应用中，如 ERP 系统，也能看到类似的趋势，因为企业与供应商和客户之间的网络连接日益紧密——当然，这些也隐含在整个万维网的架构中。由此可见，几乎在所有地方，开源的收益都在稳步增长。

如果目前的趋势继续下去，下个世纪软件技术和产品管理的核心挑战将是知道何时放手——何时允许封闭代码进入开源基础设施，利用同行评审效应，在服务和其他二级市场中获取更高的回报。

过远偏离交叉点（无论太早或太晚）显然都会导致收入损失。除此之外，等待太久还存在严重的机遇风险——你可能会被在同一市场领域率先开源的竞争对手抢先。

这是一个严重的问题，因为对于任何特定的产品类别，可用于招募参与开源合作的用户和人才库都是有限的，而且招募具有粘性。如果两个生产商先后将功能大致相当的竞争代码开源，第一个可能会吸引最多的用户以及最多、最有动力的合作开发者，而第二个则只能拾取残羹剩饭。这种招募具有粘性，因为用户会获得熟悉度，而开发者会在代码本身上投入时间。

4.11 以开源为战略利器

有时开源不仅能有效地扩大市场，还可以作为对抗公司竞争对手的战略手段。从这个角度重新审视上述的一些商业策略将大有裨益——不是直接把开源当作收入来源，而是作为打入市场、重塑市场格局的途径。

成本分担作为竞争武器

之前，我们认为 Apache 是通过开源项目中的成本分担来实现更好、更廉价的基础设施开发的典范。对于与微软及其 IIS 网络服务器竞争的软件和系统供应商而言，Apache 项目也是一种竞争武器。对于网络服务器供应商来说，微软拥有巨额的战略资金储备，在桌面市场也具有垄断地位，要完全抵消这种优势，是困难甚至是不可能的。然而，Apache 让项目中的每个企业都能提供在技术上优于 IIS，并以多数市场份额赢得客户信任的网络服务器，而且成本要低得多^a。这提升了增值电子商务产品（如 IBM 的WebSphere）的市场地位，降低了其生产成本。

这一原理具有普遍性。开放的、共享的基础设施为其参与者带来了竞争优势。第一，每个参与者生产和销售可盈利产品及服务的成本更低。第二，这样的市场地位能赢得客户信赖，他们不太可能因为某个供应商的战略或战术改变而陷入"孤儿技术"的困境。

重置竞争格局

在 20 世纪 80 年代，当开源 X Window 系统的开发由DEC资助时，他们的明确目标就是"重置竞争格局"。当时，Unix 有多个相互竞争的窗口系统^b，其中 Sun 微系统公司的 NeWS 系统最有竞争力。DEC 的战略专家们认为（他们可能是正确的），如果 Sun 能够建立一个专有的图形标准，它就能在蓬勃发展的 Unix 工作站市场上获得垄断地位。DEC 通过资助 X Window 系统、为其提供工程师的方式，同时与众多小型供应商结盟，将 X Window 系统打造为事实标准，借此消解 Sun 等公司在图形领域固有的竞争优势。这将工作站市场的竞争焦点转移到了硬件领域，而这正是 DEC 历史上占据优势的领域。

这一原理同样具有普遍性。开源对聪明的客户以及那些规模不够大、无法独立资助竞争性开发的潜在盟友具有吸引力。一个在恰当时机推出的开源项目，不仅能成功地与闭源替代品竞争，甚至能阻断闭源竞品的市场切入机会，从而重置竞争格局，并将其从发起公司处于弱势的领域转向它的强势领域。

把"池塘"做大

红帽软件公司（Red Hat）资助开发了 RPM 打包系统^c，目的是为 Linux 世界提供一个标准的二进制包安装程序。通过这样做，他们押注的是：这样的标准安装程序将提升潜在客户的信心，由此带来的长期收益，将超过软件的开发成本，也足以覆盖因竞品共用该工具而流失的潜在收入。

有时，成为一只更大青蛙的最聪明方法就是让池塘增长得更快。当然，这就是技术公司参与公共标准制定的经济原因——将开源软件当作一种可执行的标准是很有益的。这一策略不仅很好地示范了市场开拓者策略，而且当一家小公司利用它来抵消在标准联盟之外的、另一家规模大得多的公司的体量和市场力量时，它就直接成了一种竞争武器。就红帽而言，它公认的明显大竞争对手是微软；在大多数 Linux 发行版中实现 RPM 的标准化，在很大程度上有效削弱了微软 Windows 系统在运维便捷性上的原有优势。

防止受制于人

在解释之前的"战略性亏损/市场定位者"商业模式时，我曾描述过网景将 Mozilla 浏览器开源是通过怎样一种（成功的）策略，有效遏制微软垄断 HTML 标记语言和 HTTP 协议的企图。

通常情况下，阻止竞争对手在特定技术上扼制你，比你自己控制该技术更为重要。通过开源，你可以极大地扩大你的"阻击联盟"的潜在规模。

4.12 开源视角下的战略性商业风险

归根结底，开源之所以似乎注定成为一种普遍实践，根本原因更多在于客户需求和市场压力，而不是供应商侧的效率优势。我之前已经从供应商的角度讨论了客户对可靠性、无单一主导厂商的基础设施的需求所带来的影响，以及这些因素在网络技术演变历史中如何发挥作用。然而，在开源成为一个影响要素的市场中，关于客户的行为，还有更多值得探讨之处。

暂且站在《财富》（Fortune） 500 强公司 CTO 的角度，设想你正计划构建或升级公司的 IT 基础设施。也许你需要选择一个将在全公司范围内部署的网络操作系统；也许你关注的是 7x24 小时不间断的 Web 服务和电子商务；也许你的业务依赖于能够搭建高吞吐量、高可靠性的事务数据库。

假设你选择了传统的闭源路线。如果这样，你就将公司置于供应商垄断的支配之下——因为从定义上讲，你只能从单一来源获取支持、错误修复和功能增强。如果供应商表现不佳，你将没有有效的追索手段，因为你已经被初始投资和培训成本牢牢锁定。你的供应商对此心知肚明。在这种情况下，你认为软件会为了满足你的需求和你的商业计划而改变……还是会为了满足供应商的需求和供应商的商业计划而改变？

残酷的事实是：当你的关键业务流程由那些你甚至无法查看内部（更不用说修改）的不透明代码块所执行时，你就已经失去了对业务的控制。你更需要你的供应商，而不是供应商更需要你——而这种权力失衡将让你一次又一次付出代价。你会付出更高的价格，你会错失机会，而且随着供应商（通过在无数过往客户身上磨练出的手段）收紧控制，你还会因锁定效应^a付出越来越高的代价。

看看与此相对的开源选项。如果你走这条路，你拥有源代码，谁也夺不走它。你将不再面对遏制你业务的供应商垄断，而是有多家服务公司竞相争取你的业务——你不仅可以让它们相互竞争，而且如果比外包更便宜，你还能自建内部支持团队。整个市场将为你所用。

其中的逻辑令人信服：依赖闭源代码构成了不可接受的战略性商业风险。这一点如此明确，以至于我相信，在存在开源替代方案的情况下，企业仍然采购闭源的单一供应商产品，很快就会被视为真正的受托责任失职，并成为股东提起诉讼的正当理由。

4.13 开源软件的商业生态

开源社区的组织方式往往能放大开源带来的生产力效应。尤其是在 Linux 世界中，一个具有重要经济意义的客观事实是：存在多个相互竞争的 Linux 发行商，它们构成了独立于开发者的另一个层级。

开发者编写代码，并将代码通过互联网公开。每个发行商从这些公开的代码中选取一部分，进行集成、打包和品牌化，然后销售给客户。用户在不同发行版之间进行选择，也可以直接从开发者网站下载代码来补充现有发行版。

这种层级分离的效果，是为软件改进创造了一个极其活跃的内部市场。开发者为了赢得发行商和用户的关注，在软件质量上相互竞争。发行商则为了争夺用户市场，在其选择策略的合理性以及能为软件增加的价值上相互竞争。

这一市场结构的首要效应是，在开源生态网络中没有哪个节点是不可或缺的。开发者可以退出；即使他们所负责的代码部分没有被其他开发者直接接手，各方争夺关注度也往往会迅速催生出功能替代品。发行商可能失败，但这不会损害或危及公共的开源代码库。与任何单一的大型一体化闭源操作系统厂商相比，整个生态能够更快速地响应市场需求，并且具备更强的抵御冲击和自我再生的能力。

另一个重要效应是通过专业化降低开销、提高效率。开发者不会面临那些通常拖累传统闭源项目并将其变成“焦油坑”的压力——不必应付市场部门提出的各类分散精力、用来凑数的功能需求，也没有管理层强制要求使用不合适或过时的语言或开发环境，也不需要以产品差异化或知识产权保护为名，刻意采用不兼容的新方式去重复造轮子；而且（最重要的是）没有截止期限，不必在软件尚未打磨完善前就仓促上线1.0版本。DeMarco 和 Lister 在《人件》（Peopleware: Productive Projects and Teams）一书中讨论“结束了再叫我”这种管理风格时指出，这种管理模式不但提高产品质量，还能更快交付可用成果。

另一方面，发行商则可以专注于自身核心强项。他们无需为维持竞争力，持续投入巨额资金开展大规模研发，得以专心做好系统集成、软件打包、质量管控与技术服务。

用户持续的反馈与监督，作为开源模式的重要组成部分，约束着开发者与发行商，促使双方恪守经营准则。

4.14 与成功共处

“公地悲剧”或许并不适用于当今的开源开发，但这并不意味着我们就没有理由去思考：开源社区当前的势头能否持续下去？随着赌注越来越大，关键参与者会背叛合作吗？

这个问题可以从多个层面来探讨。我们提出的“公地喜剧”这一对立叙事，其核心论点是：个人对开源的贡献难以货币化。但对于 Linux 发行商这类已依托开源实现营收的企业而言，该观点便不再有太强说服力，因为它们的贡献每天都在被货币化。它们目前的合作角色稳定吗？

探讨这个问题将引导我们得出一些有趣的见解。它既能帮助我们理解当下开源软件的经济逻辑，也能看清纯粹而简单的服务型行业范式将给软件行业带来怎样的未来。

在实操层面上，针对当前存在的开源社区，这个问题通常有两种不同的提法。一：Linux 会走向分裂吗？二：反过来说，Linux 会出现一个占主导地位、近乎垄断的厂商吗？

人们在思考 Linux 是否会分裂时，经常援引的历史类比是20世纪80年代专有 Unix 厂商的行为。尽管各方都在反复倡导开放标准，也建立了无数联盟、协会和协议，专有Unix最终还是分崩离析了。厂商们通过添加和修改操作系统功能来实现产品差异化的愿望，最终压倒了通过保持兼容性来扩大整个 Unix 市场规模的兴趣——而保持兼容性本可以降低独立软件开发商的准入门槛，也能降低用户的总体拥有成本。

这种情况极不可能发生在 Linux 身上，原因很简单：所有发行商都必须依托统一的开源代码库开展运营。任何一家发行商要想保持差异化几乎是不可能的，因为 Linux 代码开发所采用的许可证实际上要求它们与所有各方共享代码。一旦某个发行商开发出一个新功能，所有竞争对手都可以自由地克隆它。

既然各方都明白这一点，没有厂商会重蹈当年专有 Unix 分裂的覆辙。相反，Linux 发行商被迫以真正有利于消费者和整个市场的方式竞争。也就是说，它们必须在服务、支持上竞争，以及比拼接口设计，看谁的方案更便于安装与使用。

公共代码库也排除了垄断的可能性。当 Linux 社区的人担心垄断时，最先想到的名字通常是“红帽”——这家最大、最成功的发行商（在美国估计占有约90%的市场份额）。但值得注意的是，在1999年5月红帽宣布其期待已久的6.0版本发布后的几天内——甚至在红帽的光盘还没有批量发货之前——一家图书出版商和其他几家光盘发行商就已经开始打广告，销售基于红帽公共 FTP 站点构建的该版本光盘镜像，价格还低于红帽的官方定价。

红帽本身对此毫不在意，因为其创始人非常清楚：他们并没有也不可能拥有其产品中的代码；Linux 社区的社会规范禁止这种做法。约翰·吉尔摩（John Gilmore）曾有名言：互联网会把审查视作故障，并主动绕行。借用这句话，有人精妙地指出：负责Linux的技术社区会将管控企图视为故障，并选择绕行。如果红帽对新版本发布前的克隆行为提出抗议，它将严重损害自己从开发者社区获得未来合作的能力。

或许在当下更重要的是，软件许可证已将社区规范落实为具有法律约束力的条款，明确禁止红帽垄断其产品所基于的代码来源。它们唯一能卖的，是与那些自愿为此付费的用户之间建立的一种品牌/服务/支持关系。在这种背景下，出现掠夺性垄断^a的可能性并不大。

4.15 开放研发与赞助体系革新

真金白银注入开源世界，还在另一个方面带来变化。社区中的顶尖黑客越来越明白，他们可以靠做自己想做的事获得报酬，而不必再将开源当作副业、靠另一份正职来养活自己。红帽公司、O’Reilly 以及 VA Linux Systems 等企业，纷纷设立半独立研发部门，专职聘用并留住大批开源人才。

这种做法具备经济价值的前提是：维持此类实验室的人均成本，能轻易由预期收益覆盖，而这些收益源于公司借此更快地拓展市场。O’Reilly 能够负担 Perl 和 Apache 的领导者的薪酬，让他们专注于自己的工作，是因为公司预期，他们的努力将有助于销售更多与 Perl 和 Apache 相关的书籍，并吸引更多人参加其会议。VA Linux Systems 能够资助其实验室部门，是因为改进 Linux 能提升其所售工作站和服务器的使用价值。而红帽公司资助红帽高级开发实验室，则是为了提升其 Linux 产品的价值，吸引更多客户。

传统软件从业者素来将专利与商业机密保护的知识产权视作企业至宝，因此他们很难理解这种做法。为什么要投入资金研发，却要让所有竞争对手都能无偿使用成果？

背后似乎有两大原因。其一，只要这些公司在其细分市场中保持主导地位，它们就有望从开放式的研发中获得相应比例的大部分回报。用研发换取未来利润，这并不是什么新想法；有趣的是，其中隐含的算盘是：预期的未来收益足够大，以至于这些公司可以坦然接受搭便车者，并借此获得同行评审带来的品质加持。

在一个由注重投资回报的精明资本家主导的世界里，这种对预期未来价值的分析固然有必要，但它其实并不是解释“聘请顶尖黑客”这一行为最有趣的分析角度，因为企业自身提出了一种更为宽泛的理由。若问及此事，它们会告诉你，它们只是在为所来自的社群做正确的事。笔者与上述三家企业的核心管理层一向交好，可以证实这些说法绝非虚言。实际上，在 1998 年末，我受邀加入 VA Linux Systems 董事会，当时的核心目的，便是为他们在行事准则方面提供建议，而且我发现他们确实愿意倾听。

经济学家有权追问：这其中到底有什么收益？如果我们接受“做正确的事”并非空洞的姿态，就要深究：这份善意背后，究竟契合了企业怎样的利益逻辑。答案本身既不令人惊讶，也易于通过提出恰当的问题来验证。与其他行业中表面上的利他行为一样，这些公司实际上相信他们购买的是“商誉”^a。

努力赢取商誉，并将其视为预示未来市场收益的资产，也并不是一件新鲜事。有趣的是，这些公司的行为表明，它们对商誉的估值极高。即便在上市前资金最为紧张的阶段，企业仍愿意高薪聘请人才，投入到无法直接创收的项目中。而且，至少到目前为止，市场对这种行为给予了丰厚的回报。

这些公司的负责人自身非常清楚，商誉为何对他们尤为宝贵。他们高度依赖客户群体中的志愿者，既借其进行产品开发，也将其作为非正式的营销力量。他们与客户群体的关系非常紧密，这种关系通常依赖于公司内外个体之间的个人信任纽带。企业并非单纯利用开发者社群，而是与之深度相融、命运与共。

这些观察印证了我们之前通过另一条推理路径得出的结论。红帽、VA、O’Reilly 与其客户/开发者之间的紧密关系，并非典型制造业企业的特征。相反，它将高度专业化、知识密集型服务业的典型模式推向了一个有趣的极端。放眼科技行业之外，我们可以在律师事务所、医疗机构和大学等组织中看到这些模式。

实际上我们可以观察到，开源公司聘请顶尖黑客的原因，与大学聘请明星学者的原因大致相同。在这两种情形中，这种做法在机制和效果上，都近似于工业革命前资助大部分美术创作的贵族赞助体系，而部分开源企业人士对此有着充分的认识。

4.16 现状到未来的转型方向

为开源开发提供资金（并从中获利！）的市场机制仍在快速演变。本文梳理的商业模式，大概率不会是最后出现的形态。投资者仍在考量，将软件行业重塑为以服务为核心（而非封闭知识产权）的行业会带来哪些影响，这类思考还将持续较长时间。

这场观念革命会使行业内依托产品销售（该部分仅占行业营收的 5%）的投资者损失一部分利润。从历史来看，服务业的盈利水平不及制造业（但任何医生或律师都会告诉你，从业者本人的实际回报往往更高）。不过，利润上的损失能够被成本端的收益大幅弥补，软件使用者借助开源产品实现了显著降本、提效。（这一现象，和互联网逐步取代传统语音电话网络所产生的影响类似。）

降本增效的发展前景催生了市场机遇，企业家与风险投资机构纷纷入局挖掘机会。本文撰写初稿期间，硅谷顶尖风投机构领投了首家提供全天候 Linux 技术支持的初创企业 Linuxcare。1999 年 8 月，即便互联网与科技股整体走低，红帽公司的首次公开募股依旧大获成功。当时业内普遍预测，1999 年底前还将有多家 Linux 及开源相关企业完成 IPO，且同样会取得良好成绩。（2000 年补充说明：事实确实如此！）

另一值得关注的新动向，是业内开始系统性地为开源开发项目搭建任务市场。SourceXchange（http://www.sourcexchange.com/process.html）^a与 CoSource（http://www.cosource.com/）^b两家平台采用略有差异的模式，将反向拍卖机制（Reverse-auction Model）用于开源项目的资金募集^c。

整体趋势十分明确。前文已提及 IDC 的预测：截至 2003 年，Linux 的增长速度将超过其余所有操作系统之和。Apache 市场占比达 61%，且持续稳步提升。互联网使用规模迅猛扩张，互联网操作系统计数器（http://leb.net/hzo/ioscount/）^c等调研数据显示，Linux 及其他开源操作系统已在互联网主机中占据相对多数，并持续挤压闭源系统的市场份额。企业对开源互联网基础设施的应用需求，不断影响着软件设计、企业经营模式以及软件的使用与采购习惯。实际上，此类趋势还将进一步加快。

4.17 结论：变革之后的生活

一旦开源转型完成，软件业界将会变成什么样子？

一些程序员担心，开源化的转型会导致他们的岗位消失、职业价值贬值，而典型的噩梦场景就是我所说的"开源末日"。这个场景刚开始的时候，因为到处都有免费的源代码，所以软件的市场价值开始归零，仅凭使用价值无法吸引足够多的消费者来支撑软件开发；随后商业软件产业崩溃，然后程序员收入锐减，被迫转行。开源文化本身（依赖于所有这些专业人士的业余时间）一旦崩溃，末日就来临了，届时再也没有人能够胜任编程工作，所有人都会完蛋。这实在令人啼笑皆非！

我们已经观察到许多充分的理由说明这不会发生，首先就是大多数开发者的薪水本来就不依赖于软件的销售价值。但最值得在这里强调的一个理由是：你见过哪个开发团队不是工作堆积如山？在一个快速变化的世界里，在一个日益复杂化、以信息为中心的经济体系中，市场永远有充足岗位，也持续渴求精通计算机技术的人才——无论他们投入多少时间、公开了多少商业机密。

要分析软件市场，可按软件服务被开放技术标准定义的完整程度来分类，而这个程度与底层服务的商品化程度高度契合。

这套分类标准，恰好对应业内常说的三大类别："应用软件"（完全没有商品化，开放技术标准薄弱或不存在）、"基础设施"（商品化的服务，强大的标准）和"中间件"（部分商品化，有效但不完整的技术标准）。2000年的典型例子分别是文字处理器（应用软件）、TCP/IP协议栈（基础设施）和数据库引擎（中间件）。

我们此前的收益分析显示，三类软件会走上不同转型路径，形成各异的开源、闭源共存格局。同时，一款软件所在领域的开源普及程度，取决于三点：是否存在显著的网络效应、故障造成的损失大小，以及它是否是支撑核心业务的关键资产。

如果我们不把这些启发式方法应用于单个产品，而是应用于整个软件市场，我们就可以大胆做出一些预测。看好了：

基础设施（互联网、万维网、操作系统，以及必须在竞争各方之间跨越边界的通信软件底层）将几乎全部开源，由用户联盟和类似如今红帽这类商业发行及服务厂商合作维护。

另一方面，应用软件将最倾向于保持闭源。在一些场景中，未公开算法或技术的使用价值极高，且产品不稳定带来的成本低、供应商垄断的风险可接受，消费者仍会愿意购买闭源软件，而这类现象在网络效应薄弱的独立垂直行业软件中会最为普遍。我们之前的锯木厂例子就是其一；而在 1999 年的热门行业中，生物识别软件似乎很可能是另一个例证。

中间件（如数据库、开发工具，或应用协议栈的定制顶层）模式则更为多元。这类软件走向开源还是闭源，主要取决于故障损失成本：成本越高，市场对开源的诉求就越强烈。

不过我们要清楚，“应用软件”与“中间件”的划分并非一成不变。此前提到，单一软件技术会自然从理性闭源走向理性开源，这一规律在整个行业层面同样成立。

随着标准化技术不断成熟、服务逐步商品化，应用软件会逐步演变为中间件。（例如，在SQL将前端与引擎解耦之后，数据库就变成了中间件。）而中间件服务进一步商品化后，又会演进为开源基础设施，操作系统领域当下正经历这一转变。

在一个包含开源竞争的未来，我们可以预期，任何软件技术的最终命运要么是消亡，要么是成为开放基础设施本身的一部分。虽然对于那些希望依靠闭源软件长期坐享垄断收益的创业者来说，这算不上什么好消息，但它确实表明，整个软件行业将始终充满创业机遇：在（应用软件）高端会不断有新的利基市场打开，而一旦这类产品归入基础设施范畴，闭源知识产权的垄断将不再牢不可破。

毋庸置疑，这种行业均衡对推动变革的软件消费者十分有利。越来越多优质软件可供人们永久使用、二次开发，不会停止维护，也不会被企业独家封存垄断。最后，瑟西德温的魔法锅炉这个比喻还是太弱了——因为琼浆玉液要么被喝掉、要么会变质，而软件源代码却可以永久存在。从广义的自由意志主义^a视角来看，一个允许所有非强制活动（无论是贸易还是礼物文化的馈赠）的自由市场，可以为每个人创造持续增长的软件财富。

4.18 附录：为什么闭源驱动反而让厂商赔钱

外设硬件（以太网卡、磁盘控制器、显卡等）厂商历来不愿开放硬件技术资料。如今形势正在转变，像 Adaptec 和 Cyclades 这样的厂商^a已开始常规性地公开其板卡的规格说明书和驱动程序源代码，然而行业内的抵触心态依旧存在。本文将逐一破除催生这类抵触心态的几大经济学认知误区。

如果你是硬件厂商，可能会担心开源会泄露硬件运行的重要细节，被竞争对手复制，从而让对手获得不正当竞争优势。在产品周期为3-5年的时代，这种说法是有道理的。但如今，竞争对手的工程师复刻、吃透技术要耗费大量时间，会严重挤占产品研发周期，而这些时间本可用于自主创新、打造产品的差异化优势。

这并不是什么新见解。前克格勃负责人奥列格·卡卢金说得很好(http://cnn.com/SPECIALS/cold.war/experience/spies/interviews/kalugin/)^b：

举个例子，当我们曾窃取 IBM 等企业的技术蓝图，以及西方其他领先电子领域的资料时，西方在这些领域突飞猛进，而我们远远落后。要真正落实情报成果往往需要数年时间。等五到七年过去，西方又往前走了，我们只能一次次再偷，结果越来越落后。

但早在大约一个世纪前，拉迪亚德·吉卜林（Rudyard Kipling）在他的诗作《玛丽·格洛斯特号》（The Mary Gloster，http://www.everypoet.com/archive/poetry/Rudyard_Kipling/kipling_the_mary_gloster.htm）^c中说得更透彻。他写道：

他们问我怎么做到的， 我给了他们一段经文： “让你的光闪耀在 比对手稍前一点的地方！” 他们能抄的全抄了， 却抄不走我的头脑， 我让他们汗流浃背地偷， 却仍落后我一年半。

进入互联网高速发展的阶段后，这一现象的影响将更有杀伤力。如果你在行业处于领先地位，那你可以让竞争对手掉进抄袭的陷阱！

如今这些技术细节根本藏不住。硬件驱动不像操作系统或应用程序，代码体量小，很容易被反汇编、仿制。就算是十几岁的编程新手也能做到，这种情况早已屡见不鲜。

成千上万的 Linux 和 FreeBSD 程序员既有能力也有动力为新板卡编写驱动。对于许多接口相对简单且有成熟标准的设备类别（如磁盘控制器和网卡），这些热心的黑客即便没有官方文档、也不逆向现有驱动，他们开发驱动原型的速度，也常常和厂商自研团队不相上下。

即使对于显卡、声卡这类复杂的设备，你也没太多办法阻止一个手持反汇编器的聪明程序员。成本低，法律壁垒也不是天衣无缝的；而 Linux 是全球协作的开源项目，全球各地司法规则不一，不少地区明确允许逆向工程。

要证明以上说法属实，只需查看 Linux 内核支持的设备列表，就能看到，即便没有厂商官方支持，内核新增设备适配的速度依然惊人。

开放驱动还有一大好处，你可以专注于创新。想象一下，你再也不用让员工耗费时间精力，为每个新发布的内核重写、测试和发布新的二进制驱动。你肯定有比这更重要的事情去做。

还有一个很好的理由：没有用户愿意为漏洞修复等待长达半年之久。如果你有任何开源竞争对手，单凭这一点，对手就足以碾压你。

当然，还有前面提到过的长效适配价值（Future-proofing Effect）。客户想要开源，因为他们知道开源能大幅延长硬件使用寿命，即便超出厂商的常规维保成本周期也能正常使用。

不过，最重要的理由是：你的盈利模式是靠卖硬件。市场并不接受技术保密，事实恰恰相反。如果你的驱动难找、需要频繁更新、最糟的是驱动运行卡顿，这会严重拖累硬件口碑，造成销量下跌。开源可以解决这些问题，并提升你的收入。

结论是什么？保护闭源驱动的商业机密在短期看来有吸引力，但从长期看很可能是糟糕的策略（尤其是当你已经与那些开放的厂商竞争时）。但如果你非要保密，那把代码烧录到板载 ROM 里，然后对外开放 ROM 的接口。尽可能开源，以拓展市场，并向潜在客户证明：你相信自己在真正重要的地方，能够在核心技术与创新能力上领先对手。

如果你执意闭源，最后只会满盘皆输：技术秘密早晚泄露，也没人免费帮你开发，更没法让那些愚蠢的对手，把时间白白耗在抄袭复刻上。最关键的是，你会错失产品早期快速铺开的机会。互联网和大多数企业数据中心的运维团队，这个体量庞大、话语权十足的客户群体，会直接认定你的公司目光短浅、固步自封，你连这些道理都没想明白。然后，他们会转而选择理念更成熟的厂商采购板卡。

第五章：黑客的复仇

1998 年，开源软件一举闯入主流行业视野，是黑客群体历经 20 年边缘化处境后的一次复仇。我本人也半意外地成了这场运动中的头号煽动者和宣传鼓手。在本文中，我将回顾此后动荡的一年，着重讲述我们当时采用的媒体策略和话语方式——正是靠这些，我们才成功叩开了《财富》 500 强企业的大门。文末，我还会对未来的趋势走向做一番展望。

5.1 黑客的复仇

我在 1996 年撰写了《黑客国度简史》的第一个版本，作为网络资源发布。早在 1990 年编辑《新黑客词典》第一版之前很久，我就对黑客文化这一文化现象产生了浓厚兴趣，这种关注也持续了多年。到 1993 年底，许多人（包括我自己）已经把我当作了黑客文化领域的部落历史学家和常驻民族志研究者，我也很适应这个角色。

当时我完全没有想到，自己这种业余层面的人类学研究，竟然会成为推动变革的重要催化剂。当这件事发生时，我想没有人比我更感到意外。而这一意外带来的影响，至今仍在黑客文化圈、科技行业以及商业领域持续发酵、产生回响。

在本文中，我将以个人视角，回顾直接引发 1998 年 1 月开源革命“响彻世界的一枪”的一系列事件，反思我们自那以后走过的漫长且非凡的历程，最后也会尝试对未来做出一些前瞻性的预判。

5.2 超越布鲁克斯定律

我第一次接触 Linux 是在 1993 年末，当时用的是开创性的 Yggdrasil 光盘发行版，那时我参与黑客文化活动已经有了 15 个年头。早年我接触过 70 年代末期尚不成熟的阿帕网，还短暂体验过 ITS 主机。早在 1984 年 FSF 成立前，我就已经开发了自由软件并发布到 Usenet 新闻组，也是 FSF 最早的贡献者之一。当时我刚出版了《新黑客词典》第二版，自认对黑客文化以及它存在的短板，都有相当透彻的认知。

我在其他文章里提过，我初次见到 Linux 时内心十分震撼。虽说我已在黑客文化中活跃多年，但我脑海中仍然暗藏着一个没验证过的固有观念：业余黑客即便天赋出众，也凑不齐足够的资源与技术，做出一套能稳定运行的多任务操作系统。毕竟 HURD 项目的研发团队，为此攻坚 10 年也没有见到成效。

可林纳斯・托瓦兹和他的社区，做成了这件他们没能完成的事，而且他们不只是达到了稳定运行、兼容 Unix 接口的基础门槛，他们的成就远不止于此。他们以充沛的精力和独到的才华远远超越了这个标准，配套程序、文档与各类资源累计数百兆。完整的网络工具套件、桌面排版软件、图形组件、文本编辑器、各类游戏，一应俱全。

当我看到这场绝妙的代码盛宴以一套工作系统的形态展现在我面前时，那种体验要比理智上直到“这些代码片段散落各处”要震撼得多。这好比多年以来我一直在整理一堆零散的汽车零部件，一转头却看见这些零件被组装成一台锃亮的红色法拉利：车门敞开，钥匙挂在锁孔上，引擎轻声低鸣，蓄势待发……

我持续观察了 20 年的黑客传统，忽然以一种充满活力的全新形态焕发生机。某种程度上，我早已是这个社区的一员了——我个人开发的多款自由软件项目都已经被整合进了 Linux 生态。但我希望更深入地参与其中……因为每一项亮眼的成果，都让我更加困惑。这简直好得令人难以置信！

软件工程的经典法则深受布鲁克斯定律支配，该定律出自弗雷德・布鲁克斯的经典著作《人月神话》。布鲁克斯提出：当开发人数 N 增加时，完成的工作量按 N 增长，但系统复杂度、对缺陷的脆弱性会以 N² 的量级上升；N² 对应的是开发者代码仓库之间沟通路径（以及潜在代码接口）的数量。

按照布鲁克斯定律的预测，拥有几千贡献者的项目，必然结构松散、稳定性差。可 Linux 社区却突破了这种 N² 量级的沟通损耗效应，产出了一个质量高得惊人的操作系统。我下定决心，要弄清楚他们实现这一切的底层逻辑。

我花了 3 年深度参与、持续观察，形成了一套理论，又用了 1 年时间通过实际项目验证这套逻辑。之后我动笔写下《大教堂与集市》，系统阐释自己观察到的这套全新开发模式。

5.3 迷因与迷思建构

我亲眼见证，这个社群演化出了史上最高效的软件开发模式，可它自己却浑然不知！这套高效的协作方式依靠社群内的惯例自然形成，依靠模仿与榜样代代相传，却始终没有一套理论体系或专业表述，去解释这套模式奏效的底层逻辑。

事后回看，理论与话语体系的缺失带来两重阻碍。第一：我们无法系统性地思考如何优化现有的协作流程；第二：我们难以向外人阐释、推广这套开发模式。

当时的我只考虑到了第一个问题。我撰写初稿只有一个目的，那就是为黑客社群提供一套内部通用的表述框架，让社群能够清晰梳理、理解自身的协作逻辑。因此我将自己长期观察到的现象写了下来，以叙事的形式展开，并配上生动贴切的隐喻，来描述那些可以从社群惯例背后推导出的逻辑。

《大教堂与集市》没有提出什么颠覆性的全新发现，文中描述的所有开发模式也并非由我创造。文章的创新点不在于罗列客观事实，而在于配套的比喻与完整叙事——一个简洁且富有说服力的叙事框架，引导读者用全新视角审视开源协作现象。我本质上是在做迷因工程，在对黑客文化的原生集体叙事做一次迷因层面的梳理与重塑。

1997 年 5 月，我在巴伐利亚举办的 Linux 大会上首次完整宣讲了这篇论文。现场听众当中几乎没有英语母语者，却全程凝神倾听，结束后掌声雷动，这个事实似乎证实了我确实捕捉到了一些重要的东西。但事后看来，周四晚宴上我恰巧坐在出版商蒂姆・奥莱利（Tim O’Reilly）身旁这件偶然小事，就引出了一系列影响更为深远的连锁反应。

我一直十分欣赏奥莱利出版社的制度风格，我多年来一直期盼着能见到蒂姆。当晚我们聊了很多，大半时间都在畅谈彼此都喜爱的经典科幻作品，这次交谈过后，他邀请我在同年晚些时候举办的 Perl 技术大会上，再次分享《大教堂与集市》。

这场演讲同样反响热烈，台下众人欢呼、起立鼓掌。我从邮件中了解到，自巴伐利亚大会过后，《大教堂与集市》一文就在互联网上飞速传播，如同星火燎原。现场不少听众早已读过原文，对他们而言，这场演讲并不是在科普全新观点，不如说是一次庆祝这套全新的描述体系、以及随之形成的行业认知的机会。那场起立鼓掌，与其说是献给我的文章，不如说是献给整个黑客社群，这份认可本就当之无愧。

虽然我当时并不知道这场迷因工程实验即将点燃，即将造气更大的火势。现场有一批听众是第一次接触这套理论，他们来自网景通信公司，而当时网景正深陷经营危机。

网景是互联网行业的先驱企业，也曾是华尔街炙手可热的上市公司，那时已经成了微软的打压目标。微软深知，网景浏览器所代表的开放网页标准，会动摇这家雷德蒙巨头（Redmond giant）在 PC 桌面市场利润丰厚的垄断格局。微软动用它数十亿美元的全部力量，以及后来引发反垄断诉讼的种种不光彩手段，全力打压网景的浏览器业务。

对网景来说，核心矛盾并非浏览器带来的营收（这块收入始终只占公司总营收很小一部分），而是要保住服务器业务的生存空间，服务器业务才是它的核心高价值板块。一旦 IE 浏览器占据市场主导，微软就有能力篡改网页协议，抛弃开放标准、转向私有闭环协议，之后就只有微软自家的服务器能适配运行了。

网景内部针对如何化解危机展开激烈争论。早期有人提议公开浏览器源代码，但这套方案很难说服管理层，当时缺少足够有力的论据，证明开源能阻挡 IE 垄断市场。

我当时并不知道，《大教堂与集市》后来成了支撑开源方案落地的关键依据。在 1997 年的整个冬天，我还在筹备下一篇论文的内容，而网景这边正在搭建打破专有游戏规则的舞台，它要打破闭源商业软件的固有规则，给开源社群带来前所未有的机遇。

5.4 通往山景城之路

1998 年 1 月 22 日，网景正式宣布，将对外公开旗下全部客户端产品线源代码。消息传到我手中的第二天，我便得知 CEO 吉姆・巴克斯代尔（Jim Barksdale）在接受全国媒体采访时，表示我的文章是促成这次决策的 “核心思想来源”。

后来行业媒体将此事称作 “响彻全球的一枪”。巴克斯代尔无形中把我推到了托马斯・潘恩（Thomas Paine）式的先行者位置，不论我是否愿意接受这个身份。黑客文化发展史上，这是头一回有一家财富 500 强、华尔街的宠儿，把自身未来押在了我们这套开发模式上，更具体地说，押在了我对这套模式的分析结论之上。

这件事带来的冲击，让人不得不冷静深思。《大教堂与集市》重塑黑客社群自我认知时，我并不意外，这本就是我写作之初想要达成的目标。但这套理论能在外界产生如此巨大的影响，我至少可以说是震惊了。消息传来的头几个小时，我做了一些非常深入的思考：Linux 与开源社群当下的处境、网景的前路，以及我个人是否有能力承接接下来的局面。

不难得出结论：帮助网景赌赢这场开源的尝试，已经成为整个开源社群、也包括我个人的头等大事。一旦网景这次押注失败，所有负面评价都会压在黑客群体头上，我们会在接下来 10 年持续遭受质疑，而这样的后果是我们难以承担的。

到这时，我已经在黑客文化中浸染了 20 年，经历了它的各个阶段。这 20 年里，我一次又一次地看着绝妙的想法、充满希望的起点和卓越的技术被圆滑的营销碾碎。20 年间，黑客们怀揣理想、埋头耕耘、搭建各类成果，可最后丰厚的市场回报，往往都落到了老朽的 IBM 或是微软这类新贵企业囊中。20 年我们都生活在贫民窟中—一个相当舒适的贫民窟，里面都是趣味相投的朋友，可外界的主流偏见筑起一道无形高墙，墙内被贴上标签：“只有怪胎住在这里”。

网景的公告击穿了那堵墙，哪怕只是一瞬间，商业世界也已经从对“黑客”能力的自满中惊醒了，但人们固化的思维模式很难轻易改变。如果网景失败了，甚至可能即使他们成功了，这次实验也可能被视为一次不可复制的孤例，不值得再尝试。那样的话，我们就会回到同一个贫民窟，外界的隔阂与偏见只会比以往更深。

为了防止这种情况发生，网景这次开源必须做成。于是我梳理了自己对集市式开发模式的全部研究心得，联系网景，并主动提出协助他们指定许可证以及制定战略的细节。在二月初，我受邀前往山景城，在网景总部和多个业务团队连续开了 7 小时会议，并帮助他们制定了后来成为 Mozilla 公共许可证和 Mozilla 组织的初步框架。

此行期间，我还会面了硅谷以及全美 Linux 社群的多位核心人物。所有人都清楚，协助网景落地开源只是短期优先事项，更关键的是，需要一套长期战略来跟进这次事件带来的行业变革。我们当下就着手搭建这套长期发展战略。

5.5 “开源”概念的起源

整套策略的框架其实十分清晰。我们要把我在《大教堂与集市》中提出的务实观点进一步完善，并面向大众大力推广。网景本身也有意说服投资者，证明开源战略并非鲁莽的决策，因此我们能争取到他们一同宣传。我们也在项目早期就拉拢了蒂姆・奥莱利，借助 O’Reilly 出版社的资源扩大声量。

但真正的概念性突破，是我们正视了一个事实：我们要做的本质上是一场营销战役，必须运用成熟的营销手段（舆论引导、形象塑造、品牌重定位），才能真正落地见效。

“开源” 这个术语就此诞生。1998 年 2 月 3 日，一众后续推动开源运动、最终成立开源促进会的核心人员，在山景城 VA Research（现 VA Linux Systems）公司办公室召开会议，共同敲定了这一称谓。

事后回顾，我们清晰地认识到，“自由软件” （free software）这个术语多年来给整个社群运动带来了极大损害。一方面，英文单词 free 本身存在双重释义，一层代表价格免费，另一层指代权利自由。理查德・斯托曼带领的 FSF 一直主张，应该把“自由软件”理解为 “要像想言论自由那样去想，而不是免费啤酒”，但这个词的歧义始终无法消除：因为大多数自由软件也确实免费分发。

而更大的负面影响来源于更深层的刻板印象：“自由软件”和敌视知识产权、共产主义等标签绑定得太深，企业的 MIS（信息系统）主管很难对它产生好感。

即便去辩解自由软件基金会并不敌视知识产权、它的主张也不能简单等同于共产主义，这种辩解在当时到现在都抓不住重点，我们心里都清楚这一点。但网景开源事件带来的紧迫局势让我们看清：FSF 真实的理念主张无关紧要，真正左右局面的是它长期布道带来的反向效果——行业媒体与企业界已经把 “自由软件” 和各种负面刻板印象牢牢绑定。

网景开源之后，我们能否持续取得突破，核心在于用一套正向认知替换掉 FSF 带来的负面标签：讲一套务实、能打动企业管理者与投资人的逻辑，突出软件稳定性更高、综合成本更低、功能更完善这些优势。

用传统的营销术语来讲，我们要做的就是完成品牌重塑，打造让企业客户争相购买的产品声誉。

首次更名会议结束次日，林纳斯・托瓦兹便认可了这套思路，几天之内我们就着手落地执行。布鲁斯・佩伦斯（Bruce Perens）一周内完成 opensource.org 域名注册，并上线了开源网站（http://www.opensource.edu）的第一个版本；他还提议把 Debian 自由软件规范升格为《开源定义》（http://www.opensource.org/osd.html），同时启动 “Open Source”（开源） 认证商标的注册流程，从法律层面做出规范，只有符合 OSD（开源定义标准）的产品才能冠以 “开源” 标识。

即便在这个早期阶段，推动这个战略所需的具体战术对我来说也相当清晰，在首次会议上大家也专门就此展开讨论，核心主题整理如下。

1. 放弃自下而上推广，转为自上而下攻坚

有一点十分明确：过去 Unix 一直采用自下而上的推广模式（依赖工程师通过理性论证说服老板）是失败的，这种策略太天真，轻易就被微软击败。况且网景这次开源突破走的也不是这条路，是企业高层决策者吉姆・巴克斯代尔看清了开源的价值，再自上而下推动整个团队落地。

结论不可避免。我们不应自下而上，而应自上而下地进行布道，要直接尽力争取 CEO/CTO/CIO 这类人群。

2. 以 Linux 作为最佳示范案例

推广 Linux 必须作为我们的主要着力点。开源领域还有不少其他项目，我们的运动也会恭敬地向它们致意，但 Linux 拥有最高的知名度、最广泛的软件基础和最庞大的开发者社区。从务实的角度来看，如果连 Linux 都无法巩固这次突破，其他的开源项目就更难获得市场认可。

3. 攻占财富 500 强

中小企业、个人工作室的整体支出规模并不小，但市场高度分散，很难集中发力。财富 500 强企业不仅预算体量巨大，资金资源高度集中，对接渠道也更清晰，软件行业的整体发展风向，基本由 500 强企业主导。因此，我们的核心说服目标，就是这批头部大企业。

4. 拉拢面向财富五百强的权威主流媒体

既然核心目标是财富 500 强企业，我们就必须拿下那些能够左右企业高管与投资者舆论导向的头部媒体，包括《纽约时报》（the New York Times）《华尔街日报》（the Wall Street Journal）《经济学人》（the Economist）《福布斯》（Forbes）以及《巴伦周刊》（Barron’s Magazine）。

按照这种观点，搞定技术行业媒体有必要，但还不够；行业媒体主要作为跳板，我们要借助顶级主流媒体，猛攻华尔街。

5. 向黑客们传授游击营销战术

同样清楚的是，教育黑客社区本身与向主流社会推广同等重要。如果只是在基层，大多数黑客仍在提出无效的论据，那么仅靠一两个能说会道的大使是不够的。

对内培训黑客社群，和对外面向主流市场宣传同等重要。如果基层的多数黑客仍然在提出无效的论据，那么整体推广效果会大打折扣。

6. 使用开源认证标识保持纯洁性

我们面临的威胁之一是，微软或其他大型厂商可能挪用歪曲 “开源” 概念、提出“拥抱扩展开源”，腐蚀的它核心内涵，让我们失去话语权。为此，我和布鲁斯・佩伦斯早早决定，将 “开源” 注册为认证标识，绑定《开源定义》（脱胎于 Debian 自由软件规范），依靠法律诉讼的威慑力，扼杀企业随意滥用这个名词的潜在风险。

后续事态发展超出预期，美国专利商标局（the U.S. Patent and Trademark office）拒绝为这类描述性通用词汇授予商标权。好在 1 年后我们彻底放弃商标注册计划时，“开源” 一词早已在各类媒体与行业场景广泛传播、形成固有认知。我们此前担忧的大规模滥用概念的情况，至少在 2000 年 11 月之前并没有真正出现。

5.6 意外的革命者

制定这套推广策略本身并不难，真正难熬的，是认清我自己必须承担的角色。

从一开始我就清楚，媒体基本不会关注抽象的理论。如果没有一位很有煽动性的“风云人物”站在前台，媒体根本不会报道一套理念。新闻需要完整的故事、戏剧冲突、抓人眼球的金句；没了这些，大多数记者只会睡着——就算他们没睡着，他们的主编也会睡着。

因此，我一开始就知道，需要一个有极其特殊特质的人，来领衔社区应对网景带来的这场机遇。我们需要一个煽动者、舆论操盘手、宣传鼓手、公关大使、狂热布道者——他能在房顶上又唱又跳又喊、引诱记者、和 CEO 死缠烂打、猛砸媒体机器，直到它的齿轮被迫反向转动、碾出这句话：革命来了！

绝大多数黑客性格偏内向，而我天生外向，而且我已经有了很多和媒体打交道的经验。环顾整个社群，没有人比我更适合扮演这个布道者的角色了。但我打心底抵触这份工作，我清楚它会占用我几个月甚至好几年全部的生活，彻底剥夺私人空间。一方面主流媒体会把我刻板塑造成怪异的极客，更糟糕的是，社群内部相当一部分人会指责我迎合资本、贪图名利。最让我难以接受的是，我大概率再也抽不出时间写代码。

我不断反问自己：眼睁睁看着社群一次次落败，这份不甘是否愿意让我不惜一切代价去赢？最终我给出了肯定的答案。下定决心后，我便投身这份繁杂、并不体面却必要的工作，以公众人物、媒体发言人的身份走到台前。

当年编纂《新黑客词典》时，我就掌握了一些对接媒体的基础方法。而这一次我更加认真地对待这件事，总结出一套完整的媒体传播逻辑，并落地实践。这套理论的核心，是运用我所说的 “吸引力反差” 勾起公众对理念宣讲者的好奇心，再充分借助这份关注度去推广整套开源理念。

这里不适合我讲太多这套理论的细节，但有心的读者仅凭 “适度制造争议感” 这个核心思路，再结合我的采访表达风格，就能推出来大半：接受采访时，我会尽量打扮得体、有少年感，一副传统意义上的美国阳光大男孩形象，同时坦然聊起自己对枪械、安那其主义、神秘巫术的兴趣。其中的关键技巧是，观点要听上去特立独行、有冲击力，却又传递出真诚质朴、值得信赖的气场。（需要说明，这套方法必须发自本心；刻意伪装两种特质极易被看穿，我并不建议模仿。）

我刻意绑定 “开源” 标签、将自己打造成布道者，果然产生了预期中的好与坏两种后果。网景开源公告发布后的 10 个月，媒体针对 Linux 与开源生态的报道量呈指数级持续攀升。这段时间里，大约 1/3 的报道直接引用我的发言，其余大部分文章也会把我作为背景参考人物。但与此同时，社群内一小部分激进黑客公开指责我爱慕虚荣、野心过重。面对两种截然不同的评价，我尽量保持幽默感，只是偶尔难免感到煎熬。

我从一开始的计划就是，最终我会把布道者的角色移交给某个继任者，或者某个专门机构。依靠个人魅力传播的模式早晚会走到瓶颈，有公信力的正规机构会更适合主导推广（而且，从我个人的角度来看，这个节点越早越好！）。如今我正逐步把我个人的关系网、精心建立起来的媒体声誉转移给开源促进会（Open Source Initiative）——这家非营利机构成立的初衷，就是统筹管理开源相关标识规范。撰写本文时，我仍担任该组织主席，但我并不打算无限期担任这个岗位。

5.7 战役阶段

开源运动始于山景城的那次会议，随后我们迅速在互联网上集结起松散的非正式同盟网络（其中包括网景和 O’Reilly 传媒的关键人物）。下文我写到“我们”时，指的就是这个同盟网络。

从 2 月 3 日会议结束，到 3 月 31 日网景正式开源前，我们的首要任务是说服黑客社区接受“开源”这个标签及其配套的论证逻辑，让大家相信这是我们说服主流世界的最佳途径。结果证明，这场转变比我们预想的要顺利得多。我们发现，许多人早已对 FSF 那种偏教条主义的说教感到厌倦，他们渴望一种更务实的声音。

3 月 7 日，蒂姆・奥莱利邀请了 20 多位主流自由软件项目负责人，召开了一场后来被称作 “自由软件峰会” 的会议。当这些领袖们投票决定采用“开源”一词时，他们就正式确认了一个在开发者基层早已清晰的趋势。山景城会议之后仅 6 周，社区中的压倒性多数已经开始使用我们的语言。

峰会带来的媒体报道，将“开源”这个术语介绍给了主流媒体，同时也向外界传达了一个信号：采用开源理念的不只有网景一家。我们为一个已经存在、但其影响力尚未被互联网社区之外的人所认识的现象，赋予了一个名字。开源软件从来不是边缘挑战者，它们在提供互联网基础设施的关键组件方面，早已是市场领导者。AApache 是领先的网页服务器，拥有超过 50% 的市场份额（如今已增长到 60%）；Perl 是新一代网页应用开发的主流语言；Sendmail 处理全网超 80% 的邮件收发；我们日常使用的域名解析系统（让我们能使用 www.yahoo.com 这样的名称，而不是晦涩的数字 IP 地址），也几乎完全依靠开源软件 BIND 运行。峰会结束后的新闻发布会上，蒂姆・奥莱利指着到场的程序员与项目负责人说道：“这群人只依靠思想的力量，以及由协同开发者组成的网络社区，就做出了市场占有率遥遥领先的产品。” 倘若如果大公司也采用开源方法论，还会有什么更大的可能性？

这为我们的媒体宣传攻势（也就是依靠媒体扭转大众认知的所谓 “空中作战”）打下了良好开端，但我们要在“地面”保持势头。4 月，在自由软件峰会落幕、网景正式开放源代码之后，我们的主要重心转向了尽可能多地招募早期采用开源的人，目标是让网景的行动看起来不那么孤立——同时也为网景如果执行不力、未能达成目标的情况买一份“保险”。

那段时间是压力最大、内心最忐忑的阶段。表面看形势一片大好：Linux 在技术上蒸蒸日上，各类行业媒体铺天盖地报道更广泛的开源相关内容，我们甚至开始在大众媒体上看到正面报道。但我心里清楚，我们的成功依然十分脆弱。在最初的一波贡献热潮之后，Mozilla 社区因要求使用专有的 Motif 工具包而严重减缓了开发者的参与速度。没有任何一家大型独立软件开发商承诺将产品移植到 Linux 上。网景仍然显得形单影只，其浏览器在市场份额上仍在输给 Internet Explorer。一旦出现重大失利，都可能导致媒体和公众舆论的猛烈反扑。

网景开源之后，我们的第一个重大突破发生在 5 月 7 日，Corel 电脑推出基于 Linux 系统的 Netwinder 网络终端设备。但只有饥渴的二线厂商的承诺还不够，想要长期维持行业热度，必须拿下行业头部企业的支持。7 月中旬，甲骨文与 Informix 两家数据库巨头发布公告适配 Linux，才真正结束了这个脆弱的阶段。

这些数据库厂商加入 Linux 阵营的时间比我预估提早 3 个月，但来得正是时候。我们一直在想，如果没有大型独立软件开发商的支持，这股正面的热度还能持续多久，并且对于到底去哪里找这种支持越来越感到不安。在甲骨文和 Informix 宣布将产品移植到 Linux 之后，其他独立软件开发商几乎开始将宣布支持 Linux 当作常规操作，即使 Mozilla 失败了，我们也能承受得住了。

7月中旬到11月初是一个巩固阶段。在此期间，我们开始看到原本作为目标的财经媒体开始持续报道，先是《经济学人》的文章，然后是《福布斯》的封面报道。各类硬件和软件厂商开始主动接触开源社区，制定配套方案，希望借助这套新模式获取商业优势。而在内部，那个最大的闭源厂商开始真正感到担忧了。

这种担忧到底有多严重，从后来臭名昭著的《万圣节文件》泄露事件中可见一斑。这些微软内部战略文件承认了开源模式的强大力量，并针对以下内容做出策略分析：通过破坏开源赖以生存的开放协议、以及扼杀用户选择权，以此对抗开源。

《万圣节文件》是一枚重磅炸弹。这份出自受 Linux 冲击最大的企业的内部材料，反倒实打实佐证了开源开发模式的核心优势；也印证了长久以来大众心中的猜测——为阻挡开源崛起，微软不惜动用各类灰色竞争手段。

11 月上旬，各大媒体集中报道《万圣节文件》，再次掀起全社会对开源的关注热潮，而文件内容恰好一一印证了我们几个月以来一直在强调的所有观点。此事过后，美林证券（Merrill Lynch）专门邀约我，和机构核心投资人座谈，探讨软件行业整体格局与开源发展前景。华尔街，终于来找我们了。

接下来的 6 个月，我经历了反差感愈发强烈的两种生活。一边，各大财富百强企业战略负责人、科技投资机构纷纷邀请我分享开源理念，人生头一回搭乘飞机头等舱、乘坐加长豪华轿车；另一边，我又和草根黑客们一起进行街头游击式的行为艺术，最典型的就是 1999 年 3 月 15 日那场趣味十足的 “Windows 退款日” 游行。当时一群湾区 Linux 用户在全美媒体的聚光灯下，列队向微软办公室进发，要求根据微软最终用户许可协议，退还他们机器中预装但并未使用的 Windows 软件费用。

那我知道那个周末我要进城，在理性基金会（the Reason Foundation）主办的一个会议上发言，于是我自愿担任这次活动的纠察队长。早在前一年 12 月，网络漫画《User Friendly》就推出过恶搞《星球大战》的篇章，故事里有我的形象。于是我和活动组织者开玩笑，说游行时我可以穿上欧比旺・克诺比（ObiWan Kenobi）的绝地武士服装。

没想到抵达现场后，组织者真的准备了一套像模像样的绝地武士服饰。就这样，我身着戏服，领着一支游行队伍，队伍里举着措辞戏谑吐槽的标语牌、美国国旗，还有一只巨大的塑料企鹅吉祥物。我对着兴致满满的记者们高声喊出改编的口号：“愿源代码与你同在！” 出乎我意料的是，大家临时推举我出面，向媒体宣读活动声明。

我想，当这段视频出现在 CNBC 上时，我们谁都不应该真的感到惊讶。这次示威取得了巨大的成功。微软的公关部门，还在努力从《万圣节文件》曝光的打击中恢复过来，又挨了一记重拳。短短几周内，主要 PC 和笔记本电脑制造商开始发布公告，他们将推出不预装 Windows 的机型，售价也不再包含所谓的 “微软附加授权费”。看来我们那场游击式的行为艺术，正中靶心。

5.8 实地态势

就在开源运动在媒体层面展开“空中攻势”的同时，一线技术与市场格局也发生了实质性变化。下文简要梳理关键进展，这些行业现实，与媒体、公众认知的演变相互呼应，形成了很有意思的联动。

在网景开源之后的 18 个月里，Linux 的能力持续快速增强：稳定可靠的对称多处理（SMP）机制落地，64 位架构适配改造工作基本完成，为未来发展奠定了重要基础。

用一整个机房的 Linux 机器完成《泰坦尼克号》（the Titanic）全片画面渲染，给高价专业图形工作站厂商带来了巨大的冲击。紧随其后，Beowulf 低成本集群超算项目证明，Linux 这种依靠大量开发者自发协作的人海战术模式，同样能落地顶尖前沿的科学计算场景。

同期，其他开源类 Unix 系统并没有出现能引爆行业的突破性成果，而闭源商用 Unix 整体市场份额持续萎缩。实际上到当年年中，财富五百强企业里只有 Windows NT 与 Linux 实现份额正向增长；入秋之后，Linux 增速进一步拉开差距，新增市场大多从 Windows NT 手中夺取，而不是其他商用 Unix。

Apache 网页服务器的行业领先优势持续扩大。（截至 1999 年 8 月，全球对外公开的网站服务器中，有 61% 运行 Apache 及其衍生版本。）1998 年 11 月，网景浏览器扭转了市场份额下滑的趋势，开始对Internet Explorer发起反击。

1999 年 4 月，权威 IT 市场调研机构 IDG 发布预测：到 2003 年，Linux 的增速将超过其余所有服务器操作系统增速总和的两倍，增长速度也会甩开 Windows NT。同年 5 月，硅谷头部风投凯鹏华盈（Kleiner-Perkins）领投了一家 Linux 初创企业。

这段时期几乎唯一的负面事件，是 Mozilla 项目持续深陷治理难题，我在另一篇文章“魔法锅炉”^a中专门分析过其中症结。矛盾在 Mozilla 联合创始人、项目对外核心发言人杰米・扎温斯基离职时彻底爆发——网景开源满 1 年零 1 天之际，他宣布退出，直言项目管理混乱、错失大量发展机遇。

但到了此时，开源已经获得了巨大的势头，Mozilla 的内部困境并没有明显延缓行业落地开源的整体节奏。行业媒体也从中提炼出了客观的结论：用杰米如今广为人知的话说，“开源[很棒，但]并不是灵丹妙药”。

1999 年初，各大独立软件厂商（ISV）掀起适配浪潮，纷纷跟进头部数据库厂商，将商用应用移植至 Linux 平台。7 月末，行业体量最大的 CA 公司（冠群电脑）宣布，旗下绝大多数产品线都会提供 Linux 适配支持。8 月一份面向 2000 名企业 IT 负责人的调研初步数据显示，49% 的受访者将 Linux 视作企业数字化战略中 “重要乃至不可或缺” 的一环。IDC 另一份调研指出，自 1998 年以来开源市场迎来爆发式增长；1998 年的市场调研甚至统计不到具备规模的 Linux 商用案例，而此时已有 13% 的企业在业务系统中部署 Linux。

1999 年还迎来一波 Linux 企业上市热潮，红帽、VA Linux 等公司 IPO 行情火爆。尽管资本市场初期给出的估值带有互联网泡沫式的虚高，也在 2000 年 3 月大盘回调后大幅缩水，但这批企业实实在在搭建起了一套可持续盈利的开源商业生态，也持续成为投资者关注的焦点。

5.9 展望未来

我在此梳理这段近期历史，并不只是为了留下记录。更重要的是它能作为背景，帮助我们理解近期的趋势、推演未来。

首先，是对接下来一年的稳妥预测：

• 开源开发者规模将持续激增，低价的 PC 硬件与高速宽带的普及会持续助推这一增长。

• Linux 仍会保持行业领先地位。即便 BSD 开源开发者整体技术水平更高、HURD 项目团队精英云集，但 Linux 开发社群体量足以形成压倒级的优势。

• 各大独立软件厂商（ISV）对 Linux 平台的承诺支持将显著增加；数据库厂商的入局是一个转折点。

• 开源运动将继续乘胜追击，持续向企业 CEO、CTO、CIO 与投资人群体普及开源价值。MIS 主管面临的开源落地压力不再来自基层技术人员，而是公司高层。

• 不少推行全微软体系的企业，也会悄悄部署 Linux 上的 Samba 服务，替换掉越来越多的 Windows NT 服务器。

• 闭源商用 Unix 的市场份额持续缩水；至少一家竞争力薄弱的商用 Unix（很可能是 DG-UX 或 HP-UX）会彻底退出市场。而到那时行业分析师会将其衰败归因于 Linux 崛起，而不是微软的挤压。

• 微软拿不出成熟可用的企业级操作系统，因为 Windows 2000 难以交付稳定可用版本。（系统代码已达 6000 万行还在持续膨胀，开发早已失控。）

以上预判写于 1998 年 12 月中旬。截至 2000 年 11 月，也就是 2 年后，绝大多数判断依然站得住脚。只有最后一条尚有争议：微软当年大幅删减系统功能，才勉强推出 Windows 2000，但市场实际装机使用率并没有达到微软预期。

顺着上述趋势推演，我们可以做出一批中期预判（周期 18 至 32 个月），这类判断风险会更高一些：

• 面向开源操作系统商业客户的技术运维支持服务将发展成庞大产业，商用开源热潮既会催生这类业务，配套服务又会反过来加速企业落地开源。 （这条预判已于 1999 年应验：LinuxCare 成立，IBM、惠普等企业也发布了提供 Linux 官方技术支持服务的公告。）

• 以 Linux 为代表的各类开源操作系统，将占领 ISP 与企业数据中心市场。Windows NT 无力有效阻挡这一趋势；低成本、代码开放、真正 7x24 小时可靠性这三者的组合将势不可挡。

• 闭源商用 Unix 阵营几乎全线溃败。Solaris 看起来有望在高端Sun硬件上幸存，但其他大多数厂商自研的商用 Unix 系统会迅速沦为无人维护的老旧遗留系统。（2000 年初，SGI 内部全面改用 Linux，IRIX 系统宣告终结；同年年中 SCO 同意被 Caldera 收购。如今看来，多家 Unix 硬件厂商都会平稳完成 “换赛道” 转向 Linux，而 SGI 早已在这条转型路上深耕了很久。）

• Windows 2000 要么直接取消发布，要么一上市就“见光死”。无论哪种结局，都会演变成一场灾难性的战略崩盘，成为微软历史上最严重的战略失败。然而，他们对此失败的营销包装会非常巧妙，未来 2 年内基本不会动摇它在消费桌面市场的垄断地位。（2000 年年中 IDG 发布调研显示，“见光死”的可能性持续走高：大多数大型企业受访者直接拒绝部署初版系统，而已部署的环境也遭遇了严重的安全漏洞与稳定性故障。2000 年 10 月底至 11 月初，微软自身内网两度遭黑客攻破，更是雪上加霜。）

乍一看，这些趋势似乎让Linux有望成为最后的赢家。但现实没那么简单，微软依靠桌面业务攫取巨额营收与行业话语权，就算 Windows 2000 遭遇彻底滑铁卢，也绝不能轻易判定它就此出局。

但我们同样有依据判断，微软在 2001 年会迎来另一重严峻危机，这场麻烦和 Linux 无关，也和美国司法部反垄断调查无关。随着硬件售价持续走低，微软有 59% 的营收源于向 PC 整机厂商（OEM）售卖固定定价的预装系统许可证，这块业务正在承压。这笔固定授权费在整机厂商的毛利润里占比越来越高；到了某个临界点，OEM 厂商为了盈利，将不得不从雷德蒙德（微软总部）手中夺回部分最后的利润空间。从嵌入式设备、掌上 PDA 市场的行情能看出这个临界价格点大约在 350 美元。按照当时的价格走势，台式机售价会在 2001 年年中之前跌破 350 美元；一旦出现这种情况，各大整机厂商为活下去，只能倒戈、脱离微软阵营。

即便微软采用最直观的补救方案，按系统零售价百分比收费，而不是固定单价，也无济于事。厂商只需把显示器这类高价外设拆分单独计价，就能轻松钻规则空子。就算厂商不这么操作，华尔街也会把这种调价行为解读成微软已经失去对未来收入控制的信号。无论怎么走，微软的收入都很可能在司法部最终裁决之前就大幅跳水。

因此，两年之后的行业走向就很难清晰预判了。我们最终走向哪种未来，取决于几个问题：司法部能否成功拆分微软？BeOS、OS/2、Mac OS X 或是其他小众闭源操作系统，或者某个采用全新架构的系统，有没有可能选择开源路线，和底层架构积淀已有 30 年的 Linux 形成有力竞争？至少千年虫危机最后平安落幕了……

这些都是相当难以预测的。但有一个问题值得深思：Linux 社区究竟能不能打磨出一套完整的、对普通用户友好的图形图形界面？

在这本书 1999 年的第一版中，我曾说，到 2000 年末、2001 年初，Linux 会有效掌控服务器、数据中心、ISP 和互联网，而微软则守住桌面。截至 2000 年 11 月，这一预测已基本完全应验，除了大型企业数据中心——但看起来几个月内也会实现。

而在此之后行业格局如何演变，关键要看 GNOME、KDE 或是其他 Linux 桌面图形环境（以及配套适配重构的各类应用软件）是否足够优秀，在微软的主场发起挑战。

如果这只是单纯的技术难题，结局倒不会有任何悬念。可事实并非如此——这是人机工效设计和界面心理学的问题，而黑客们从来不擅长这些。也就是说，虽然黑客能为其他黑客设计出很好的界面，但他们往往不擅长建模其他 95% 人群的思维过程，写出能让普通用户和他大姨愿意掏钱购买的界面。

1999 年我们面临的核心短板是应用软件生态；如今局面已经明朗，大批独立软件厂商会入局补全社区自研之外的应用缺口。在我看来，2001 年及往后真正的考验在于：我们能否打磨出媲美（甚至超越！） Macintosh 标杆水准的界面设计，同时保留传统 Unix 体系的各项优势。

截至 2000 年中，来自Macintosh发明者的帮助或许已在路上！安迪·赫兹菲尔德（Andy Hertzfeld）和其他原 Macintosh 设计团队成员成立了一家名为Eazel的开源公司，他们的明确目标就是将 Macintosh 的魔力带给 Linux。

我们常半开玩笑说要“统治世界”，但实现它的唯一途径是服务世界。这意味着要服务于普通用户和他大姨；也意味着要学习以一种根本性的新方式来思考我们所做的事，并将默认环境的用户可见复杂度削减到绝对最低。

计算机终究是服务人的工具。归根结底，软硬件设计的一切挑战，最终都要回归到为所有人、为所有人类而设计。

这条路很长，且不易。但我相信，黑客社区与其企业界的新朋友们联手，将能胜任这项任务。而且正如欧比旺·克诺比可能会说的那样：“源代码与我们同在。”

后记：超越软件？

本书收录的一系列文章只是起点，而不是终点。

关于开源软件，还有许多问题尚未解决。开源这一现象，也引出了很多其他创造性成果与知识产权相关的问题，但它本身并没有提供完善的解决方案。

经常有人问我，开源模式能不能有效应用到软件之外的类型产品。提问最多的，是音乐作品、部分图书内容，或者计算机、电子硬件的设计方案。也经常有人问我是否认为开源模式具有政治含义。

对于音乐、出版、硬件乃至政治议题，我自有不少看法。其中部分观点，的确和本书探讨的同行评审、去中心化、开放共享等思想一脉相承。有兴趣的读者可以访问我的个人主页 http://www.tuxedo.org/~esr/，自行从中推导思考。不过，当我以开源理论研究者、理念布道者的身份开展工作时，我刻意不去延伸这类猜想。

原则很简单：一次只打一场仗。我们社群当下的使命，是提升软件用户对产品质量、稳定性的预期，颠覆软件行业的标准操作流程。我们面对的是根深蒂固的反对势力，他们拥有大量资金、话语权和垄断权力。这场战斗注定艰难，但逻辑和经济规律是清晰的；我们能够赢，而且我们将会赢。而实现这一切的前提，就是守住目标、不分心。

保持目标专注，意味着不要被很多诱人的旁支议题带偏。我在面向黑客群体演讲时，常常强调这一点。过去，我们社群的对外发言人总是容易陷入意识形态争论；如果他们坚持相对具体、务实的主张，本能取得更好的传播效果。

诚然，开源模式的成功，确实让人们开始反思层级管控体系、保密机制、集中式架构以及部分知识产权制度的价值。如果不承认：开源理念暗含（或者至少高度契合）一套关于个人与组织合理关系的广义自由至上主义观点，那就几乎是在自欺欺人。

然而在当下阶段，我认为应该尽量避免把这套思路过度泛化。举个典型例子：音乐作品、大多数书籍和软件有着本质区别，它们一般不需要持续修复缺陷、长期维护。一旦缺少这个前提，同行评审的效用就大大降低，推动类似开源开放模式的理性激励也就基本不复存在。我不想把开源在软件领域行之有效的论证，和其他领域前景不明的尝试捆绑在一起，进而削弱这套立论本身的说服力。

我预计，3-5年之内（也就是 2003–2005 年前后），开源运动就能在软件赛道基本取得阶段性胜利。等到目标实现、成果持续显现一段时间之后，开源思想将会沉淀为非技术人群普遍认知的一部分。到那时，我们才更适合把从开源实践中收获的洞见，推广到更广阔的领域。

与此同时，即便我们黑客没有就相关意识形态制造一些动静，我们依然在实实在在地改变世界。

附录 A：如何成为一名黑客

为什么会有这份文档？

作为《行话档案》（Jargon File，http://www.tuxedo.org/jargon/）的编辑，以及另外几篇类似性质的知名技术文章的作者，经常有满怀热情的网络新手发来邮件，他们实际上在问：“我要怎么学习，才能成为技术顶尖的黑客？”可奇怪的是，似乎没有没有任何一份 FAQ（常见问题解答） 或网页专门解答这个关键的问题，所以我就写了这一篇。

如果你正在离线阅读本文的存档快照，当前最新版本位于 http://www.tuxedo.org/~esr/faqs/hacker-howto.html。

提示：文章末尾附有完整常见问题答疑清单。¹如果你打算发邮件向我咨询本文相关内容，请先通读这份 FAQ，建议仔细阅读两遍。

什么是黑客？

《行话档案》（Jargon File，网址：http://www.tuxedo.org/jargon/）收录了很多对“黑客”（hacker）一词的释义，这些释义大多围绕高超的技术能力、乐于解决问题与突破限制有关。然而，如果你想弄明白怎样才算一名真正的黑客，其中只有两条定义有参考价值。

有一个由专家级程序员和网络高手组成的社群，他们拥有共享的文化，源头可以追溯到早期分时小型机、ARPA 网初代实验，社群成员是顶尖程序员与网络技术高手，正是这群人创造了“黑客”这个词。黑客们搭建了互联网，黑客们成就了今天的 Unix 操作系统，黑客维护着 Usenet 新闻组，万维网能正常运转也离不开黑客。如果你是这个文化的一部分、为社群做出过贡献，圈内人认可你的身份并称呼你为黑客，那你就是一名黑客。

黑客思维并不只局限于软件领域的黑客文化。不少人把这套探索精神用到电子、音乐等领域；实际上，在所有顶尖科学、艺术领域都能看到这种特质。软件黑客能认出各行各业同频的探索者，也可能会称他们为黑客，甚至有人认为黑客精神和所从事的载体无关。但本文后续内容，我们将聚焦于软件黑客的能力和心态，以及创造了“黑客”一词的共享文化的传统。

还有一类人，他们大肆宣称自己是黑客，但其实名不副实。他们大多是处于青春期的男性，以非法入侵计算机、破解电话通信系统为乐。真正的黑客称这些人为骇客（cracker），并且不想与他们有任何关系。真正的黑客大多认为骇客懒惰、不负责任、不太聪明。并反对“能够攻破安全系统就能让你成为黑客”这种观点，就像会搭线偷开汽车算不上汽车工程师一样。可惜有很多记者和作者混淆这两个概念，用 “黑客” 代指恶意入侵者，这让真正的黑客非常恼火。

基本的区别在于：黑客创造，骇客破坏。

如果你想成为一名黑客，请继续往下读。如果你只想做骇客，那就去看 alt.2600 新闻组，等你认清自己没有想象中那么高明的时候，等待你的将是 5-10 年牢狱之灾。关于骇客，我就说这么多。

黑客的态度

黑客解决难题、创造事物，信奉自由，也崇尚自愿互助。想要被圈内认可为黑客，你的行事方式就要体现出这样的心态。而想要做出这种姿态，你必须发自内心认同这套理念。

可如果你只把养成黑客心态当作融入社群的手段，那你就没有抓住要点。发自内心认同这些理念，对你本身很重要——它能推动你持续学习、保持热情。和所有创造性的技艺一样，想要修炼成高手，最有效的办法是效仿大师的思维模式，不止是在理性层面理解，更要在心境上贴合。

所以，如果你想成为一名黑客，请反复体会下面这些理念，直到真正发自内心认同：

1. 世界上充满了要解决的有趣问题。

做一名黑客很有趣，但这是一种需要付出大量努力的有趣。努力需要动力，成功的运动员从身体表现、超越自身极限中获得身体上的愉悦感，从而获得动力。同样地，想成为黑客，你必须从解决问题、打磨技艺、调动思考中获得本能的兴奋。

如果你不是天生就有这种感觉的人，想要走上黑客这条路，就得主动培养这种心态。不然你的钻研热情，迟早会被情欲、财富、旁人的认可这些杂念给消耗掉。

（同时你还要建立对自身学习能力的信心：哪怕当下尚不具备解决难题的全部知识，只要解决其中一小块并从中积累经验，你就会学到足够的知识来解决下一部分，循序渐进，直到最后大功告成。）

2. 同一个问题不应该解决两次。

富有创造力的大脑是宝贵、有限的资源。有那么多迷人的新问题等待解决，不该把脑力浪费在重新发明轮子上。

要表现得像个黑客，你必须相信其他黑客的思考时间是宝贵的。正因如此，分享信息、解决问题之后公开方案，几乎算是一种道义责任。这样其他黑客就可以去解决新问题，不必没完没了地处理旧问题。

（你不必觉得有义务把自己全部创造成果无偿公开，不过愿意这么做的黑客，往往最受其他黑客尊重。出售成果换取收入，填饱肚子、交房租、购置电脑，这完全符合黑客价值观。利用你的黑客技艺养家糊口，甚至靠它致富都没有问题，但你不要背弃你所投身的技艺，也不要背叛你的黑客同伴。）

3. 枯燥和苦役是一种恶。

黑客（乃至所有富有创造力的人）不该陷入枯燥的状态，也不必埋头干愚蠢、重复的苦役。一旦出现这种状况，就代表他们没能去做只有他们才能做的事情——解决新问题。这种人力浪费会损害所有人。所以枯燥与苦役不只是让人难受，它本身就是一种恶。

要表现得像个黑客，你必须由衷认同这一点，尽可能把枯燥的工作自动化，不仅为你自己，也为其他所有人（尤其是其他黑客）。

（这条原则存在一个显而易见的例外。外人看来，黑客有时会去做重复、枯燥的事，或是当作梳理思绪的练习，或者是为了学习某项技能、获取别的地方难以得到的独特体验。但这全都自愿的选择——任何拥有思考能力的人，都不该被迫困在枯燥的处境里。）

4. 自由是一种善。

黑客天生反感威权。任何人一旦有权向你发号施令，就有可能打断钻研你所着迷问题的过程——而且，按照威权主义者的思维方式，他们通常会找出一些愚蠢得惊人的理由这么做。因此，无论在哪里遇到威权主义者的那套脑回路，都必须和它抗争，别让它压制你和其他黑客。

（这不等同于对抗一切权威。孩童需要引导，罪犯应当受到约束。黑客有时可以选择接受某种权威，以换取比服从命令所耗费的时间更有价值的东西。但这是有限度、经过深思熟虑的交易；绝不能对威权主义者想要的那种无条件个人臣服妥协。）

威权主义者靠审查与保密维系自身。他们不信任自愿协作、信息共享，只接纳受自己掌控的所谓“合作”。要表现得像个黑客，你必须本能抵触审查、保密，敌视动用强制或欺骗手段逼迫心智成熟的成年人的行为。而且你愿意把这份信念付诸行动。

5. 态度不能替代能力。

想要成为黑客，你必须养成上面这些心态。但光是摆出一副姿态成不了黑客，就像只靠摆姿态没法成为顶尖运动员或者摇滚巨星一样。成为黑客，离不开才智、实操、投入与辛勤的工作。

所以你要明白，不必迷信所谓 “态度”，应该尊重各式各样的真本事。黑客不愿被故作姿态、装模做样的外行浪费时间，却非常崇拜能力——黑客领域的能力自不必说，任何领域的过硬本事都值得认可。掌握少数人能攻克的高难度技能尤为可贵，而那种需要思维敏锐、深耕技艺、高度专注才能驾驭的本事，则最为难得。

如果你发自内心崇尚实力，就会乐于打磨自身能力；付出的辛劳与投入，会变成高强度的趣味游戏，而不是枯燥的苦役。这一点对成长为黑客至关重要。

黑客基础技能

黑客的态度固然重要，但技能更加重要。态度无法替代能力，而且有一套必备基础技能，你必须先掌握，否则没有任何黑客会认可你称得上黑客。

这套技能清单会随着时代缓慢变化：新技术诞生，旧技能逐渐过时。比如过去它曾包含机器语言编程，而直到最近才纳入 HTML。但就目前而言，它明确包含以下几项。

1. 学会编程

   这当然是最核心的黑客技能。如果你一门计算机语言都不懂，我建议从 Python 开始学起。它设计干净、文档完善，对初学者也相对友好。尽管是一门很好的入门语言，但它绝不是只玩具：它非常强大、灵活，足以胜任大型项目。我写过一篇更详细的 Python 评测：http://noframes.linuxjournal.com/lj-issues/issue73/3882.html。Python 官方网站 http://www.python.org 上也有教程。

   Java 也是一门适合学习编程的语言。它比 Python 更难一些，但编译出来的代码执行速度更快。我认为它非常适合作为你的第二门语言。

   但要认清一点，如果你只懂得一两门语言，是达不到黑客的水平、甚至称不上程序员的——你需要掌握编程的通用思路，而不局限于哪一门具体语言。要成为一名真正的黑客，你得达到这种境界：拿到一门新语言的手册，能将其中的内容与你已知的知识关联起来，短短几天就能上手。这意味着你应该学习几门思路截然不同的语言。

   如果你进入严肃的编程领域，你必须学 C，这是 Unix 的核心语言。C++ 与 C 关系非常密切；如果你懂其中一门，学另一门不会太难。但这两门语言都不适合作为第一门语言入门。

   对黑客来说，其他特别重要的语言还包括 Perl（http://www.perl.com）和 LISP（http://snaefell.tamu.edu/~colin/lp/）。出于实用角度，Perl 值得学。它广泛用于动态网页和系统管理，所以即使你永远不写 Perl，也至少要能读懂它。LISP 值得学，是因为当你彻底领悟它的时候，会获得深刻的启迪——这份感悟会让你此后整个编程生涯都受益，哪怕你日常很少真正使用 LISP。

   实际上，最好能把这 5 门语言全都学一遍（Python、Java、C/C++、Perl、LISP）。它们不只是黑客最重要的编程语言，更代表几种截然不同的编程范式，每一门都能带给很大的启发。

   我无法在这里给出完整的编程学习指南——编程是一门复杂的技艺。但我可以明确告诉你，只靠书本、课程是远远不够的（很多顶尖黑客，甚至可能是大多数都是自学的）。你能从书籍里学到语言特性、零散知识点，可是把知识内化为技能的思维模式，只能靠实践、阅读借鉴别人的好代码不断历练。真正有效的路径是：(a) 阅读代码；(b) 动手写代码。

   学习就像学习用一门自然语言写作。最好的方式是阅读大师的作品，自己动手创作；多读、多写，再多读、多写……直到你写出的文章开始有了范文那种精炼有力的风格。

   在过去，新手很难找到优质代码阅读，因为能让新手黑客研读、动手修改的大型开源程序很少。如今局面已经彻底改变——开源软件、编程工具和操作系统（全都出自黑客之手）已经随处可见。这也正好引出了我们的下一个话题……

2. 获取一款开源 Unix，并学会使用运行

   先假定你拥有一台个人电脑，或是能够借到一台（现在的年轻人条件可太好了:-)）。新手想要学习黑客技能，最重要的一步，就是拿一份 Linux 或是某款 BSD-Unix，装在个人电脑上亲自上手使用。

   是的，这个世界上除了 Unix 还有其他操作系统，但它们是二进制分发的，你读不到代码，也无法修改它。打算在 DOS、Windows 或 MacOS 机器上学习黑客技能，就像裹着石膏学跳舞。

   此外，Unix 是互联网原生的操作系统。就算不懂 Unix 也能上网，但不理解 Unix，就不可能成为互联网黑客。正因如此，今天的黑客文化强烈地以 Unix 为中心。（也不是一直都这样，一些老牌黑客至今仍对此不太满意，但 Unix 和互联网早已深度共生，哪怕微软手握雄厚资本与行业影响力，似乎也难以撼动这层联系。）

   所以，装上一套 Unix。我个人喜欢 Linux，当然你还有别的选择（没错，同一台机器可以同时运行 Linux 和 DOS/Windows）。去学习它、运行它、动手折腾它；用它接入互联网，阅读源码、修改源码。你能拿到一大批编程工具（包含 C、LISP、Python、Perl），它们的水准比微软系操作系统提供的工具要好太多了，可以说是在微软操作系统上是梦寐以求的。你会获得乐趣，而且你会在不知不觉中吸收大量知识，直到后面有一天你再回头看，你已经是一名黑客大师了。

   想要了解更多学习 Unix 的相关内容，可以阅读《登录那吒迦》（Loginataka）：http://www.tuxedo.org/~esr/faqs/loginataka.html 想要获取 Linux，可以访问“哪里可以获取 Linux”页面：http://linuxresources.com/apps/ftp.html

   BSD Unix 的帮助文档与资源站点：http://www.bsd.org

   （提示：如果你是纯新手，我其实不太建议独自硬啃 Linux 或 BSD 的安装流程。想学 Linux，可以寻找本地 Linux 用户社群求助；也可以联系 Linux 互联网互助合作社 LISC：http://www.linpeople.org。LISC 维护着 IRC 交流频道 http://openprojects.nu/services/irc.html，你能在频道里找人协助。）

3. 学会使用万维网，并编写 HTML

   黑客文化创造的大部分成果，都默默在幕后运转，支撑工厂、写字楼与高校正常运作，却不会直观影响普通人的生活。万维网是为数不多的重大例外。这件闪闪发亮、出自黑客之手的 “大玩具”，就连政客都承认它正在改变世界。只凭这一点（当然还有很多其他理由），你就有必要学怎么用万维网。

   这不只是学会用浏览器（谁都会），你还要掌握网页标记语言 HTML。如果你还不会编程，书写 HTML 能够帮你养成一些有益的思维习惯。动手搭建一个个人主页吧。

   不过只有个人主页，离成为黑客还差得很远。网络上到处都是个人主页，其中绝大多数都是毫无意义、没有实质内容的垃圾。就算页面做得花里胡哨，它们仍然只是垃圾（想要了解更多，可以阅读《HTML 地狱页》（The HTML Hell Page）：http://www.tuxedo.org/~esr/html-hell.html）。

   要让你的主页有价值，它必须有内容——要能让其他黑客感到有趣，或是对他们有所帮助。这就引出了下一个话题……

黑客文化中的声誉体系

与大多数不存在货币经济的社群文化一样，黑客世界依靠声誉运转。你试图解决有趣的问题，但这些问题究竟有多有趣，你的解决方案是否真正出色，通常只有具备同等技术水平的技术同行与前辈才有能力评判。

因此，当你参与黑客游戏时，便会明白评判自身成就的标尺，主要来自其他黑客对你技术能力的认可。（这也解释了：只有持续获得其他黑客的认同，你才算一名真正的黑客）这一真相，往往被大众印象中 “黑客独自埋头钻研” 的形象所遮蔽；同时，黑客文化中存在一条不成文的禁忌，尽管它的影响力日渐衰减，但依旧根深蒂固：人们不愿承认，自身行动的动机里掺杂着自我认同与外界的认可。

说得更准确一点，黑客文化是人类学家所称的礼物文化。想要在此获得地位与声誉，不是靠支配他人，不是靠容貌出众，也不是靠拥有他人想要的东西，而是靠给予。具体而言，就是给予你的时间、创造力，以及凭借技术换来的成果。

大体上有五种事可以让你赢得其他黑客的尊重：

1. 编写开源软件

第一种，也是最核心、最传统的方式：开发其他黑客认为实用或有意思的程序，并将源代码开放给整个黑客社群使用。

（我们早年将这类成果称作“自由软件”，但这个名称容易引发歧义，许多人无法准确理解“自由”的含义。如今圈内更多人倾向使用“开源软件”这一说法，参阅：http://www.opensource.org/。）

黑客社群中最受众人敬仰的半神式人物，是那些写出大型成熟程序、满足广泛需求，并且无偿开放成果的开发者。如今人人都在使用他们的程序。

2. 参与开源软件的测试与 debug

那些坚守阵地并 debug 开源软件的人也同样功不可没。这个世界并不完美，软件开发工作里，绝大部分时间不可避免要耗费在 debug 调试阶段。因此任何清醒的开源项目作者都会告诉你：一名优秀的 Beta 测试者价值连城，他们能清晰描述故障现象、精准定位问题，包容快速预览版本里存在的 bug，并且愿意执行简单的诊断流程。哪怕只有一个这样的测试者，就足以改变调试工作的面貌，把一场漫长煎熬的噩梦，变为不过是一次有益无害的磨砺。

如果你是新手，试着找一个你感兴趣的、正在开发中的程序，努力成为一名优秀的Beta测试者。从协助测试、参与 debug，再到动手修改代码，这是一个自然的成长过程。你会在这个过程中学到很多，以后也会有人愿意向你伸出援手。

3. 整理发布有价值的资料

Another good thing is to collect and filter useful and interesting information into web pages or documents like Frequently Asked Questions (FAQ) lists, and make those generally available.

另一种可行方式：搜集、筛选实用且有价值的资讯，整理成网页或者文档（例如常见问题清单 FAQ），向所有人公开分享。

主流技术 FAQ 的维护者，收获的尊重几乎与开源软件创作者不相上下。

4. 维护社群基础设施运转

黑客文化（以及互联网的工程发展）依靠志愿者维系运转。体系持续运作离不开大量必要却鲜有光环的工作：管理邮件列表、运营新闻组、维护大型软件归档站点、起草 RFC 文档与各类技术标准。

那些能把这类事情做好的人会获得很多尊重，所有人都清楚，这些工作极其耗费精力，而且不如写代码那么有趣。愿意承担这类工作，本身就是奉献精神的体现。

5. 回馈、传播黑客文化本身

最后，你可以服务传播这种文化本身（比如编写一份详实可靠的入门指南，介绍如何成为一名黑客 :-)）。但你不能一上来就承担这件事，需要先在圈内积累足够资历，并凭借前面四项贡献中的一项建立声誉。

严格来说，黑客文化没有领袖，但确实有文化英雄、部落长老、历史记述者和代言人。当你在一线奋战够久，也有可能跻身其中。要当心：黑客群体对身居长老之位却大肆标榜自我的人抱有戒备之心，刻意追逐这种名声十分危险。不必主动强求声名，不如踏实沉淀、顺其自然，低调行事、保持雅量。

黑客与书呆子的关联

和大众流传的刻板印象不同，想成为黑客并不一定非得是书呆子。但书呆子特质确实能带来优势，很多黑客本身就是 书呆子。作为社会的边缘人，能让你专心投入真正重要的事，比如思考和黑客活动。

正因如此，不少黑客已经接受了“书呆子”（nerd）这个称呼，甚至把更刺耳的“怪咖”（geek）当作荣誉勋章，借此宣告自己不愿迎合世俗常规的社交标准。想要深入了解相关讨论，可以查阅《极客专题页》（The Geek Page）：http://samsara.circus.com/~omni/geek.html。

如果你既能沉下心深耕技术、做到精通，同时还能兼顾日常社交生活，那自然再好不过，这比我在 1970 年代还是新手时要容易得多。当下主流社会对技术爱好者的包容度高了很多，越来越多人也发现，黑客往往是靠谱、优质的伴侣人选。

如果你之所以投身技术钻研，是因为本身缺少社交生活，这也没关系——至少你能毫无杂念地专注钻研。或许以后你也会慢慢拥有丰富的个人生活。

黑客的格调准则

再说一遍，要成为一名黑客，你必须进入黑客的思维方式。有一些事情，即使你不在电脑前也可以做，它们似乎会有所帮助。这些事不能替代真正的黑客行为（也没有什么能替代），但许多黑客都会做这些事，并且觉得它们在某种基本层面上与黑客的本质相连。

• 学会熟练运用你的母语写作。 尽管程序员不会写作是常见的刻板印象，但数量惊人的黑客（包括我所认识的所有最优秀的黑客）都是出色的写作者。

• 阅读科幻小说，参加科幻大会（这是结识黑客和准黑客的好途径）。

• 修习禅宗，或是练习武术。（二者的心智修炼在关键方面似乎有共通之处。）

• 培养对音乐的鉴赏力，学会欣赏独特的音乐类型。熟练掌握一门乐器，或是练习歌唱。

• 学会品味双关与文字游戏。

你已经在做的这些事情越多，你就越有可能是天生的黑客苗子。为什么偏偏是这些事情，原因并不完全清楚，但它们与一种似乎很重要的左右脑混合技能有关联。黑客既要擅长严谨的逻辑推理，又要能够瞬间跳出问题显而易见的表面逻辑。

最后，再说几件不该做的事：

• 不要使用愚蠢、浮夸的用户 ID 或网名。

• 不要在 Usenet 新闻组（或者其他地方）参与骂战。

• 不要自称 “赛博朋克”，也不要在这样自称的人身上浪费时间。

• 不要发布、发送都是拼写错误与语病的文字。

但凡做出以上任何一种行为，你只会落下蠢货的名声。黑客群体记性很好，你可能需要耗费好几年的时间，才能弥补早年的失误，被他们接纳。

关于网名、代号这件事，值得进一步说明。用代号隐藏真实身份，是幼稚肤浅的行为，也是骇客（cracker）、盗版软件团伙（warez d00dz）以及其他低等生物的典型特征。真正的黑客不会这么做；他们为自己的成果自豪，希望自己的作品与真实姓名绑定。因此，如果你还在用代号，趁早舍弃吧。在黑客文化中，代号只会让人把你当作不入流的门外汉。

其他资源

彼得・西巴赫（Peter Seebach）维护了一份非常实用的《黑客管理 FAQ》（Hacker FAQ，网址：http://www.plethora.net/~seebs/faqs/hacker.html），专门写给不了解黑客群体、不知该如何管理黑客员工的企业管理者。我本人还撰写了《黑客文化简史》（A Brief History of Hackerdom），在线地址：http://www.tuxedo.org/~esr/writings/hacker-history/hacker-history.html。《大教堂与集市》（The Cathedral and the Bazaar）一文系统剖析了 Linux 与开源社群的运行逻辑，链接：http://www.tuxedo.org/~esr/writings/cathedral-bazaar/index.html；续作《开拓智域》（Homesteading the Noosphere）对相关议题展开了更深入、直接的探讨，原文地址：http://www.tuxedo.org/~esr/writings/homesteading/。

常见问题解答（FAQ）

你会教我怎么成为黑客吗？

自从首次发表这篇文章以来，我每周都会收到几封（通常每天几封）希望“教我关于黑客的一切”的邮件。遗憾的是，我没有时间和精力去做这件事；我自己的黑客项目，再加上作为开源理念推广者四处奔走，已经占据了我110%的时间。

即使我有空，黑客之道本质上也是一种你必须自学的心态和技能。你会发现，虽然真正的黑客愿意帮助你，但如果你乞求他们将知道的一切都喂给你，他们不会尊重你。

先自主学习基础知识，展现你的行动力与自学能力。之后，再带着具体问题向你结识的黑客请教。

那我该怎么入门呢？

对你而言，最好的入门方式是参加 LUG（Linux 用户组）线下聚会。你可以在 LDP Linux 综合资讯页面（http://MetaLab.unc.edu/LDP/intro.html）找到各地群组；你附近很可能就有一个，也许与某所学院或大学有关联。如果你主动询问，LUG 的成员或许会提供 Linux 系统，并且肯定会指导你完成安装、带你入门。

我该从什么时候入门？现在学是不是太晚了？

只要你拥有学习的动力，不管年龄多大都是合适的起点。大多数人在 15-20 岁之间产生兴趣，但我也见过不少更早、或是年纪更大才起步的例子。

学会黑客的能力需要多长时间？

取决于你的天赋，以及投入的努力。如果集中精力，大多数人可以在 18 个月到 2 年内掌握一套相当扎实的技能。不过不要以为这就结束了，如果你是一个真正的黑客，你一生都要持续学习、打磨你的手艺。

Visual Basic 和 Delphi 适合作为入门语言吗？

不适合，因为它们不可移植。这些语言没有开源实现，所以你只能受限于供应商选择支持的那些平台。接受这种垄断生态，不符合黑客之道。

Visual Basic 尤其糟糕，凭它是微软专有语言这一点，就可以将它排除掉了。而且和其他早期 Basic 语言一样，它的语言设计有缺陷，会让你养成不好的编程习惯。

其中一个坏习惯，就是会养成依赖单一厂商提供的程序库、图形组件与开发工具的习惯。总的来说，一门语言如果不能至少在 Linux 或某款 BSD 系统，或是至少三家不同厂商的操作系统上运行，就不适合用来学习黑客技术。

你愿意帮我破解系统，或者教我怎么破解吗？

不能。读完这篇 FAQ 还提出这种问题的人，即便我有空辅导，也说明他蠢到不可教化。收到这种邮件，我要么直接无视，要么会用最难听的话怼回去。

我要怎么拿到他人账号的密码？

这是在搞破坏。滚开，白痴。

我的系统被人入侵了。你能帮我防御以后的攻击吗？

不能。到目前为止问过我这个问题的人全都在使用 Windows。想要有效防护 Windows 不被入侵几乎没有可能，它的代码与架构缺陷实在太多，保护 Windows 就像试图用筛子给船舀水。唯一可靠的办法就是换成 Linux 或其他具有真正安全性的操作系统。

我的 Windows 软件出问题了，你能帮忙解决吗？

可以。打开 DOS 提示符，输入“format c:”。几分钟之后，你遇到的所有麻烦都会消失^b。

我在哪里可以找到真正的黑客交流？

最好的方式是找到本地的 Unix 或 Linux 用户组，参加他们的线下聚会（你可以在 Metalab 站点的 LDP 网页上找到各地用户组清单链接：http://metalab.unc.edu/LDP/）。

（我过去常说在 IRC 上找不到真正的黑客，但据我所知，这种情况正在改变。不少和 GIMP、Perl 这类项目相关的正统黑客社群都有了 IRC 交流频道。）

你能推荐一些和黑客相关的优质书籍吗？

我维护了一份《Linux 阅读清单 HOWTO》（http://sunsite.unc.edu/LDP/HOWTO/Reading-List-HOWTO/index.html）或许对你有所帮助。另外《登录那吒迦》（Loginataka）^a也值得一读。

我应该先学哪种语言？

如果你还不了解，先学 HTML。市面上有很多华而不实、炒作过度且质量低劣的 HTML 读物，好书却少得可怜。我最推荐《HTML 权威指南》（HTML: The Definitive Guide，http://www.oreilly.com/catalog/html3/）。

但HTML不是完整的编程语言。当你准备正式学习编程时，我推荐从 Python（http://www.python.org）开始。你会听到很多人推荐 Perl，而且 Perl 仍然比 Python 更流行，但它更难学，而且（在我看来）设计得没有 Python 好。为 Python 初学者准备的网络资源可以在http://www.deja.com/getdoc.xp?AN=523189453找到。

C 语言非常重要，但它比Python或Perl都难得多。不要把它当作第一门编程语言。

Windows 用户，不要满足于 Visual Basic。它会让你养成坏习惯，并且写出来的代码不能移植到 Windows 之外。不要再使用它。

我需要什么样的硬件设备？

过去个人电脑算力不足、内存容量有限，这给黑客的学习过程带来了人为限制。但这种情况在不久前已经改变：一台 Intel 486DX50 级别及以上的设备，就可以进行开发工作、运行 X 窗口系统、进行网络通信，而且今天你能买到的最小的磁盘也足够大。

在选择学习用的机器时，重要的是它的硬件是不是与 Linux 兼容（或者与 BSD 兼容，如果你选择这条路的话）。大多数现代设备都能满足条件；唯一容易出问题的地方是调制解调器（猫）和打印机，部分设备搭载只适配 Windows 的专属硬件，无法在 Linux 环境正常工作。

有一份硬件兼容性的 FAQ，最新版本在这里：http://users.bart.nl/˜patrickr/hardware-howto/Hardware-HOWTO.html。

我需要憎恨、抨击微软吗？

不，你没必要这么做。不是说微软就不让人厌恶，而是在微软诞生之前，黑客文化就已经存在；就算微软已经成为了历史，黑客文化也仍然会存在。别把精力浪费在憎恶微软上，专心打磨自己热爱的技艺就好。写出优秀的代码足以有力回击微软，而不会玷污你的业力。

但开源软件不会让程序员无法谋生吗？

可能性并不大。到目前为止，开源软件行业整体是在创造岗位，而不是削减岗位。如果开发一套程序比放任需求空缺更有净经济效益，那么无论成品最终是否开放免费，程序员都能够获得报酬。而且，无论写了多少“自由”软件，用户似乎总是有更多新应用、定制应用的需求。我在开源（http://www.opensource.org）页面上对此有更多论述。

我该怎么入门？我在哪里可以得到免费的 Unix 系统？

我在本文其他部分提供了一些最常用的免费 Unix 链接。想要成为黑客，你需要具备动力、主观能动性与自学能力。现在就行动吧……

附录 B：fetchmail 项目增长的统计趋势

下方散点图由 Gnuplot 3.7 绘制，数据直接从 fetchmail 项目的 NEWS 文件中提取，提取过程使用了两个自定义的 Shell 脚本，脚本可在项目官网获取。

这张图展现 fetchmail 项目参与人数的增长趋势。横轴为距离基准时间的天数，基准时间是 1996 年 10 月，我从项目 1.9.0 版本开始收集统计数据；左侧纵轴代表参与人数。每一个版本发布对应一个数据点，因此数据点标记的密度变化能够反映版本发布频率。

图表最靠前区域的峰值（标注「无效地址已剔除」之前）属于统计伪迹，因为当时我还没有定期清理失效邮箱地址。邮件列表人员流动率，目测大约为每月 5%（但这只是估算，我没有确切数据）。

方块散点代表总参与人数；将邮件列表拆分之后，叉号散点对应 fetchmail-friends 邮件列表人数；三角散点则是拆分后 fetchmail-announce 列表的人数。

菱形散点用来追踪项目代码规模（单位：代码行数，对应右侧纵轴）。这组曲线与另外三组数据之间的刻度比例是人为设定的，不具备真实对应关系。

这张图很能说明问题，以下几个趋势格外突出：

• 长期来看，项目参与人数随时间呈现相当稳定的线性增长。

• 项目发展历程里的关键节点，是 1997 年 10 月发布的 4.3.0 版本。当时我宣告代码不再进入新功能开发阶段，转入维护模式，同时拆分了 fetchmail 邮件列表。

• 4.3.0 版本发布前夕，是项目史上版本迭代最密集的一段时期（密集发布过程中间出现了一个空档，是因为我休了两周假期）；在此之后，版本发布节奏明显放缓。

• 4.3.0 之后，开发者人数大体保持稳定，平均人数约 250 人。

• 4.3.0 之后新增的参与者，几乎全部来自 announce 列表；他们只是 fetchmail 使用者，并不积极参与协同开发。

• 代码规模的增长趋势看起来属于亚线性，有可能是对数增长。

参与人数的线性增长趋势格外耐人寻味。项目依靠口碑自发传播，按照先验推测，我们原本预期会见到指数增长或是逻辑斯谛增长。

也有人提出：之所以会呈现线性增长，可能是因为开源项目总量、具备开发能力的程序员人数，两者都以相同的趋势曲线（大概率是指数增长）同步上升。

还有一些网页也做了同类项目统计分析：

• http://kitenet.net/programs/debhelper/stats/：收录打包工具 debhelper 的各项增长统计数据。

• http://durak.org:81/sean/pubs/kfc/：专门整理 Linux 内核相关术语词汇

译后记：论此译本的翻译范式、翻译作为社会行动

在本篇小记中，译者会集中阐释在翻译过程当中思考的一些问题与具体的方法论，尤其针对论证类文本翻译中突出的问题，借此抛砖引玉。把问题意识推到最显眼的地方、逐一辩驳各类对立观点并非此篇的意图，目的仅仅是从批判性视角说明译者每一处译法取舍背后的考量。

此译本的翻译伦理

译者认为必须坦诚承认：译者很难全然隐身于幕后，而译者对文本的理解必然会影响文本本身，像 ESR 《大教堂与集市》这种涉及到跨学科概念层面的多层论证更是如此。因此，译者选择显化潜在的影响，而不是装作不会带来影响。

非虚构类翻译的功能对等

当下流行的翻译伦理沿袭严复提出的“信达雅”理念，“信达之外，求其尔雅”，作为“尔雅”的“雅”，是“合规范；纯正”的意思，与文笔优雅的雅存在根本的区别。关于以优雅作为“信达雅”的标准所产生的危害，可以参照这篇文章。译者在此只是借用曹明伦老师对“雅”的辨析，并意图再向前推进一步：

我们现在比以往任何时候都更加需要去提防过分优雅的写作；因为当学问取得了某种进步、各种写作中都出现了杰出的作者之后，人们最容易陷进去的，正是过分优雅的写作方式。

——休谟《论写作的质朴和优雅》

另外，传统翻译（尤其是文学类翻译）似乎总有一种“什么都不准删掉，什么都不准加上去”的论调，在文学类翻译（尤其是经典文学类翻译）里保持字句忠实固然自洽也很有价值，在处理论证类文本时也相当有正本清源的意义，然而译者在处理论证文本的过程中，对此理念也有所疑问：此时“信达雅”到底服务于字词本身，还是作者本人想构建的论证结构与概念体系？译者认为，“信达雅”不应该只针对字词（尤其是作为“尔雅”的“雅”），无视论述文体具有的论证结构维度，既然同样的“信达雅”会导致好几种截然不同的理解，那么其标准就应该更加具体、更具有可操作性，而不是仅停留于“会批判性思考就行”。论证类文本与文学类文本不同，不以字词风格、语感最优先，而是论证结构最优先：

1. 如果二者可以兼顾，那最优先的策略是保留精确的概念锚点；
2. 如果二者产生了系统性的冲突，从字词的角度来看“忠实”的、严格逐字直译的译法，会让读者花费更多精力梳理逻辑，那么个人的倾向就是展现论述文体的论证结构，而并非局限于字词。

“什么都不准删掉，什么都不准加上去”的评判标准在这类体裁中会暴露出异文化背景意象、理解精确学术/专业概念及论证的理解困难，或许更好的处理方式是：坦诚哪里做了改动及做出改动判断的理由。

戏谑感的传达

• hackerdom：“黑客国度”而不是“黑客圈”。此处 ESR 有意玩 kingdom 的梗，还主动用了远古时代、网络国度、historian 这类表述，他的用意已经很明确，故选择贴合这类比喻。

专业/学术概念不同于日常语言

涉及学术/专业概念时，刻意保留精确溯源的锚点，概念精度 > 流畅性。

• 3.3 中的 consensus：“一致性理论”而不是“共识”。“共识”并不与“不成文的权属惯例”构成矛盾关系，而一致性理论蕴含的“共识背后的制度正当性”却与“不成文的权属惯例”形成了思想上的张力。
• 3.4、3.5 等章节中的 property：“财产权/产权”而不是“所有权”。此处是欧美普通法作为权利束的产权，4.5 ESR 还援引了洛克的土地财产权理论，并非大陆法下不可分割的所有权，绝不能与“所有权”混同。
• 4.4 中的 free：兼有“自由”与“免费”的含义。由于与自由软件理念体系强绑定，且在原文中“竞争性商品的排他性信息”作为 Information wants to be free 的反证，落脚点在“不自由”的排他性而不是“不免费”，故选择“自由”而不是免费，但添加引号、加注说明。
• 4.8 中的 reciprocity：“互惠性”而不是“对等性/等价性”。作“对等性”译确实通顺，但会丢掉莫斯礼物文化理论脉络中“等价互惠”这一关键锚点，会丢失包含“给予-接受-回报”义务的思想张力。

反例：只是比喻借用，不涉及理论内核，日常化处理

• 1.5 中的 colossi：没有明确证据指向罗德岛太阳神巨像“宏伟但很快倒塌”这层含义，故保守处理，作“巨头”译。
• 1.5 中的 fault line：不涉及塞缪尔·亨廷顿的“断层线冲突”理论内核，故作“两大截然不同的阵营”意译。

论证结构与字词的张力

• 4.9：“吃自助餐不能几个人合买一份拼单”而不是“沙拉吧内禁止分享食物”（no sharing at the salad bar）。此处是理解“如果站点使用支持服务的用户数量超出合同约定，则可以终止服务合同或要求支付更高费用”这一逻辑的类比，此处以方便汉语读者直观理解为优先。

• 其余改写

  • 显化ESR的论证语气

  • 显化ESR未明确说明的论点与逻辑链

    • 显化论点

      e.g.

      a. Indistinguishable from Magic （开源社区的成就）与魔法无异

      b. Beyond Geeks Bearing Gifts 超越极客与礼物文化（的视角）

      c. The Inverse Commons 反向公地（的正向循环）

      d. Why Sale Value Is Problematic 销售价值的困境

      e. Indirect Sale-Value Models （开源软件的）间接获利之道

      f. 以及其它大部分标题

    ESR的正文几乎都是在论述，指向不明的标题显然会增加读者的阅读负担。译者意图用这种做法，确保读者看到标题就能一眼理解ESR这篇文章要说什么，从而实现ESR文本在中文语境下的功能对等。d的全文语境是销售价值遇到了很多问题和挑战，而不是抨击销售价值本身漏洞百出、站不住脚，因此problematic需要适度意译，消除“销售价值概念本身有漏洞”这一歧义。

    • 显化行文逻辑链

    e.g. 4.7中ESR原文如下：

    Maybe it’s for electronic commerce,

    maybe you’re a high-visibility media outlet selling advertising,

    maybe you’re a portal site.

    译者采用了以下处理，补写了原文没有深入阐释的逻辑：

    它可能用来支持电子商务（高频交易），

    也可能用来给高流量媒体做广告营销，

    又或者用来支持门户网站（日常运维）。

    另外此处用了“……也……又”让列举层层递进，同时补齐细分业务场景与“高流量媒体做广告营销”对齐，以提升各位读者的阅读体验。 又例如4.9中ESR的各小节标题：

    Loss-Leader/Market Positioner

    Widget Frosting

    Give Away the Recipe, Open a Restaurant

    Accessorizing

    Free the Future, Sell the Present

    Free the Software, Sell the Brand

    Free the Software, Sell the Content

    译者的处理如下：

    （舍卒保车，）抢占市场

    开源软件，反哺硬件

    共享配方，经营餐馆

    （立足开源，）销售周边

    限期闭源，永久开源

    解放软件，销售品牌

    解放软件，销售内容

    全部采用4-4字的格式，在不损害原意的前提下保持对仗，加粗的标题和括号部分并不对应英文原文，Widget Frosting“西点上撒糖霜”的意象也做了中文语境下容易理解的重构。译者这里也采取了处理章节标题的策略，结合对应的文本拟定了提纲挈领的标题，让读者一眼理解小节的论述，实现该小节标题的功能对等。

译注

• 刻意保留精确溯源的锚点（中文人名、原文人名、中文书名、原文书名，谁在哪本书中提出了xxx），供有需求的读者溯源使用，以求概念可溯源、可验证

人机协同翻译

AI 工具在此译本的翻译中承担了以下辅助工作：

• 生成译文初稿：AI 辅助生成各章节的初稿译文，作为人工修订的起点。所有 AI 生成的初稿均经过逐句审校、修订或重译。

• 辅助润色译文：AI 辅助润色语句通顺度与语体。

• 辅助学术查证：在译者确认学术判断的方向后，AI 协助检索文献出处、核对外文人名及书名原文、整理跨学科术语的背景信息。所有查证结果均由译者独立核实和判断。

术语锚定和译注框架并非在翻译开始前预先确立，而是在 AI 初稿生成后，由译者在逐章修订的过程中逐步做术语锚定、确立译注框架、术语统一等动作，引入一致性、建立体系。最终所有术语定名、译注学术判断及论证结构的显化策略，均由译者独立完成。

开源翻译作为社会行动

ESR 在“超越软件？”一节中说过“音乐作品、大多数书籍和软件有着本质区别，它们一般不需要持续修复缺陷、长期维护”，然而时隔二十多年，音乐书籍等创作产物也越来越多地采用数字化模式，生产模式也产生了剧烈的变化。数字化模式让长期维护数字化的需求浮上水面，数字化书籍多了：维护作品存续、适配 PDF/EPUB/MOBI 格式，防止未授权篡改的需求；书籍纠错评审流程慢、读者反馈流程长甚至无果的情况也屡见不鲜，而这个问题由于数字化程度加深显得更加迫切了。一本重要的译著（比如《大教堂与集市》），在豆瓣、知乎、技术社区被反复引用、讨论、争论。如果译文中存在一处术语误译或逻辑偏差，这个错误会像病毒一样在网络上扩散，成为后续讨论的“事实前提”，等到出版社重印时修正或者出修订版那就至少得好几年了，这样的效率是难以响应当下的需求的。译者认为，提供相应的 Issue 模块是加快纠错评审流程可以认真考虑的一个方案（PR 则需要谨慎考虑）。

• 从代码作为社会行动，到翻译作为社会行动（翻译服务的深层目的）
• SSL 式知识传播 vs P2P 式知识传播
• 出版社/机构权威翻译 vs 民间众包翻译
• 当代翻译的“文化转向” 为什么用学术翻译的标准翻译技术随笔？《大教堂与集市》不只是技术随笔，翻译并非复制与“译者透明隐身”，经典并非静止的、而是生成的，当下有需要回应与深化的议题，不能视而不见。忠实于字句的翻译传统固然有相当的价值，然而注疏传统也同样存在。翻译行为的价值不仅在于传递文本本身，更在于与原本对话、常译常新
• 开源翻译的实践及好处
  • 开源翻译配套设施（重点强调可追溯性，翻译过程可见透明，回应当下议题）
  • 开源翻译不代表集市模式

此译本的版本理念

以上翻译伦理呼吁一套符合数字时代特征、内容透明、灵活查阅更改的版本机制，故译者也需要在此阐述全新的版本理念。此译本的版本理念与传统出版有较大出入，具体区别在此不加赘述。该版本由分布式版本控制工具 git 做版本管理，译者认为有必要单独提出。

为什么是 git 而不是区块链？

当前在讨论数字内容的可信性与版本管理时，一种常见的 AI 回应是“使用区块链”，而这一建议在出版等需要持续迭代的场景中并不适用。下文说明为何选择 git 而非区块链。

• 核心是修改可追溯、修改内容可见，而不是不修改，区块链的技术特性决定了修改流程繁琐。出版流程理应鼓励快速迭代、及时修正，减少修改的时间成本，而不是增加修改的时间成本。git 也有精细的权限管理，不合规的提交不会并入主线导致内容污染
• 区块链圈层小，普通用户不可及，普通用户接触 git 远比区块链友好
• 区块链本质高度依赖资本生态的小圈子，git 则能做到从中解耦
• 落地的成本-效用核算：区块链费用高昂，动辄上万，搭建繁琐；git 是免费的，搭建简单

git commit 作为版本最小粒度

与传统出版的第一版、第二版不同，此译本采用git commit的哈希值作为译本的最小粒度，以便各位读者追溯，贯彻修改可追溯、译本演化过程可见的翻译伦理。

和当今各大图书平台的电子书不同，git的分布式特性使得译稿的历史痕迹很难被一笔抹去，即使有人在自己的仓库做了篡改，只要还有人clone了仓库，那么这种篡改的尝试也终将失败。clone仓库的人越多，那么译本的历史痕迹越难成功篡改。

源码防伪与产物防伪

仅凭上述手段无法解决两个高发问题：

• 他人 clone 代码仓库，更改其中内容
• 直接更改释出的 pdf 内容

如果没有机制能将译者的产物与上述两种情况的产物区分开，那么此译本的可信度将被稀释。译者不愿出现上述后果，所以采用以下思路采取防伪措施：

• 在源码（及其提交）和产物两个层级上加入唯一的、无法伪造/去除/混淆的作者身份识别标记，无论是 fork、clone 源仓库还是直接更改 pdf，都无法提供等同于本仓库提交和释出文件的身份识别标记。
• 不做额外的 pdf 加密。防伪≠加密，防伪的首要目的在于识别产物唯一且无法伪造的作者身份，不对内容更改做额外限制。

基于这种思路，在仓库提交和释出文件上签署 PGP 公钥签名 + X.509 自签名证书就是顺理成章的方式了。

附言

此译本已采用 typst 排版工具深度优化 pdf 文件的排版，使其更适合深度文本阅读，并提供更好的阅读体验。预计将分别提供适合纸质版打印的 A5 pdf 文件与适合电子设备阅览的 pdf 文件，如有排版上的优化建议也可以提 issue。

另外，此译本计划：

• 为 zotero 提供更细粒度的引用格式，以便引用以 git commit hash 为颗粒度的网络文本；
• 采用功能更强大、更适配书籍表现力的 asciidoc 输出格式，而不是现行的 markdown。

支付声明

你可以支付看这本译本的费用（对，是支付，不是打赏/赞助😉），份额随喜，下限为 0 元。你的一笔支付，译者完全不保证用途：它可能会成为译者一瓶金银花露，可能会成为译者一顿辣椒炒肉，也可能成为译者手头一本新漫画书，但未必是用于完善译本和基建设施的资金；支付的 0 元也同样可能会用来完善译本和基建设施:D