http://www.pgsqldb.org/mwiki/index.php/%E6%95%99%E5%A0%82%E4%B8%8E%E9%9B%86%E5%B8%82%EF%BC%88%E8%BD%AC%E8%BD%BD%EF%BC%89

教堂与集市（转载）

From PostgreSQL 中文维基, PostgreSQL 中文站, PostgreSQL 中国社区, PostgreSQL Chinese community

Jump to: navigation, search

第一章 Hacker文化简史

[编辑] 序曲: Real Programmer

故事一开始，我要介绍的是所谓的Real Programmer。

他们从不自称是Real Programmer、Hacker或任何特殊的称号；"Real Programmer"这个名词是在1980年代才出现，但早自1945年起，电脑科学便不断地吸引世界上头脑最顶尖、想像力最丰富的人投入其中。从 Eckert & Mauchly 发明ENIAC後，便不断有狂热的programmer投入其中，他们以撰写软件与玩弄各种程式设计技巧为乐，逐渐形成具有自我意识的一套科技文化。当时这批Real Programmers主要来自工程界与物理界，他们戴著厚厚的眼镜，穿聚酯纤维T恤与纯白袜子，用机器语言、汇编语言、FORTRAN及很多古老的语言写程式。他们是Hacker时代的先驱者，默默贡献，却鲜为人知。

从二次大战结束後到1970早期，是打卡计算机与所谓"大铁块"的主机（mainframes）流行的年代，由Real Programmer主宰电脑文化。Hacker传奇故事如有名的 Mel （收录在Jargon File中）、Murphy's Law的各种版本、mock- German "Blinkenlight" 文章都是流传久远的老掉牙笑话了。

※译者：Jargon File亦是本文原作者所编写的，里面收录了很多Hacker用语、缩写意义、传奇故事等等。Jargon File有出版成一本书：The New Hacker's Dictionary，MIT PRESS出版。也有Online版本： http://www.ccil.org/jargon

※译者：莫非定律是：当有两条路让你抉择，若其中一条会导致失败，你一定会选到它。它有很多衍生说法：比如一个程式在demo前测试几千几万次都正确无误，但demo 那一天偏偏就会出bug。

一些Real Programmer仍在世且十分活跃 (本文写在1996年)。超级电脑Cray 的设计者Seymour Cray，据说亲手设计Cray全部的硬体与其操作系统，作业系统是他用机器码硬干出来的，没有出过任何bug或error。Real Programmer 真是超强！

举个比较不那么夸张的例子：Stan Kelly-Bootle，The Devil's DP Dictionary 一书的作者(McGraw-Hill， 1981年初版，ISBN 0-07-034022-6)与Hacker 传奇专家，当年在一台Manchester Mark I开发程式。他现在是电脑杂志的专栏作家，写一些科学幽默小品，文笔生动有趣投今日hackers所好，所以很受欢迎。其他人像David E. Lundstorm，写了许多关於Real Programmer的小故事，收录在A few Good Men From UNIVAC这本书，1987年出版，ISBN-0- 262-62075-8。

※译：看到这里，大家应该能了解，所谓Real Programmer指的就是用组合语言或甚至机器码，把程式用打卡机punch出一片片纸卡片，由主机读卡机输入电脑的那种石器时代Programmer。

Real Programmer的时代步入尾声，取而代之的是逐渐盛行的Interactive computing，大学成立电算相关科系及电脑网络。它们催生了另一个持续的工程传统，并最终演化为今天的开放代码黑客文化。

[编辑] 早期的黑客

Hacker时代的滥觞始於1961年MIT出现第一台电脑DEC PDP-1。MIT的Tech Model Railroad Club（简称TMRC）的Power and Signals Group买了这台机器後，把它当成最时髦的科技玩具，各种程式工具与电脑术语开始出现，整个环境与文化一直发展下去至今日。这在Steven Levy的书《Hackers》（Anchor/Doubleday 公司，1984年出版）前段有详细的记载。

※译：Interactive computing并非指Windows、GUI、WYSIWYG等介面，当时有terminal、有shell可以下指令就算是Interactive computing了。最先使用Hacker这个字应该是MIT。1980年代早期学术界人工智慧的权威：MIT 的Artificial Intelligence Laboratory，其核心人物皆来自TMRC。从1969年起，正好是ARPANET建置的第一年，这群人在电脑科学界便不断有重大突破与贡献。

ARPANET是第一个横跨美国的高速网络。由美国国防部所出资兴建，一个实验性质的数位通讯网络，逐渐成长成联系各大学、国防部承包商及研究机构的大网络。各地研究人员能以史无前例的速度与弹性交流资讯，超高效率的合作模式导致科技的突飞猛进。

ARPANET另一项好处是，资讯高速公路使得全世界的hackers能聚在一起，不再像以前孤立在各地形成一股股的短命文化，网络把他们汇流成一股强大力量。开始有人感受到Hacker文化的存在，动手整理术语放上网络，在网上发表讽刺文学与讨论Hacker所应有的道德规范。（Jargon File的第一版出现在1973年，就是一个好例子）， Hacker文化在有接上ARPANET的各大学间快速发展，特别是（但不全是）在信息相关科系。

一开始，整个Hacker文化的发展以MIT的AI Lab为中心，但Stanford University 的Artificial Intelligence Laboratory（简称SAIL）与稍後的Carnegie-Mellon University（简称CMU）正快速崛起中。三个都是大型的资讯科学研究中心及人工智慧的权威，聚集著世界各地的精英，不论在技术上或精神层次上，对Hacker文化都有极高的贡献。

为能了解後来的故事，我们得先看看电脑本身的变化；随著科技的进步，主角MIT AI Lab也从红极一时到最後淡出舞台。

从MIT那台PDP-1开始，Hacker们主要程式开发平台都是Digital Equipment Corporation 的PDP迷你电脑序列。DEC率先发展出商业用途为主的interactive computing及time-sharing操作系统，当时许多的大学都是买DEC的机器，因为它兼具弹性与速度，还很便宜（相对於较快的主机mainframe）。便宜的分时系统是Hacker文化能快速成长因素之一，在PDP流行的时代，ARPANET上是DEC机器的天下，其中最重要的便属PDP-10，PDP -10受到Hacker们的青睐达十五年；TOPS-10（DEC的操作系统）与MACRO-10（它的组译器），许多怀旧的术语及Hacker传奇中仍常出现这两个字。

MIT像大家一样用PDP-10，但他们不屑用DEC的操作系统。他们偏要自己写一个：传说中赫赫有名的ITS。

ITS全名是"Incompatible Timesharing System"，取这个怪名果然符合MIT的搞怪作风――就是要与众不同，他们很臭屁但够本事自己去写一套操作系统。ITS始终不稳，设计古怪，bug也不少，但仍有许多独到的创见，似乎还是分时系统中开机时间最久的纪录保持者。

ITS本身是用汇编语言写的，其他部分由LISP写成。LISP在当时是一个威力强大与极具弹性的程式语言；事实上，二十五年後的今天，它的设计仍优於目前大多数的程式语言。LISP让ITS的Hacker得以尽情发挥想像力与搞怪能力。LISP是MIT AI Lab成功的最大功臣，现在它仍是Hacker们的最爱之一。

很多ITS的产物到现在仍活著；EMACS大概是最有名的一个，而ITS的稗官野史仍为今日的Hacker们所津津乐道，就如同你在Jargon File中所读到的一般。在MIT红得发紫之际，SAIL与CMU也没闲著。SAIL的中坚份子後来成为PC 界或图形使用者介面研发的要角。CMU的Hacker则开发出第一个实用的大型专家系统与工业用机器人。

另一个Hacker重镇是XEROX PARC公司的Palo Alto Research Center。从 1970初期到1980中期这十几年间，PARC不断出现惊人的突破与发明，不论质或量，软件或硬体方面。如现今的视窗滑鼠介面，雷射印表机与区域网络；其D系列的机器，催生了能与迷你电脑一较长短的强力个人电脑。不幸这群先知先觉者并不受到公司高层的赏识；PARC是家专门提供好点子帮别人赚钱的公司成为众所皆知的大笑话。即使如此，PARC这群人对Hacker文化仍有不可抹灭的贡献。1970年代与PDP-10文化迅速成长茁壮。Mailing list的出现使世界各地的人得以组成许多SIG（Special-interest group），不只在电脑方面，也有社会与娱乐方面的。DARPA对这些非`正当性'活动睁一只眼闭一只眼，因为靠这些活动会吸引更多的聪明小夥子们投入电脑领域呢。

有名的非电脑技术相关的ARPANET mailing list首推科幻小说迷的，时至今日ARPANET变成Internet，愈来愈多的读者参与讨论。Mailing list逐渐成为一种公众讨论的媒介，导致许多商业化上网服务如CompuServe、Genie与Prodigy的成立。

[编辑] Unix 的兴起

此时在新泽西州的郊外，另一股神秘力量积极入侵Hacker社会，终於席卷整个PDP-10的传统。它诞生在1969年，也就是ARPANET成立的那一年，有个在AT&T Bell Labs的年轻小夥子Ken Thompson发明了Unix。

Thomspon曾经参与Multics的开发，Multics是源自ITS的操作系统，用来实做当时一些较新的OS理论，如把操作系统较复杂的内部结构隐藏起来，提供一个介面，使的programmer能不用深入了解操作系统与硬体设备，也能快速开发程式。

※译：那时的programmer写个程式必须彻底了解操作系统内部，或硬体设备。比方说写有IO的程式，对於硬碟的转速，磁轨与磁头数量等等都要搞的一清二楚才行。

在发现继续开发Multics是做白工时，Bell Labs很快的退出了（後来有一家公司Honeywell出售Multics，赔的很惨）。Ken Thompson很喜欢Multics上的作业环境，於是他在实验室里一台报废的DEC PDP-7上胡乱写了一个操作系统，该系统在设计上有从Multics抄来的也有他自己的构想。他将这个操作系统命名Unix，用来反讽Multics。

※译：其实是Ken Thompson写了一个游戏"Star Travel" 没地方跑，就去找一台的报废机器PDP-7来玩。他同事Brian Kernighan嘲笑Ken Thompson说：「你写的系统好逊哦，乾脆叫Unics算了。」（Unics发音与太监的英文eunuches 一样），後来才改为Unix。

他的同事Dennis Ritchie，发明了一个新的程式语言C，於是他与Thompson用C把原来用汇编语言写的Unix重写一遍。C的设计原则就是好用，自由与弹性，C 与Unix很快地在Bell Labs得到欢迎。1971年Thompson与Ritchie争取到一个办公室自动化系统的专案，Unix开始在Bell Labs中流行。不过Thompson与Ritchie的雄心壮志还不止於此。

那时的传统是，一个操作系统必须完全用汇编语言写成，始能让机器发挥最高的效能。hompson与Ritchie，是头几位领悟硬体与编译器的技术，已经进步到作业系统可以完全用高阶语言如C来写，仍保有不错的效能。五年後， Unix已经成功地移植到数种机器上。

※译：Ken Thompson与Dennis Ritchie是唯一两位获得Turing Award（电脑界的诺贝尔奖）的工程师（其他都是学者）。

这当时是一件不可思议的事！它意味著，如果Unix可以在各种平台上跑的话，Unix 软件就能移植到各种机器上。再也用不著为特定的机器写软件了，能在Unix上跑最重要，重新发明轮子已经成为过去式了。

除了跨平台的优点外，Unix与C还有许多显著的优势。Unix与C的设计哲学是"Keep It Simple, Stupid"。Programmer可以轻易掌握整个C的逻辑结构（不像其他之前或以後的程式语言）而不用一天到晚翻手册写程式。而Unix提供许多有用的小工具程式，经过适当的组合（写成Shell script或Perl script），可以发挥强大的威力。

※注：The C Programming Language是所有程式语言书最薄的一本，只有两百多页哦。作者是Brian Kernighan 与Dennis Ritchie，所以这本C语言的圣经又称`K&R'。

※注："Keep It Simple, Stupid"简称KISS，今日Unix已不follow这个原则，几乎所有Unix 都是要灌一堆有的没的utilities，唯一例外是MINIX。

C与Unix的应用范围之广，出乎原设计者之意料，很多领域的研究要用到电脑时，他们是最佳拍档。尽管缺乏一个正式支援的机构，它们仍在AT&T内部中疯狂的散播。到了1980年，已蔓延到大学与研究机构，还有数以千计的hacker想把 Unix装在家里的机器上。

当时跑Unix的主力机器是PDP-11、VAX系列的机器。不过由於UNIX的高移植性，它几乎可安装在所有的电脑机型上。一旦新型机器上的UNIX安装好，把软件的C原始码抓来重新编译就一切OK了，谁还要用汇编语言来开发软件？有一套专为UNIX设计的网络――UUCP：一种低速、不稳但很成本低廉的网络。两台UNIX机器用条电话线连起来，就可以使用互传电子邮件。UUCP是内建在UNIX系统中的，不用另外安装。於是UNIX站台连成了专属的一套网络，形成其Hacker文化。在1980第一个USENET站台成立之後，组成了一个特大号的分散式布告栏系统，吸引而来的人数很快地超过了ARPANET。

少数UNIX站台有连上ARPANET。PDP-10与UNIX的Hacker文化开始交流，不过一开始不怎么愉快就是了。PDP-10的Hacker们觉得UNIX的拥护者都是些什么也不懂的新手，比起他们那复杂华丽，令人爱不释手的LISP与 ITS，C与 UNIX简直原始的令人好笑。『一群穿兽皮拿石斧的野蛮人』他们咕哝著。

在这当时，又有另一股新潮流风行起来。第一部PC出现在1975年；苹果电脑在1977年成立，以飞快的速度成长。微电脑的潜力，立刻吸引了另一批年轻的 Hackers。他们最爱的程式语言是BASIC，由於它过於简陋，PDP-10 的死忠派与UNIX迷们根本不屑用它，更看不起使用它的人。

※译：这群Hacker中有一位大家一定认识，他的名字叫Bill Gates，最初就是他在8080上发展BASIC compiler的。

[编辑] 古老时代的终结

1980年同时有三个Hacker文化在发展，尽管彼此偶有接触与交流，但还是各玩各的。ARPANET/PDP-10文化，玩的是LISP、MACRO、TOPS-10与ITS。UNIX与C的拥护者用电话线把他们的PDP-11与VAX机器串起来玩。还有另一群散乱无秩序的微电脑迷，致力於将电脑科技平民化。

三者中ITS文化（也就是以MIT AI LAB为中心的Hacker文化）可说在此时达到全盛时期，但乌云逐渐笼罩这个实验室。ITS赖以维生的PDP-10逐渐过时，开始有人离开实验室去外面开公司，将人工智慧的科技商业化。MIT AI Lab 的高手挡不住新公司的高薪挖角而纷纷出走，SAIL与CMU也遭遇到同样的问题。

※译：这个情况在GNU宣言中有详细的描述，请参阅：（特别感谢由AKA的chuhaibo翻成中文http://www.aka.citf.net/Magazine/Gnu/manifesto.html）

致命一击终於来临，1983年DEC宣布：为了要集中在PDP-11与VAX生产线，将停止生产PDP-10；ITS没搞头了，因为它无法移植到其他机器上，或说根本没人办的到。而Berkeley Univeristy修改过的UNIX在新型的VAX跑得很顺，是 ITS理想的取代品。有远见的人都看得出，在快速成长的微电脑科技下，Unix一统江湖是迟早的事。

差不多在此时Steven Levy完成《Hackers》这本书，主要的资料来源是Richard M. Stallman (RMS)的故事，他是MIT AI Lab领袖人物，坚决反对实验室的研究成果商业化。

Stallman接著创办了Free Software Foundation，全力投入写出高品质的自由软件。Levy以哀悼的笔调描述他是"the last true hacker"，还好事实证明Levy完全错了。

※译：Richard M. Stallman的相关事迹请参考: http://www.aka.citf.net/Magazine/Gnu/cover.htm

Stallman的宏大计划可说是80年代早期Hacker文化的缩影――在1982年他开始建构一个与UNIX 相容但全新的操作系统，以C来写并完全免费。整个ITS的精神与传统，经由RMS的努力，被整合在一个新的，UNIX与VAX机器上的Hacker文化。微电脑与区域网络的科技，开始对Hacker文化产生影响。Motorola 68000 CPU 加Ethernet是个有力的组合，也有几家公司相继成立生产第一代的工作站。 1982年，一群Berkeley出来的UNIX Hacker成立了Sun Microsystems，他们的算盘打的是：把UNIX架在以68000为CPU的机器，物美价廉又符合多数应用程式的要求。他们的高瞻远嘱为整个工业界树立了新的里程碑。虽然对个人而言，工作站仍太昂贵，不过在公司与学校眼中，工作站真是比迷你电脑便宜太多了。在这些机构里，工作站（几乎是一人一台）很快地取代了老旧庞大的VAX等timesharing机器。

※译：Sun一开始生产的工作站CPU是用Motorola 68000系列，到1989才推出自行研发的以SPARC系列为CPU的SPARC station。

[编辑] 私有Unix时代

　1984年AT&T解散了，UNIX正式成为一个商品。当时的Hacker文化分成两大类，一类集中在Internet与USENET上（主要是跑UNIX的迷你电脑或工作站连上网络），以及另一类PC迷，他们绝大多数没有连上Internet。

※译：台湾在1992年左右连上Internet前，玩家们主要以电话拨接BBS交换资讯，但是有区域性的限制，发展性也大不如USENET。Sun与其他厂商制造的工作站为Hacker们开启了另一个美丽新世界。工作站诉求的是高效能的绘图与网络，1980年代Hacker们致力为工作站撰写软件，不断挑战及突破以求将这些功能发挥到百分之一百零一。 Berkeley发展出一套内建支援ARPANET protocols的UNIX，让UNIX能轻松连上网络，Internet也成长的更加迅速。

除了Berkeley让UNIX网络功能大幅提升外，尝试为工作站开发一套图形界面也不少。最有名的要算MIT开发的Xwindow了。 Xwindow成功的关键在完全公开原始码，展现出Hacker一贯作风，并散播到Internet上。X 成功的干掉其他商业化的图形界面的例子，对数年後UNIX的发展有著深远的启发与影响。少数ITS死忠派仍在顽抗著，到1990年最後一台ITS也永远关机长眠了；那些死忠派在穷途末路下只有悻悻地投向UNIX的怀抱。

UNIX们此时也分裂为BerkeleyUNIX与AT&T两大阵营，也许你看过一些当时的海报，上面画著一台钛翼战机全速飞离一个爆炸中、上面印著AT&T的商标的死星。Berkeley UNIX的拥护者自喻为冷酷无情的公司帝国的反抗军。就销售量来说，AT&TUNIX始终赶不上BSD/Sun，但它赢了标准制订的战争。到1990年，AT&T与BSD版本已难明显区分，因为彼此都有采用对方的新发明。随著90年代的来到，工作站的地位逐渐受到新型廉价的高档PC的威胁，他们主要是用Intel80386系列CPU。第一次Hacker能买一台威力等同於十年前的迷你电脑的机器，上面跑著一个完整的UNIX，且能轻易的连上网络。

沈浸在MS-DOS世界的井底蛙对这些巨变仍一无所知，从早期只有少数人对微电脑有兴趣，到此时玩DOS与Mac的人数已超过所谓的"网络民族"的文化，但他们始终没成什么气候或搞出什么飞机，虽然聊有佳作光芒乍现，却没有稳定发展出统一的文化传统，术语字典，传奇故事与神话般的历史。它们没有真正的网络，只能聚在小型的BBS 站或一些失败的网络如FIDONET。提供上网服务的公司如CompuServe或Genie生意日益兴隆，事实显示non-UNIX的操作系统因为并没有内附如compiler等程式发展工具，很少有source 在网络上流传，也因此无法形成合作开发软件的风气。 Hacker文化的主力，是散布在Internet各地，几乎可说是玩UNIX的文化。他们玩电脑才不在乎什么售後服务之类，他们要的是更好的工具、更多的上网时间、还有一台便宜32-bitPC。

机器有了，可以上网了，但软件去哪找？商业的UNIX贵的要命，一套要好几千大洋($)。90年代早期，开始有公司将AT&T与BSDUNIX移植到PC上出售。成功与否不论，价格并没有降下来，更要紧的是没有附原始码，你根本不能也不准修改它，以符合自己的需要或拿去分享给别人。传统的商业软件并没有给Hacker们真正想要的。

即使是Free Software Foundation (FSF)也没有写出Hacker想要的操作系统，RMS承诺的GNU操作系统――HURD 说了好久了，到1996年都没看到影子（虽然1990年开始，FSF的软件已经可以在所有的UNIX平台执行）。

[编辑] 早期的自由的Unix替代品

在这空窗期中，1992年一位芬兰Helsinki University的学生――Linus Torvalds开始在一台386 PC上发展一个自由软件的UNIX kernel，使用FSF的程式开发工具。

他很快的写好简单的版本，丢到网络上分享给大家，吸引了非常多的Hacker来帮忙一起发展Linux――一个功能完整的UNIX，完全免费且附上全部的原始码。 Linux最大的特色，不是功能上的先进而是全新的软件开发模式。直到Linux 的成功前，人人都认为像操作系统这么复杂的软件，非得要靠一个开发团队密切合作，互相协调与分工才有可能写的出来。商业软件公司与80年代的Free Software Foundation所采用都是这种发展模式。

Linux则迥异於前者。一开始它就是一大群Hacker在网络上一起涂涂抹抹出来的。没有严格品质控制与高层决策发展方针，靠的是每周发表新版供大家下载测试，测试者再把bug与patch贴到网络上改进下一版。一种全新的物竞天择、去芜存菁的快速发展模式。令大夥傻眼的是，东修西改出来的Linux，跑的顺极了。

1993年底，Linux发展趋於成熟稳定，能与商业的UNIX一分高下，渐渐有商业应用软件移植到Linux上。不过小型UNIX厂商也因为Linux的出现而关门大吉――因为再没有人要买他们的东西。幸存者都是靠提供BSD为基础的UNIX 的完整原始码，有Hacker加入发展才能继续生存。

Hacker文化，一次次被人预测即将毁灭，却在商业软件充斥的世界中，披荆斩棘，筚路蓝缕，开创出另一番自己的天地。

[编辑] 网络大爆炸时代

Linux能快速成长的来自令一个事实：Internet大受欢迎，90年代早期ISP如雨後春笋般的冒出来， World Wide Web的出现，使得Internet成长的速度，快到有令人窒息的感觉。

BSD专案在1994正式宣布结束，Hacker们用的主要是免费的UNIX（Linux与一些4.4BSD的衍生版本）。而 Linux CD-ROM销路非常好（好到像卖煎饼般）。近几年来Hacker们主要活跃在Linux与Internet发展上。World Wide Web让Internet成为世界最大的传输媒体，很多80年代与90年代早期的Hacker们现在都在经营ISP。

Internet的盛行，Hacker文化受到重视并发挥其政治影响力。94、95年美国政府打算把一些较安全、难解的编码学加以监控，不容许外流与使用。这个称为Clipper proposal的专案引起了Hacker们的群起反对与强烈抗议而半途夭折。96年Hacker又发起了另一项抗议运动对付那取名不当的 "Communications Decency Act"，誓言维护 Internet上的言论自由。

电脑与Internet在21世纪将是大家不可或缺的生活用品，现代孩子在使用Internet科技迟早会接触到Hacker文化。它的故事传奇与哲学，将吸引更多人投入。未来对Hacker们是充满光明的。

第二章大教堂与市集

　　　　　　　　　　　　◇◇　原文修订历史　◇◇

　　2000-09-11 1.57版，esr，增加"要多少个眼球来驯服复杂度"小节　　2000-08-28 1.52版，esr，MATLAB和EMACS的相似性　　2000-08-24 1.51版，esr，第一个DocBook格式版本，更新了一些时间数据　　2000-05-05 1.49版，esr，增加了关于期限和功能的注释"HBS" 　　1999-08-31 1.51版，esr，O'Reilly出版社发行的第一版（译注：原文版本号有误）　　1999-08-08 1.45版，esr，增加了SNAFU法则注释，市集风格的原始例子，和市集　　　　　　　　　　　　　模式的原创性讨论　　1999-07-29 1.44版，esr，增加"关于管理和马其诺防线"小节，一些关于市集模　　　　　　　　　　　　　式在搜索设计空间的优越性讨论，完善了后记　　1998-11-20 1.40版，esr，根据"万圣节文档"，增加了对Brooks回顾的一个修正　　1998-07-28 1.39版，esr，作为对Richard Stallman的一个有力观点的回应，删除　　　　　　　　　　　　　了Paul Eggert关于GPL图和市集的讨论　　1998-02-10 1.31版，esr，增加"后记：网景欢迎市集"小节　　1998-02-09 1.29版，esr，改称"自由软件"为"开源代码" 　　1997-11-18 1.27版，esr，增加了Perl大会上的逸事　　1997-07-07 1.20版，esr，增加参考文献　　1997-05-21 1.16版，esr，Linux Kongress会议官方版本

　　　　　　　　　　　　　　　◇◇　摘　要　◇◇

　　　　Linux的发展史促生了一些关于软件工程的惊人理论。在开源项目fetchmail 　　中，我有意应用了这些理论并取得了很大成功。以fetchmail的成功为例，我在本　　文中系统地总结和剖析了这些理论。这里涉及到两种截然不同的开发模式：大多数　　商业项目使用的"大教堂"模式和Linux世界的"市集"模式。我们将看到，这两　　种模式源于对软件调试工作本质的两种彼此对立的假设。我接着从Linux的经验出　　发，对"只要眼球足够多，所有臭虫都好捉"的定理作了论证；给出了它与由自私　　个体组成的自纠错系统的相似之处。最后，我探讨了这个发现对未来软件业的启示。

　　　　　　　　　　　　　　　◇◇　目　录　◇◇

　　 1. 大教堂和市集　　 2. 邮件必须得通过　　 3. 用户的重要性　　 4. 早发布、常发布　　 5. 要多少个眼球来驯服复杂度　　 6. 玫瑰何时不再是玫瑰　　 7. Popclient变成了Fetchmail 　　 8. Fetchmail长大了　　 9. Fetchmail带来的其它几条经验　　10. 市集风格的必要前提　　11. 开源软件的社会语境　　12. 关于管理和马其诺防线　　13. 后记：网景欢迎市集　　14. 参考文献　　15. 致谢

[编辑] 大教堂和市集

Linux是颠覆性的。就是五年以前（1991），谁能想得到散布在全球各地的几千名开发者，仅靠细细的互联网连接，能够在业余时间魔术般地铸成一个世界级的操作系统呢？

反正我没想到。在1993年初Linux引起我的注意的时候，我已经在Unix和开放源代码开发领域做了十年了。我是80年代中期最早的GNU开发者之一，已经在网上发布了相当一部分软件，正在开发或协助开发好几个直到今天都在广泛使用的软件（nethack，Emacs的VC和GUD模式，xlife和其它）。我觉得我很懂行了。

Linux颠覆了许多我以为我懂的东西。当时，我已经宣扬小而专的工具、快速建模和演进式开发等Unix理念多年了。但我也相信项目到了一定复杂程度后就需要更集中地按事先计划管理。我相信最重要的软件（操作系统和Emacs之类的大型工具）需要像大教堂一样来搭建：遗世独立的圣人巨匠们牵尺引斤琢之磨之；时候不到beta版不出。

Linus Torvalds的开发风格（尽早尽多的发布，委托所有可以委托的事，对所有的改动和融合开放）令人惊奇地降临了。这里没有建造大教堂的安静和虔诚；Linux社区更像一个充满不同议程和方法的嘈杂的市集（Linux归档站点就是绝好的例子，任何人的作品都接收）。然而，一个统一稳定的系统就象奇迹一般从这个市集中产生了。

这种设计风格不但可行，而且工作得很好，对我无疑是一个巨大的震撼。在我的摸索过程中，我不仅效力与个别项目，而且努力去理解为什么Linux世界没有在混乱中分崩离析，而是以大教堂建造者们难以想像的速度茁壮成长。

到1996年中，我想我开始理解了。我有了一个测试我理论的完美机会，一个我可以有意识地用市集风格来运行的开源项目。我这样做了，结果非常成功。

这里讲述的就是这个项目的故事。我将借它来提出一些开源软件有效开发的精髓。它们并非全部源自Linux世界，但我们会看到它们如何在Linux世界中得到印证。如果我是正确的话，它们会帮助您准确理解是什么使Linux社区成为优秀软件的源泉――或许，它们还会帮助您变得更加高效。

[编辑] 邮件必须得通过

从1993年以来，我负责宾州西切斯特一家提供免费网络服务的小公司CCIL的技术工作。我协同创建了CCIL，并写了我们独家的多用户论坛软件――您可以用telnet连接locke.ccil.org来试一下。今天它在三十条线上支持近三千名用户。这份工作允许我通过CCIL的56K线路每天二十四小时上网――其实，这份工作事实上要求这一点！

那时，我已经习惯使用即时的互联网邮件。我发现不时地要telnet登录上公司服务器"locke"检查邮件很烦人。我想要的是把我的邮件传送到我家里的个人机器"snark"上，这样我可以在邮件到达的时候得到通知，并使用我自己的软件来处理它。

这里互联网的默认邮件输送协议SMTP不适用了。SMTP是为全时在线的机器设计的，而我的个人机器并不总在网上，也没有一个固定的IP地址。我需要一个程序在我拨号上网期间连到服务器上，把要下到本地的邮件取回来。我知道有这种工具存在，且多数使用一个简单的叫做POP的协议。现在常用的客户端邮件软件都支持POP，但那个时候，我的邮件阅读器不支持它。

我需要一个POP3的客户端软件，所以我就跑到网上找了一个。事实上，我找到了三四个。其中的一个我用了一段时间，但它少了一个看起来很明显的功能：修改到达邮件的来信地址以便正确回信。

问题是这样的：假设"locke"上一个叫"joe"的人给我发了信。如果我把信取到"snark"上，然后试图回复，我的邮件程序会高高兴兴地努力把回信发送给"snark"上一个并不存在的"joe"。通过手工修正邮件的回信地址很快就变成了一件很痛苦的事。

显然这该是电脑替我做的事。但是现有的POP客户端软件没有一个会做！这给我们带来了第一个教训：

每一个好软件的起因都是挠到了开发者本人的痒处。

这或许应该是很显然的（一直有箴言道"需要是发明之母"），但软件开发人员太过经常地在那些他们既不需要也不喜欢的程序上消磨时日、换取工资。但在Linux世界不是这样子的――这或许解释了为什么Linux社区中产生的软件平均质量这么高。

那么，我立马儿投入到了一轮疯狂的编程中来写一个和现有POP3客户端竞争的软件了吗？不是！相反，我仔细检查了我拿到手的那些POP程序，自问"哪一个离我要的最接近？"因为：

好的程序员知道写什么。伟大的程序员知道改写（和重复使用）什么。

虽然我不自封伟大，但我努力模仿伟大的程序员。伟大者的一个重要特点是建设性的懒惰。他们知道你需要的是结果而不是过程，而且从一个好的部分方案开始总比从零开始要容易得多。

以Linus Torvalds为例，他实际上没有试图从零开始写Linux。相反，他的代码和主意开始于PC机一个小小的类UNIX系统MINIX。最终所有Minix的代码都被拿掉或重写了――但在起步的阶段，Minix提供了那个最后成为Linux的新生儿成长的脚手架。

遵循同样的精神，我出发去寻找一个已有的、写得过得去的POP程序来作为开发的基础。

UNIX世界里的源代码共享传统一直对代码再用很友好（这也是为什么GNU项目尽管对

UNIX很有成见，还是选择了UNIX作为其基本操作系统）。Linux世界几乎把这种传统发挥到了技术上的极限；有上万亿字节的开放代码可供获取。所以花点时间在Linux世界里找个别人"差不多够好"的程序，比其它任何地方都更有可能找到。

我就找到了。加上我以前找到的，我的第二次搜索有了九个候选对象：fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail和upop。我第一个选用的是欧松宏（音，Seung-Hong Oh）的"fetchpop"。我把我改写邮件头的功能加了进去，并作了其它一些改进。松宏后来把这些加进了他的1.9版本。

然而几个星期以后，当我碰到了Carl Harris的"popclient"代码时，我发现我遇到了一个问题。尽管fetchpop有一些很好的新主意（例如它的后台daemon模式），它只能处理POP3协议，而且程序代码写得比较业余（松宏当时是个聪明但是缺少经验的程序员，这两个特点都有显示）。Carl的代码好一些，很专业和稳固，但他的程序缺几个重要的而且难实现的fetchpop里的功能（包括我自己写的那些）。

继续用fetchpop还是转换到popclient上来？如果转换的话，我得扔掉我已经写好的那些代码来换取一个好一些的开发基础。

一个实用的转换动机是对多种协议的支持。POP3是服务器端POP协议中最常用的，但不是唯一的。Fetchpop和那一个竞争对手都不支持POP2、RPOP或APOP，而且为了好玩，我那时已经有了添加IMAP（最新设计的、最强大的POP协议）的模糊想法。

但我还有一个更理论上的原因来认为转换也是个好主意。这是我远在Linux之前就学到的。

"计划扔掉一个；无论如何你都会扔掉一个的。"（Fred Brooks《人月神话》第11章）

或者换句话说，直到你第一次实现一个方案之前，你常常并没有真正理解你的问题。第二次呢，或许你已经学到了如何把它做对。所以，要想把事做对，你得准备至少重来一次［注：JB］。

[注：JB］在《编程珠玑（Programming Pearls）》中，知名的计算机科学大师JonBentley对Brooks的上述文字有如下评注："如果你计划要扔掉一个，你也会扔掉第二个"。他说的完全正确，Brooks和Bently不仅仅指出第一次尝试往往会错，而且指出用新的方法重新开始往往比挽救一堆乱代码来得快捷。

好吧（我对自己说），对fetchpop做的修改算我的第一次吧。于是我转换了。

在1996年6月25日我给Carl Harris发送了我写的第一批popclient补丁后，我发现他一段时间之前就基本上对这个项目失掉兴趣了。项目的源代码有些陈旧了，小臭虫们流连不去。我有很多要修改的东西；我们很快同意：理所当然，我该把整个项目接手过来。

在我没有觉察的时候，这个项目升级了。我不再是试图给一个现有的POP客户端程序做些小补丁。我开始负责维护整个程序，而且我知道我脑子里冒着的新主意可能会导致一些主要的变动。

在一个鼓励代码共享的软件文化中，这是一个项目进化的自然方式。我在实践下面这个原理：

如果你有正确的态度，有意思的问题会自动找上门。

Carl Harris的态度甚至更重要。他懂得：

当你对一个项目失去兴趣时，你最后的职责是把它交给一个称职的继承者。

尽管Carl和我从来没有讨论过这一点，我们知道我们的共同目标是找出问题的一个最好解决方案。我们唯一的问题是我能否证明我的能力。一旦我作到了，他优雅而迅速地作了交接。我希望当这一天轮到我的时候，我也能做得同样出色。

[编辑] 用户的重要性

就这样，我继承了popclient。同样重要的是，我继承了popclient的用户群。拥有用户是件美好的事情。他们的存在不仅证实了你的工作正在满足一种需求，而且证实的你做的不错。通过适当的培养，他们还可能成为你的开发伙伴。

很多用户也是黑客，这是UNIX传统中的另一个强项，而Linux把它发展到了快乐极致。因为可以得到源代码，他们可以是有效的黑客。这一点对缩短调试时间会非常有帮助。给上一点点鼓励，他们会帮助诊断问题，提出建议和补丁，并以你一个人不可企及的速度帮助改进代码。

把用户看作合作者是通往快速改进代码和有效调试的最佳通道。

这一点所蕴藏的能量很容易被低估。事实上，直到Linus Torvalds给我们演示之前，开源世界里几乎所有人都严重低估了它如何随用户数目而增长潜能，如何随系统的复杂度增大而更显威力。

事实上，我认为Linus最聪明、最有影响的手笔不是Linux内核本身，而是发明了Linux的开发模式。有一次当我当面向他表达这个观点时，他微笑了，安静地重复了他经常说的一句话："我基本上是一个很懒惰的人，喜欢在其实是别人做的事情上领取荣誉"。象狐狸一样懒惰，或者象Robert Heinlein［译注：著名科幻作家］笔下的一个著名角色：太懒惰而不会失败。

回头来看，Linux方法和成功的一个先例是GNU Emacs的Lisp库和Lisp代码档案。与Emacs C核心和大多数的其它GNU工具的大教堂建造风格相反，Lisp代码群的进化是活跃的、多由用户驱动的。点子和原型经常要重写三四次才能达到一个稳定的最终形式。象Linux那种通过互联网的松散协作也很频繁。

确实，我自己在fetchmail之前最成功的一次编程可能是Emacs的VC（版本控制）模式。那是类似Linux一样与其他三个合作者仅通过电子邮件交流的一次合作。三个人中我至今只见过一个（Richard Stallman，Emacs的作者、自由软件基金会的创始人）。VC是Emacs中SCCS，RCS和后来CVS模式的前台；Emacs借此提供"单击式"的版本控制操作。它是由一个别人写的小小的、粗糙的sccsl.el模式演进而来。VC开发的成功也是因为不象Emacs本身，Emacs Lisp代码可以快速地通过多轮"发行／测试／改进"的循环。

Emacs的故事不是唯一的。其它软件也有这种双层的构架和双层的用户群：核心用大教堂模式；工具箱用市集模式。其中的一个是MATLAB，一个用于数据分析和可视化的商业工具。MATLAB和其它类似架构产品的用户一致认为，产品的开放部分――有一个巨大多样的用户群可以对其推敲的地方――才是动力、热情和创新的所在。

[编辑] 早发布、常发布

早发布和频繁发布是Linux开发模式中关键的一个部分。以前多数开发者，包括我，都认为这对复杂项目来说是个坏办法，因为早期版本几乎是问题版本的同义词，而你不想这么早就消耗完用户的耐心。

这个观点也促使人们普遍采取建造大教堂式的开发。如果首要的目标是尽量让用户少遇到臭虫，那么你应该六个月甚至更久才发布一个版本，在两次发布之间象狗一样拼命去调试。Emacs的C核心就是这样开发的。Lisp库实际上不是――因为在自由软件基金会所辖之外还有其它活跃的Lisp存档，提供独立于Emacs发布周期的新版本和测试版本。

那时最重要的Lisp库――俄亥俄州立大学Emacs Lisp档案――已经超前具有了今天Linux大型档案的管理精髓和许多功能。但是我们中很少有人深考过我们在做什么，以及俄亥俄档案的存在本身说明了自由软件基金会大教堂开发模式的哪些问题。在1992前后，我曾努力要把一大批俄亥俄代码合并到Emacs Lisp的官方库，但遇上政治性的麻烦，结果非常不成功。

一年以后，Linux影响逐渐扩大。显然Linux的开发者拥有一些不同的但是远远更为健康的东西。Linus的开放性开发政策正与建造大教堂的方式相反。Linux的互联网档案枝蔓繁衍，多个发行版在坊间流传。而所有这些都是由Linux内核前所未闻的发布频率所驱动的。

Linus在以最有效的合作者方式来对待他的用户：

早发布、常发布，听取用户的意见。

快速发布、采纳大量用户反馈，并不怎么算Linus的创新（Unix世界历来就有这种传统）。他的创新之处是把这个办法升级到了与所开发系统复杂性相匹配的规模和强度。在早期（1991年左右），我们不是没听说过他一天发布不止一个新的内核版本！因为他比任何人都努力地培养合作开发群体、促进网上合作。他的办法生效了。

但它是怎样生效的呢？难道只有Linus Torvalds的独特天才才能实现？

我想不是的。Linus当然是个骨灰级黑客。有几个人能从零开始开发出一个企业级操作系统的内核？但是Linux并不代表任何概念上的重大突破。Linus不是（至少还没有成为）象Richard Stallman或James Gosling（Java之父）那种设计和创新的天才。在我看来，Linus更象是工程和开发的天才，有着避开臭虫和死胡同的第六感官和找到从一点到另一点最快捷径的本领。确实，整个Linux内核透露着这种特质，反映了Linus本质上保守和一切从简的设计方法。

如果快速发布和淋漓尽致的利用互联网媒介不是偶然，而是Linus对最快捷径的天才工程洞察力的有机部分，那么他试图最大化的是什么？他试图从这个机制释放出一种什么样的力量？

这样一问，答案一目了然。Linus在不断地激励和奖掖他的黑客用户们――激励来自于在参与中得到的自我实现，奖掖来自于看到他们自己工作的持续（甚至每天）进步。

Linus直接瞄准了调试和开发力量的最大化，即使牺牲程序的稳定性或因某个修正不了的严重问题导致丧失用户也在所不惜。似乎Linus相信：

足够多beta测试者和合作开发者会让任何问题快速显形并很快被解决。

或者通俗一点，"只要眼球足够多，所有臭虫都好捉"。我称之为"Linus法则"。

对上述法则，我最早的表述是每个问题"都会有某个人能解决"。Linus有异议：理解和解决问题的人不一定甚至一般不是第一个发现问题的人。"一个人发现问题"，他说，"另一个人把它搞明白，而且我会作证说发现问题这一步更困难一些。"这是个重要的纠正；在下一节具体研究实际调试时我们会看到为什么。但是关键一点是，发现和解决问题这两个步骤一般都会很快完成。

我认为Linus法则中包含有大教堂模式和市集模式的关键区别。在大教堂式的编程观念中，臭虫和开发上的问题是复杂、困难和深奥的，要几个人全心全力几个月的投入才有把握已经把它们清理干净的，所以需要很长的发布周期；一旦等候已久的版本不够完美，失望就在所难免。

恰恰相反，在市集式的观念中，你预设臭虫都是简单的问题――至少在上千个共同开发者热心地琢磨每一个新版本的情况下，它们会很快就变简单了。相应地，你频繁发布来得到更多的纠错。作为一个附加效应，偶尔出个大勺子的后果也没有那么严重了。

这就是了。这也就够了。如果"Linus法则"是错误的，那么象Linux内核这样复杂的系统，经过了那么多人的敲打，应该在某一时刻已经在不曾预见的恶性互动和深藏不露的问题的重压下崩溃了。如果它是正确的，它足以解释Linux相对较少的问题，和数月甚至数年以上的持续运行时间。

或许这不该是如此一个意外。社会学家们多年前就发现了一大群同样内行（或同样白痴）观察者的平均预测要比其中随机选择一个人的预测可靠得多。他们称之为"神庙效应"。看来Linus显示了这一点甚至适用于调试一个操作系统――甚至是内核级的复杂程度，"神庙效应"也可以简化开发。

Linux情形中对"神庙效应"有帮助的一点是，任何一个项目的参与者都是自我选择的。一个早期评论指出，对Linux的贡献不是来自于一个随机的人群；他们都有足够的兴趣来使用这些软件、研究其机理、并试图解决所遇到的问题，而且真正给出显然可行的解决办法。经过了这些筛选的人一般都会有可以贡献的真才实料。

Linus法则也可以表述为"调试是可并行的"。尽管调试者们需要一个人来通讯协调，调试者们之间并不需要多少的协调。添加开发人员所带来的平方级复杂度和管理成本在这里不适用。

理论上因为调试者重复做功而导致的效率损失在Linux世界中似乎从来都不是问题。"早发布、常发布"策略的一个后果就是通过快速公步反馈修补来把重复做功最小化。

Fred Brooks（《人月神话》作者）甚至作过一个相关的非正式评论："一个广泛使用的程序的维护费用一般是它开发成本的40％以上。令人惊奇的是，这个费用受用户数强烈影响。用户越多，发现的问题也越多。"

用户越多、发现问题越多是因为检验程序的角度也越多。当用户同时是合作开发者时，这个效应放大了。在检测问题的过程中，每个人都有一些不同的观察方法和分析工具，从不同角度逼近同一问题。"神庙效应"似乎正是因为这种多样性而有效。在调试程序这个特定的环境下，这种多样性也利于减少重复做功。

所以从开发者的角度来讲，增加更多的beta测试者不见得会减少当前最大问题的复杂程度，但会增加某个人的工具箱正好适用于该问题的几率――这样对这个人来说，这个问题其实很简单。

Linus在此之外还留有一招。如果可能存在大的"臭虫"，Linux内核的版本编号允许潜在用户选用老一点的"稳定"版本，或冒"臭虫"之险以求"实验"版本的最新功能。多数Linux黑客还没有系统地模仿这一招；但他们或许应该去模仿。给出这个选择使得两种版本都更有吸引力。［注：HBS］

[注：HBS］Linux内核的稳定版和实验版之分除了分担风险目的之外，还可针对解决发布期限问题。事实表明，当开发人员同时面临死板的功能列表和发布期限时，软件的制作质量明显降低。哈�商学院的Marco Iansiti和Alan MacCormack指出放松其中任何一个限制均可产生可行的计划，在此表示感谢。

稳定版内核采用的是放松功能列表，但限制发布期限的策略。稳定版内核的维护者Alan Cox定期发布新的稳定版，但是不承诺何时必须解决哪个问题或加入哪个开发版新功能。

实验版内核刚好相反，采用的是放松发布期限，但固定功能列表（所谓"做完了再叫醒我"）的策略。De Marco和Lister引用的研究结果表明该策略不仅导致高质量的软件，并且平均比"保守"或"激进"开发计划都可带来更短的发布时间。

2000年初我开始怀疑我在本文先前的版本中低估了这种"做完了再叫醒我"的策略对提高开源项目生产力和质量的重要性。1999年GNOME项目为赶1.0版导致的负面影响表明，即便是开源项目，为赶进度而发布尚未成熟的代码也会严重影响到软件质量。

很有可能我们会发现，开发过程的透明性，连同"做完了再叫醒我"以及开发者的自我选择，可能是推动开源项目质量的三个同等重要的作用力。

[编辑] 要多少个眼球来驯服复杂度

在整体上观察市集风格很大地加速了调试和代码进化是一回事，在微观、日常的开发者和测试者行为上来准确理解怎样和为什么是另一回事。在这一节（写在原始文章的三年以后，采纳了读了本文、又对照了自身的很多开发者们的意见），我们来实打实地看一下其背后真正的机制。不喜欢技术的读者可以安全地跳到下一节。

理解这个问题的一个关键在于认识到以下重要的事实，那就是对源码知之甚少的用户所递交的问题报告往往并没有多少用处。这些用户一般只会报告表面症状；他们往往忽略了软件的运行环境，所以这些提交的报告不但会漏掉关键的背景数据，而且极少包括重现问题的步骤。

这里更深层的问题是测试者和开发者对程序的不同理解。测试者从外往里看，而开发者从里往外看。在封闭源码的开发模式中，他们都被卡在各自的这种角色里了，往往各说各的话，同时又觉得和对方交流非常困难。

开源开发打破了这种束缚，测试者和开发者基于源代码很容易建立起统一的模型，就之进行有效地交流。仅仅描述外观症状的问题报告和直接联系到基于源码抽象模型的报告对开发者的帮助是截然不同的。

如果能够在代码层给出一个对出错条件哪怕是不完整的提示性的描述，大多数臭虫在大多数情况下都是容易捉到的。当某个beta测试员指出"在某某行有一个边界问题"，或者只是"在某某条件下，这个变量溢出"，对这些代码的一个快速扫描常常足以锁定出错的准确模式并搞定一个修补办法。

所以，如果beta测试者和核心开发者都对源代码心里有数，双方的交流和合作会得到大大增强。这意味着核心开发人员的时间会节约下来，即便合作者人数众多。

开源方法另一个节约开发者时间之处来自于开源项目的典型通讯结构。我在上面用到了"核心开发者"一词；这反映了项目核心（一般很小；一个核心开发者很平常，一到三个很典型）和beta测试人员、补丁提供人员组成的项目外沿（经常上百人）的区别。

传统软件开发结构需要解决的根本问题是Brooks法则："在延期的项目添加程序员只会延期更久"。普遍来讲，Brooks法则认为，随着开发人员数目的增加，项目的复杂程度和通讯成本按平方增加，而业绩仅以直线增加。

经验表明，臭虫大多集中在不同人写的代码的界面上；而一个项目的通讯协调成本一般按照人与人之间的交流渠道数量增加。这是Brooks法则的基础。也就是，问题随开发者之间通讯路径数目的增加而增加，而后者与开发者数目是平方关系（更准确地说，遵从公式N*(N-1)/2，这里N是开发者的数目）。

Brooks法则的分析（以及它引起的开发团体中对人数过多的恐惧）基于一个潜在的前提：项目的通讯结构必须是一个完整的图，每个人都与其他所有人交接。但是在开源项目中，外沿开发者做的实际上是平行分离的子项目，彼此交接甚少；代码变动和臭虫报告都流经项目的核心，只有在小小的核心团体中，才需要完整的Brooks通讯开销。

由于一个错误常常可以产生多个不同的症状，在用户使用习惯和环境细节不同时有不同的表现，这使得源代码层次上的问题报告往往非常有效。这类错误一般正是那些复杂和微妙的臭虫――那些最难重现并难以用静态分析捕捉的，并在软件中制造长期问题的祸根（比如动态内存管理错误或随机的中断窗口错误）。

一个测试者提供的对此类错误尝试性的源码级诊断（例如："看起来第1250行的信号处理部分存在一个窗口"或者"你在哪里把缓冲区清零了？"）可能会成为对这些部分代码熟视无睹的开发者同时解决七八个不同症状的关键线索。此时，往往无法判定症状和臭虫的对应关系，但是多发布使得我们无须去一一了解。其他用户很快就会发现问题是否不再出现。很多情况下，源码级的问题报告使得症状无须明确被哪个补丁解决而自然消失。

复杂的多症状错误也常常会有从表面症状联系到内在臭虫的多个跟踪途径。一个特定的开发者或测试者所能追寻的跟踪途径可能取决于这个人的具体环境细节，也很可能随着时间的改变发生不便预测的变化。实际上，每一个开发者和测试者在寻找一个症状的病原时都是在检查该程序的状态空间的一个"半随机"集合。臭虫越微妙越复杂，此人技能和所追寻空间相关的保证就越小。

对于简单的容易重现的臭虫，那么，重音要放在"半"上面而不是"随机"上面；此时，调试技能和对代码、框架的熟悉程度是最重要的。但对于复杂的臭虫，重音就要放在"随机"上面。在这种情况下许多人同时追踪要比少数人串行追踪有效的多――即使这少数人的技能水平高的多。

要是从不同的表面症状挖掘到臭虫的跟踪途径难度不一、难以从观察症状来预测的话，并发追踪的效果就会非常之明显了。一个持续追踪这些路径的开发者在开始可能会遇到一个简单的路径，也同样可能会遇到一个复杂的路径。另一方面，试想有许多人在快速发布下平行地来检查这些追踪路径，那么其中某人很可能会碰上最容易的路径，在短的多的时间里解决这个问题。维护项目的人会看到这个，发行一个新版本；其他在更困难的路径上追踪同一个臭虫的人们就可以在花费太多时间之前停下来。［注：RJ］

注：RJ］给我提供不同难度跟踪途径的读者推测此类多表症问题跟踪的难易程度呈"指数"分布（我把其理解为高斯或泊松分布，且同意他的看法）。如果有实验数据可以给出类似的分布曲线，将会非常有价值。如果此曲线与等概率分布的平行线差别甚远，那么即使在一个开发者的情况下，也应该模仿市集模式，采取限定在一个表症上跟踪时间的策略。坚持有时不一定是件好事……

[编辑] 玫瑰何时不再是玫瑰

研究了Linus的作法并形成了一个它何以成功的理论后，我决定在我的新项目（当然没有Linux那么复杂和宏伟）里有意识地测试这个理论。

但我做的第一件事是把popclient重组和简化了许多。Carl Harris的代码实现得很好，但是有一种在C程序员中常见的多余的复杂。他把代码放在了中心位置，数据结构作为辅助。结果代码很漂亮，但是数据结构设计得潦草甚至丑陋（至少按我这个LISP老手的标准来看）。

然而，除了改进代码和数据结构设计以外，我的重写还有另一层目的，那就是把它进化成一个我完全理解的东西。要是你不完全理解一个程序，维护起来可不是好玩的。

于是在最初的一个月左右，我只是在按照Carl的章程做事。我作的第一个重要改变是添加了IMAP支持。我实现这点的方法是：把协议的具体部分做成插件形式，用一个通用的驱动来根据不同协议调用不同插件的方法表（分别针对POP2、POP3和IMAP）。这些变动都示范了下面这个程序员们应该记住的通用原则（尤其像C这种本身不支持动态数据类型的语言）：

[编辑] 聪明的数据结构和愚蠢的代码要比反过来好的多。

Brooks的第九章："给我看你的流程图而隐藏你的数据结构，我会继续糊涂着。给我看你的数据结构，我一般就不需要你的流程图了；它们将显而易见"。经过三十年的文化和术语的变迁，这个观点仍然正确。

这时（1996年9月初，大约开工后六个星期），我开始想这个程序大概该换个名字了――它毕竟不再仅仅是一个POP客户端软件。但是我在犹豫，因为在设计上还没有什么真正的新东西。我的popclient版本还需要发展出它自己的特征。

当popclient学会了怎样把取到的邮件再通过本机SMTP端口转发的时候，这一点迅速改变了。我过一会儿再细谈这个。但是首先：我说过我决定用这个项目来测试我关于Linus的成功理论。（您也会问）我是怎样做的呢？在以下方面：

我早发布和常发布（几乎从未低于十天一次；高强度开发的时候，一天一次）。
我把每个和我交流有关fetchmail的人加进了我的beta测试名单。
每当我发布一个版本，我就给beta名单发送一个内容丰富的通告，鼓励大家参与。
我听取beta测试者的意见，在设计上征求他们的看法，当他们送交补丁和反馈时给予鼓励。

这些简单的办法立杆见影。从项目一开始，我就收到很多那种多数开发者梦寐以求的高质量的臭虫报告，经常还附带了好的补丁。我收到过深思熟虑的评论、粉丝的邮件，还有高明的功能性建议。这说明：

将你的beta测试者作为"最有价值资源"来对待，他们就会成为"最有价值资源"。

Fetchmail庞大的beta测试名单（fetchmail-friends）成为衡量其成功的一个有意义的指标。在我最近一次修订这篇文章的时候（2000年11月），它有287名成员，而且每个星期在增加两三名。

实际上，当我在1997年5月下旬改写的时候，我发现这个名单由于一个有意思的原因，从它近300的巅峰开始流失成员了。一些人要求我把他们从名单中去掉，因为fetchmail对他们来讲近乎完美，他们再也不需要阅读这个邮件列表了！或许这是一个成熟市集风格项目正常生命周期的一部分。

[编辑] Popclient变成了Fetchmail

当Harry Hochheiser把他转发邮件到客户机SMTP端口的草稿程序发给我的时候，这个项目的真正转折点来临了。我几乎马上意识到，这个功能会让其它所有的邮件递送模式成为历史。

许多星期以来，我一直在按照原来的架构改进fetchmail，但总有些不舒服的感觉。我感觉目前的接口设计还可以用，但是不够干净漂亮，而且到处是微不足道的选项。把收取的邮件直接输出到一个邮箱文件或转到标准输出里的选项尤其让我心烦，但我想不出为什么。

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

受到SMTP转发的启发，我终于看清了。Popclient在试图做太多的事情。它被设计成了既是一个邮件传输工具（MTA），又是一个本地投递工具（MDA）。有了SMTP转发功能，它就可以摆脱MDA的负荷，像sendmail那样专心只作MTA，并把邮件的本地投递留给其它程序来完成。

几乎每一个支持TCP/IP的平台上都预留了25号端口，为什么还要去折腾MDA的复杂配置或邮箱的"锁定－添加"呢？更有甚者，通过SMTP转发意味着收到的邮件看起来几乎和正常的SMTP邮件一样。这正是我们想做到的。

（返回到高一层次上……）

即使读者没看懂上面的技术细节，这里也有几条重要的经验可以学习。首先，这个SMTP转发的点子是我有意模仿Linus方法的最大收获。一个用户给了我这个好点子――我需要做的仅仅是理解它的含义。

自己拥有好主意是好事，认识到来自用户的好主意也是好事。有时候后者会更好。

很有意思的是，如果你谦虚地坦白别人的贡献很多，你很快就会发现外面的世界不会这么看。他们会认为是你创造了这一切，只不过是你太谦虚而已。Linus就是最生动的例子。

（当我在1997年的第一次Perl大会上发言时，黑客大亨Larry Wall正坐在前排上。当我讲到上面的那句话时，他以激动的口吻喊了起来，"说出来，说出来，哥们！"全场都笑了，因为他们知道这一点对Perl的发明者［译注：即Larry Wall］也不例外。）

在我发扬这种精神把项目运行了几个星期以后，我开始得到类似的赞扬――不仅来自我的用户，而且来自于其他有所耳闻的人们。我把其中一些邮件收藏了起来；要是什么时候我开始疑惑我生命的意义时，我就拿出来再看看 :-)。

但是有两条基本的、非政治性的经验对各种设计都适用。

最有突破和创新的方案常常来自于意识到你把问题的模型弄错了。

我之前想继续把popclient做成一个支持五花八门的本地递送模式的MTA/MDA时，就是试图在解决错误的问题。Fetchmail应该重新被设计为一个纯粹的MTA，作为正常SMTP邮件传输路径的一部分。

当你在开发中碰到死胡同时――当你绞尽脑汁要超越下一个补丁的时候――一般来讲你这时该问的不是你的答案对不对，而是你的问题对不对。或许你的问题需要重新定义。

嗯……我重新定义了我的问题。显然，正确的路子是

加入SMTP转发支持，
把它设置为默认模式，
最终把其它的传递模式都去掉，尤其是传递到文件和标准输出这两种模式。

这第三步让我犹豫了一段时间，担心会影响那些依赖于此类模式的popclient老用户。理论上，他们可以马上用.forward文件或其它非sendmail方式的类似功能来获得相同的效果。但在实践中，这种转换可能会让人头大。

但事实证明，做完这三步后好处非常明显。驱动代码中毛病最多的地方消失了。配置选项也大大简化――不再需要围着系统MDA和用户信箱打转，也不再需要担心背后的操作系统是否支持文件锁定。

而且，唯一可能丢失邮件的情形不见了。以前，如果你指定递送到文件而磁盘满了的话，你的邮件就丢了，而这在SMTP转发中不会发生，因为除非邮件成功传送或至少缓存了，SMTP的聆听端不会给以确认。

同时，性能也提高了（尽管不是你运行一次就能感觉到的）。改变后另外一个不小的好处是说明手册简化了许多。

后来，我为了对付一些涉及到动态SLIP（Serial Line Internet Protocol，串行线互联网协议）的晦涩情形，不得不把递送到用户指定MDA的功能加回来，但做起来简单多了。

说明了什么道理？在不损失效率的情况下，不要犹豫把多余的功能扔掉。Antoine deSaint-Exupéry［译注：著名法国作家，著有儿童故事《小王子》等］（他不在写作经典儿童图书的时候是个飞行员和飞机设计师）曾说过：

"设计达到完美的时候，不是增加得不能再增加了、而是减少得不能再减少了"。

代码变得既优良又简单的时候，标志着它上正轨了。在这个过程中，fetchmail有了它自己的设计特色，脱离了上一代的popclient。

到了该换名字的时候了。新的设计和老的popclient相比，更像是sendmail的对偶；二者都是MTA，但sendmail是往外投递，新的popclient是接过来再投递。所以在动工两个月后，我把它重命名为fetchmail。

在这个SMTP转发功能如何进入fetchmail的故事里，有一个更普遍的经验。那就是不仅调试是可并行的；开发和（在可能令人吃惊的程度上）搜索设计空间也是。当采用快速短周期的开发模式时，开发和添加新功能在某种意义上就成为调试改错的一个特例――改正软件原始设计中的"功能不足错误"。

即使在高一层次的设计上，有许多共同开发者在你产品的设计空间附近随机行走将会很有价值。想象一下：一滩水是怎样发现下水口的，或者更恰当一点，蚂蚁怎样发现食物的？本质上是分散、搜索，并通过一个可扩展的通讯机制来协调。这一点很管用，就像Herry和我一样，你们随行中的一个很可能会发现有一个宝藏就在附近，你只不过太专注了一点而没有看到。

[编辑] 第二章，大教堂与市集（续）

[编辑] Fetchmail长大了

现在我有了一个整洁新颖的设计；我知道代码工作良好因为我每天使用；beta测试名单繁荣热闹。我慢慢明白了我不再是在做一个可能只对几个人有用的琐碎的个人编程――我在主持一个所有使用SLIP/PPP邮件接口的Unix用户都需要的程序。

带有SMTP转发功能的fetchmail在竞争对手面前表现强劲，并很可能成为那种在它的功能领域里鹤立鸡群的经典程序，那种让对手们不仅被放弃而且几乎被遗忘了的"领域杀手"。

我觉得这种结果不是你想达到就能达到的。你需要某种超级的设计构想，自然而然地、甚至命中注定地把你推到那里，而找到这种构想前提无非就是要有很多想法可以去尝试――或者有工程眼光把其他人的点子发挥到其原作者根本想象不到的地步。

Andy Tanenbaum最先想到了做一个运行于IBM PC机的简单Unix作为教学工具（他称之为minix）。Linus把Minix的概念推进到了Andy可能想都想不到的地步，使其变成一个如此神奇的东西。与此类似（不过是规模小些），我从Carl Harris和Harry Hochheiser那里借来主意并努力推进它们。我们都不是"原创"――那种人们浪漫想象中的天才。但是话说回来，多数科学、技术和软件的进展都不是由"原创"或者黑客神秘主义中的超级天才完成的。

这两个项目的结果都一致是那种很眩目的东西――那种每一个黑客毕生追求的成功！而且这意味着我将不得不把我的标准设得更高。为了让fetchmail达到我预想的目标，我不仅要为自己，而且还要为别人编程，同时保持程序简洁、健壮。

意识到这点之后，我所写的第一个也是绝对最重要的一个功能是集体收发（multidrop）――从一群用户的集体信箱里把累积的所有邮件取来，然后把每一封分发给单独的收信人。

我决定添加集体收发功能，一部分是因为用户们吵着要，但主要还是因为我觉得它会迫使我更全面地处理地址问题，从而甩掉单信发送模式中的臭虫。结果如我所愿。我花了很长的时间才把RFC822的地址解析搞定，不是因为它的哪一部分很难，而是因为它涉及了一堆相互关联的烦人细节。

然而集体收发也成为了一项优秀的设计决定。我是这样知道的：

任何一个工具都应该达到预期的用处，但是一个真正优秀的工具会带来预期不到的用处。

集体收发一个不曾预期的功能是可以在网络连接的客户端建立邮件列表、管理列表成员和展开别名。这样，通过ISP上网的个人不必持续访问ISP方的别名扩展文件就可以管理一个邮件列表。

我的beta测试员们要求的另一个重要功能是支持8位的MIME操作。这个很容易，因为我已经很小心地保持了代码的8位兼容性（没有强迫ASCII字符集中没有使用的第8位比特去携带程序中的信息）。不是因为我预料到了这个功能要求，而是遵循了另一个原则：

在写任何接口软件的时候，花点功夫尽可能不要干扰数据流――除非用户强迫你，永远不要扔掉任何信息！

要是我没有遵守这个规则，8位MIME支持会很困难且毛病不断。事实上，现在我所需要做的仅仅是读一下MIME标准（RFC1652），然后添加一条小小的文件头生成规则。

在一些欧洲用户的要求下，我添加了一个选项来限制每次连接能下载的邮件数目（这样他们可以控制他们昂贵的电话费）。我对这件事抵制了很长一段时间，直到现在也不是完全满意。但是如果你是给外边的世界写程序，你就不得不聆听你的顾客――就算他们不付你钱也是这个道理。

[编辑] Fetchmail带来的其它几条经验

在回到更广义的软件工程问题之前，还有几条fetchmail经历中的经验值得细想。非技术性的读者可以安全地跳开这一节。

Fetchmail用户配置文件（rc）语法中包括了一些完全不解析的、可选的"噪音"关键词。它们所带来的类似英语的配置文件语法比把它们全部梳理掉之后所剩下的传统"关键词－对应值"语法要可读得多。

这开始于一个深夜实验――那时我注意到rc文件的定义看起来多么像一个微型的命令式语言。（这也是我把popclient原有的"server"关键词换成"poll"的原因。［译注：server是名词"服务器"，poll是动词"检查"，后面跟随的是邮件服务器名。改成poll使配置文件读起来更象句子。］）

在我看来，努力把这个微型指令语言做得更像英语可能会使它更容易使用。那时，尽管我支持"把它做成一门语言"的设计流派，比如Emacs、HTML和许多数据库引擎设计的那样，我还不是特别热衷于"类似英语的"语法。

传统上，程序员们倾向于选用简洁紧凑、完全没有冗余的控制语法。这是计算资源昂贵时期的文化遗留。那时，解析过程不得不尽可能的廉价和简单，大概有50％冗余的英语明显是一个非常不合适的模型。

这不是我一般避免英语式语法的原因；我在这儿提起它正是为了打破这个看法。有了便宜的主频和处理器，简洁不应该为了简洁而简洁。现在一门语言对于人的方便比对于计算机处理的方便更重要。

然而我们还有需要小心的原因。其中之一是解析过程的复杂性成本不能被提高到富产臭虫和困惑用户的程度。另外，试图把一门语言的语法做得像英语经常迫使它的"英语"严重扭曲变形，以至于对自然语言的表面模仿变得像传统语法一样令人困惑。（你可以在许多所谓的"第四代"和商业数据库查询语言中看到这个坏效果。）

Fetchmail配置文件的语法似乎避免了这些问题，因为它的语言空间极为有限。它离一个通用的编程语言还很远；它需要表达的内容也很简单。所以在这里，由语言扭曲引起困惑的可能性很小。我觉得这里可能有一个更普适的经验：

当你的语言离图灵完备还差得远的时候，不妨给语法加点"糖衣"包装。

另一条经验是关于隐藏和安全性的问题。一些fetchmail的用户要求我改一下软件来把储存在rc文件里的密码加密，这样入侵者就不会在无意中看到它们。

我没有照办，因为这实际上并不会添加保护。不管怎样，任何一个有权读你rc文件的人都可以像你一样来运行fetchmail打开你的信箱――如果他们真的来找你的密码，他们也可以从fetchmail的代码中剥离出必要的解码器来得手。

所以，在rc文件中使用加密的密码只不过是给那些不怎么用心思考的人一种虚假的安全感。这里的一般规则是：

一个安全系统的安全性取决于其秘密的安全性。小心伪秘密。

[编辑] 市集风格的必要前提

这篇文章的早期审阅者和试验听众们不断希望了解市集开发风格的成功前提，包括项目领导人的素质和他开放项目和开始建立合作者社区时的程序代码状态。

很显然，市集风格不能帮助你从零开始编程［注：IN］。你可以使用市集风格测试、调试和提高你的代码，但是直接以市集模式来孕育一个项目会是很困难的。Linus没有这样试过，我也没有。你新生的开发者社区至少需要一个能运行和测试的东西。

[注：IN］另外一个和市集风格能否帮助你从零开始一个项目的话题是市集风格中能否产生创新。一些人声称市集风格缺乏强有力的领导，因此只能模仿或改进已有的工　　程方法，但无法孕育创新。该观点最有代表的作品要属"万圣节档案"了。这是微软关　　于开源现象的两篇内部备忘录，其作者认为，Linux只不过是追着Unix系统的尾巴跑，"（一旦追上了后者开始领跑），庞大的管理开销便会让其前进得非常缓慢"。

这个观点和事实完全不符。甚至万圣节文档的作者自己后来又指出"往往新点子首先在Linux中被实现，然后再被搬到其它平台。"

其实这也不是什么新现象。把上述论断中的"Linux"换成"开源项目"，我们可以发现来自开源社区的Emacs、万维网甚至英特网本身，不是追谁的尾巴跑出来的，也没有看到任何庞大的管理开销。现在开源项目不断创新给我们带来的是前所未有的广阔选择空间。随便举个例子，GNOME项目中关于图型界面和对象技术的创新已经受到大量的商业关注。其它例子举不胜举，随便那一天看一下Freshmeat.net就可证明。

该论断还包含的一个更根本的错误，即隐含地假设大教堂模型（或市集模型，或任何其它管理结构）可以有效的产生创新。这一点根本站不住脚。群体并没有更创造性的眼光。即便是市集模式中自愿组成的架构师团体往往也缺乏新点子，更不用说那些需要在权力平衡中考虑自身利益的公司委员会了。相反，创新来自个体。其周围的社会机制能做得最好的就是给予响应――去培育、奖励并严格的测试它们，而不是排挤它们。

所以，不论是软件还是其它任何领域，创新的关键在于如何去激发更多人提供新点子，以及如何不去排挤它们。

显然，假定大教堂开发模式有利于创新，而门槛低、流程通畅的市集模式不利于创新，是很荒谬的。如果创新的起点是一个人加一个点子，那么一个可以使该主意吸引成百上千合作人的环境将不可避免地优于一个为继续工作于该点子而不至于被解职，其主人不得不通过政治性的手腕将其推销到上级管理层的环境。事实是，那些使用大教堂方式机构的创新史表明，来自其自身的创新极为少见。大公司依赖大学研究成果作为其新点子（这也是"万圣节文档"作者对Linux有力地加速和吸收学术研究的不安），或收购那些基于某项创新而成立的小公司。这两种情况，创新均非来源于大教堂文化。恰恰相反，很多以类似方式买来的创新被"万圣节文档"作者所鼓吹"庞大的管理开销"所扼杀了。

上面讲的是负面的例子。这里更应该把一个正面的例子奉献给读者。我建议大家试试下面的方法：

定下一个你可以严守的创新准则。比如"看到了我就知道"就满足这个测试的条件。

再定下任何一个和Linux竞争的商业操作系统，和一个其开发工作进展的最好的消息渠道。同时观察该消息渠道和Freshmeat一个月，每天各自记下两者中你认为是创新的新点子数。三十天后，统计这两个数字。

我写这些文字这天，Freshmeat有22条软件发布信息，其中有3条看起来部分推进了现有技术。这只是Freshmeat上较差的一天。然而，如果哪个读者能在一个月中在某个商业渠道上找出类似的发现，我都会非常吃惊。

当你开始社区建设的时候，你要能够给出一个可行的承诺。你的程序不一定要工作得非常好。它可以是粗糙的、问题多多的、不完整的、缺少文档的，但它不可或缺的是

能运行
能说服潜在的合作者，它可以在可预见的将来进化成真正漂亮的东西。

Linux和fetchmail开放的时候都带有强劲、吸引人的基本设计。许多像我描述的那样来思考市集模式的人正确地认为这一点很关键；于是进而断定在项目领导人身上，高度的设计灵感和聪明不可或缺。

但是Linus的设计来自于Unix，我的最初设计来自于先前的popclient（尽管它后来变化很大，按比例来说比Linux的大的多），那么一个市集风格项目的领导人／主持人真的一定要有杰出的设计天才，还是只需掌握四两拨千斤的方法来利用大众的设计才能呢？

我认为项目主持人能否想出杰出灿烂的设计不是很关键，但绝对关键的是，他必须能够慧眼识别出他人的优秀设计或想法。

Linux和fetchmail项目都显示了这方面的证据。Linus，（像前面讨论过的）尽管不是一个特别有原创性的设计者，却展现了识别优秀设计并把它集成到Linux内核里强大才能。我也已经描述了在fetchmail里的最有力的一个设计思想（SMTP转发）怎样来自于另一个人。

这篇文章的早期读者捧我的场说我容易低估市集项目里原创设计的价值，因为我自己不缺创造性，因而就想当然的习惯了。这话大概有一点点的真实性在里面；设计（而不是编码或调试）确实是我的强项。

但是在软件设计里表现聪明和创造力的问题在于它会形成一种坏习惯――当你应该保持代码稳固和简单的时候，你开始放任地把它们搞得好玩和复杂。我曾经因为犯了这个错误把项目搞砸过，但是我在fetchmail里做到了避开这个错误。

所以我相信fetchmail项目的成功有一部分是因为我克制住了自作聪明的习惯；这（至少）反驳了设计的原创性是市集项目的成功关键。再想一下Linux，假设Linus在开发中试图整出操作系统设计的根本性创新，做出来的内核还会像我们现在的这么稳定和成功吗？

当然一定的设计和编码水准还是必要的，但是我认为几乎每个认真考虑发起一个市集型项目的人已经超出了这个基本要求。开源社区内部的声望机制给人们一种微妙的压力，就是不要发起自己不能坚持下去并搞好的开发项目。迄今为止，这一点似乎工作得很有效。

另外有一个和编程能力无关的技能，我认为对于市集型项目来讲和设计才能一样的重要――甚至可能更重要，那就是一个市集项目的主持人或领导者必须有良好的人际交流技能。

这应该是显而易见的。要建设一个开发社区，你需要吸引人群，让他们对你所做的感兴趣，并且让他们对自己的工作量舒心。要做到这一点，高超的专业技能会起很大的作用，但远远不是故事的全部，你所展现的人格也很重要。

Linus是一个平易的人，让人们喜欢他、想帮助他――这不是巧合。我是个活泼外向的人，喜欢和人群打交道，有着一些现场喜剧演员的直觉和本事――这不是巧合。要使市集模式运行起来，你最好还能有些让别人喜欢你的本领。

[编辑] 开源软件的社会语境

这句话写到了实处：最好的程序因作者日常问题的个人解决方案而开始，因一大批人正好都有这个问题而流行。这把我们带回了第一条经验的内容，用一种或许更有用的方式来表达是：

要解决一个有意思的问题，首先找到一个你觉得有意思的问题。

Carl Harris和先前的popclient如此，我和fetchmail也是如此。但是这点大家已经明白很久了。Linux和fetchmail的历史看来要求我们关心的是另外一个有意义的话题，即在下一个阶段――在用户和合作者形成了庞大活跃的社区时的软件的进化。

在《人月神话》中，Fred Brooks表述了程序员的时间是不能简单进行叠加的；添加开发人员的做法只能使得已经延期的软件项目更为延期。像我们前面提到的，他论述了项目的复杂程度和通讯成本按开发人员数目的平方增加，而业绩仅以直线增加。Brooks法则被广泛的认同为真理。但在这篇文章里，我们已经探讨了开源开发过程在好几处破除了Brooks规则的前提假设――而且事实证明，如果Brooks法则统领一切，Linux就不可能发生。

以事后之明来看，Gerald Weinberg的经典《计算机编程的心理学》对Brooks法则作出了一个关键的修正。在他对"无私编程"的讨论里，Weinberg注意到一些地方的开发人员不对自己的源码画地为牢，而是鼓励他人在其中寻找错误和指出改进的余地――在这些地方，改进比别处进展得明显快很多。（最近，Kent Beck的"极度编程"技术――把编程者配对让他们互相监督――或许可以看作是强制这一效果的尝试。）

Weinberg的用词可能让该结论未获得应有的认可――把网络黑客说成毫无私心未免让人莞尔。但是我认为他的结论在今天看起来比以往任何时候都更让人信服。

市集模式，借助"无私编程"效果的极致动力，有力减弱了Brooks法则的效果。Brooks法则背后的原理没有被推翻，但是庞大的开发者群体和廉价的通讯所带来的前所未有的准线性可扩展性，开始将其效果淹没。这就像牛顿式的和爱因斯坦式的物理之间的关系――旧的系统在低能量下仍然有效，但当质量和速度变得足够大的时候，就得到了如同核爆炸或Linux那样的惊奇。

Unix的历史应该使得我们对研究Linux的结果（和我在小规模上有意拷贝Linus的方法所实验确认的结果）有了心理准备。这是说，虽然编程基本上仍是一种个人封闭的活动，真正高超的程序来自于借助整个社区的注意力和脑力。一个在封闭的项目中只使用自己脑力的开发者，将会输给一个知道怎样创造一个开放和进化式环境的开发者、一个知道从中吸收成千上万人的探索设计空间的反馈、编码贡献、臭虫检测和其它改进的开发者。

但是有几个因素阻止了传统的Unix世界把这个方法发挥到极致。一个是各种软件许可、贸易秘密和商业利益的法律限制。另一个（回头来看）是互联网还不够好。

在便宜的互联网普及之前有过一些地域性的紧密团体，在文化上鼓励Weinberg的"无私编程"，使得一个开发者可以容易地吸引到一批有水平的"军师"和合作者。贝尔实验室、麻省理工的人工智能和计算机实验室、伯克利加州大学――这些成为了传奇性的和依然强劲的发明家园。

Linux是第一个有意识地并成功地把全世界当作智囊库使用的项目。我不认为Linux的孕育期与互联网的诞生重叠是一个巧合。Linux在1993－1994之间网络服务业起步和对互联网的主流兴趣爆发的同期脱离了它的婴儿时代也不是巧合。Linus第一个学会了如何运作普及的网络连接所促成的新规则。

虽然便宜的互联网是Linux模式进化出来的必要条件，我觉得它还没有构成充分条件。另一个关键的因素是一种领导风格和一套合作制度的建立――使得开发者可以吸引合作者并在这个媒介中获取最大程度的收益。

但什么是这种领导风格、什么是这些制度呢？它们不可能是基于权力关系的――就算是可能，强制性的领导不会产生我们所看到的成果。在这个题目上，Weinberg很恰当地引用了19世纪俄罗斯无政府主义者Pyotr Alexeyvich Kropotkin的自传《一个革命者的回忆录》：

成长于一个农奴主的家庭，我进入社会后，像我那个时候所有的年轻人一样，很是相信领导、命令、训斥、惩罚等等的必要性。但是在早期我不得不管理重要的事业和对付［自由的］人们的时候，在每个错误都会立刻导致严重后果的时候，我开始领悟到按指令的原则行事与按共同理解的原则行事之间的区别。前者在阅兵式中运行得令人崇敬，然而就真实的生活而言，它却一文不值；而且目标只有通过许多共同意志的竭诚努力才能实现。

这个"许多共同意志的竭诚努力"正是Linux这种项目所要求的；在这个我们叫作互联网的无政府主义者天堂里，对志愿者们行使"指令的原则"事实上是不可能的。要有效地运作和竞争，想要领导协作性项目的黑客们不得不学会怎样按照Kropotkin的"共同理解的原则"里模糊地提出的模式，招募和激励活动中的相关社区。他们必须学会使用Linus法则。［注：SP］

［注：SP］除了Kropotkin对"指令的原则"的批判和Linus法则，关于社会组织的内在机制问题还存在更广泛的讨论。其中包括另一个众所周知的软件工程定理――Conway定理，其通俗地表述就是"如果分四个小组去开发一个编译器，得到的会是个四遍编译器"。其最初的描述更为一般化："软件产品的体系结构必然是其开发机构内在通讯结构的缩影"。简单说来就是："方法决定结果"，或者"过程演变为产品"。

同样有必要指出的是开源社区存在多层与其功能吻合的组织结构，网络无处不在。除了英特网本身，成员间还存在一个分布式、松耦合的点对点网络，具有多重冗余性和可降级。在这两个网络中，节点的重要性只取决于外界愿意和他合作的程度。

其中的点对点网络对于开源社区惊人的生产力至关重要。以下的SNAFU法则又进一步发展了Kropotkin解释权力关系的尝试："真正的交流只能在平等的个体间存在；下级从上级得到更多回报的可靠方式是通过顺耳的谎言而非事实真相。"团体项目的创新最终依赖于真正平等的交流，因此，会受到权力关系的严重阻碍。开源群体不存在权力关系的事实从反面告诉了我们权力关系导致的修正错误的可怕代价、生产力的底下和机会的丧失。

更进一步，SNAFU法则预测在基于权力的机构中，随着流入决策层的顺耳谎言越来越多，决策者和现实之间的脱节将越来越严重。这个结果在传统软件开发中扮演的角色显而易见，就是下级极力掩饰、无视及淡化问题，做出的软件将成为灾难。

我早先引用了"神庙效应"作为Linus法则的一个可行的解释。但是不可避免自我呈现出的一个更有力的类比是生物学和经济学中的自适应系统。Linux世界在很多方面都接近自由市场或生态系统：其中的自私个体都试图将自身的利益最大化，但在这个过程中形成了一个自我纠正的自发秩序，其周密度和有效性不管多少中央计划都无法与之媲美。那么，这里就是寻找"共同理解的原则"的地方。

Linux黑客们最大化的这个"利益函数"不是经典经济学上的，而是他们自我的满足和在其他黑客中的声望这些摸不到的东西。（有人或许可以把他们的动机称为"利他的"，但这忽略了利他主义自身对利他主义者就是一种自我满足这一事实。）这样运作的自愿者文化其实也很常见；我长期参与的另一个就是科幻粉丝族。不像黑客族，他们早就明白地认识到了"自我彰显"（ego-boosting，或在其他粉丝中增强个人的声望）是志愿者活动背后的基本动力。

Linus，通过成功地把自己定位为一个主要由其他人来开发的项目的看门人，以及培养对这个项目的兴趣直到它可以自我维持，表现了对Kropotkin"共同理解的原则"的敏锐把握。上述对Linux世界的类经济学视角使得我们能够看到这种理解是如何应用的。

Linus方法其实就是利用"自我彰显"来创造有效的市场。是"自我彰显"把单个黑客的自我利益最大化行为紧密地和那些只有通过持续合作才能达到的困难目标绑在一起。通过fetchmail项目，我证明（尽管在小规模上）可以通过复制他的方法产生出好结果。或许我甚至做得比他更有意识和更系统一点。

很多人（尤其是在政治上不相信自由市场的那些）会以为自我驱动的个人主义者们形成的文化会是支离破碎、占山为王、低效浪费、秘密诡异和充满敌意的。但是这个设想显然被（只举一个例子）Linux文档的惊人的广度、深度和质量所证伪。既然程序员痛恨写文档是众所周知的，上述事实简直是奇迹。Linux黑客们是怎样生产出这么多文档的呢？显然，Linus自我彰显的自由市场在产出优良的、协同的行为上优于商业软件厂商的大笔资金驱动的文档工厂。

Fetchmail项目和Linux内核项目都表明，通过适当地表彰众多其他黑客的成就，一个有力的开发／协调者可以使用互联网来收获拥有许多合作者的好处，而不至于让项目陷入嘈杂的混乱。所以针对Brooks法则，我反过来建议下面的一条：

如果开发的协调者有一个至少和互联网一样好的通讯媒介，而且懂得如何不通过强迫来领导，那么多个头脑不可避免地优于一个头脑。

我认为开源软件的未来会更多地属于那些懂得如何运行Linus规则的人们，属于那些告别大教堂来拥抱市集的人们。这不是说个人的远见和才华不再重要；而是，就我看来开源软件的前沿会属于那些开始于个人的远见和才华，然后通过有效地建设相关志愿者社区来扩展放大的人们。

或许这不仅是开源软件的未来。要对付一个问题，没有闭源的开发者可以比得上Linux社区所能驱动的才能之众。极少有人甚至能雇得起那些对fetchmail作出了贡献的200（1999:600, 2000: 800）多人！

也许，开源文化最终胜利的原因不是因为合作在道德上正确或软件"劳役"在道德上错误（假设你相信后者，Linus和我都不），而只是因为开源社区可以在一个问题上投入多几个数量级的技术工时。闭源世界无法赢得这场进化式的军备竞争。

[编辑] 关于管理和马其诺防线

原始于1997年的《大教堂和市集》文章以上述预见结束――程序员／无政府主义者的幸福网络群体胜出并压倒了传统闭源软件的阶层化世界。

然而，很多怀疑者并不信服；他们提出的问题值得我在这里做出回应。多数对市集模式的反对归结到以下观点：市集模型的鼓吹者们低估了传统管理促进生产率的效果。

老脑筋的软件开发经理经常指责开源世界里项目组创建－变动－解散的随意性大大抵消了开源社区对单个闭源开发机构在人数上的明显优势。他们会指出对软件开发真正重要的是长时间里不懈的努力和多大程度上顾客可以预期对产品的持续投资，而不仅仅是多少人往锅里扔一块骨头让它炖着。

没有疑问，这条争论有一定道理；实际上，我在"魔法大熔炉（The Magic Cauldron）"一文中就已经说明预期的未来服务价值是软件产业经济的关键。

但是这个论点隐藏有一个严重的问题：它暗中假设开源开发不能形成持续的努力。事实上，有的开源项目在很长的时间段里保持了一致的方向和有效的维护团体，而不需要传统管理必不可少的那些奖励机制或制度性的控制。GNU Emacs编辑器的开发是一个极端的、说明问题的例子：尽管人事变换频繁、一贯持续下来的只有一个人（它的作者），它在超过15年的时间里吸取了成百上千贡献者的劳动、形成了一个统一的结构设计。没有哪个闭源的编辑器或曾比得上这个长寿记录。

这建议了一个质疑传统管理模式下软件开发优势的理由（与其它关于大教堂和市集模式的争议不相干）。如果GNU Emacs可以在15年里表述一个一致的框架设计，如果Linux操作系统在8年多快速变化的硬件和平台技术中作到了同一点，如果（事实的确如此）存在许多设计优良的开源项目超出了5年的历史――那么我们有权发问传统管理开发的庞大开销到底给我们买来了什么――如果有的话。

不管是什么，它显然不包括按期、按预算和按指定功能完成预定计划的可靠管理运营手段；能满足这三个目标中仅仅一条就是一个罕见的"管理好"的项目了，更不用说全部了。它看来也不包括在项目进行过程中适应技术和经济环境变化的能力；在这点上，开源社区已证明其远远来得更为有效（来简单确认这点，比方说，可以比较互联网30年的历史和私有网络技术短短的半衰期；或者比较微软视窗从16位转换为32位的成本和Linux同一时期几乎毫不费力的升级――不仅是围绕英特尔系列，而且还包括含64位Alpha芯片在内的十多个其它硬件平台）。

很多人觉得从传统模式中购买到的一件东西是有人负法律责任：如果事情出了问题可以找赔偿。但这是一个幻觉；大多数软件协议甚至免除可商品化的保证，更不用说性能了――而且由于软件不工作而索赔成功的案例少得近于虚幻。退一步说，即便成功案例很多，因为有打官司的对象而觉得心安是搞错了要点。您不想打官司；您要的是能工作的软件。

那么这些管理开销都买了什么呢？

要理解这个问题，我们需要理解管理软件开发的经理们是怎么想的。我认识的一个似乎很优秀的女经理指出，软件项目管理有以下五项功能：

明确目标并保持大家向同一个方向努力（目标定义）
监督并确保关键的细节不被漏掉（监督细节）
动员人们做枯燥但是必要的苦力活儿（驱动力）
组织人员分配来达到最佳生产力（组织结构）
监护项目持续所需要的资源（资源监护）

显然是有价值的目标，所有这些都是；但是在开源模式下，并且在它周围的社会语境中，这些功能会变得出奇地不相干。我们来按逆序讨论这几条。

我的朋友报告说许多"资源监护"基本是防卫性的；一旦你有了你的人员、机器和办公空间，你不得不防卫其他经理竞争相同的资源，和防卫上级调用有限资源中最高效的部分。

但是开源开发者是志愿的、在兴趣和对所参与项目的贡献能力上自我挑选的（甚至在他们领了薪水为开源项目编码的情况下这条也一般适用）。志愿者的特点会自动解决资源监护的"攻击方"；人们把自己的资源带到桌面上来，而且对管理者来说，没有或几乎没有必要来作传统意义上的"防卫"。

不管怎样，在一个有便宜电脑和快速互联网连接的世界里，我们很一致地发现项目真正唯一稀缺的资源是来自技术人才的关注。开源项目本质上从不会为了争夺机器或网络或办公空间而成立；它们只在开发者自己失掉兴趣的时候消亡。

在这点之外，加倍重要的是开源黑客们通过自我选择产生的"组织结构"来达到最大生产率――社会环境也无情地对能力作选择。我的朋友对开源世界和大型闭源项目都熟悉，她认为开源的成功部分归功于它的文化只接受编程人员中最有才华的5％左右。她花费了她大部分时间来组织部署其他的95％，并第一手观察到了那著名的事实，即最优秀的和仅仅及格的程序员之间上百倍的效率差别。

这个巨大的差别程度总是引发一个尴尬的问题：不管单个的项目还是整个行业，甩脱了那50％最差的是不是会更好一些？肯动脑的管理者很久以来就懂得，如果传统软件管理的唯一功能是把最差的一帮人从净损失转为微盈利，这事儿恐怕就不值得折腾。

开源社区的成功提供了硬性证据显示从互联网上招募自我选择的志愿者经常要比管理一整栋楼的"身在曹营心在汉"的人们要便宜和有效的多。这在相当程度上尖锐化了上述问题。

这恰好把我们带到"驱动力"的问题上。对我朋友观点的一个等同的、常有耳闻的转述是：传统开发管理是对缺乏动力的程序员的必要补充，不然他们做不好工作。

这个回答一般携带着一个说法：只能指望开源社区做那种"眩目"的或技术上好玩的工作；任何其它的会被拉下（或敷衍其事）――只有金钱驱动的坐隔间的人在经理们的鞭策下才能把这些给搅出来。我在"开拓智域（Homesteading the Noosphere）"里从心理学和社会学角度论述了我对这个说法的怀疑。然而就当前的目的，假定它正确而来看看其衍生出的推论会更有意思一些。

如果传统的、闭源的、冗肿管理的软件开发方式的是为了对付一堆马其诺防线般的枯燥问题，那么它在每一个应用领域里的寿命就只有指望没有人发现这些问题真正有意思，而且没有人发现绕道而行的方法。因为一旦一种"枯燥"的软件出现了开源的竞争者，顾客们会知道终于有人因为关注这个问题本身而选择来解决它了――对软件业，这一点像对其它任何的创造性工作一样，是比单独的金钱远为有效的驱动力。

仅仅为了驱动力来要一个传统的管理结构，或许是一个好的战术、坏的战略：可以获得短期的胜利，但长期下去必将失败。

说到这里，传统式开发管理和开源相比，现在在两点（资源监护，组织结构）上看起来不是明智之选，而且在第三点（驱动力）上朝不保夕。可怜的受困的传统项目经理也不会在"监督细节"一项上得到任何帮助；开源社区最强大的一个优势就是其非集中式的同行评议在试图保证细节不被忽略上胜出了所有的传统方法。

我们可以把"目标定义"留下来作为接受传统软件项目管理开支的理由吗？可能吧；但是这样的话，我们需要好的理由来相信管理委员会们和公司的远景规划比开源世界里的扮演类似角色的项目领导和部落长者们在定义有价值的、被广泛接受的目标上更为成功。

就面上来看，这很难讲得通的。困难没有多少是来自于对峙的开源一方（Emacs的长寿，或Linus以"统领世界"的说辞动员大群开发者的能力），而是来自于传统机制在定义软件项目目标上表现出来的尴尬。

软件工程里一个出名的大众定理是60％到75％的传统软件项目要么从没完成过，要么被目标用户否决了。要是这个数字真的和事实沾边（我从没有遇到过一个有经验的管理者否定过这点），那么占多数的项目都瞄向了

现实里达不到的或
错得离谱的目标。

上述事实使得在今天的软件工程世界里，"管理委员会"这个词会让听者背上直冒冷气――甚至（或者尤其）当听者是管理者的时候。那些只有程序员们咒骂这一现象的日子早已过去了；Dilbert卡通如今挂上了管理层的案头［译注：呆伯特是美国著名卡通系列的人物；该系列的主题是技术人员对管理层的揶揄］。

我们对传统软件开发经理的答复也就很简单――如果开源社区真的低估了传统管理的价值，为什么你们这么多人表现了对你们自己开发过程的轻蔑？

开源社区的例子再次把这个问题尖锐化了――因为我们做事乐在其中。我们创新的游戏已在技术、市场占有和观念的成功上以惊人的速率得分晋级。我们在证明不仅我们可以开发更好的软件，而且欢乐是一种宝贵财产。

在这篇文章第一版的两年半后，一个开源统领的软件世界不再是我能用来结尾的最激进的观点；毕竟，今天很多穿西服套装的人都已认同这个结局的可能性。

相反，我想提出一个对软件业或许更广泛的教训（或许也是对于任何一种创造性的或专业性的工作）。人们一般在一项任务处于一种适当难度范围的时候享有乐趣；不要太简单了至于无聊，不要太难了无法完成。一个快乐的程序员是一个既没有被浪费也没有被错误制定的目标和烦人过程摩擦所压倒的人。乐趣决定效率。

以畏惧和厌恶来谈论你自己的工作过程本身（即使通过悬挂Dilbert卡通这种改头换面的讽刺性方式）应该被看作一个过程失败了的信号。欢乐、幽默，和趣味是真正的财富；我在上面写的关于"快乐的一群"主要不是为了押韵，Linux的吉祥物是一个可亲的、稚气犹存的企鹅也不仅仅是玩笑。

也许，开源的成功所带来的最重要的影响是教育我们，乐趣才是创造性工作经济上最有效的模式。

[编辑] 后记：网景欢迎市集

与历史同行，那是一种奇特的感觉……

1998年1月22日，大概在我发表"大教堂和市集"七个月之后，网景通讯公司宣布了开放网景浏览器源代码的计划，事先我一点都不知道。

之后不久，网景的执行副总和首席技术官Eric Hahn发给我这样一封电邮："我希望代表网景的每一个人感谢您带头帮助我们走到了这一步。您的思考和文字给了这个决定关键性的启迪。"

接下来的那周我接受网景的邀请飞到硅谷，和他们的高层管理和技术人员进行了一整天的战略性会议（1998年2月4日）。我们一起制定了网景的代码开发计划和发放执照。

几天后我写道：

网景将要给我们提供一个商业世界里的对市集模式的大型的、现实的尝试。开源文化现在正面临着一个危险；如果网景此举失败，开放源代码的概念会信用扫地，商界在之后的十年内都不会再碰它。

另一方面，这也是一个绝好的机会。华尔街和其它地方的初步反应是谨慎的赞成。我们也得到一个证明自己的机会。如果网景通过此举夺回一定的市场份额，或许会触发一场软件业等待已久的革命。

接下来的一年将会很有指导意义，也将会十分有趣。

确实是这样。2000年中期我修订此文之际，后来命名为Mozilla的开发项目只算是及格的成功。它达到了网景的最初目标――阻止微软在浏览器市场的垄断锁定。它也达到了一些显著的成功（尤其是下一代Gecko转换引擎的发布）。

然而，它还没有召集到来自网景之外的、Mozilla创办者们起初所期冀的那种开发规模。这里的问题似乎是，在很长的一段时间里，Mozilla的发布实际上破坏了市集模式的一条基本规则；它没有发放一个潜在的参与者可以轻易运行和眼观其效的东西。（直到发布后一年多，编译Mozilla需要一个专有的Motif库许可。）

最消极的是（从外部世界的角度来看），Mozilla团队在项目开始后两年半里没有发布出一个具有工业质量的浏览器――而且在1999年，一个项目骨干的辞职引起了不小的影响。他抱怨管理不力，错失良机。"开源"，他正确地评论道，"不能点石成金"。

确实不能。现在（2000年11月）Mozilla项目经过长期恢复，比起当初Jamie Zawinski辞职时看起来有了戏剧性提高――最近几个星期的日末发布终于跨过了生产性使用的关键门坎。但是Jamie的观点完全正确。走开源路线并不一定会挽救一个目标错乱、或编码堆面条、或患有其它软件工程慢性病的已有项目。Mozilla成了一个同时展示开源如何成功和如何失败的案例。

然而与此同时，开源的理念已经在其它地方获得了成功和支持。自从网景的计划公布以来，我们目睹了对开源开发模式的兴趣的爆炸式增长――Linux操作系统的持续成功既是驱动方也是收益方。这个由Mozilla触发的潮流正在加速前进。

[译者按］尽管网景后来难敌微软垄断性的重压，几年后从Mozilla中浴火重生的Firefox再次证明了开源社区的能量。Thomas Friedman在他2005年的畅销书《The Worldis Flat》中把网景列为全球化的十大动力之一，因为网景为互联网的普及作出了奠基性的贡献。

[编辑] 参考文献

我多次引用了Frederick P. Brooks的经典《人月神话（The Mythical Man-Month）》。在很多层面，他的观点到目前为止仍然有效。我全心推荐收录了其1986年文章"不存在银弹（No Silver Bullet）"的25周年纪念版（Addison-Wesley出版社，ISBN 0-201-83595-9）。

这个版本还包含了非常珍贵的一份Brooks在20年以后对文中极少数没有经得住时间考验的论点的回顾。在本文第一个公开版本几近完工时，我第一次阅读了这份回顾，并惊讶的发现Brooks把市集模式归功于微软。事实证明这是不正确的。1998年我们通过"万圣节文档"了解到，微软内部开发团队之间帮派严重，根本不可能真正存在市集模式所必须的绝对源码共享。

Gerald M. Weinberg的《计算机编程的心理学（The Psychology Of Computer Programming）》（纽约，Van Nostrand Reinhold出版社，1971年）引入了（可惜命名地不太好的）"无私编程"的概念。他虽然远不是意识到"命令的原则"不实用性的第一人，但他可能是第一个将此观点和软件工程联系起来的人。

Richard P. Gabriel在其1989年的文章"LISP：好消息、坏消息及如何做大（LISP: GoodNews, Bad News, and How To Win Big）"中勉强地阐述了一个准市集模型的优越性。尽管在一些方面有些过时，此文仍然受不少LISP迷（包括我）的推崇。一位读者提醒我题为"更坏即是更好（Worse Is Better）"的小节读起来更象是对Linux出现的预言。该文的网址为：http://www.naggum.no/worse-is-better.html

De Marco和Lister的《人件：高产的项目和团队（Peopleware: Productive Projectsand Teams）》（纽约，Dorset House出版社，1987，ISBN 0-932633-05-6）是一个被低估了的好作品。我很高兴看到Brooks在其回顾中引用了此书。虽然文中所述极少可被直接应用于Linux和开源社区，此书作者对产生创造性工作先决条件的精辟论断值得每个希望将市集模式精华移植到商业领域中的人参考。

最后，我必须承认我差点将"The Cathedral and the Agora"作为本文的题目。Agora特指古希腊、罗马的露天市集或公众聚会场所。Mark Miller和Eric Drexler关于"agoricsystems"的系列开创性文章描绘了类似自由市场的计算机生态学。此文帮助我在5年后领悟了Linux开源文化中的类似现象。相关文章的网址为： http://www.agorics.com/agorpapers.html.

[编辑] 致谢

此文质量的提高得益于很多人与我交流并提供修改建议。特别感谢Jeff Dutky<dutky@wam.umd.edu>提出"并行改错"的观点并帮助完成其后的分析。感谢Nancy Lebovitz<nancyl@universe.digex.net>建议我模仿Weinberg来引用Kropotkin。General Technics邮件列表的Joan Eslinger <wombat@kilimanjaro.engr.sgi.com>和Marty Franz <marty@net-link.net>提供了关于可读性的批评。Glen Vandenburg <glv@vanderburg.org>指出贡献者人群自我选择的重要性，并提出了开发新功能即改正"功能不足错误"的富有成效的观点。Daniel Upper <upper@peak.org>指出了自然界中的类似现象。感谢费城Linux用户组作为本文第一个公开版本的第一批测试读者。Paula Matuszek <matusp00@mh.us.sbphrd.com>提供了关于软件管理的实践知识。Phil Hudson <phil.hudson@iname.com>指出黑客的社会结构映射出了其软件结构，反之亦然。John Buck <johnbuck@sea.ece.umassd.edu>指出MATLAB和Emacs的有益类比.。Russell Johnston <russjj@mail.com>让我意识到"要多少个眼球来驯服复杂度"中讨论的一些内在机制。最后，Linus Torvalds提供了有用的建议和对本文很早的公开支持。

来源： http://www.ebanpo.com/roamingo/esr/catb.txt

原文版本：2000年9月11日1.57版

参考译文：

habpi，http://www.rockiestech.com/rl/files/cathedral_RL_v1.1.pdf

HansB，http://www.linuxforum.net/books/c&b.html

翻译整理：管旭东 <roamingo@gmail.com>

取自"http://www.pgsqldb.org/mwiki/index.php/%E5%A4%A7%E6%95%99%E5%A0%82%E4%B8%8E%E9%9B%86%E5%B8%82"

第三章开拓智域

在观察由开放原始码版权所定义的"官方"意识形态与真正玩家的行为後，发现到一些矛盾之处。重新检视真正掌控开放原始码拥有权的文化。我们发现暗藏著一个源自於Locke的土地产权理论的现象。我们将此与玩家文化跟"礼物文化"关联起来，意即参与者透过投入时间、精力、及创造力所生产的礼物来竞争并获取名望。接下来检视在文化中，迁涉到对冲突解决的分析，并发展一些常规。

[目录]

1. 矛盾的现象 2. 玩家意识形态的多样性 3. 杂乱的理论，清教徒实践 4. 开放原始码及拥有权 5. Locke及土地头衔 6. 玩家文化即礼物经济 7. 驾御之乐无穷 8. 名望的多面性 9. 拥有权及名望诱因 10. 自我的问题 11. 人性的价值 12. 名望游戏模型对整体的密切关系 13. 智域特质及领土於动物行为学的影响 14. 冲突的起因 15. 计划结构及拥有权 16. 冲突与冲突解决 17. 薪传机制及与学界的关联 18. 结论：由文化到文化规范 19. 对进一步研究的一些问题 20. 参考文档，附注，及感谢（不翻译）

1. 矛盾的现象

　　任何人观察忙碌，巨大生产力的网际网路开放原始码软件世界一阵子，一定都会注意到一个很有趣的矛盾，开放原始码玩家们，所说及所做之间的矛盾――即开放原始码官方的意识形态及其实际的实践。

　　文化是善於应变的机器。开放原始码文化是对应到一系统可指认出的驱力及压力。一如往常，文化对环境的适应力显示出清析的意识形态，及隐含地，潜意识或半意识的意识形态。而，并非不寻常地，半意识的适应力扮演与清析的意识形态同样重要的地位。

　　在本文，我们将深掘此一矛盾的根，并用来发掘这些驱力及压力。我们将演绎一些关於玩家文化习俗的有趣的事。并透过建议一些方式，以升华这一玩家文化的知识层次。

2. 玩家意识形态的多样性

　　网际网路开放原始码文化的意识形态（玩家们说他们所相信的）本身是相当复杂的话题。所有成员都同意开放原始码（也就是，软件可以免费散播及能够毫无困难地演化及修改成适合自己所需）是件好事，并值得投入大量群体的力量。这样的一致很有效地定义了文化的成员资格。不过，有许多理由值得我们考量，尤其是许多个体及次文化信念的多样化。

　　一种是狂热；一种不论开放原始码开发仅仅是个到达终点的便利工具（好的工具，有趣的玩具，及有意思的游戏）或者本身就是终点的热情。

　　狂热之辈会说："自由自由软件是我的生命！我生命的意义在於生产有用，优美程式及资讯资源，然後送给人家。"中等热诚者会说："开放原始码是好东西，我愿意花下大量时间协助。"低度热诚之流则会说："对，开放原码有时还可以。我玩弄它，并且尊重建造它的人们。"

　　另一种是对商业软件或企图统治商业软件市场的企业的敌意。

　　非常反对商业的人会说："商业软件是偷窃及聚财。我写自由软件来结束这个恶魔。"中等反商业的人会说："商业软件一般还好啦。程式设计师需要有收入，但是那些推行劣质产品并且胡搞一通的则是恶魔。"不反商业的人会说："商业软件还好啦。我用或写开放原始码软件是因为我比较喜欢它。"

　　这样的态度组合表现出九种开放原始码次文化。值得将这分别指出的原因是它们暗示著不同的议题，及不同的适应，及合作的行为。

　　从历史上来看，最引人注目及最有组织的玩家文化是非常狂热及非常反商业的。由Richard M Stallman（RMS）所设立的自由软件基金会，自1980年代早期，大力支持著开放原始码的发展，包含了像Emacs及GCC到目前为止，在网际网路开放原始码世界依然是最基本的，而且看来依然会在未来继续下去。

　　许多年来，FSF是唯一最重要的开放原始码的焦点，产生大量至今依然对该文化非常重要的工具。FSF同时也是对外界来说，唯一对玩家文化的赞助者。他们有效地定义该辞"free software"，慎重地定义其重要性（新一点的"open source"则慎重地避免一些误解）。

　　因此，内内外外对玩家文化的认知都倾向指出该文化是FSF的热情态度及反商业目标（RMS自己否认他是反商业的，但他的程式是被许多人这样的解读，包含他许多的口头游击战）。FSF的强力而明显的口号"赶走软件聚财员外！"变成玩家意识形态的中心，而RMS是最接近玩家文化的领导者的地位。

　　但FSF并不是游戏中的唯一成员。还有一些比较安静的，比较不那麽激烈，而且在玩家文化中，对市场比较友善。实用主义者比较不像早期FSF那样的传统上的意识形态。这些传统包含了，更重要的，纠缠著UNIX技术文化及前商业的网际网路。

　　典型的实用主义者态度是适度地反商业，而其主要对商业的抱怨并非"宝库"。而是该世界对较好的技术UNIX，开放标准及开放原始码软件的顽强拒用。如果实用主义者痛恨任何东西，那大概不是"聚宝"，而是在软件市场的龙头；过去是IBM，现在Microsoft。

　　对实用主义者来说，GPL的重要性是个工具而非终点目标。它主要的价值不是用来对付"聚宝"，而是用来鼓励分享软件及成长市集模式发展团体。实用主义者以拥有好工具及玩具来衡量价值，而非不喜欢商业，并且会使用高品质商业软件而不会有意识形态上的不舒适。同时，其开放原始码经验已经教导他技术品质的标准，很少会有封闭软件能够达到。

　　许多年来，实用主义者的观点在玩家文化中，常顽固地透过拒绝完全使用GPL版权及FSF章程的方式来表达。从1980年代到1990年代早期，这样的态度倾向与Berkeley Unix的风迷有关，BSD版权的使用者，及早期以BSD原始码为基础来建立开放原始码UNIXes的付出。这些付出，无法建立起大规模的市集团体，因而变得片断及无效率。

　　一直到Linux在1993-1994年间开始爆发，实用主义者找到了很有力的基础。虽然Linus Torvalds从未反对过RMS，他设下了商业Linux工业成长的良好典范，透过保证商业用途软件上的高品质，及轻微地嘲弄清教徒及狂热文化中的元素。

　　Linux快速成长的副作用引介了许多新的玩家进入，而Linux是他们主要的兴趣，FSF的信念则是历史的兴趣。虽然新一波的Linux玩家会描述Linux为"GNU一代的选择"，大部份会仿效Torvalds而不是Stallman。

　　许多的反商业清教徒都发现他们自己处於少数地位。在Netscape於1998年二月宣布要公开其Navigator 5.0原始码之前，许许多多的事情都已经改变了。这激起商业世界对"自由软件"的更大兴趣。其後果是唤起玩家文化探索空前的机会及重贴其产品标签，由"自由软件"成为"开放原始码"，以符合大众参与的认证许可。

　　在一个增援开发中，文化中的实用主义者在1990年代有许多个中心。其它半独立的团体及其半意识及有魔力的领导者开始由 UNIX/Internet的根发芽。在这些当中，在Linux之後，最重要的是Larry Wall带领的Perl文化。比较小，但依然很重要的是由John Osterhout创建的Tcl及Guido Van Rossum的Python语言。所有这三个团体都透过发布其非GPL版权方案来表达其意识形态。

3. 杂乱的理论，清教徒实践

　　然而，在历经了所有的这些改变，依然存在广泛的舆论在什麽是"自由软件"或"开放原码"。对共同理论的最清楚的表述可在各式开放原始码版权中找到，都有一些重要的共同元素。

　　在1997年，这些共同元素被结合到Debian Free Software Guidelines，後来变成开放原始码定义。在开放原始码定义的指导下，一份开放原始码版权必须要保护无条件的由任何人或团体来修改开放原始码软件的权利。

　　因此，与OSD相关的理论（及OSD-conformant版权，诸如GPL、BSD、及Perl's Artistic License）就是任何人可以玩弄任何东西。没有人可以防止一大票人来玩弄任何开放原始码产品（诸如，以Free Software Foundations的gcc C compiler），复制原始码，将它们朝各种不同的方向演化，但都可以宣称依然是该产品。

　　但在实际上，这样的"分歧"几乎没有发生过。大计划分歧的状况很少，而且几乎都是由重新贴个标签及大规模的自我正当化来完成。很清楚的，在 GNU Emacs/XEmacs分支，或gcc/egcs分支，或各式各样的BSD分支群，这些分歧者都感觉到他们是在对抗一个相当巨大力量的社会规范。

　　事实上（与anyone-can-hack-anything的大众理论相矛盾之处）开放原始码文化有个很复杂但大体自我正当化的拥有权习俗。这些习俗规范了谁能修改软件，这些状况决定了谁能够修改，谁有权力再发行修改过的版本到团体中。

　　这些文化的禁条明确地规范基准。因此，我们在此摘要一些重要的部份会对未来有点用处。

　　对计划分歧来说，社会的压力很大。除非实在是非这样做不可，透过大众的自我审判。发行一个未经原创者同意对计划的改变是受到阻止的，除非在特殊状况下，诸如一些一般的修正码。将一个人的名字从计划历史，或维护者中抹去是绝对不可行的，除非当事者同意。在本文，我们将细细检验这些禁条及拥有权习俗。我们将探索它们是如何运作的，并且揭露在其内中的社会动力及开放原始码团体的诱因结构。

4. 开放原码及拥有权

　　当产权可无限复制时，"拥有权"的意义为何，或者延申来说，整个文化不具有强制高压力量关系或稀有物质经济？

　　事实上，在开放原始码文化的例子中这是个很容易回答的问题。软件计划的拥有者是那些拥有独有权力，被大规模团体认定，可再发行修改过的版本。

　　（在讨论"拥有权"这一节中，我使用单数，因为所有计划都是由某个个体所拥有。有时候，应该要了解有些计划是由一群人所拥有的。我们会在本文後段检验这样族群的内部的动力。）

　　根据标准的开放原始码版权，所有参与者在演化游戏中都平等。但在实际上，大众对"正式"版，即由大众认可的维护者所整合并认可的版本，及支援厂商的"游离"修补版，有很明显的差别待遇。游离修补版是不寻常的，而且一般都不受信任 [RP]。

　　大众发行版是基础的是很容易了解的。习俗鼓励个人需要时可以进行对软件的修补。习俗对那些再将修改版发行的人或发展团队的待遇是不同的。当修改版在开放原始码团体中被发行时，用以与原有版本来竞争，拥有权就变成是个问题。

　　一般来说有三种方法来看一个开放原始码计划的拥有权。第一种，最明显的，是计划的创建者。当计划只有一个维护者/创建者，而创建者还在活动时，习俗不允许质疑谁是计划的拥有者。

　　第二个方式是计划的拥有权是由上一个拥有者所转移过来的（有时可称为"转交指挥棒"）。在这个团体中，一般认可，计划拥有者不再感兴趣或无能再进行维护的时候，会将责任交给下一个继任者。

　　在大计划中这就很重要，控制权的转移往往伴随著华丽的吟咏。对大多数开放原始码团体中，大家所不知道的，它实际影响著拥有者对继承者的选择，习俗明白说明正统嫡系的重要性。

　　对小一点的计划，在历史记录上记录一下计划拥有者的改变即可。如果前一位拥有者并非志愿的转移控制权，他可以在一段时间内在团体透过向大众公开来取回控制权。

　　第三种获取计划拥有权的方式是观察该计划需要工作，而拥有者却失去兴趣或消失了。如果您希望做这件事，您需要去找到拥有者。如果您找不到，那麽可以在相关的地方宣告（像在该领域的新闻讨论网）该计划似乎变成孤儿，而您正在考虑负起责任来认养。

　　习俗要求您在您宣告您是新的拥有者之前，要等待一段时间。在这段时间内，如果有人宣告他们已经在这方面开始工作，那麽他们的宣告胜过您的。多让大众知道您对这方面的兴趣是很好的方式。最好是你在许多相关的讨论区中宣告（相关新闻讨论网，邮件列表）；而如果您有耐心等待回应。一般，您制造越多的注意，让上一个拥有者或其它的宣告者来反应，当没有人反应时，您的宣告会更有效。

　　如果您已经通过在计划使用者中这样的过程，而没有人异议，那么您可以宣告该孤儿计划的拥有权，并且在历史档中记下一笔。不过，这比正式交棒来的不安全，您并不被视为嫡系，除非您在使用者族群中做了许多的改善以後。

　　我已经观察了这样的习俗二十年了，可以回朔到前FSF的古早开放原始码软件历史中。他们有许多非常有趣的特色。最有趣的事，大多数的玩家都不需要人家告知便知道要这样做。的确，以上所述是第一次完整写下的摘要。

　　值得一提的事，潜意识的习俗，实在是令人惊人的协调。我已经不夸张地观察到数百个开放原始码计划的演化，而我还可以用手指来算出这些违反传统的例子。

　　第三个有趣的特色是这些传统在时间下的演化，他们在协调的方向下如此运作。这样的方向鼓舞更多的大众责任，大众注意，及更关心於现有拥有者保留原有拥有人的成就及历史记录。

　　这些特色建议了这些习俗并非意外发生的，而是某种暗示性的条文，或是开放原始码文化中的生产形式，在运作中这些是完全基本的条件。

　　早先一位回响者指出，相对於网际网路玩家文化的骇客/海盗文化（"warez d00dz"主要集中於破解游戏及海盗BBS）也有类同的两种生产形式。我们将会在文中稍後回到d00dz的比较。

5. Locke及土地头衔

　　要将整个一般的型态了解，历史上，在玩家之外，有些类同的传统，与玩家的习俗是相同的。一些历史或政治哲学的学生或者会认出，这个产权的理论暗示著与英美一般惯例法理论中的土地产权相同的观念！在这个理论中，有三种方法来确认土地的拥有权。

　　在边疆，领土可以存在而没有拥有者，一个人可以透过开垦来获取拥有权，在未有人拥有土地时，混以血汗，架起栏干，并且抵御个人的名衔。

　　一般转移土地的方法是头衔转移，也就是从上一位拥有者的手中收到契据。在这个理论中，"头衔传承"观念是很重要的。拥有权理想证据是整个契据传承及转移可用於追朔土地在最早期被开垦时的规模。

　　最後，一般法理论了解到土地头衔可能会遗失或被抛弃（例如，如果拥有者死去而无继承者，或者要建立头衔传承的文件遗失了）。无主的土地可透过adverse possession的方式所认领――透过迁入，改善它，并为其抵御，就由如是开垦它一般。

　　这个理论，正如玩家习俗一般，会在中央权威薄弱或不存在的背景下有机地演化。它在挪威及日耳曼部族演化了数千年。因为它被早期英国政治哲学家John Locke理性而系统化，有时它被称为"Locke"产权理论。

　　类似逻辑的理论倾向在高度经济或生存价值，而没有任何权威有足够的力量来强制分配稀有物品。在以打猎聚货的文化中，大家认为没有产权观念的想法下，这一点甚至也有。例如，在Kalahari沙漠的!Kung San布西曼族，并没有猎地的拥有权。但水洞或泉却有类同於Locke的产权存在。

　　!Kung San的范例是具有教育性的，因为它显示了Locke产权习俗适用的时机――当从该资源所能获取的回报大过於需要抵御的代价时。猎地并非产权，因为打猎所能获得的回报很难预测而可变的，而且并非每日生存的必须品。水洞，另一方面来说，对生存来说非常重要，并且小到足够抵御。

　　在本文标题中，"智域（noosphere）"是所有思想的领土，所有可能想法的空间[N]。我们在玩家拥有权习俗中看见了Locke产权理论在智域次集合――所有程式的空间――上的暗示。即此"开拓智域"，正如所有新的开放原始码计划的建立者所做的事一般。

　　Fare Rideau <rideau@ens.fr> 正确地指出玩家们并不是在单纯的思想领土中运作。他断定玩家们所拥有的是程式计划――有目标地专注在物质劳力上（开发，服务，等等），而与名望，信赖度等等连上关系。他因此断定由玩家计划所延展的空间，并非智域，而是一种双重的智域性质，由智域计划拓展的空间。（有位天体物理学家在此同意，在词语学上，正确地可称这个重复的空间为"ergosphere"或"工作的领域"。）

　　在实际上，智域及工域的分别在本文目地中并不重要。在纯净的思想中，"智域"要存在实在也很难；大概要有柏拉图式的哲学家才会相信了。而将智域及工域分开，也只有在某人希望断定想法（智域的元素）不能被拥有，但如计划之类的可以被拥有的时候，才会有实际作用。这个问题导致一个智慧财产权理论的问题，远远超过本文探讨的范围。

　　为了避免困惑，要注意到智域或工域跟整个虚拟的电子媒体被称为"cyberspace"（大部份玩家伪装的地方）是绝不相同的。产权规范法则在此是完全不同於物质阶层的――基本上，拥有媒体或机器属於"cyberspace"便拥有"cyberspace"的一部份。

　　Locke的结构强烈建议开放原始码玩家观察这些所为的习俗以持有对付出的代价所得的回报。这些回报必然要比开拓计划所付出的更重要――花在维护"头衔传承"的版本历史上的代价，花在引起大众注意的时间代价，及等待领养孤儿计划的时间上。

　　再者，由开放原始码所获得的"成果"必然是远超过简单的使用软件，是一些会被分歧所连累或稀释的其它东西。如果就是使用软件这麽简单，应该不会有对分歧的禁条存在，而开放原始码拥有权不会像土地产权一样的类同。事实上，这样的世界确实（即使用为唯一成果）在现有开放原始码版权中存在。

　　我们可以现在就将一些可能的成果候选者扫除。因为您不能够强制网路连线，找寻在那里的存在的力量。同样地，开放原始码文化不能构有任何像钱或内部稀有经济的类同品，因此玩家不能够追求与物质富裕相关的任何事物。

　　在开放原始码活动中，有个方法可以协助人们变得更富裕。偶而，某人在玩家文化中所获得的名望可在现实生活中获得经济上的重大好处。它可以使您获的更好的职业收入，或者顾问合约，或者书约。

　　这样的副作用对大多数玩家来说是很少见的；这可独立做为一个解释，既使我们经常见到玩家们抗议说，他们所为是出发於理想或爱，而不是为了钱。

　　不论如何，调停这样的经济副作用很值得加以检验。以下我们会看到了解在开放原始码文化自身的名望动力，很可以自我解释。

6. 玩家文化即礼物经济

　　要了解名望在开放原始码文化中的角色，我们需要从历史移到进一步的人类学及经济，并检验交换文化及礼物文化之间的不同。

　　人类对社会地位的竞争有天生的驱动力；它与我们的演化史息息相关。在农业发展之前，90%的历史，我们的祖先生活在游牧打猎的生活形态中。地位高个体获取较建康的伴侣并取用最好的食物。这个透过地位来表达自我的驱力表现在多方面，大致上是由於生存货物的缺乏所致。

　　大部份方式中，人类采行组织的方式来获取稀有货品及所需。每种方式都有其获取社会地位的方式。

　　最简单的是命令阶层。在命令阶层中，稀有品的分配是由中心权威来完成，并以武力做为後盾。命令阶层所达程度很有限[Mal]；他们在组织成长时变得越来越兽性而无效率。基於这个理由，在大家族中的命令阶层往往在不同大型经济形态中变成寄生虫。在命令阶层中，社会地位主要是透过取得高压力量来达到。

　　占我们社会主导地位的是交换经济。这是对稀有品的复杂采用形式，不像命令阶层模式，它成就很高。稀有品的分配是透过分散的交易及志愿合作（事实上，竞争野心是产生合作行为的主要效应）。在交换经济中，社会地位主要是透过控制用以交易的东西来决定（不一定需要是物质的）。

　　大多数人在精神上都有受到以上两种模式的影响，并决定如何与他人互动。政府，军队，及组织罪犯（举例而言）皆为在我们称为"自由市场"的广泛交换经济下的命令阶层寄生虫。不过，其实还有第三种模式，在根本上完全与两者不同，而且除了人类学家以外，一般人并不知晓；即礼物文化。

　　礼物文化不是因为稀有而采用而是丰富才采用。它们是在没有物质稀有问题，而生存必须品丰富的族群中掘起。我们可以观察到礼物文化在气候温和及食物丰足的原始生态系中发展。我们可以看见他们是在我们社会阶层中的确定地位，特别是那些商业中富裕的族群。

　　丰富使得命令关系结构变得很难维系，而交换关系则变程式无意义的游戏。在礼物文化中，社会地位不是由您能控制多少而决定，而是由您给出多少来决定。

　　因此这是瓜基乌图酋长的冬季赠礼舞会。这是百万富翁精心的大众慈善行为。这是玩家长时间付出的生产高品质开放原始码。

　　透过这样的检验，开放原始码玩家社会很明显地是个礼物文化。在其中，没有严重的"生存必须品"的短缺――硬碟空间，网路频宽，电脑速度。软件是免费地分享的。这样的丰富产生一种状况，即唯一的竞争是同跻间的名望。

　　不过，这样的观察并不足以完全解释整个玩家文化的特性。cracker d00dz也有相同於礼物文化的特质，但他们的行为是大不相同的。其族群文化的智力在玩家中算是很强及独有的。他们聚集秘密，而非分享；一个人需要投靠某个cracker组织来获取破解的软件，而非取得如何破解的技巧。

　　（译注: 很多人认为Hacker及Cracker之间没有明显的界线。但实际上，这是错误的观点。Hacker及Cracker不但可以很容易的分开，而且可以分出第三群――"海盗"Internet Pirate出来，一般大众认定的"破坏份子"，事实上是这第三种。Hacker及Cracker都有明确的定义，要发表有关Hacker及 Cracker之间的评议之前，最好要详细调查一番，否则招惹这两群技术高明的族群都不是好受的事。比较容易判断的方式，"Hacker从来不自称 Hacker；Cracker会自称Cracker；自称Hacker的不是Hacker；自称Cracker的不见得是Cracker；被确认为 Hacker称为Hacker的，是Hacker；而Richard M。Stallman是Hacker圣者"。相信大家应该可以看出来，为何大众对Hacker及Cracker会有错误观点的由来，Pirate利用这样的漏洞来污染整个玩家文化在大众的观点。）

　　在此所展示的，看来不是很明显，是礼物文化运作方式不只是一种。历史及价值是很重要的。我已经将整个玩家文化做了大体的摘要[HH]；现有行为状态并非神秘的。玩家透过选择他们竞争的形式来定义他们的文化。而本文的接下来的部份将会检验这些形式。

7. 驾御之乐无穷

　　在做这个"名望游戏"分析的同时，顺便说一下，我并非有意诋毁或忽略单纯的设计美妙软件并使其工作的艺术上的满足。我们都经历过这样的满足并爱上它。这些重大动机，对那些并非是那麽执著的人们来说，从一开始就不会成为玩家，正如不爱音乐的人不会成为作曲家一样。因此，我们应该要考虑到另一种玩家行为模式，即以技艺为单纯的主要动机。这个"技艺"模式应可解释玩家传统在技艺的机会上及结果的品质上的最大效果。这是否建议与"名望游戏"模式相冲突或不同的结果呢？

　　（译注: 在电脑科学中，有个很大的争议，即"软件设计是艺术"及"软件设计是工业"的争执。最著名的"软件艺术家"可说是Knuth这位大师。我们在此所见到的，便是"软件艺术"。"软件工业"在电脑科学上，可由软件工程来代表。）

　　不见得。在检视"技艺"模式中，我们回到同样的问题上，玩家圈子运作像礼物文化。如果品质没有尺度来衡量，要如何将品质最佳化呢？如果稀有品经济不运作，除了同跻评估外有什麽度量呢？这显示出任何技艺文化最终要架构在名望游戏中――而事实上，我们观察到正是这个动力，在中世纪同业公会中，推动许多历史上的技艺文化。

　　从一个重要的观点来看，"技艺"模式比起"礼物文化"来得弱；其自身，并没有帮助我们解释在本文开始所说的矛盾。

　　最後，"技艺"动机本身可能如我们所假设的，在心理上不会离名望游戏太远。想想看您美妙的程式被锁在抽屉中，而不再被使用。现在想像它被许多人很满意的有效使用。那一个梦想比较满足您呢？

　　不过，我们将会注意这个技匠模式。它直觉地揭露了许多玩家，并相当完美地解释了许多的个体的行为。

　　在我发表了本文的第一个版本後，许多匿名的回响者建议："您没办法用获取名望的动机来工作，不过名望是当您把工作做好，而获取的真实回报。" 这是个微妙而重要的观点。名望诱因可继续运作，不论工匠是否关心到它们；因此，最终，不管玩家是否了解其自身的行为是名望游戏的一部份，他的行为都会被这个游戏所修饰。

8. 名望的多面性

　　在每个礼物文化中，有许多理由表明同跻名望是值得付出的：

　　第一，最明显的，同跻之间的好名望是基本的回报。我们是为此而活，这是个我们在前面已触及的革命性动力。（许多人试著将驱策他们的动力，由名望换成其它升华的形式，而与同跻之间没有明显的关连，诸如``荣耀，``建全伦理，``信仰等等。；这些并没有改变其中的机制。）

　　其次，名望是（在单纯的礼物经济中，是唯一的方法）吸引注意力及与他人合作的好办法。如果一个人有雅量，智慧，公平处置，领导能力，及其它的好品德，这将会非常有力地说服其他人来一起共同合作。

　　第三，如果您的礼物经济与交换经济或命令结构纠缠关联，您的名望将会溢满并使您获得更高的地位。

　　在这些一般理由之外，玩家文化独特的状况造成名望比"真实世界"礼物文化更有价值。

　　主要的"特例"是某人送出的手工艺品（或者，换另一种方式来解译，是明显地看得出是一个人下足精力及时间所制的礼物）是非常复杂的。其价值很明显地跟物质礼物或交换经济金钱完全不同的。要客观地区别出好礼物及坏礼物是更加困难的。所以，赠与者企图的成功是微妙地由同跻间的风评来决定。

　　另一种特质是相对纯正的开放原始码文化。大部份礼物文化是由这些元素所组成的――由交换经济关系，诸如交换奢侈品，或是由命令经济关系，诸如家族或部落族群。在开放原始码文化中，并没有类同的方式存在；因而，除了透过争取同跻名望之外别无它法。

9. 拥有权及名望诱因

　　我们现在准备将之前的分析放在一起，成为一个连续而完整的玩家拥有权传统。我们了解到这是由进驻智域而来的；它是在玩家礼物文化中的同辈名望，及其所附带的副作用。由此这样的了解，我们可以分析Locke在玩家圈子的产权习俗，是一种名望诱因的最大化；这可确保同跻名望可由该获得的人取得，而不会漏到其它地方去。

　　我们以上所观察到的三个禁条，在这个分析下，就很有点道理了。在某些状况下，有些人胡搞，有些人的名望会遭到不公平的处理；这些禁条（及相关习俗）试图避免以下这些发生。

　　分歧计划是不好的，因为它将过去的贡献者置於牺牲名望的危险中，而他们只好在分歧後，继续在两个案子中都活动。（一般来说这会变得很混乱而且难以实践。）发行一个游离修补版会使拥有者受到不公平的名望危机。就算正式版是完美的，拥有者也会被这些游离版中的臭虫发出的高射炮射中（但请见 [RP]）。偷偷摸摸地将某人的名字将计划中移除，在文化条文中，是大恶不赦的事。他偷取受害者的礼物并且变成小偷的礼物。这三项禁条的违反者伤害整个开放原始码团体及受害者本身。这还迁连他们会伤害到整个团体，导致降低潜在贡献者对礼物/产品会收到回报感受的可能性。很重要的对其他两个禁条有其它可能的解释。

　　第一，玩家会对分歧计划表示厌恶，并且悲叹重复的工作，在未来，需要在所有几个子计划中付出代价。他们也会观察到分歧会将共同开发者团体分开，导致两个子计划有较少於原有计划的智群在工作。

　　有位回响者指出，在分歧的工作中，很少有见到能够有多於一个分歧能够存活，并且在长期享有"市场占有率"。这加强了所有参与者参与的诱因，互相合作并避免分歧，因为很难事先知道，谁将会站在输的一边，而看到他们辛苦的工作不是整个消失就是逐渐漠落。

　　不喜欢游离修补通常可被解释为造成错误追踪的复杂度增高，而且会造成维护者增加他们的工作量，而他们自己通常就已经有很多自己需要做的事了。

　　这些解释都可以考虑为正确的，而他们确实在Locke逻辑下的拥有权理论下行得通。但同时理性吸引力，他们无法解释为何当这些偶而发生的违反禁条事件，会导致如此在情绪及领土上的反感 -- 不只是在受伤的一方，而且旁观者及观察者也会反应严厉。冷血地关心工作量及维护量的重复并不足以解释这些观察者的行为。

　　对於第三个禁条。除了名望游戏的分析以外很难解释。事实上这项禁条很少被分析为"它不公平"的结论，则揭露的其本身的问题，而我们会在下一节看到。

10. 自我的问题

　　在本文的一开始，我提到了文化的潜意识适应知识通常是起源於其意识形态。一个很大的事实范例即Locke的拥有权传统被广泛地使用，虽然事实上，它们违反标准版权所陈述的条文。我在与玩家们讨论到名望游戏的分析时，观察到另一个有趣现象的范例。即许多玩家拒绝这个分析，并且强烈反对承认他们的行为是起源於渴望同跻名望的动机，或者我在此不太精确地标为"自我满足"。

　　这展现了玩家文化有趣的一面。很清悉的大家都不信任并鄙视自我中心及自我出发的动机；自我奖励被残酷的批评，既使该团体事实上对此可获取许多有利之处。很大一部份，事实上，该文化的"大大"及部族长者被要求要谦逊并幽默地自我贬低，以便维护自己的地位。这样的态度几乎使自尊呼之欲出用以编织解释整个诱因结构。

　　在大体下，可以确认的，这一般起源於欧裔美国人对"自我"的负面态度。整个玩家圈子都告诉自己，渴望自我满足是很坏的动机（至少是不成熟的）；自我只是对追求女性时的可容忍的怪僻，而且通常被认为是个精神病状。只有在升华的形式或伪装的形式如"同跻名望"，"自尊"，"内行气派"或"成就的自豪"才是可被接受的。

　　我可以写一整篇论文来讨论这个文化传承中的不良部份的根，我们可以发见，相信我们有真正的"无私"动机（违背心理学及行为的证据），将会造成自我迷惘的巨大伤害。或者我可以，如果Friedrich Wilhelm Nietzsche及Ayn Rand没有已经将整个解构"利他主义"成为许多不同的个别兴趣的工作完成。

　　我并非在此做道德哲学或是心理学，因此我在此仅观察一个以认为自我是邪恶的观点所造成的一些伤害，就是：它在情绪上造成许多玩家很难以清析地了解自己文化的社会动力！

　　但我们并没有在此线调查中完成。在玩家文化中对於自我出发的行为的禁忌是如此的深，玩家要怀疑是否该采用其它的可行方式。当然了这样的禁条在其它礼物文化中并没有这麽强，像剧场或巨富之间的同跻名望！

11. 人性的价值

　　在建立了名望是玩家文化回馈机制的中心之後，我们现在需要了解为何它看来如此的重要，然而确依然是半隐密地并且不受承认。对比的是海盗文化的指令式。在那个文化，追求地位的行为是露骨的甚或炫耀的。这些crackers追求宣称释放"zero-day warez"（在原版软件释放的当天破解该软件并再发行）但却对如何做到的闭口不提。这些魔术师并不喜欢把密技公开。因此，这导致了cracker文化的知识库在整体上进步缓慢。

　　（译注: 社会大众及Eric S Raymond对骇客文化有所误解，在整体知识库的发展上，骇客文化透过结帮来进化，因此骇客文化有点像帮派文化。其整体知识库的发展上，步调并不慢。）

　　在玩家团体中，对比来说，一个人的工作代表一个人的表达方式。这是非常严格的英才制度（最好的工匠胜利）而且有很强的意识，即品质会说话。最大的吹牛就是程式"能跑"，而任何有能力的程式设计师会看到的是好东西。因此，玩家文化的知识库增加快速。

　　对抗自大驱使的装模作样的禁条导致增加生产力。但那是个次级效应；在此受到保护的是该团体同跻评估系统的资讯品质。即，自吹自擂或自我放大是被镇压的，因为在创造及合作的行为者中，它就像杂音一样搞乱实验室中的美妙。

　　玩家文化传播礼物的媒介是无形的，其通讯频道很难表现情绪的细微差别，而面对面的成员接触是唯一的例外。这使得该文化比其它礼物文化对杂音有更低的容忍力，而需要花不少时间来解释大众谦逊需要部族长者。

　　谈吐谦逊对一个有志成为成功计划维护者的人也是有用；他必须要使该团体相信他有很好的判断能力，因为一个维护者的大部份工作是判断其他人的工作。谁愿意贡献给那些无法判断其工作品质的人呢，或者谁愿意贡献给那些会吞食计划成果的人呢？潜在的贡献者希望计划领导者有足够的谦逊及品味，当客观时机到来时，有能力说，"对，这比我的版本工作来得好，我会用它"――并且将成就让该收到的人收取。

　　另一个在开放原始码世界需要谦逊行为的理由，您很少希望给大众认为计划已经"完成"的映象。这可能会导致潜在的贡献者觉得不须要贡献。要将您的工作成效最大化，需要对您程式的状态谦逊。如果您吹牛自己的程式，然後说"没什么价值，它对x，y，及z无效，因此它并不好"，然後很快的自己偷偷补上 x，y，及z。

　　最後，我自己亲眼见到有些玩家领导者自鄙的行为反映了害怕成为崇拜的教首。Linus Torvalds及Larry Wall两者的行为都很明显地想要避免成为这样的对象。有一次跟Larry Wall一起吃晚餐，我开玩笑"您是在场的头号玩家――您选餐厅"。他畏缩了。这样做是对的；无法分辨他们领导的分享价值会搞砸一个很好的团体，这是个他及Linus都无法忽略的一点。另一方面来说，大部份玩家喜欢有Larry的问题，如果他们有办法自我承认这一点。

12. 名望游戏模型对整体的密切关系

　　名望游戏的分析有些不是很明显的其它关连。许多都是从建立一个成功的计划可获得比与现有计划合作获得更大的名望而来。一个计划如果有许多创新，也会获得许多的名望，相反於"me，too"的对现有计划的持续改善。另一方面来说，只有作者了解的软件或是需要非入门者的，在名望游戏中，通常贡献一个现有计划比自己建立一个来得受人注目。最後，要与现有成功的计划相竞争比填补一个空缺的壁灶来的困难的多。因此，有个与邻居的最佳距离（类同计划间的竞争）。太接近就会有其中一个产品会变成"me，too！"的有线价值，一个贫乏的礼物（其中一个可能最好放弃）。离得太远，没有人有能力使用，了解，或察觉到另一位的付出的关系（同样，贫乏的礼物）。这产生一个在进驻智域中的型态，如拓荒者散播在实体边疆上――并非散乱的，但很像是散乱的碎形波。计划倾向开始於在边疆的范围填补空缺。

　　有些非常成功的计划变成"目录杀手"；没有人愿意再去与那些已经建立起来的计划竞争，因为对玩家来说实在太难。大家最多是发现自己所须，而在这些成功的计划中，新增附加功能。典型的"目录杀手"范例是GNU Emacs；由1980年代开始，它的多样化功能就已经填补整个程式设计编辑器的目录生态系，没有人再去试图写一个新的出来。因而，人们只写Emacs modes。

　　整体来说，这两种倾向（缝隙填补及目录杀手）在时序上的发展可用来预测未来的倾向。在1970年代，大部份开放原始码都是玩具或范例。在 1980年代，则是在开发工具及网际网路工具。在1990年代，这项行动移向作业系统。在每个案例中，当前一个问题接近被处理掉时，一个新而更加复杂的问题层次被开始攻下。

　　这种倾向在不远的未来有点有趣的关连。在1998早期，Linux看来很像是"开放原始码作业系统"目录的杀手――所有为其它竞争的作业系统，现在都已经开始为Linux device drivers及extensions写作。而大部份这个文化所想要的开放原始码的低阶的工具都已经存在了。还有什么吗？

　　应用软件。当2000年接近，看来预测开放原始码发展的能力会逐步迈向最後的处女地带――为非技术人员所设计的程式――是不过份的。稍早的指标是GIMP的发展，类似于Photoshop的影像处理软件，这是个开放原始码第一个主要对end-user-friendly GUI的界面软件，并可被考虑为在过去十年中足勘与商业软件相比的应用软件。另一种则为流言四传的应用软件工具KDE及GNOME。

　　最後，名望游戏分析解释了屡次引用的格言，即您无法用自称玩家来变成玩家――当其它玩家称您为玩家时，您才是玩家。"玩家"，以这种观点来考量，是某人显示出了（透过贡献礼物）他或她有技术能力及了解名望游戏的运作。这样的评断大半是一种知觉及传承，并且只有身在文化中之辈才会意会。

13. 智域特质及领土於动物行为学的影响

　　了解产权习俗的结果会帮助我们从另一个角度来看它；即动物行为学，特别是领土动物行为学。

　　产权是一种动物领土观念的抽象化，是演化来用以降低同物种之间暴力发生。透过划出界线，并尊重其他的界线，一匹狼如果与其它发生战斗，可能会导致它受伤或致死，并降低生存繁演的机会。

　　类同的，在人类社会中的产权功能是避免人际间的冲突，透过设立疆域清楚地分别合平的行为及侵略的行为。有时大家喜欢将人类产权看成是个抽象的社会传统，但这完全是错的。任何人有苹狗就会知道，当狗对陌生人接近时的吠叫，是一种介於动物领土及人类产权之间的连续性。我们本地的狼兄地就本能地比许多人类政治理论家知道的更清楚。

　　宣告领土（就像制造领土）是个表示实现愿望的行为，一种表示在什麽样的界线下将会防御。社会支持产权宣告是一种减少阻力及促进合作的行为。这些比栏杆或狗吠更抽象的"宣告产权"依然是有效的，甚至既使它只是在README档案中简单的描述计划维护者的名字，也是有效的。它依然是个抽象的领土，而且（就像其它的产权形式）我们本能式的产权模式是由领土演化而用来解决冲突解决。

　　这个动物行为学分析，第一眼看来很抽象，很难以跟真正玩家的行为关连起来。但它有一些重要的结果。其中之一解释了全球资讯网的大众化，特别是解释了为何开放原始码计划有个公开网站看来会比没有网站的来得重要。

　　客观地想，这看来很难解释。与原来在原创及维护上所付出的力量来说，一个网页很简单，因此很难想像一篇网页是个重要或非凡的付出。

　　网站的本身功能并不足以解释一切。网页的通讯功能可以混合FTP站，mailing list，及Usenet。事实上一个计划的平日通讯很少是完全透过网站来通讯的，反而mailing list或newsgroup更重要。那麽，为什麽公开网站会变成是计划的中心呢？

　　"主页"这个隐喻提供了一个重要的线索。当在建立开放原始码计划时，它是个在智域中宣告领土的行为（而传统也认知为此），它在心理层次上并非十足强制的。毕竟，软件并没有位置的本质，而且可以立即复制的。它在我们本能的"领土"及"产权"记号上是可同化的，不过，要在付出一点代价后。

　　一个计划的网页表现了抽象的进驻可能的计划领域空间，透过全球资讯网表达其王国的"本土"领域。从智域降到"cyberspace"并没有让我们通过真实世界的栏干及狗吠，但它确实保障我们宣告产权的力量，并使我们对领土更加感到安全。而这也是有网页的计划看起来更加地"真实"。

　　这个动物行为学的分析，也鼓励我们更加详细的检验，在开放原始码文化中，这个处理冲突的机制。他带领我们预期，除了将名望诱因最大化以外，拥有权传统将会在避免冲突及解决冲突上扮演一个角色。

14. 冲突的起因

　　在开放原始码软件的冲突大致有以下主要议题：　　　　由谁来做下计划的决策？　　　　由谁来接受荣耀或谴责，承受什麽样的？　　　　要如何减低负担，特别是在复杂的错误追踪中避免劣质版本？　　　　技术上来说，什麽是正确的事？

　　如果我们看看"什麽是正确的事"议题第二眼，它将应该要消失掉。对任何这样的问题，要看是否有个客观的方式来让大家都接受。如果有，那游戏结束大夥都赢。如果没有，那麽就变成"谁来决定？"。所以，这三个问题的冲突解决理论将可解决一个计划的三大问题：（A）决定设计时的闲扯要何时而止，（B）要如何决定那些贡献者接受荣耀及如何授与，及（C）如何保持一个团队不会变成多重分歧。

　　拥有权的角色在解决（A）及（C）的问题上是很清楚的。惯例确保计划拥有者可做下决策。我们在以前曾见过，惯例会对分歧者施加压力并稀释其拥有权价值。

　　注意这些惯例是合理的，甚至对某些不关心名望游戏的人来说都很有帮助。我们可从检验纯正的"工匠"模型的玩家文化来看出。在此观点下，这些惯例很少与稀释名望诱因有关，而比较保护工匠在选择眼光上的权益。

　　技匠模型并不足以解释关於（B）的玩家惯例，谁做了什麽而接受什麽荣耀（因为对一个纯正的工匠来说，并不关心名望游戏，因此没有其它动机可循）。要分析这一点，我们需要将Locke理论带到另一个新高点，并检验冲突及运作的权力在计画中及计划之间。

15. 计划结构及拥有权

　　一般的个案来说是一个计划有一个单一个拥有者/维护者。在这种状况下没有可能会有冲突。拥有者可做下所有的决定，拥有所有的益处，及受到所有的谴责。唯一会冲突的问题可能是继承者――当旧的拥有者失去兴趣或不见了，由谁来当新的拥有者。该团体亦对避免分歧很感兴趣。这些兴趣都由文化规范所表达，即当一个拥有者/维护者对该计划不再有兴趣，应该公开地将名衔交给下一位。

　　非一般的最简单的例子，是许多位共同维护者在一位"仁慈的独裁者"下工作。在共同计划中习惯於这个模式；我们在大计划像Linux kernel或Emacs中看到，及解决"由谁来决定"的问题，这看起来不会比其它的方式来得糟糕。

　　典型来说，一个仁慈的独裁者组织由一个拥有者-维护者组织，建立者吸引贡献者演化而来。即使拥有者依然在位，它也有计划部份的功劳由谁来获取的争执存在。

　　在这种状况下，习俗有义务由拥有者/独裁者来公平地处理贡献者的贡献（例如透过在README或历史档中提及）。在Locke的产权模型术语来说，这意味透过贡献一个计划来获取部份的名望（正面或负面的）。

　　追朔这个逻辑，我们见到"仁慈的领导者"并非真正拥有整个计划。虽然他有权力做下决策，他事实上是透过交易名望来交换其他人的工作。这类比就像佃农耕种，是很难抗拒的，除了有时候当某个贡献者不再活动，他的名字依然继续获得好处。

　　一个仁慈的独裁者计划加上许多参与者，他们倾向於发展出两族贡献者：一般贡献者及共同发展者。一个典型的途径，变成共同开发者，可获得计划较大部份的责任。另一种是以"lord high fixer"的角色，专长在修正许多臭虫。以这种方式或其它种类的，共同开发者在整个计划中，是那些以透过投资时间并有重大贡献的贡献者。

　　次系统拥有者角色在我们的分析中特别重要并且要求更进一步的检验。玩家喜欢说"权威要负责"。接受维护责任的共同作者可获得一个次系统的掌控权及所有相关部份的计划，只受到计划领导者的修正（可说是建筑师）。我们观察到这项法则有效地圈起Locke模型的计划产权，并且同样地有其它产权界线避免冲突的效用。

　　传统上，"独裁者"或计划中的领导者及共同作者，是预期要与共同作者在关键决定上做协商。特别是该决定与共同作者所拥有的次系统有关（也就是说，有投资时间并负责任）。一个有智慧的领导者，认识出计划内部产权界线的作用，是不会轻率地影响或反转由次系统拥有者的决定。

　　有些很大的计划完全不吃"仁慈的独裁者"这一套。一个方法是转共同作者成为投票委员（像Apache）。另一种为轮换独裁者，即控制权由一位成员轮换到另一位资深成员（为Perl组织所采用）。

　　这样复杂的安排通常被考虑为不太稳定及复杂。很明显地这些困难的认知，为这些委员及设计者本身所了解；这些问题是玩家文化中，大家清悉地了解的。不论如何，我认为有些玩家对委员会或轮换独裁者组织心中不舒服，因为它与过去Locke模型的思考大不相同。在这些复杂的组织中，不论是做拥有权或是名望回报的计算是有问题的。很难看出其内部界线在那里，除非高度的协调及信任，否则很难避免冲突。

16. 冲突与冲突解决

　　我们曾经见过在计划中，角色复杂度的增加是由设计权威及部份产权的分布来表现。这是个有效的方式来分散诱因，同时也稀释了计划领导者的权威性 ――更重要地，它稀释了领导对潜在冲突镇压的权威性。当设计上的技术争执看来会导致互相残杀的冲突时，它们很少是起因於吵架的。这些通常都是由个别的领域的权威来负责解决。

　　另一种解决冲突的方式是"资深"――如果两个贡献者或贡献群有所争执，而争执无法客观地解决，并且都不拥有该争执的领域，曾经为这个计划付出较多的一方胜利（即在计划中，拥有较多产权的一方胜利）。

　　这些法则通常都足以解决大部份计划的争议。当这些不生效时，计划领导者的命令通常可解决。争议在通过这两关之後还存在的很罕见。

　　冲突除非在两个关键上都指向不同的方向的时候（"当权者要负责"及"长者胜利"）是不会变得严重的，而计划领导者的权威是很微弱或不发生作用的。这种状况最明显地是在继承权争执时，而领导者不在时。我曾见过这样的战斗一次。非常地丑陋，痛苦，折磨，只有当所有参与者都变得精疲力竭时，将它交给外人来处理，我锺心地期望不要再看见任何这一类的争执。

　　最终，当所有冲突解决机制，在所有玩家社团中都失效时。唯一剩下的机制只剩吵架及躲避――对那些拒绝合作，破坏传统的人们的公众审判。

17. 薪传机制及与学界的关联

　　在这篇文章的先前版本曾提出一个研究问题：这个团体究竟是如何告知并指导成员符合习俗？这些习俗是否是在半知觉状态下，不言自明的或自我组织起来的？是否是由范例所导引的？是否由明白的教条所授？

　　由教条所授明显的很罕见，因为至今为止只有少数几条该文化的规范曾经有人提出过。

　　大部份的规范都是由范例所导引的。用个很简单的例子，在所有软件发行中的规范中，应该都会有个README或READ.ME档案，用以说明这个软件的简略说明。这个传统至少从1980年早期就已经建立起来了，但至今尚未有人将本条写下。这是由观察许多软件发行而来的。

　　另一方面，有些玩家习俗是自我组织起来的，尤其是一旦有其中的份子了解到这个基本的（或者不自觉地）名望游戏。大部份玩家不需要被传授以我在第三节所列的三个禁忌，或者可说这些是不言自明的。这个现象导出更进一步的分析――而我们可能可以在探讨玩家在探索该文化智库的过程中找到解释。

　　大部份文化透过暗示（更精确一点"神秘"，透过宗教式或神秘性的方法）做为薪传机制。这些秘密对外来者是不揭露的，但可预期到可被热诚的新手所发现或理解。要被内部所接受，他需要展示他对该文化的神秘的了解及学习程度，以接受认可。

　　玩家文化对此是不凡地警觉，并且大量使用这些暗示及测试。我们可在至少三种层次的过程运作中找到：

　　犹如密码式的神秘。拿个例子，在USENET新闻讨论群中有个alt.sysadmin.recovery有个很明显的秘密；您不可能在不知道之前就提出问题，而知道该秘密您才会被准许进入。其中的老手对揭露这个秘密有很严格的禁忌。对特定技术秘密的基本要求。一个人必须要在送出礼物之前先吸收大量的技术知识（例如，必须要至少了解一种主要的电脑语言）。这个隐藏线索由大处至小节都有作用，犹如做为品质过滤（诸如抽象思考力，坚持，及精神力量）的功能用以发挥该文化的力量。神秘社会内容。要与该文化迁连上关系必须要参加特定计划。每个计划都是活生生的玩家社会文化范例，即贡献者必须要调查并了解该团体的社会及技术以便能有效参与。（具体来说，一般的方式是透过阅读该计划的网页或邮件）透过这些计划团体，新手体验到有经验的老玩家的社会行为。在透过探索这些秘密的过程中，这位未来的玩家学到丰富的知识，而使得这些禁条及其它习俗不言自明。有些人可能会偶然议论玩家礼物文化结构是其中心秘密。一个人在掏心吐胆的展现其对名望游戏及其暗藏的习俗，禁忌及使用的了解之前，是不被考虑为受传承的。但这不重要；所有文化都对其未来的参与者有这样的要求。更进一步地说，玩家文化表明对其参与者没有野心――或者，至少，没有人因为我揭露这些而来跟我吵架！

　　有大量的人对本文回应指出玩家拥有权习俗看来十分接近（而且很可能直接源於）学术界的业务，特别是科学研究团体。研究团体有很类似的问题，特别是在开采潜在可能的思考领域，及展现非常类似的对问题可行的解决途径上，使用同跻检视及名望。

　　既然许多玩家曾经在学界打滚过（通常都是在大学时学会玩电脑），在了解过玩家文化後，将玩家文化与学界做会类比自然是不稀奇的。

　　玩家"礼物文化"有明显地与学界平行类同的特质。一旦研究员取得终身职，他不再需要担心生存问题（的确，终身职的观念可回溯至早期的礼物文化，即"自然哲学家"基本上是富裕的绅士，时间满满可奉献於研究上。）在生存的危机解除後，名望成了驱动的目标，也就是在期刊或媒体上，鼓励分享新点子及研究成果。这造成客观而正面的功能，因为科学研究，就如玩家文化一般，非常依赖"站在巨人的肩膀上"，而不需要一再地重新发现一些非常基本的原理。

　　有些人则进一步推论玩家文化只是研究团体风气的一种反射，而且已经几乎到达相当程度。这可能讲得过头了，因为玩家文化似乎不过是以高中学历的聪明人们所架构起来的！

　　这里还有一些有趣的可能性存在。我怀疑学界与玩家文化的类同型式，并不止是因为其起源类同，还因为它们所做的事，在自然法则及人类本能的连系之下，而演化出最理想的社会组织。历史的裁决似乎断定自由市场资本主义是整体来说对经济效益最佳的方式；或者，以类同的方式来说，名望游戏礼物文化是在生产（及检验）高品质创造力的工作上最佳的合作方式。

　　这一点如果是真的话，那就比学术兴趣更加有意义了。因为这提出了一点与教堂观与市集观中稍微不同的观点；即，最终，软件产品工业资本家模式的末日到来，而将被排出竞争，从资本主义开始产生大量的剩馀财富，而导致大量程式设计师生活下饥荒後的礼物文化下的那一刻开始。（译注：换言之，也就是大软件公司自掘坟场。任意垄断操纵软件市场的後果，造成软件设计师无法生存，引发大规模投向以名望为基础的礼物文化中的活动，增强了玩家文化的後盾。我们可以在科技史的发展上发现许多类同现象。）

18. 结论: 由文化到文化规范

　　我们已经检视了用以控制及规范开放原始码软件产权的习俗。我们已经见到这是如何揭露出在其下的权益特质及与Locke的土地产权理论的关系。我们已经将玩家文化与"礼物文化"关连起来，即参与者透过投入时间，精力，及创造力来竞争名望。我们已经检验过在文化中的有相关的冲突解决分析。

　　下一个合理的问题应该是"为何这些这麽重要？" 玩家们并无意识分析而发展出这些习俗，而且直到今日，下意识地遵守这些习俗。这些有意识地分析并没有立即明显地有任何的实用性――除非，或许，我们可以进一步推展这些描述成为处方，并演绎出一些改善这些习俗功能的方法。

　　在英式美国一般法传统下，在玩家文化及土地产权理论之间，我们已经发现一个相当合理的类比。历史上来说 [Miller]，欧洲种族文化发明了这个传统来解决他们的争执解决系统，即由未书写的，下意识的习俗系统到明白地由种族中智者所记下的惯例法规――然後最後白纸黑字写下。

　　或者，既然我们的人口逐步上扬，而对所有成员的薪传越来越困难，是为玩家文化做点类同的事的时候了――发展一套对解决各种争议的实用"程式码（written code）"，可增加在开放原始码计划的实力，及一套仲裁传统，即团体中的资深成员可做一些争执调解。

　　本文中的分析已经将这样的"程式码"大纲划出，将过去暗示性的变成明白书写的。不会出现在以上没有出现过的；他们需要由各计划的建立者或拥有者志愿采用。也不会完全地苛刻，因为在该文化的压力会随时间而改变。最後，要将这样的"程式"付诸实现，他们必须要反射出该玩家部落的广泛接受。

　　我已经开始进行这样的"程式码"，可能会叫做"Malvern Protocol"，以我所住的小镇名字来命名。如果在本文中的这些分析逐渐受到广泛接受，我会让大众都可取得Malvern Protocol，用以解决争执范例"程式"。有兴趣批评及发展这套"程式"的团体，或者希望提供一些他们的想法的，都很欢迎与我连络。

19. 对进一步研究的一些问题

　　该文化（也是我自己的文化）了解到，不跟著一位仁慈的独裁者的模式是脆弱的。这样的计划大多都失败了。有些则惊人地成功而重要（Perl， Apache，KDE）。没有人真正了解其中的差别在何处。（每个计划的生命力，与其参与者的组织动力生息相关，是个相当温和的观点，是否真得存在一个组织可重复实行无碍的策略呢？）

　　就观察到的事实而论，我们确实发现到，成功的计划，获取比需要相同工作量的除错及协助成功计划的工作来得更高的名望。这是否是个对相同付出的理性价值评断呢？或者它是个我们在此所演绎出来潜意识的领土模型所造成的次级效应？

20. 参考文档，附注，及感谢

[Miller] Miller, William Ian; Bloodtaking and Peacemaking: Feud, Law, and Society in Saga Iceland; University of Chicago Press 1990, ISBN 0-226-52680-1. A fascinating study of Icelandic folkmoot law, which both illuminates the ancestry of the Lockean theory of property and describes the later stages of a historical process by which custom passed into customary law and thence to written law.

[Mal] Malaclypse the Younger; Principia Discordia, or How I Found Goddess and What I Did To Her When I Found Her; Loompanics, ISBN 1-55950-040-9. Amidst much enlightening silliness, the `SNAFU principle' provides a rather trenchant analysis of why command hierarchies don't scale well. There's a browseable HTML version.

[BCT] J. Barkow, L. Cosmides, and J. Tooby (Eds.); The adapted mind: Evolutionary psychology and the generation of culture. New York: Oxford University Press 1992. An excellent introduction to evolutionary psychology. Some of the papers bear directly on the three cultural types I discuss (command/exchange/gift), suggesting that these patterns are wired into the human psyche fairly deep.

[MHG] Goldhaber, Michael K.; The Attention Economy and the Net. I discovered this paper after my version 1.7. It has obvious flaws (Goldhaber's argument for the inapplicability of economic reasoning to attention does not bear close examination), but Goldhaber nevertheless has funny and perceptive things to say about the role of attention-seeking in organizing behavior. The prestige or peer repute I have discussed can fruitfully be viewed as a particular case of attention in his sense.

[HH] I have summarized the history of hackerdom at http://www.tuxedo.org/~esr/faqs/hacker-hist.html. The book that will explain it really well remains to be written, probably not by me.

[N] The term `noosphere' is an obscure term of art in philosophy derived from the Greek `nous' meaning `mind', `spirit', or `breath'. It is pronounced KNOW-uh-sfeer (two o-sounds, one long and stressed, one short and unstressed tending towards schwa). If one is being excruciatingly correct about one's orthography, it is properly spelled with a diaresis over one `o' -- just don't ask me which one.

[RP] There are some subtleties about rogue patches. One can divide them into `friendly' and `unfriendly' types. A `friendly' patch is designed to be merged back into the project's main-line sources under the maintainer's control (whether or not that merge actually happens); an `unfriendly' one is intended to yank the project in a direction the maintainer doesn't approve. Some projects (notably the Linux kernel itself) are pretty relaxed about friendly patches and even encourage independent distribution of them as part of their beta-test phase. An unfriendly patch, on the other hand, represents a decision to compete with the original and is a serious matter. Maintaining a whole raft of unfriendly patches tends to lead to forking.

I am indebted to Michael Funk <mwfunk@uncc.campus.mci.net> for pointing out how instructive a contrast with hackers the pirate culture are. Robert Lanphier <robla@real.com> contributed much to the discussion of egoless behavior. Eric Kidd <eric.kidd@pobox.com> highlighted the role of valuing humility in preventing cults of personality. The section on global effects was inspired by comments from Daniel Burn <daniel@tsathoggua.lab.usyd.edu.au>. Mike Whitaker <mrw@entropic.co.uk> inspired the main thread in the section on acculturation.

取自"http://www.pgsqldb.org/mwiki/index.php/%E5%BC%80%E6%8B%93%E6%99%BA%E5%9F%9F"

第四章魔法大锅炉

前言 ――――――――――――――――

　　本文分析了正在不断发展的开放源代码现象的经济基础。我们首先推翻了一些流行的关于软件开发中投资和软件价格结构的神话，给出了一个关于开放源代码协作稳定性的游戏规则分析。我们给出了九种开放源代码开发的可发展模型，其中两种是不盈利的，七种是盈利的。接着我们发展了一种定性的理论，说明什么时候封闭代码在经济上是合理的。然后我们考察了当前市场上发明的几种新颖的开放源代码开发的盈利方法学，包括赞助系统和任务市场的引入。我们最后做出了结论，试着对将来做了一些预测。

[编辑] ==============

1. 近乎魔法 2. 超越高手的天赋 3. 制造业的错觉 4. "信息需要免费"的神话 5. 驳斥公用悲剧说 6. 封闭源码的原因 7. 使用价值集资模型 7.1 Apache案例：成本分担 7.2 Cisco案例：风险分散 8. 为何销售价值存在问题 9. 间接的销售价值模型 9.1 失败的领导者/市场定位者 9.2 糖霜策略 9.3 奉送食谱，开办饭店 9.4 衍生物 9.5 现在收费，未来免费 9.6 软件免费，卖标准 9.7 软件免费，卖内容 10. 何时开放，何时封闭 10.1 靠什么盈利？ 10.2 他们如何互相作用？ 10.3 Doom：一个学习的案例 10.4 知道何时该放手 11. 开放原代码的商业运作 12. 成功的复制 13. 开放研发和二次开发 14. 由此及彼 15. 结论：自由软件变革之后 16. 参考文献和致谢 17. 附录：为何封闭驱动程序损失卖主金钱 18. 本文档修订记录

1. 近乎魔法

　　在威尔士的神话中，Ceridwen女神有一口巨大的锅，当女神念动只有她自己知道的咒语时，那口锅就变出奇妙的食物。在现代科学中， Buckminster Fuller提出了一种"短暂化"的概念，认为在早期的物理资源投资越来越多的被信息内容所代替的情况下，技术会变得越来越有效和廉价。Arthur C. Clarke指出"任何足够高级的技术都与魔法别无二致"，从而把二者联系起来。对很多人来说，开放源代码社区的成功看来就象难以置信的魔法。高质量的软件变得免费，在充满竞争而且资源稀缺的现实世界，这似乎不能继续下去，但是它进行的还不错。要点在哪？Ceridwen的大锅只是一个小诡计吗？如果不是，在这种情况下，"短暂化"是怎么工作的――女神究竟念动了什么咒语？

2. 超越高手的才能

　　开放源代码文化的经验肯定使许多学习过软件开发的人们感到困惑。"大教堂和市集"一文描述了分散协作软件开发是怎样有效的推翻了Brooks 的定律，产生了使一个独立的工程具有空前可靠性和质量的开发方式。"开拓智域"一文揭示了市集模式开发风格中的社会动力学，这应该用人类学家所谓的"赠与文化"的术语而不是常规的交换经济术语来理解，在这种文化中，成员在做出贡献大小方面竞争。本文中我们将开始推翻一些流行的关于软件生产经济学的神话；然后对"大教堂和市集"和"开拓智域"两篇文章进行经济学、搏弈论和商业模型领域的分析，发展一种新的概念工具，来理解开放源代码开发者的赠与文化在交换经济里也可以继续下去的理由。

　　先不岔开话题，沿着上面的线索分析，我们需要抛弃（至少要暂时忽略）在"赠于文化"层次上的分析。"开拓智域"中赠于文化的存在是基于生存所需要的物质资料极大的丰富，以至于社会交换已经不很重要的环境里；这种分析虽然在纯粹的精神世界中非常有说服力，但针对现实生活中大多数开放源码开发者实际所处的综合经济环境来说，这种解释则显得有些无力。对许多人来说，社会交换仍然是他们努力工作的驱动力，但是已经渐渐失去了吸引力。必须在资源匮乏的经济学中为他们的行为找到足够的理由，才能使这些行为在物质资料丰富的赠于文化中得以立足。

　　因此，我们现在将（从整个资源匮乏经济学领域）思考维持开放源码开发的协作和交换模式。在分析的过程中，通过深入剖析和列举实例，我们同时也就回答了那个非常实际的问题："我如何通过开放源码来赚钱？"。不过，这个问题是根据与软件开发本质相悖的普遍软件开发经济模型而提出的，首先我们需要展示一下隐藏在这个问题之后的许多思维误区。

　　（在展开分析之前还有最后一个需要说明的是：本文中对开放源码开发模式的讨论和提倡，不能被理解为对封闭源码模式的彻底否定，也没有反对现有的软件知识产权体系，更不是对"共享"的无私呼吁。虽然开发源码开发团体中的一些人仍然热衷于这些讨论，但从"大教堂和市集"发表以来，经验已经清楚的表明这些争论没有必要的。重要的是开放源码的开发模式和经济效益能够制造出质量更好、可靠性更高、成本更低、可以选择的方案更多的好产品来。）

3. 制造业的错觉

　　我们需要注意的是计算机程序和其他类型的工具和资本货物一样，都有两种经济价值：使用价值和销售价值。

　　程序的使用价值就是它作为工具的经济价值；销售价值是它作为作为商品的价值。（用经济学的专业说法，销售价值是产品最终价值，使用价值是产品中间价值）

　　当大多数人说到软件产业时，总是按照拥有下列特性的"工厂模式"经济来分析：

　　1. 大多数开发者的劳动由销售价值的收入来支付　　2. 软件的销售价值与开发成本（例如，功能复制所需的资源花费）和使用价值成一定比例

　　换句话说，人们有很强的思维惯性去假定软件具有标准工业品的特性。但是这两个假设都错了。

　　首先，编写用于出售的代码只是编程行业的冰山一角。在微机世界前期，大家普遍认为世界上90%的代码在银行和保险公司内部编写。这虽然已经不再是事实――现在其他行业也越来越加大了软件开发的力度，金融行业所占的比例从而下降――但是短期内我们仍将会看到大约95%的代码是公司内部编写。

　　这些代码包括大多数为中等或大规模公司所定制的MIS，金融和数据库软件。包括象设备驱动这样的专业技术代码（几乎没有人靠卖设备驱动赚钱，这一点我们将会在后面讨论）；包括日益增长的数控机器的各种嵌入式代码――从机械工具和喷气客机、汽车、微波炉甚至烤面包炉。

　　大多数这种内部代码与其环境集成在一起，复制和再利用十分困难（不论环境是商业办公室的程序套件还是联合收割机的加油系统）。因而一旦环境变化，需要做许多工作使软件与之同步。

　　这种工作称为"维护"。任何软件工程师或系统分析员都会告诉你这就是程序员的大部分工资的来源（超过75%）。因此，大多数程序员工时花费在编写和维护更本不能卖的内部代码上（当然大多数程序员以此为生）――读者们也许乐意去查查报纸上的"诚聘信息"部分的编程工作列表检验一下。

　　我强烈的希望读者试试浏览本地报纸的招聘信息，看看编程，数据处理，和包含软件开发工作的软件工程项目等等。将这些工作按照其目的是使用还是销售进行分类，你将深受启发。

　　很明显，即使为"销售"定义了最大范围，20人中还是至少有19个由使用价值资助（作为产品中间价值）。这就是为什么我们认为软件工业中以销售价值驱动的部分只占5%原因。注意，本文中其他部分的分析并非完全倚赖于这个数；即使这个数字达到15%甚至20%，在经济上的推论结果仍然八九不离十。

　　（当我在技术讨论会上演讲时，我经常由讨论两个问题开始：听众为写软件付多少钱，和有多少薪水是依赖于软件的销售价值的。第一个问题应者甚众，而第二个问题则寥寥无几，大而且量的听众对这个问题十分诧异）

　　其次，经过对实际客户行为的调查，软件销售价值与其开发和升级成本相关的理论很容易被推翻。开发和升级成本相关的商品（对打折之前来说）占很大比例――食品，汽车，机械工具，甚至有许多无形的产品――例如，音乐、地图或数据库资料的复制权，这产品在生产者倒闭后仍然能保持甚至增加其销售价值。

　　与上述形成鲜明对比的是。当一个软件产品生产者歇业时（或者如果产品开发被终止），几乎没有客户愿意为其花钱，而不管它理论上的使用价值或同样功能产品的开发费用有多高。（要检验这个说法，去你附近的软件商店打折柜台看看吧：-））

　　在生产者失败时，零售商的行为很有启示。他们知道一些生产者不知道的东东。他们深知：客户愿意花费的价格在很大程度上由卖主未来可以提供的服务决定。（这里的"服务"被广义的理解为完善，升级和后续产品）

　　换句话说，软件主要是一个稳定的服务性行业，认为它是制造性行业是没有理由的错觉。

　　另外，检查一下我们为什么会有这些惯性思维也很有益处。它们也许来自于软件生产者大力宣传的销售类产品，这些是的软件业一小部分，也是宣传的唯一的一部分，大多数明显和重头的广告宣传的产品是昙花一现的短期产品，就像游戏，他们几乎不需要提供后续服务（合同规定的除外）。

　　另外，值得注意的是，制造业错觉所倡导的价格体系事实上会越过保持开发预算不崩溃的底线。既然（像一般认为地）超过典型软件产品周期花费的75%在维护，调试和扩展上，那么通常的那种只采用高额售价，极低相关服务费用的定价策略，只会导致各方面都差的服务。

　　用户的损失在于，即使软件是服务性行业，工厂模式促使生产者减低服务质量。如果生产者靠出卖比特挣钱，大量的努力是制造比特并将它们推销出门；帮助服务部分，因为不是利润的中心，将会成为只付出的一点点努力和资源，为了避免激怒用户所设的垃圾站。

　　另一方面是大多数生产者使用这种工厂模式会导致长远的失败。为满足无限的售后服务和技术支持需要的固定价格产品提供资金，只有在那些膨胀足够迅速的市场里――其过去的销售和未来的收入能够满足支持和生存周期的花费――才能存活。一旦市场成熟和销量下降，维持生计，大多数生产者除了消减单独产品的开支之外没有别的选择。

　　不管是直接（废止产品）还是间接（支持很差），都会把客户推给竞争对手（因为这些行为损害了依附于服务产品的期望值）。短期来看，可以通过将修正过bug的版本发布为新产品避免这个陷阱。而长远来看，避免陷阱的唯一可能是对行业进行有效的市场垄断。最终，只有唯一的幸存者。

　　事实上，我们一再的看到这种缺乏支持的模式害死一些市场环境中很强大的竞争者（这种模式对那些那些经历过计算机发展史幸存下来的人尤其深刻，包括个人操作系统，字处理，通用财务程序或商业软件）。这种不正确的动机来自于工厂模式导致的赢家通吃的态势，而且最后即使你是赢家的客户也会遭殃。

　　如果不是工厂模式，那又是什么？为了有效的控制软件生存周期真实的花费体系（同时在经济学和非正式场合的意义上的"有效"），我们需要一个建立于服务合同，合约，和买卖双方持续交易基础上的价格体系。所以，在以效益为目的的自由市场条件下，我们能管窥大多数成熟的软件工业最终遵循的价格体系。

　　为什么说开放源码软件的地位日益增长，不仅仅是技术，也是经济上对主流秩序的挑战？上述内容给我们一些启示。软件开发的"free"，会将我们推向以服务支配的世界，同时暴露出一直依赖销售封闭源码产品的方式有多脆弱。

　　"free"的概念很容易被误解为其他含义。降低产品花费会导致支撑软件业的整个基础投入增长，而不是降低。只有汽车的价格降低时，汽车的需求才会上升――这也是为什么在开放源码世界中，另外那5%的根据销售价值付酬的程序员不好受的原因。在free的变革中，有损失的不是程序员而是那些没看清形势而将赌注押在封闭源码策略上的投资者。

4. "信息应该免费"的神话

　　与工厂模式错觉相呼应的是，思考开放源码经济的人们还常常被另外一个神话搞糊涂。那就是"信息应该免费"。这常常以数字信息产品的复制边际成本几乎为零来解释，这个解释暗示了其价格似乎就应该为零。

　　其实你只要考虑一下诸如藏宝图，瑞士银行的账号口令，或计算机服务的确认口令，等等信息的价值，就很容易看破这个神话。即使这些确认信息可以不用任何花费的复制，但是被其确认的对象无法复制。也就是说，非零的边缘成本由被那些确认信息继承下来。

　　提到这个神话的主要目的是声明它与开放源码的经济价值的讨论无关；就象我们在后面将会看到的，即使假设软件是符合制造业产品（非零）价值结构，仍是如此。所以我们没必要钻软件是否应该免费的牛角尖。

5. 驳斥公用悲剧说

　　质疑主流模式，看看我们是否能建立另一种模式――对是支撑起开放源码协作的原因作出有力的经济学解释。

　　这个问题需要从两个不同的方面考查。一个方面是我们要解释那些为开放源码作出贡献的人士的个体行为；另一方面，我们需要理解那种支撑象Linux和Apache这样的开放源码项目的经济力量。

　　Hardin的著名寓言告诉我们：设想一个乡村农夫们拥有一片公用绿地。他们在那里放牧牲畜。但是放牧使公用性退化，撕裂草皮，留下泥泞，很难恢复。如果没有对分配放牧的权利达成协议（或约定）以防止过度放牧；所有牧主都还会赞成尽可能快的增加牲畜数量，以便在公共绿地变成泥潭之前榨取最大的利润。

　　大多数人使用象这样的直觉的合作模式。这事实上并不是对开放源码――他们是（供不应求的）自由骑士，而不是（被过度使用的）过剩的公共货物――经济问题的正确判断，不过，我在大多数未充分考虑的反对声后面都听到过类似的看法。

　　公共拥有的悲剧预言只会出现三种结果。一种是泥潭；一种是为了村民的利益，强制性的使用某种分配协定（共产主义的解决方案）；第三种是公用被打破，村民各筑藩篱，保护自己的一小块草地（私有制的解决方案）。

　　当人们本能的的将这种模式应用于开放源码合作时，因此预计它只有很不稳定的短暂的半衰期。因为没有明显的方法去强制在互联网上工作的程序员执行工作时间分配策略，这种模式就断言公用将会打破，结果是出现各种各样的封闭代码软件和反馈给公用的工作量迅速减少。

　　事实上，经验清楚的显示出了与之相反的趋势。开放源码开发的广度和深度（由Matalab和freshmeat.net的每日宣布的数据统计）在稳定增加。很明显，这些都得出"公用悲剧"模式无法描述事态的发展。

　　答案的一部分正是建立在软件使用并不降低其价值的事实基础之上。实际上，对开放源码软件来说，当用户被其修正和特性（代码补丁）把握之后，软件的广泛使用还会增加其价值。公用悲剧被颠覆了，越放牧，草长得越高。

　　答案的另一部分是基于很难收取那些为公用源码基础所作的小补丁的市场价值。假设我为一个恼人的bug写了个修正，而且有人认为这个修正值钱；我如何才能从那些人手里拿到钱？对于这种小额的，通常也是适当的付款，常规的付费体系如此昂贵竟成为真正的问题。

　　比起价钱不仅仅很难收取，也许如何定价还要难得多。让我们想一想，假设互联网上已经拥有理论上完美的小额付费系统――即安全，方便，又不需要更多手续费。而你写了个补丁叫做"Linux内核的某某修正"。你该要价多少？在潜在购买者还没看到补丁时，他们又该如何判断值不值得为它付费呢？

　　我们的问题就像F.A.Hayek的"计算问题"在哈哈镜中的变形――它就象个超市，即要估价补丁的功能值多少，又要相信定价是合理的以促进交易。

　　不幸的是，超市方式有一系列的不足，所以补丁的作者――打补丁的黑客有两种选择：躺在补丁上收钱，或免费扔出去。第一种选择将一无所获。第二种也可能如此，不过或者它会促使其他人提供互惠的给予，以解决上面那位黑客所头疼的问题。第二种明显无私的选择，在这种游戏情况中，竞然事实上是自私的。

　　在分析这种合作时，自由软件的开发所面临的问题会很重要（他们可能会工作在清贫，或没有足够的回报的情况下），这并不是由最终用户的数量决定的。开放源码项目的复杂性和沟通所带来的成本几乎完全和参与的开发者的数量成函数关系；拥有更多的几乎从不看源码的最终用户对此似乎没有任何益处。这只会增加在项目邮件列表中无聊问题出现频率，但是建立一个相关的常用问题列表，不理睬那些显然不读FAQ的人（事实上这已经是通用做法），可以很容易解决这个问题。

　　开放源码软件的真正最重要的自由软件开发问题是提交补丁功能时的磨合成本。可能的贡献者在声望上小有收获（见《开拓智域》一文），而没有金钱上的补偿，想着"根本不值得提交这个修订，因为我不得不打补丁，写修改记录，在FSF任务文件上署名..."。因为这个原因，拥有大量贡献者（其次才是成功）的项目很强壮。与之相反的是，每个有许多相互有制约关系的项目都需要有从始到终的贡献者。这种磨合成本就像政治一样呆板。总之，自由软件项目本身可以向你解释为何松散，无组织的Linux文化，比紧密组织且集中管理的BSD项目的努力，更能吸引合作能量的意向；以及为何自由软件基金会，也在Linux 崛起时重要性相对的减弱。

　　这条路不管走多远都是好的。但是，这只是在黑客写了补丁并公布了这个补丁后的事后诸葛式解释。我们需要的另一半答案是对为何JRH最初会写这个补丁，而不是为拥有销售回报的封闭源码程序工作。作出经济解释。到底什么商业模式创造了开放源码开发繁荣发展的环境呢？

6. 封闭源码的原因

　　在给开放源码经营模式分类之前，我们应该先大致地考虑一下封闭的代价。当我们封闭源码时，我们究竟在保护什么？

　　比方说你雇了某人来编写和组织一个（不妨说）为你的生意专用的结算软件，那么和开放源码比起来，封闭源码一点也不会有助于解决问题。如果你想封闭源码，唯一合理的理由就是你想把这个软件卖给别人，或者不让你的竞争者使用它。

　　比较明显的原因是你在保护销售价值，但是对95%的供内部使用的软件来说这没意义。那么封闭还有别的什么好处吗？

　　第二个原因（保持竞争优势）还有待检验。假如说你把那个结算软件开放源码了，它流行起来，并且从社会上得到了改进。现在，你的竞争者也开始使用它了，他没有花开发费用就得到了好处，而且影响了你的生意。这是不是一种反对开放源码的理由呢？

　　可能是――也可能不是。真正的问题在于你从分散开发负担中得到的好处是否多于由那些不劳而获的人带来的竞争损失。许多人倾向于为这类交易作苍白的辩解，方法是：（a）避而不谈从额外的开发帮助中得到的功能上的改进。（b）不认为开发费用是降低了，而是假定你无论如何也是要承担这些开发费用的，所以把它们作为开放源码（如果你这么选择的话）的代价是错误的。

　　还有别的许多封闭源码的根本就是荒谬的理由。举例说，你可能误以为封闭源码可以使你的商用系统更加安全，不容易被破解或闯入。如果是这样，我建议你立刻找一个密码专家来诊断一下你的系统。真正的猜疑心很重的人都知道不能相信封闭源码程序的安全性，因为这是他们是从惨痛的教训中学到的。安全性是可靠性的一个方面；只有那些被彻底检查过的算法和代码实现才可能被相信是安全的。

7.使用价值集资模型

　　使用价值与销售价值之间的差别让我们注意到的一个基本事实是只有销售价值本身受到了来自从封闭原码到开放原码这个转变的威胁；使用价值并没有。

　　如果使用价值，而不是交换价值，的确是软件发展的根本驱动力；而且开放原代码的发展的确是比原代码封闭要更加有影响力和更加有效率，那么我们应该期待着去寻找一种环境，在这种环境中光是使用价值已能够完全地促使开放原代码向前发展。

　　实际上，这样的几个环境模型并不难以找到。在这样的模型中，开放原代码的全职开发者的生存完全可以由（开放原代码的）使用价值来实现。

　　7.1 Aapache的个案：（价值分享）

　　假如你在为一个拥有高效性高可靠性网络服务器的商业公司服务。也许这个服务器是用来为电子商务服务的，也许是作为一个出售广告的高可视性的媒体输出装置，也许只是用来构建一个门户站点。你需要一天7小时的在线时间，你需要速度，还有规范性。

　　那么你该如何做呢？这里有些基本的策略可以供你参考：

　　购买一个私有的网络服务器，这样，你是在冒险相信卖方的宣传与你的需求是一致的，你在冒险相信卖方的技术竞争力能给提供完善的保障。即使假设这两个方面是有保障的，网络服务器本身也会由于缺乏规范的服务而出现问题。你只能通过卖方的经过挑选提供的几种工具来维护的你的服务器。这种购买私有的服务器的路子并非一个很大众化的方法！

　　自己做一个！做一个自己的网络服务器在目前还是不可忽略的一种调剂办法；网络服务器并不太复杂，当然比浏览器要简单。一个专门用途的网络服务器可以做得功能专一但很好用。走这条路的话，你能得到你所需要的各种特性和自己的规范，尽管在其升级的过程中你要付出很多。或许你的公司在你离开或退休后，还会发现这个服务器有了这样或那样的问题。

　　参加Apache小组！Apache服务器是有一个通过Internet交流的小组写出来的――小组成员都是系统管理员，他们相信比较明智的做法是将他们的能力集合起来去写，并提高一个单一方向的代码集而不是去花费时间各自同时写完全不相关的代码。这样做的结果是他们能够同时发挥"自己做一个"和大范围大规模测试代码的优势。

　　选择Apache小组的优势很明显。到底有多明显，可以根据Netcraft的每周回顾来判断一下。Netcraft上说Apache服务器从其诞生起一直在稳定地夺取其他私有服务器的市场份额。1999年6月，Apache的各种版本占有了61%的市场份额<http: //www.netcraft.com/survey>；――没有合法的拥有者，没有组织机构，也根本没有合同制约的组织形式在背后操纵。

　　总的说起来，Apache的故事提供了一个模式：软件使用者通过支持开放原代码计划而发现了这个模式，他们发现这样做能以最小的代价给他们带来越来越好的软件，比其他任何方法都要有效。

　　7.2 Cisco的个案：风险均摊

　　一些年以前，两个Cisco（网络产品制造厂家）的程序员被分配来写一个分布式的打印系统的程式代码用做Cisco的合作网络的应用。这个项目的挑战性很大。这个系统要使任意一个用户能在这个网络上的任意一台打印机上打印东西（而用户和打印机可能只是隔壁或者相隔几千公里），当打印机没有纸了或其他紧急情况系统要能够将任务导向另一台附近的打印机。系统还要能够将这一个突发时间报告给打印机管理员。

　　他们两个对Unix上的打印软件做了一些很不错的修改，加上一些包的原语言，就做成了那项工作，但接着问题就来了。

　　问题是两个程序员都不愿意在Cisco永远呆下去。结果两名程序员都将离开，而软件也会无人维护而"腐烂"（就是无法满足实际应用中不断变化的要求而失去其应用）。没有任何一个人愿意看到这样的情况在他自己或工作上发生，那两个程序员也认为他们已经做了Cisco公司要求他们做的事情，其他的问题已经不是他们的工作范围了。

　　于是他们跑到他们的经理那里要求将这个打印软件的源代码开放。他们认为这样的话Cisco不仅不会失去什么反而会得到更多。通过协作鼓励用户和软件开发合作者的组织的发展，Cisco能够弥补因为软件原创人员的离开所带来的损失。

　　Cisco的故事引出另一个模式：源代码开放使开发一个软件的风险被众多协作者分摊了而且投资分花费很小。所有的团体都发现原代码的开放，以及一个成员各自独立却互相协作的社区的存在将提供一个无风险的开发环境，而且这个环境是有商业价值的――它能够自己赚钱养活自己！

8. 为何销售价值存在问题

　　开放源码使得直接获取软件销售利润非常困难。困难并不是来自技术方面的，因为源代码和可执行代码一样易于拷贝，并且版权法和许可证法的约束不同使得通过开放源码软件来获取销售利润比封闭源码软件难。

　　真正的困难来自维护开放源码发展的许可证本身。因为三个相互推动的原因，大多数的开放源码许可证禁止对用户使用、分发、修改软件的权利进行限制，以此避免有人利用开放源码软件牟取直接利润。为了更好的理解这些原因，我们有必要对这些许可证所涉及的社会背景――黑客文化（可以访问以下网址： http://www.tuxedo.org/~esr/faqs/hacker-howto.html>）做一番探讨。

　　原因与对市场的敌视无关，虽然这样的误解在黑客圈外至今广为流传。不排除有小部分的黑客确实一直对商业动机抱有敌意，但大部分的黑客还是愿意与一些以盈利为目的Linux集成商（如REDHAT、SUSE、Caldera）合作的。这也表明只要符合他们的意愿，大多数的黑客会乐意和商家合作的。如此看来，黑客们敌视以获取直接利润为目的的许可证的真正原因非常微妙也非常有趣。

　　原因之一，对等原则。大多数开放源码的开发者允许别人利用他们的成果来获取利益，还有许多开放源码的开发者同时还规定不允许某一方（有时源码的开发者除外）出于特权地位来牟取利润。只要黑客们自己潜意识里打算从他们开发的软件或补丁中赢利，他们一般也愿意别人来与他合作，共同赢利。

　　原因之二，意想不到的后果。黑客们发现在许可证中对软件的商业应用与销售进行限制和收费（为获得销售利润而通常采用的做法）会使得人际关系变得淡漠。其中一个特例就是所谓的"盗版光盘"，这本来应该鼓励的，但现在却被认为是违法和不道德的。总的来说，对用户使用、销售、修改、分发软件的权力（以及版权协议中其他复杂权利）进行限制会导致人们循规蹈矩，时时刻刻担心自己会犯法（这种担心会随着人们使用的软件包的增加而愈演愈烈）。这无疑是非常不妙的，因此简化许可证，解除许可证中的各项限制已成为大势所趋。

　　原因之三，也是最关键的一个原因，就是代码共享。这种赠与文化在《开拓智域》一文中有生动的描述。某些许可证体系中用来保护知识产权或者限制直接获取销售利润的各项规定使得人们不能合法的实现代码共享，（如Sun公司的Jini Java"社区资源"许可证）。然而代码共享却被认为是最后一根救命"稻草"（《开拓智域》一文中大段大段的解释了这个问题），当软件维护者无力承担或者放弃对代码的维护时（比方说是一个非常封闭的许可证），代码共享就非常关键了。

　　黑客群体对于对等原则还是有所妥协的，所以他们能够容忍一些象Netscape的NPL（NPL明确规定不允许非公开源码的产品使用开放源码的Mozilla代码）一样给予源码创作者一些特权的许可证。对于第二条原因，妥协的就少一些。而对第三条原因极少会作出让步（这也是Sun公司的 JAVA and Jini Community License计划遭到黑客们广泛反对的原因）。

　　上述原因解释了开放源码定义中的各项条款。这些条款从一些典型的自由软件版权协议（如GPL协议，BSD协议，MIT协议以及Artistic协议）的细微特征中表达了黑客群体的思想，它们（虽然不是有意的，但客观上）使得获取直接利润极为困难。

9. 间接销售价值模式

　　然而，还是有办法来开拓与软件服务相关的市场，从而获得间接销售价值。有五种已知的和两种正在探索的模式（未来可能会发展出更多的新发展模式）。

　　9.1 失败的领导者/市场定位者

　　在这种模式中，利用开放源代码软件为直接产生收入的专有软件来创造或维持一种市场位置。在大多数普遍的情形中，开放源代码的客户端软件带动了服务器软件的销售，或者可增加了门户网站的访问量/广告收入。

　　网景公司（Netscape）在1998年开放了Mozilla浏览器的源代码时，就是使用了这种策略。他们浏览器端的商业收入只占总收入的 13%，而且在Microsoft开始发布Internet Explorer后市场份额还在下降。IE强大的市场营销（及其捆绑策略后来成为反托拉斯案的核心问题）迅速的吞噬了Netscape浏览器的市场份额，造成了Microsoft试图垄断浏览器市场，并利用微软强加给用户的HTML的"标准"，形成逐步把Netscape赶出服务器市场的态势。

　　通过开放仍然流行的Netscape浏览器的源代码，Netscape有效的阻止了Microsoft垄断浏览器的可能性。他们期望开放源代码协作会加速浏览器的开发和测试，并希望能降低Microsoft的IE的发展速度，阻止它独自定义HTML标准。

　　这个策略生效了。在1998年11月，Netscape实际上开始从IE那里夺回市场份额。在1999年初Netscape被AOL收购时，保持Mozilla所取得的竞争优势是很明显的，这一点可以从AOL的行动中显而易见，AOL首先对外的承诺的就是继续支持Mozilla计划，虽然她还处在alpha测试阶段。

　　9.2 糖霜策略

　　这种模式是针对硬件制造商的（这里的硬件包括从以太网或其他外部设备直到计算机系统的所有东西）。市场压力迫使硬件公司书写和维护软件（从设备驱动程序、配置工具直到整个操作系统的级别），但是软件本身并不是利润中心。它是一项开支――通常是一项重要开支。

　　在这种情况下，开放源代码是一种很好的策略。由于没有赢利上的损失，所以没有负面影响。销售商获得的是奇迹般膨胀的开发人员队伍，对用户需求获得更加快速、灵活的反应能力，并且通过同行检查而获得的更好的可靠性。而且可以免费得到了其他系统的移植。这种做法还可在很大程度上提高客户对公司的信任度，因为客户的技术人员可以花费了更多的时间根据自己的需要定制代码。

　　有一些经常被销售商提出的反对开放硬件驱动程序源代码的理由。为了不把它们和这里的更加一般的问题搅在一起，我在附录里专门讨论了这个问题。

　　开放源代码的"将来获益"的效果在糖霜策略中体现的尤其强烈。硬件产品有一个有限的制造和支持的生命周期，在那以后，用户就自己照顾自己了。但如果他们可以获得驱动程序的源代码，并可根据需要加以修改的话，他们就更可能高高兴兴的成为同一公司的回头客。

　　糖霜模式的一个非常戏剧性的例子是苹果公司在1999年三月中旬决定开放它们的Mac OS X服务器的操作系统"Darwin"的代码。

　　9.3 奉送食谱，开办饭店

　　在这种模式中，开放源代码软件建立了一种市场定位，并不是为了象在失败的领导者/市场定位者模式中一样针对封闭源代码软件，而是针对服务。

　　（我曾经把这种模式称为"奉送剃刀，销售刀片"，但是软件和服务二者的关联并不如剃刀/刀片所类比的那么紧密。）

　　这是红帽和其他Linux发行商所采用的模式。他们卖的其实并不是软件代码本身，而是通过组合和测试一个能转的操作系统产生的附加价值，这个操作系统被担保有销路并与同一品牌的操作系统兼容。构成他们的价值的其他元素包括免费安装和提供可选的持续技术支持合同。

　　开放源代码的创造市场的能力极为强大，尤其是对那些天生就作服务的公司来说更是如此。进来一个非常有教育意义的例子是Digital Creations公司，它是一个创建于1998年的web站点设计机构，专长于复杂的数据库和事务站点的开发。他们的主要工具，公司的知识财产――皇冠上的明珠，是一个对象发布系统，它曾经有过几个名字，现在被称为Zope。

　　当Digital Creations的人寻找风险投资时，风险投资商仔细的估计了他们的预期市场份额，他们的人力资源和那套工具后，就建议Digital Creations开放Zope的源代码。

　　从传统的软件工业标准来看，这看起来绝对是一个疯狂的举动。常规的商业学校认为象Zope这种核心知识财富是一个公司的掌上明珠，是在任何情况下也不能放弃的。但是那位风险投资商从两个相互关联的角度来考虑问题，一个是Zope的真实核心资产实际上是它的人员的大脑和技术；第二个是Zope作为一个创造新市场的标准而不仅仅是一个秘密武器会产生更多的价值。

　　为了看清这一点，请比较两种情况。在通常情况下，Zope保留为Digital Creations的秘密武器。让我们假定它是一个很有效的武器。结果，公司可以在很短的时间内交付高质量的软件――但是没人知道这个秘密武器。满足客户是容易的，但是建造一个客户群体是困难的。

　　然而那个风险投资商看到了对Zope系统开放源码可以为Digital Creations的真正财富――它的技术员工产生巨大的广告效应。他期望使用Zope的客户会认为雇用象Digital Creations这样的专家会比自己开发自己的Zope技术更加高效。

　　Zope的一个负责人曾经非常公开的确认了他们的开放源代码策略"开启了许多其它方式无法开启的门"。潜在的客户确实反应了这种情况――所以Digital Creations公司迅速发展起来。

　　另一个很近的例子是e-smith公司<http://www.e-smith.net>。这个公司出售定制的开放源代码的 Linux的Internet安全服务器。他们的一个负责人描述了e-smith迅速扩展的免费下载服务，他说"大多数公司都要考虑软件盗版问题，而我们把它看作一个自由市场。"<http: //www.globetechnology.com/gam/News/19990625/BAND.html>

　　9.4 附加产品

　　在这种模式中，我们出售开放源代码的附加产品。在低端市场，出售杯子和T恤衫；在高端市场上，出售专门编辑并出版的文档和书籍。

　　O'Reilly集团是一个附加产品公司的很好的例子，他出版了很多优秀的开放源代码软件的参考资料。O'Reilly实际上雇用和支持了一些著名的开放源代码黑客（例如Larry Wall和Brain Behlendorf），并以次提高它在市场上的声望。

　　9.5 未来免费，出售现在

　　在这种模式下，我们以封闭的许可证发布软件的可执行文件和源代码，但是包含一个有关封闭条款的期限。比如，我们可以写一个许可证，允许免费的散发软件，禁止不付报酬的商业应用，并保证发布一年以后或开发商终止开发后软件将在GPL保护之下。

　　在这种模式下，客户可以保证产品能够根据他们的需要定制，因为他们可以得到源代码。产品的将来也是得到保证的――许可证保证了如果始创公司失败后，开放源代码社区仍能够接管该产品。

　　因为销售价格和数量是依赖于客户对产品的期望值，始创公司可以享受到比以封闭源代码许可证发行的软件更优厚的收入。而且，因为老的代码是在GPL保护下的，所以它可以得到同行认真的检查、排错和添加其他小功能，这样可以为原创者减轻75%的维护负担。

　　这种模式被Aladdin公司成功的采用了，它创造了流行的Ghostscript程序（一个PostScript解释器，它可以把PostScript翻译成许多打印机的内部语言）。

　　这种模式的主要缺点是那些封闭的条款倾向于抑制产品开发早期的同行检查和参与，而那时是最需要的大家的参与的时候。

　　9.6 软件免费，销售品牌

　　这还是一个试探性的商业模式。我们开放一项软件技术，保留测试包或一套兼容性标准，然后卖给用户一个品牌认证，保证他们对这种技术的实现和其他具有这种品牌的产品相互兼容。　　（这是Sun公司应该对待Java和Jini的方式。）

　　9.7 软件免费，销售内容

　　这时另一种试探性的商业模式。想象一些象股票信息订阅的服务。价值既不在客户端软件也不再服务器商，而在于提供客观的的可靠的信息。因此我们开放所有的软件，出售内容订阅。当黑客们把客户端移植到新的平台上或者以不同方式扩展它时，我们的市场自动扩展了。　　（这是为什么AOL应该开放它的客户端软件。）

10. 何时开放，何时封闭

　　在考察了支持开放源代码软件开发的几种商业模型之后，我们可以来讨论一下何时开放源代码、何时封闭源代码才有经济意义这样的一般性问题了。首先，我们必须弄清楚每种策略如何盈利。

　　10.1 靠什么盈利？

　　封闭源代码的方式让你可以从秘密的比特中收取利润；另一方面，它阻止了其他同行对代码进行检验的可能性。开放源代码方式为其他同行检验创造了条件，而且你也不能从秘密的比特中获得利润。

　　从秘密的比特中盈利很好理解；传统的软件商业模型就是围绕着它建立的。但是直到近来，其他同行检验代码的价值还未被很好的理解。然而， Linux操作系统使得我们对问题的认识更加清晰，这些认识我们本应在几年前从Internet核心软件和其他软件工程分支的发展历史中就应该学到――开放源代码的同行检验是得到高可靠性和高质量的软件的唯一可伸缩的方法。

　　因此，在一个竞争的市场上，寻找高可靠性和高质量软件的客户会给那些开放源代码软件开发人员以回报，是他们探索出怎样在服务、附加值和与软件相关的辅助市场中维持一个稳定的收支循环。这种现象正是Linux令人惊讶的成功背后的原因，Linux在1996年的一片空白发展到1998年末的商业服务器市场的17%，而且似乎会在两年之内占领这个市场（1999年初，IDC预测Linux将在2003年成长的比所有其它操作系统的总和还要快）。

　　开放源代码的一个几乎同样重要的作用是作为一种传播开放标准，围绕它建立市场的手段作用。Internet的戏剧性增长得益于没人拥有TCP/IP；没人有权封锁Internet的核心协议。

　　TCP/IP和Linux成功的所造就的互连网络对世界的影响是显而易见的，开放的系统最终减少了信任和平等的问题――如果大家都能够看到底层结构是怎样工作的话，他们就会理所当然的更加信任它；人们更加喜欢一个所有人都是平等的底层结构，而不是一个某一方具有获利的特权并可以施加控制的底层结构。

　　然而，其实为了向软件用户说明平等的重要性时，我们不必非要强调网络的影响力。没有哪个软件用户在质量和功能类似的开放源代码软件存在的条件下放弃开放源码软件，而去选择封闭源代码软件，非要让自己被某个供应商垄断控制才高兴。软件对消费者的事务越重要，这个问题就越突出――它越重要，消费者就越不能容忍自己被另外一方控制。

　　最后，和信任问题相关的开放源代码的重要优势就是它的光明前景。如果源代码是开放的，即使发行者垮掉了，客户还是能掌握一些资源。这对于糖霜策略尤其重要，因为硬件趋向于较短的生命周期，但是作用更加普遍，并转换成开放源代码的增长价值。

　　10.2 它们怎样相互作用？

　　当从秘密比特得到的回报比从开放源码高的时候，从经济意义上说应该封闭源代码。当从开放源代码得到的收益比从秘密比特高的时候，那么无疑开放源代码更有意义。

　　从表面上看，这是一个很普通的想法。但是当我们注意到开放源代码的回报比秘密比特更加难以度量和预计时，就是说回报常常被低估而不是被高估，这一点就不那么平淡无奇了。实际上，直到1998年初业界主流开始重新考虑遵从Mozilla发行源代码的前提时，开放源代码的回报一直被普遍错误的认为是零。

　　那么我们怎样评价开放源代码的回报呢？一般的说这是一个困难的问题，但是我们可以象处理其他任何一个预言性问题一样来处理它。我们可以从观察开放源代码成功和失败的案例开始。试着抽象出一个模型，至少给出一个定性的感觉，在什么情况下开放源代码对投资者或追求最大回报的商业操能产生净收益。然后我们再用数据来细化这个模型。

　　从《大教堂和市集》一文的分析中，我们可以得到开放源代码在（a）可靠性/稳定性/可扩展性至关重要时，和（b）设计和实现的正确性除了采用其他同行检验的办法外难以验证时具有高的投资回报。（在实践中多数重要程序都符合第二个标准。）

　　当软件对一个消费者至关重要时，消费者为避免被一个垄断的供应商所控制的愿望提升了他对开放源代码的兴趣（也因此提升了开放源代码厂商的市场竞争力）。因此，另一个标准（c）当软件是一项非常重要的资产时（例如，很多企业中的MIS部门），封闭源码会把用户推向开放源代码一方。

　　在应用程序领域，我们看到开放源代码底层软件创造了信任和平等的结果，随着时间的推移，一定会吸引到更多的客户，从而胜过封闭源代码底层软件；在这个迅速扩张的市场上占有较小的份额常常比在封闭的和迟缓的市场上占有较大份额还要好。因此，对于基础结构软件，开放源代码的方式比利用知识产权得到收益的封闭源代码方式会得到更高的长期回报。

　　实际上，潜在用户根据发行商的策略推知它的将来发展能力，同时他们有不愿接受一个垄断供货商的本能，因为这将意味着要处处受到约束；除非已经有了一个压倒性的市场力量，否则你可以选择一个开放源代码的方式也可以选择一个从封闭代码直接受益的方式――但是不可能同时选择二者。（在别的地方可以看到类似的情况，举例来说，在电子市场上用户常常拒绝购买单独货源的设计。）这种情况的消极性可以消除一些：在网络占支配地位的地方，开放源代码似乎是正确的选择。

　　我们可以总结一下这种逻辑：在（d）创建一个公共计算和通讯的底层结构时，开放源代码软件似乎可以比封闭源代码软件成功的获得更大的回报。

　　最后，我们注意到，相对于核心算法和基础知识已被很好理解的服务提供商，提供唯一或独特服务的商家更加担心竞争对手会模仿他们的方法。因此，在（e）核心方法（或功能）是公有知识一部分时，开放源代码更加可能取胜。

　　实现了Internet核心软件，Apache，和ANSI标准的Unix API的Linux系统是上面分析的五个标准的典型样板。在十五年建造自己的封闭协议（如DECNET，XNS，IPX等等）帝国的尝试失败之后，90年代中期数据网络重又向TCP/IP集中，这生动的印证了这种市场向开放源代码演化的道路。

　　另一方面，开放源代码对拥有自己独特的创造价值的软件资产的公司没有太多意义（强烈满足条件（e）），下面这些情况也不太适用与开放源码，比如软件（a）对失效相对不敏感，（b）可以用同行检验以外的方式来验证，不是（c）关键事务的，并且不是主要从（d）网络作用或普遍使用上获得价值的。

　　作为一个极端的例子，1999年初由一家公司问我"我们是否应该开放源代码？"，这家公司为锯木机编写计算切割模式的软件，可以从原木中获得最大的板材。我的结论是"不"。他们唯一接近满足的条件是（c）；但是在紧要关头一个熟练的操作员可以手工的决定切割模式。

　　值得指出的是，满足这些条件的特定产品或技术会随时间发生变化，从下文的案例中我们会看到这一点。

　　总而言之，下面的条件宜于采用开放源代码模式：

　　（a）可靠性/稳定性/可扩充性非常关键时　　（b）设计和实现的正确性不能很容易的用其他同行检验以外的方法验证时　　（c）软件对用户控制他/她的事务非常关键时　　（d）软件用来创建一个公共计算和通讯基础结构时　　（e）关键方法（或等价功能）是公共工程知识的一部分时

　　10.3 Doom：一个案例

　　id软件公司卖得最火的游戏Doom的历史展示了市场压力和产品演化怎样改变了封闭源代码软件相对于开放源代码的收益数量。

　　当Doom在1993年末第一次发布时，它的主观视角，实时动画是极为独特的（条件（e）的对立面）。不仅因为它那令人叫绝的视觉效果，而且在很长一段时间内没人知道他们是怎样在低级的处理器上实现这些效果。这些秘密的比特可以获得非常重要的收益。而且，开放源代码的潜在收益很低。作为一个单独的游戏，这个软件（a）它的故障的代价很小，（b）不是非常难于验证，（c）对任何一个用户来说都不是至关重要的，（d）并不得益于网络。所以Doom 成为封闭源代码在经济上是很合理的。

　　然而，Doom周围的市场不是静止的。竞争对手发明了它的动画技术的等价功能，其他的"主观射击"游戏比如毁灭公爵（Duke Nukem）等开始出现。当这些游戏侵蚀Doom的市场份额时，秘密比特的收益开始下降。

　　另一方面，扩展市场份额的努力带来了新的技术挑战――更好的可靠性，更多的游戏特色，更大的用户群，和跨平台。随着"death match"的多人游戏模式和Doom游戏服务的出现，市场开始显示出对网络的依赖。所有这些需求都要求id公司在下面版本的游戏中花费更多的精力。

　　所有这些趋势都提升了开放源代码的回报。在某一点回报曲线交叉，开放源代码成为id公司在经济上合理的选择，他们可以从诸如游戏扩展选集等第二市场上获益。在这一点之后的某个时间，事情确实发生了。1997年末Doom的完整源代码被公开发行。

　　10.4 知晓何时放手

　　Doom是一个有趣的案例，因为它既不是一个操作系统也不是一个通讯/网络软件；因此这远离了开放源代码的通常的明显的例子。确实，Doom 的生命周期，包括交叉点，可以作为今天的代码生态中应用软件的典型――在这个生态环境中，通讯和分布计算软件要求较高健壮性/可靠性/可扩充性、只能通过同行检验来验证，并且常常超越技术环境和竞争者之间的界限（包含信任和平等）。

　　Doom从一个单机游戏演化到death match模式。网络计算越来越重要。同样的趋势可以从最重要的商业应用程序，如ERP系统看到。商务网络把供应商和客户更加紧密的联系在一起――当然，它们包含在整个万维网的体系结构之中。这种情况到处可见，开放源代码的回报稳步增加。

　　如果当前的趋势继续下去的话，下个世纪软件技术和产品管理的核心挑战将是知晓应该何时放手――何时把封闭源代码转变为开放源代码体系结构，从而得到同行检验的好处，并从服务和其他第二市场上得到更高的回报。

　　大家很明显都不想在任何一个方向上离交叉点太远。除了这个，等待太长时间面临着严重的风险――你可能会被一个走向开放源代码的同一市场上的竞争对手铲平。

　　这个问题之所以严重的原因是，可以被吸引到某类产品的开放源代码合作者的用户群和专家群是有限的，而且这些人很难于转移。如果两个功能基本相同的竞争代码一先一后开放源代码，那么先开放的更加可能吸引更多数的用户和更多数的最激情的合作开发人员；后开放的则不得不吃剩饭。吸引来的人员难以转移，因为用户对软件已经熟悉，而开发人员已经在代码上投资了很多的时间。

11. 开放原代码的商业运作

　　在开放式原代码的社区中，通常是以一种倾向于增强开放式原代码生产效益的方式来组织其自身的商业活动的。尤其在Linux的世界里，存在着一个具有重要经济意义的事实，那就是存在有许多相互竞争的发行商，而他们形成了一个与开发团体相分离的、独立的层次。

　　开发人员写原代码，并且使得这些原代码在互连网上是可以被下载的。每个发行商都从这些可下载的原代码中选取一些，并将它们进行综合，包装，并且注册商标，最后将其买给顾客。用户可以选择发行商的产品，也可以通过直接从开发商的网站下载原代码而增补其自己已安装的发行版。

　　这一分化出来由发行商形成的层的作用是为创造了一个非常易于改变、可对产品不断完善的内在市场。开发人员为了吸引更多的发行商和顾客的注意力，在他们软件的质量上彼此竞争。而发行商则为了从用户那里赚得更多的钱，互相在他们选择原代码的策略以及他们给软件带来的附加价值上竞争。

　　内在市场结构中的第一特征就是网络中没有什么原代码是不可缺少的。开发商可能倒闭，即使他们的那部分底层代码没有直接被其他开发者所用，为吸引更多注意力而导致的竞争将倾向于尽快产生一个在功能上可替代的产品。发行商可能在没有破坏或修改开放原代码的情况下就破产了。整个开放式原代码的商业系统作为一个整体，与任何一个独立的封闭原代码的操作系统的发行商相比较而言，对市场需求有着更快的反应，并且在抑制巨大的波动及自我创新方面有着更强的能力。

　　开放源码另一个重要的特征就是通过分工降低成本，提高了效率。开发商不愿经受传统的封闭原代码项目中那种例行公事般的压力，而是象这样来工作：没有来自市场方面的那些不得要领、分散注意力的表单；没有要求他们使用不适合的而且已过时的语言或开发环境的强制命令；没有打着突出产品的特性和保护知识产权的幌子要求用一种新的，不兼容的方式重新设计"轮胎"的命令；而且最重要的是没有项目完成最后期限的约束。这样，公司就不会在产品还没有做好以前，就匆匆忙忙地推出一个1.0版本，正如Demarco和Lister在从对"做完了再喊我"管理模式的讨论中所作出的评论（见《开发队伍与产品》一文）那样，这种模式通常不仅会有益于质量的提高，而且实际上有助于一项真正的研究成果以最快的速度进行传播。

　　另一方面，发行商们可以专门从事他们能高效完成的事情。这样，他们就可以集中精力在系统的综和一体化，包装，质量保证及服务方面，而不用去考虑所需要的大量的资金问题以及使正在进行的软件开发保持其竞争力的问题。

　　通过作为开放式原代码商业模式中不可缺少的一部分，即来自于用户的不断的信息反馈和监督，无论是发行商还是开发商都会比较诚实一些。

12. 成功的复制

　　公用的悲剧也许并不在于他们对现如今存在的开放式原代码商业模式发展的适应性，但这并不意味着不存在任何理由去怀疑开放式原代码社区内目前的状况是否能持续下去。主要的参与者是否会随着风险的进一步增大而背叛共同的合作？

　　这一问题可以从几种不同的层次来提出。我们的那个与"成功的公用"相反的故事是基于这样一种论断的，那就是个人对开放式原代码的贡献价值很难以量化的方式来衡量。但是这一论断对于像Linux的发行商那些已经拥有一部分与开放式原代码相连系的收入的公司来说，就没有太大的影响力了。而且，他们每天的贡献价值已经量化了。但是，现在这种合作角色稳固吗？

　　对这一问题的研究将导致我们对一些问题有趣的思考，譬如现如今真实世界中开放式原代码软件的经济状况，以及什么才是未来软件业中真正的软件服务行业中的典范。

　　从实际的角度来讲，适用于现存的开放式原代码社区的这一问题通常可以用两种不同的方式来提出。一种Linux将分裂吗？另一种是与第一个相反的，Linux将发展成为一个处于支配地位，类似于垄断性的产品？

　　当暗示Linux将分裂时，我们不能不联想到20世纪80年代UNIX版本分裂的历史，许多人又重新开始思考历史是否回重演。尽管无休止的有关开放标准的讨论，尽管有许许多多的联盟，协作和合同，UNIX的所有权归属还是分裂了。事实证明卖方通过增加或改变操作系统设备从而使他们的产品与众不同的愿望比他们通过维持其兼容性，不断的减少独立软件开发商的进入障碍，以及降低维持与顾客的固定业务关系的总成本，来增大UNIX的整个市场份额的兴趣要更强烈。

　　但是上述情况不大可能发生在Linux身上，这是基于一个很简单的原因，那就是Linux的所有开发商都被限制基于开放原码这样的根基来进行开发和其他运作。而且事实上，对于他们其中的任何一个发行商来说都不太可能保持他们产品的与众不同，因为使得Linux的原代码得以高效发展的许可证条款要求他们与所有的发行商一起分享原代码。任何一个发行商只要一开发出新的特性，他们有的竞争对手都可以免费克隆它。

　　因为所有的发行商都深知这一点，所以甚至没有人想过要实施一个阴谋，一个和导致UNIX标准分裂的策略类似的计划。相反，Linux的发行商被迫以一种实际上对顾客和整个市场有利的方式进行竞争。那就是，他们必须在服务、技术支持、以及实际上能使得安装和使用都比较方便的设计方面进行竞争。

　　共同的开放的原代码还去除了垄断的可能性。当Linux社区内的人们担心这一问题时，通常会抱怨一个叫"RedHat（红帽子）"的名字，而 "RedHat"是Linux最大的也是最成功的发行商，它几乎拥有美国市场上90%的份额。但是还有一个值得引人注目的事情，那就是在被大家期盼已久的 RedHat的6.0版本在1999年5月份宣布发行后的一段时间里，通过从RedHat自己的FTP站点下载光盘镜像，一个图书发行商和许多其他光盘软件发行商就已经开始以比RedHat更低的价格进行销售了，而且事实上在这段时间里RedHat的CD-ROM还没有真正的成批装船销售。

　　但是，RedHat自己并未对此事怒不可遏，因为他们非常清楚的知道他们没有也不可能拥有他们他们产品中二进制数据中的任一个比特。因为 Linux社区里的社会准则不允许他们这样做。在后来的日子里出现了Johngil More的著名的论断，那就是互连网上的人将对互连网的检查制度解释为对它的破坏和一些例行公事的程序。基于此，对Linux负责的黑客们则巧妙地将企图控制原代码也解释为是对它们的破坏和一些例行公事的手续。对于RedHat来说，他们如果反对对他们的新产品在发行之前进行克隆，这一行为将严重地使他们未来吸引开发商们进行共同合作的能力大打折扣。

　　也许就目前来说，以一种与法律相结合的形式来表达Linux社区准则的软件许可证制度正积极主动的阻止了RedHat对他们的基于开放源码产品的垄断。他们唯一能卖的就是一个品牌、服务以及与那些自愿付给他们钱的用户之间的技术支持关系。这不会让压倒性的垄断局面出现有太大的的可能性。

13. 开放研发和再开发

　　投资者向开放源码世界投资的另一个原因就是要改变他。开发者逐渐感觉到他们可以从他们想干的事情中获得报酬，而不是用自己的正式工作的收入来维持他们对开放源码运动的爱好。象RedHat，O'Reilly Associates和VA Linux System这样的公司正在探索通过雇佣并维持稳定且能干的开放源码程序员来建立半独立的研发机构需要多大的投入。

　　这种方式只有在公司通过迅速扩大市场所带来的收入能够足够用于支付那种研究实验室时才是经济上可行的。O'Reilly之所以能够负担 Perl和Apache的主要作者来完成他们的工作是因为经过努力公司能够出售和Perl以及Apache相关的书；VA Linux System能够让实验室有足够的经费来源的原因是随着Linux的繁荣，他们可以卖掉更多的工作站和服务器；RedHat可以负担他的高级研发实验室也是由于实验室可以不断提升公司的Linux产品的价值并吸引更多的用户。

　　在将专利、商业秘密等知识产权看成是企业的掌上明珠的文化的熏陶中，这种思想（开放源码）对于传统软件产业的战略家来说简直是无法解释（尽管自由软件市场事实上在不断地扩大）。为什么你花钱来做的研究得到的成果却可以让你的每个竞争对手都可以无偿享用呢？

　　看来可以有两个合理的解释。一个是随着这些公司继续在他们的市场中保持领先位置，他们就可以从开放研发中获得巨大的市场占有率所带来的回报。通过开放研发来换取"明天"的利润，这似乎有些天方夜谈，不过有意思的是要不是真的如此，为什么那些公司都毫不迟疑的容忍了自由的存在呢？

　　在这个资本家都拼命盯着投资风险评估的世界上，虽然风险投资分析是必要的，但是这并不能很好的解释明星效应，因为实际上投资人自己也对投资风险不是很清楚。如果被问及，他们就会告诉你他们做了他们所从属的团体所认为是对的的事情。拙笔和前面所提及的三个公司的总裁非常熟悉，因此可以说明我所说的结论绝对不是骗人。实际上我还在1998年末亲自在VA Linux Systems公司干过一段，因此我可以对他们提出一些"正确的"建议，我发现公司对我所做的基本上没有任何反对。

　　经济学家会问，那么如何为这些工作计算报酬呢？如果我们已经接受了前面提到的"做正确的事"的说法不是空洞的做作的话，我们接下来就会想到， "做正确的事"会给公司带来什么好处呢？对这个问题的回答既不令人惊讶，也不困难。实际上在其他产业，表面上的大公无私，实际上都是为了给企业赢得好的名气。

　　为名气努力，并将此看成是一种可以在未来的市场中得到回报的无形资产，这已经不是一件新鲜事了。这些公司的行为显示他们正在建立信誉，这是一个很高价值的多么大的利益啊。他们很明确的希望能够不惜高价请到真正的高人来做项目，并非为了直接从中赢利，即使是在股票准备上市前资本非常匮乏的阶段也是如此。而且至少到现在为止，这种做法已经开始从市场中获得回报了。

　　这些公司的头头们心里都十分清楚信誉对公司来说是多么重要。客户群中的志愿者们不仅帮助他们做研发，也是一种非正式的市场伙伴，这些都是他们的靠山。公司和用户之间的关系是非常亲密的，通常是建立在公司内部或外部相互信任的私人关系之上。

　　这些现象增进了我以前从另一个角度所作出的推断的理解。象RedHat，VA和O'Reilly这些公司和他们的客户以及开发人员之间的关系和传统的制造业完全不同。这是一种非常有意思的特别模式，是一种知识密集型的服务产业。除了技术工业以外，我们还可以从法律界、临床医学界和学院中找到这种模式的影子。

　　实际上，我们可以看出开放源码公司雇佣优秀的黑客和大学聘请知名教授之间有异曲同工之妙。在实现方式上，二者都有些象工业革命前贵族们对高雅艺术的投资方式，一些方面的相似性是显而易见的。

14. 由此及彼

　　资金支持（当然也要从中获利）源码开放开发的市场机制仍然在迅速的发展之中。本文中所述及的商业模型并不是最终的定论。投资商还在不断从软件产业变革的结果中不断总结经验，这种新模式面向服务的而不是强调保护知识产权，他们将会在一个适当软件业在思想上的革命将给原来人们仅通过向5%的市场价值投资来赢利的方式带来好处；传统意义上服务业不如制造业有利可图（可是医生或律师会告诉你，服务业的创业者所获得的回报更高）。然而，当软件用户可以从自由软件产品中获得许多好处并可以节省开支的时候，从投资中可以获得更多的利润。一个类似的例子是从传统的语音电话网络向现在的互连网发展所带来的巨大影响。

　　对于节约开支和更好用的承诺正在创造一个巨大的市场机会，许多企业和风险投资商们开始来开拓这个市场了。在本文的第一份草稿完成的时候，硅谷一家非常著名的风险投资机构开始下了头注，他们投资了一家提供24*7的Linux技术支持的服务公司，一般预计在1999年年底之前，会有几家 Linux厂商和一些与自由软件相关的股票上市，他们的融资应该会非常成功。

　　另一个很有意思的发展方向是系统性的创造一个自由软件开发上的外包市场。SourceXchange公司<http: //www.sourcexchange.com/process.html>和CoSource公司<http: //www.cosource.com/>分别代表了两种稍有区别的将减价拍卖模式应用于开放源码软件开发的新尝试。

　　整体的趋势已经很明显了。在前面提到的IDC预测中可以看出Linux会在2003年之前以比其他操作系统都快得多的速度增长。Apache 现在占有60%的市场份额，而且还在不断增长。互连网的传播是爆炸式的，象Internet Operating System Counter给出的调查报告显示Linux和其他开放源码系统已经是互连网上主机所采用的主流系统，而且在以比封闭系统更快的速度扩大市场占有率。不断开拓互连网领域自由软件的需要并不只是由编制更多的软件来决定，更重要的是各个公司的商业行为和软件的使用/购买模式使然。这个趋势现在看来正在不断加快。

15. 结论：自由软件变革之后

　　在向自由软件形式过渡完成之后，整个软件产业将会是什么样子呢？

　　为了回答这个问题，有必要根据软件所需要为用户提供的服务程度将软件分分类，服务体现了软件的开放性，这种划分又是与软件所业服务的市场化程度紧密相关的。这个提法的精髓恰好与我们日常所说的三个名词相似：应用程序（基本没有商品化的服务，没有或缺少开放的技术标准）、构件（服务商品化、标准性很强）、中间件（需要一些商品化的服务、有技术标准但是不完善）。当前（1999年）对于上面三种软件的典型例子就是字处理软件（应用程序）、 TCP/IP协议包（构件）和数据库引擎（中间件）。

　　前面关于分配方式的分析向我们展示了构件、应用程序和中间件三种软件形式将会以不同的方式向自由软件体系过渡，以及他们各自体现出的自由软件与封闭软件相结合的形式。还需要指出的是，在软件业的某一领域自由软件普及程度还要受到那里的网络影响力是否很强，软件企业倒闭所带来的负面影响程度以及软件产品在多大程度上还是一种商业上敏感的资本资源等因素的影响。

　　如果不局限于某个特定的领域，从软件业的整体角度考虑我们可以大胆的作出如下预言：

　　象因特网、互连网、操作系统以及其他需要在竞争的软件各方互相交叉的底层通讯软件等构件产品会逐渐全部开放，这些软件将由今天象RedHat这样赢利的软件发行商或其他服务机构将会与用户团体来共同维护。

　　另一方面，应用程序类型的软件会继续保持封闭的状态。这种软件通常是他们未公开的算法使用价值非常高或使用的技术非常先进，促使用户仍然愿意花钱去购买这些封闭源码的软件，同时这也意味着这种软件可靠性要求非常底，并且可能导致行业垄断的风险还在可以容忍的范围内。这种现象最有可能出现在网络影响比较小的垂直性市场领域中。我们以前提到的一个lumber-mill就是这种产品，1999年最亮丽的软件产品――生物分子结构识别软件也属于这一类。

　　中间件，象数据库工具、开发工具或其他用于特定领域的高端应用程序协议软件包将是一种自由与封闭的融合。这些中间件软件产品是会逐渐走向封闭还是开放或许将取决于软件的破产风险，为打开市场而所需的成本越高的软件将更需要开放。

　　不管怎样，为描绘一个完整的蓝图，我们仍然应该看到无论是应用程序还是中间件，这都是一个静态的划分。在前文"何时会开放"一节里面我们已经分析了对于任何一个软件产品都将要走过一个从理智的封闭到理智的开放这样一个生命周期，对整个软件产业来说同样是这个道理。

　　随着关键技术的普及和标准化，随着商品化的服务在软件产业中所占的比重越来越大，应用程序会逐渐转化为中间件，比如在将数据库前端接口和数据库引擎分开以后，数据库接口就成为了一种中间件。当中间件产品所需服务越来越要商品化时，就轮到他们逐渐转化为开放源码的构件了，我们今天看到的操作系统的变革就是这种例子。

　　我们可以预料到在未来，随着自由软件所带来的强大竞争力，某个软件的最终命运将不是走向灭亡就是成为开放构件系统的一部分。虽然这对于那些打算永远从封闭软件中赚取利润的软件企业来说的确是个坏消息，但是软件产业作为一个整体仍然是一种产业，那时新的高层应用软件将不断开放，私有化的智力资源垄断某个软件将只有一个有限的生命周期，最终将纷纷转化为自由软件。

　　最后，我们要看到这种从封闭到开放的变革还是主要要由软件产品的用户来推动才能不断发展。越来越多的高质量软件将被创造出来并得到长期使用，而不是被某些人藏在密室里得不到发展。这种奇迹用Ceridwen的魔锅来比喻还不够恰当，因为魔锅变出来的食品如果不吃就会逐渐腐烂掉，而自由软件世界中的软件将是取之不尽的宝藏。在自由软件中你拥有最自由的自由，无论你是打算提供商业服务还是打算为他作出贡献，自由软件世界将向所有人提供一个不断积累、取之不竭的宝贵财富。

16. 参考文献和致谢

　　[CatB]大教堂和市集 <http://www.tuxedo.org/~esr/writings/cathedral-bazaar/>

　　[HtN] 开拓智域 <http://www.tuxedo.org/~esr/writings/homesteading/>

　　[DL] De Marco and Lister， Peopleware 合著的 Productive Projects and Teams（New York； Dorset House， 1987； ISBN 0-932633-05-6）

　　[SH] Shawn Hargreaves 写过的一篇关于如何将开放源码和游戏制作相结合的佳作 Playing the Open SourceGame <http://www.talula.demon.co.uk/games.html>.

　　在完成本文的过程中，通过与David D. Friendman的几次激烈讨论帮我进一步提炼了介绍如何加强开放源码团体合作的"翻身的平民"一章。感谢Marshall van Alstyne为我指出了"热门信息产品"的确切含义，我欠了他一个人情。Indiana组织的Ray Ontko给了我许多有益的批评。还有许许多多在我今年6月发表演讲时的热心听众也给了我很多帮助，如果你是听众中的一员，你就会明白我指的是谁。

　　在我公布这篇文章以后，我还通过电子邮件收到了许多关于自由软件发展模式的材料，这些材料不断充实了这篇文章的内容。Lloyd Wood指出了"将来获益"自由软件发展模式的重要性；Doug Dante提醒我注意"未来免费"这种商业模式；Lionel Oliviera Gresse帮我给一个商业运作模式起了一个更好听的名字；Stephen Turnbull对于无视自由骑士现象给了我当头一棒。

17. 附录：为何封闭驱动程序源码的硬件厂商会浪费投资商的金钱

　　外围设备开发商，象网卡、硬盘驱动器或显卡的制造商，他们的传统作法就是将驱动程序的源代码封闭起来。但是这种现象现在已经有所改变，比如 Adaptec公司和Cyclades公司已经习惯于将他们的各种板卡的驱动程序源代码和相应文档公开化。不过要想让开放源代码成为一种普遍的作法还是有不少困难的。在本附录中我们就是打算澄清在商业领域中仍然维持封闭源代码体系的一些错误观念。

　　假定你是一个硬件制造商，你也许会担心将驱动程序代码的开放会泄露你硬件如何工作的许多重要秘密，从而让你的竞争对手可以通过分析你的源代码来给你造成一种不公平的竞争环境。这种想法在三、五年才会将产品更新换代的时代里也许还站得住脚；但是今天即使将源代码开放，你的竞争对手也将不得不花费占整个产品更新周期的一大部分来琢磨你已经公开了的代码，因为现在产品更新的周期大大的缩短了，你的竞争对手将没有足够的时间来好好思考和革新他们自己的产品。所以说他们去研究你开放的源代码的时刻实际上已经钻进了你的圈套。

　　不管怎样，在今天代码中的秘密不会被隐藏很久了。硬件驱动程序并不象操作系统或应用程序那么复杂，他们一般都很小，很容易被反编译和模仿，这种活连一个十几岁的电脑初学者也可以搞定，而且实际上常常也被这些人搞定。可以毫不夸张的说，世界上现有数以千计的为Linux或FreeBSD工作的有激情的优秀程序员，他们愿意为任何一种新的板卡编写驱动程序。由于许多种类的硬件设备有着相对简单和标准化的接口规范，比如常见的磁盘控制器或网卡，热情澎湃的黑客们即使在没有文档也不需要反编译已有的驱动程序的条件下就可以迅速的写出正确的驱动程序来，而且常常比原生产厂家还要来得快。

　　即使遇到象显卡这样的复杂设备，也难不倒用反编译工具武装起来的牛人。这种工作即不需要花费很大的精力，也很难说是否违法，而且在全球程序员的共同努力下，已经可以对Linux做任何在法律上合法反向工程了。从Metalab网站查一查Linux核心和设备驱动程序库所能支持的硬件类型列表，你就会立刻明白前面所言非虚，Metalab的网址是：<http: //metalab.unc.edu/pub/Linux/hardware/index.html>。访问该网站时你还可以留意一下新的驱动程序正在以何等迅速的速度不断涌现。

　　保守你驱动程序中的秘密从短期效应上来说还是有诱惑力的，但是从长期战略的角度来看则不可取，特别是当你的竞争对手都已经将源码开放的时候。如果你非要固执的封闭你的源代码，那就只能将那些代码烧到电路板上的ROM中，而只对外公开访问接口了。所以赶紧开放你的源代码吧，迅速扩大市场，你要相信自己有能力通过自身的不断思考和创新来吸引更多的本来属于你的竞争对手的潜在用户群。

　　坚持走封闭的路线是一条死胡同，你的秘密将不可避免的被逐步暴露，你将无法得到自由程序员的帮助，也没有什么愚蠢的竞争对手会去花时间模仿你的设计。更重要的是你如果及早采纳开放的思想本来可以获得更广阔的发展空间，但是你却遗憾的错过了。由于你的设备太保守、缺少资料和固步自封，并且不能认识到你自己的错误，因此互连网上大部分的网络管理员和超过17%的商业数据中心所形成的巨大市场将把你的硬件设备从他们的采购清单中删除，而把目光转向其他开放的硬件厂商中去。

18. 本文档修订记录

　　你现在看到的是本文档的1.14版

　　在下面的列表中，一些微小的修订和印刷版就不再列出了。

　　1999年5月20日，1.1版 ―― 草稿　　1999年6月18日，1.2版 ―― 第一用于私下交流的版本　　1999年6月24日，1.5版 ―― 对外公布的第一个版本　　1999年6月24日，1.6版 ―― 作了一些小改动，给出了'hacker'的定义。　　1999年6月24日，1.7版 ―― 澄清了一些标准　　1999年6月24日，1.9版 ―― 增加了关于"将来获益"、"未来免费"发展模式的讨论和关于封闭的代价的章节　　1999年6月24日，1.10版 ―― 给"刀片"模式取了一个更好的标题　　1999年6月25日，1.13版 ―― 更正了关于Netscape公司13%收入的问题，增加了关于自由骑士的分析，更正了封闭网络协议的列表。　　1999年6月25日，1.14版 ―― 增加了e-smith公司的例子　　1999年7月9日，1.15版 ―― 更新了关于硬件驱动附录的内容，并在Rich Morin的帮助下给了"热门货"一个更好的解释。

取自"http://www.pgsqldb.org/mwiki/index.php/%E9%AD%94%E6%B3%95%E5%A4%A7%E7%86%94%E7%82%89"

Tao Jin

2009年3月19日星期四