第九章 由 Fetchmail 学到的一些经验

在我们回头讨论一般软件工程的议题前，由 fetchmail 得来的一些特殊教训值得深思。

Fetchmail 配置文件（rc file）的语法包括可有可无的关键字，这些如「噪音」般的字眼会被语法分析程序忽略，这些字的加入，使得配置文件的语法和英文很接近，和传统中简洁的「关键字 ―― 设定值」配对表示法（把噪音字去掉就可以得到）比较起来，要来得容易阅读。

这个教训开始于某一个夜晚的实验，我注意到配置文件中的宣告语法可以组成一个迷你的祈使语言。（这也是为什么我把原来 popclient 中的关键字 server 改成 poll）。

对我而言，如果把这个祈使语言弄得更像英文，那会让 fetchmail 更易于使用，虽然我现在信服如 Emacs、HTML 及许多数据库引擎制定出来的模范语言，在正常情况下我也不那么迷英文的语法。

传统的程序员喜欢非常精确而简洁的配置语法，不希望有任何冗余在其中，这是因为早期的电脑计算资源昂贵而遗留下来的观念，他们认为语法分析的过程要节约计算资源，并要尽可能的简单。英文的语句大约有百分之五十的冗余，所以不利于做为配置语法。

但这并非我在正常的情况下不用英文语法的原因，我在此提及是为了推翻像英文的语法不适合作配置语法的论点，当中央处理器和内存都变得便宜时，配置语法的简洁已不再是我们的目标，现在的情况是︰一个电脑语言中符合人性易于使用的重要性已超过节约电脑的计算资源。

然而还是有好几个地方要小心，其中之一是语法分析过程变得比较复杂的代价 ―― 你不会想把这个特点（使用像英文的配置语法）变成程序错误的来源及使用者的疑惑处。另一个是当我们要订出一个像英文的语言时，通常需要做些修改，表面上看起来修改过后的语法可重组出自然语言，但可能也会因修改过以致于和传统的配置语法一样，令人感到疑惑。（我们可以在许多所谓的第四代程序语言和商业用的数据库查询语言看到这个现象）

Fetchmail 的控制语法看起来免除了这个问题，因为我严格地限制控制语法的范围，它不是一个以通用为目的的语言，它简单并不很复杂，所以在极小的英文子集和真正的控制语言之间的相混处很少，我认为这里还有一个更广义的教训︰

格言16︰当你设计的语言没有一处是 Turing-complete，你可以采用比较平易的语法。

另有一个教训是关于含糊的保密性，有一些 fetchmail 的使用者要我修改程序，以把经保密处理的凭证储存于配置文件内，这样一来，偷窥者就没办法看到真正的密码了。

我并没有这么做，因为这个做法并不能达到真正的安全，能拿到读取你配置文件权限的人，也能以你的身份执行 fetchmail ―― 如果你的密码经保密处理存在配置文件中，他们可以由 fetchmail 中取得解码程序来得到你真正的密码。

如果我把程序改成可以在 fetchmail 的配置文件中储存保密的密码，那会给认为这并不难的人们对保密性的错误观念。一般的守则应该是:

格言17︰一个保密系统是否安全依存于它隐藏的秘密，注意不要有「虚拟秘密」。¹

第十章 市集模式必要的条件

早先看过这篇文章的书评家和试读者都提出同样的问题，那就是以市集模式发展软件，获得成功的先决条件为何？包括项目领导人的资格，代码到什么样的程度，才对社群发布并开始成立协同发展团队。

相当明显的，任何人无法以市集模式建立软件基础²，但是可以用市集模式来测试，debug，改进软件，在一个项目的起始点很难运用市集模式，Linus 没试过，我也没有。项目初始的协同发展团队需要有一些东西可以测试，可以执行。

当你开始召募项目团队时，你必须能提出大致合理的保证，你的程序不需要运作得很好，它可以暴力，有错，不完整，及注释贫乏，只要它可以使潜在的协同开发者相信，这个程序在可预见的未来大有可为。

Linux 和 fetchmail 公开发布时都具有强健及吸引人的设计，许多人认为这和我所报告的市集模式有所不同，并以为这样的设计很重要，甚至进一步做出一个他们的结论 ―― 高度的设计直觉和聪明是一个项目领导人不可或缺的特质。

但是 Linus 的设计由 UNIX 而来，我的设计由原先的 popclient 而来（虽然它后来改变甚大，比例上说来还超过 Linux），所以市集模式项目的领导人或协调者真的需要格外的设计技巧？或者能提升别人的设计技巧呢？

我想对于项目协调者是否能做出耀眼的设计并不重要，最重要的是协调者是否能认知别人在设计上的好点子。

Linux 和 fetchmail 都证明了这件事，Linus 这位仁兄如同之前所讨论的，他并不是伟大的创新设计师，但他展现了另一种卓越的技巧，即认同别人好的设计点子，且将这些好的设计整合到 Linux 的核心中。而我之前描述过 fetchmail 最有力的设计（藉 SMTP 转发邮件）也来自他人。

这篇文章的早期读者指出︰我低估了市集模式项目中创造力的重要性，因为我自己本身就已具备了许多的创意，所以将此视为理所当然。这真是抬举我，也许这说法有几分真实，相对于写程序及debug，设计应该是我最强的本领。

但以聪明和创意来设计软件的问题在于「习惯的养成」 ―― 当你应该保持程序的强健和简洁时，反而把它弄得花俏而复杂，我曾因犯了这个错以致于把项目搞砸了，但我在 fetchmail 这个项目中小心地控制，避免发生这种错误。

所以我相信 fetchmail 项目的成功部分的原因是我防止设计上「聪明」的倾向，这个论点（至少）已经反驳了设计上的创意是市集模式项目成功的基本条件。以 Linux 来说，假设 Linus Torvalds 在开发程序的过程中，试图在操作系统的基本设计上力求创新，那么我们现在已有的 Linux 内核程序会如此稳定和成功吗？

当然，任何想开始一个市集模式项目的人，应该具备基本程度的设计能力和写程序技巧，但我认为如果他们有认真想过，那他们的程度应该已在要求之上。开源社群对于名誉的重视，给予其中的人们一种微妙的压力，如果无法胜任项目后续的发展，那么就不会想去开始，直到目前，这种惯例似乎仍运作得很好。

还有一种技巧，通常与我们不会把它和软件开发联想在一起，但我认为这和市集模式项目中聪明的设计一样重要，也许还更重要，就是市集模式项目中的协调者或领导人必须有人缘和好的沟通技巧。

这应该很明显，为了召集发展社群，你需要吸引人们，让他们对你所做的有兴趣，并且保持他们加入后工作愉快。技术上的末节很难达成这样的目标，更难以完成整个项目，你个人的人格特质也和项目息息相关。

Linus 是一位好人，令人喜欢并乐于帮助他，这不是巧合，我精力旺盛，活泼外向，喜爱为群众们工作，并具有喜剧演员的本能，这也不是巧合，为了让市集模式项目顺利运作，如果能用一点小技巧来吸引人们，那帮助会很大。

第十一章 开源软件的社会关联性

我们谈过︰最好的程序起自于作者个人要解决他每天的切身之痛，然后因为这通常也是许多人的痛处，所以这个程序便开始传播，这让我们把格言1用另一种更有用的说法来陈述︰

格言18︰要解有趣的问题，从寻找你感兴趣的问题开始！

所以 Carl Harris 写了早期的 popclient，而我写了 fetchmail，然而这句格言应早已为人所知许久，Linux 和 fetchmail 发展的历史似乎要让我们注意到这有趣的一点，就是软件开发的下一步 ―― 使用者和协同开发者组成了庞大而活跃的社群，带动软件的演化。

在《人月神话》一书中，Fred Brooks 观察到︰程序员的时间有不可替换性，在一个进度已经落后的项目中，加入更多的开发者只会使进度更加落后，他讨论到一个项目的复杂度和人员间沟通的代价以参与发展人数的平方倍成长，而完成的进度只随人数做线性成长，这个声明自从发表以后，就被称为 Brooks 定律且被视为真理，但假如 Brooks 定律主宰了一切，那么根本就不可能有 Linux 这个操作系统。

Gerald Weinberg 的经典著作《计算机程序写作之心理学》（The Psychology of Computer Programming）中有后见之明，提出对 Brooks 定律极为重要的修正，在 Weinberg 对「忘我编程」（egoless programming）的讨论中，他观察到在软件工作室中，如果程序员们不只「自扫门前雪」，而是鼓励其他的程序员去看他们的程序，以找出错误或提出改进的建议，那么程序改善的速度会远超过每个程序员只顾自己的情况。

也许 Weinberg 的术语选择不当，以致于原本该为人所接受的观念却未被接受，当想到用「忘我」（egoless）来形容因特网上的电脑黑客，令人发出微笑，但我认为他的论点在今天要比过去更有力。

UNIX 的历史其实早已准备好我们从 Linux 学到的东西（以及经由我实验得证的事情，这个实验经过仔细地仿效 Linus 的方法³，但规模较小），当大家还认为写程序仍然是单打独斗的行为时，真正了不起的黑客已经在善用社群的注意力和脑力。在一个封闭项目中的程序开发者，他们只单靠自己的头脑，所达成的进度将落后于知道怎么搞一个开源项目的开发者，因为在开源的项目中，有数以百计的人在报告错误及改进程序。

但是传统 UNIX 的世界因为好几个原因，无法把这个方法的功效发挥到最大，其中包括︰不同版权的法律限制，商业机密，市场上的利益等等，还有一个原因（算是后见之明）就是︰当初的因特网还不够发达。

在廉价的因特网来临之前，有一些地域性的社群集中在一起，他们的文化鼓吹著 Weinberg 的「忘我」的程序写作，其中的程序开发者可以轻易地吸引许多有技巧的建言者和协同开发者，如贝尔实验室，麻省理工学院人工智能实验室及加州大学伯克利分校 ―― 这些地方都是创新的来源，都带有传奇色彩，至今都仍具有影响力。

Linux 是第一个致力于把全世界当成是它智库的项目，我并不认为在 Linux 的孕育期恰好诞生了全球资讯网是个巧合，而且在 Linux 发展的早期，因特网服务供应商的事业正在起飞，因特网的主流商机正在爆发，Linus 是第一位学会在因特网普及的情况下利用新游戏规则的人。

虽然廉价的因特网是 Linux 模式演进的必要条件，但我认为它并非充分条件，另一个极重要的因素是项目中领导人的领导风格，以及一群合作的客户，其中有人会被开发者吸引而成为协同开发者，进而把网络媒体的功能发挥到最大。

但我们要问什么是领导风格？客户是哪些人？他们之间的关系并非依赖权力而建立 ―― 或者就算是，强制的领导风格没办法带给我们今天这样的成果，Weinberg 引用十九世纪俄国无政府主义者 Pyotr Alexeyvich Kropotkin 自传中＜纪念一位革命家＞（Memoirs of a Revolutionist）的一段，来解释这个问题︰

因自幼在拥有佃农的地主家庭中长大，当我的生命开始活跃时，就像那时所有的年轻人一样，我们非常相信命令，指使，责骂以及处罚等等行为的必要性，但当我早期必须管理正式的企业时，我要和自由的人打交道，任何错误可能最后都会引发严重的后果，我才开始接受命令和规定与建立共识的不同之处，前者在军事体系中效用极佳，但在真实的生活中却一文不名，真实生活中的目标，是在许多人同心协力下达成的。

「许多人同心协力」（severe effort of many converging wills）正是像 Linux 这样的项目所需要的 ―― 「命令法则」（principle of command）并不适用于被我们称为因特网的无政府主义者志愿者，为了更有效的运作和竞争，想要领导与他人合作的项目的电脑黑客，必须学习如何吸引和激励有兴趣的社群，并且是在 Kropotkin 所建议的「共识法则」（principle of understanding）的模式下进行，他们也必须要学习去使用「Linus法则」⁴。

稍早我提及「Delphi效应」是因为它可能可以解释「Linus法则」，但在生物学和经济学中的自适应系统中，有更多类似的地方可以更有力地印证它，Linux 的世界从许多方面看来，像是一个自由的市场或生态，由一群个体所组成，这些个体以一种自发性的自我更正程序，试着去发挥他最大的功用，所发挥出来的功用比起集中式的规划要来得更精巧，更有效率，这种方式正是在寻求「共识法则」（principle of understanding）。

Linux 黑客们最大化的实际利益不是典型的经济价值，而是在黑客中得来无形的自我满足和荣誉，（你也许可以认为他们的动机是「利他」，但这忽略了一项事实，就是利他主义只是利他主义者自我满足的一种形式），以这种方式进行的志愿者文化并非真的不寻常，就我长期参加的一个科幻小说俱乐部来说，它不像电脑黑客俱乐部那么明显地以「egoboo」（ego-boosting 或在同好圈里增强某人的信誉）做为驱动志愿者的力量。

Linus 在 Linux 项目中，成功地坐上项目守门员的位置（这个项目大部份的工作都由其他人所完成），也成功地培养项目的利基，直到它可以自我维持，这显示 Linus 精确地抓住 Kropotkin 所说「建立共识」的精神，用这个像经济学的观点来看 Linux 的世界，让我们知道共识是如何作用的。

我们可以把 Linus 的方法，视作一条开创有效率市场的路 ―― 以最强韧的方式联合个别的黑客来达成困难的目标，这些目标只有在持续的合作下才能达成。在 fetchmail 的项目中（虽然规模比较小），我已经展示出 Linus 的方法可以用在别的项目，并同样有好的成果，或许我有意地，更有系统地利用他的方法。

许多人（尤其是在政治上不信任自由市场的）以为重视自我的个体文化会造成分裂，自扫门前雪，浪费，私密，和敌对，只要举一个简短的实例，就可以很明显地证明这个看法是错的，这个例子就是 Linux 相关的说明文档的多样，品质，和深度都相当令人惊讶，程序员不喜欢写说明文档似乎是金科玉律，但 Linux 的黑客们是如何写出这么多的文件呢？很明显地，Linux 重荣誉的自由市场运作得要比商业软件生产者重金投资的说明文档撰写公司好。

Fetchmail 和 Linux 这两个项目都展示出藉由适当地回报许多黑客，优秀的开发者或协调者能利用因特网，获得许多协同开发者，但不致让项目因混乱而失败，所以针对 Brooks 定律，我提出以下的反驳︰

格言19︰假如项目开发协调者拥有至少跟因特网一样好的媒体，而他也不靠强制力来领导，那么一群人必定胜过一个人。

我认为开源软件的将来属于知道如何进行 Linus 游戏规则的人，属于离开教堂拥抱市集的人，这并不是说个人的眼光和智慧不再重要，而是我认为开源的软件的优势将属于一种人，他以个人的眼光和智慧开始一个项目，并且之后能有效地号召有兴趣的志愿者群来加入他的项目。

也许不只是开源的将来，非封闭性源代码的开发者也能吸引 Linux 社群的智库到他们的问题上，很少有人付得起 fetchmail 项目中超过两百位的贡献者的雇佣费用。

也许最后开源文化会赢，但不是因为合作是善的，或软件「栅栏」（hoarding）是恶的（假设你相信后者，但 Linus 和我则否），而是因为封闭源代码的世界无法在演化的角力中胜过开源的社群，社群能投入的资源要比封闭源代码的项目来得多。

第十二章 管理与马其顿防线

1997年版的《教堂与市集》这篇文章的结论是 ―― 网络上由程序员（或者该说是无政府主义者）形成的快乐游牧民族，正以锐不可挡的气势冲击著传统封闭软件的阶层式世界。

仍有许多怀疑论者不能信服，但他们提出来的问题应该受到公平的审视，对市集论点最主要的反对意见可归结为︰市集的支持者低估了传统管理的生产力乘积效应（productivity-multiplying effect）。

传统的软件开发经理人反对的论点在于开源项目的偶然性（casualness），项目团队在偶然中成立，改组，和解散，虽然开源社群比起任何封闭开发者拥有人数上明显的优势，但偶然性却否定了这个优势。他们目睹软件开发需在时间上持续付出代价，并且要看客户是否继续投资重量级的产品，而不是有多少人把骨头丢到锅里等待它熬成汤。

这个论点有一些意义，但事实上我已在《神奇熔炉》（The Magic Cauldron）这篇文章中指出，未来软件产业经济的关键在于服务价值。

这个论点也隐藏着一个大问题，就是它假设开源项目无法长久维持，事实上，确实有长久持续发展的开源项目，一直保持一致的发展方向和有效的维护者社群，但其中却没有传统项目管理上的激励组织或制度化控制。GNU Emacs 编辑器的发展正是一个极端且具有代表性的例子，它在十五年间，以统一的结构观点，吸收了数百位贡献者的努力，尽管参与的人这么多，其实只有一个人（原作者）在十五年间持续活跃著。没有一个封闭源代码的编辑器曾创下如此长寿的纪录。

在此，我们有理由质疑传统管理下的项目开发，但这却与其他教堂与市集的论战无关。如果 GNU 的 Emacs 编辑器可以在十五年间，保持一贯的结构，在过去八年间，虽然硬件平台的技术进步飞快，Linux 操作系统也同样做到了，假如（事实如此）有这么多结构良好的开源项目持续的时间超过五年，那么我们不禁要问，传统的项目管理除了带来巨大的额外花费，是否还有其他益处？

传统管理下的软件项目当然不保证在期限内有效执行，不保证不超支预算，不保证实现所有的规格，很难得有一个「管理下」的项目能达到以上任一个要求，更不用说三个都达到了。管理下的项目似乎在它的生命周期中，很难去适应技术上和经济环境上的变化，而开源社群却已证明了开源项目有更高的绩效。（我们可以做一个基本的验证，例如比较因特网三十年的历史和短命的私有网络技术，或者微软windows系统由 16 位转移到 32 位付出的代价和同时期 Linux 轻易地移植到 Intel 系列之外超过一打的平台，其中包含 64 位的 Alpha。）

许多人认为传统商业软件模式下，某些人能提供法律上的保证，如果该软件的方向错了，还可以补救回来，但这是个错觉，大多数的软件合约只宣告商业上的保证，而不是「履行」的保证，而且很少见到有未完成软件成功地补救回来。即使这种情形稀松平常，因为有人可以告而让我们感到宽慰并不是有意义的事。我们不要诉讼，我们要可用的软件。

到底传统项目管理的额外花费带来了什么？

为了了解这个问题，我们首先必须弄清楚软件项目管理者做些什么事，一位我认识的女士在这个工作上表现优异，她说软件项目管理有五个主要功能︰

1. 定义目标，确保每一位成员方向一致。
2. 监督并且确定重要的细节没有被忽视。
3. 诱导成员去做乏味但必要的苦工。
4. 调整成员组织以期发挥最大生产力。
5. 安排足够的资源以支持整个项目。

这些很明显地都是很有价值的目标，但在开源模式，及开源的社会意义下，这些目标看起来似乎很突兀，我们以倒过来的顺序看︰

我的朋友提到争取资源基本上是防御行为，一旦你有了人，有了机器和办公室空间，你就必须保卫他们，以防被其他项目经理抢走，或者被高层榨干。

但开源的发展人都是志愿者，在所从事的项目中，依个人的兴趣和能力，自行分工（就算他们是在有给职下精研开源软件，一般而言，上述仍然属实。）志愿者的风格自动倾向于争取资源的攻方，他们带来自己所拥有的资源，因此对开源项目的管理者来说，很少需要打传统的「保卫战」，或者根本就不必要。

不论如何，在廉价的个人电脑和快速网络网络的世界中，我们发现了一个非常一致的事实︰唯一有限的资源，就是具熟练技术的参与者。当一个开源项目成立后，原则上不需要争取电脑，网络或者办公室空间，只有当开发者们失去兴趣时，它才会结束。

以此为例，非常重要的一点︰开源的黑客们如何自行分工以发挥最大的生产力 ―― 这个环境会冷酷地挑选出称职者。我的朋友同时熟悉于开源世界和大型封闭性项目，她相信开源已算是局部成功了，因为它的文化只接受最具才能的5%或说是写程序的人。她大部份的时间花在组织运用其余95%的人，并且亲身见识到（许多人都知道）最强的程序员的生产力和仅能胜任的程序员相差100倍。

这个差异的倍数一定会引来一个笨问题︰如果个别的项目，甚至整个领域，把能力差的人减到少于 50%，不就好了吗？熟虑的管理者早已知道︰如果传统软件项目管理的功能只在于把能力不及格的人训练到及格，那么软件项目管理就不值得去做了。

开源社群的成功，更加突显出这个问题，证明由因特网上征召自行分工的志愿者，通常省钱又有效，胜过管理整栋在做其他事的人。

以上把我们带向「动机」的问题，与我朋友观点同义的，且常听到说法是︰传统软件项目的管理，是对于缺乏主动性的程序员的一种补救措施。

这个答案通常伴随一点声明︰我们对开源社群能完成工作的信赖，源自于「性感」的吸引力或者技术上的喜悦，缺乏这两个要素的工作，如果不是没人做，就是做得很糟，除非有经理挥动鞭子，驱使不自由的受雇者去搅局，我在＜Homesteading the Noosphere＞这篇文章中已经由心理和社会的因素去质疑这个论点。然而就现在的目的而言，我想︰点出接受这种说法背后的意义会更为有趣。

如果传统，封闭，重管理的软件开发风格所防御的是无趣的问题，那么在该应用领域中，以马其顿防线为手段，只有在无人发现这些问题的趣味，或者无人绕过这些问题的情况下，才算有效。但在目前，软件无趣的部份有了开源的竞争者，使用者将知道最后有人处理的原因是︰因为问题本身的魅力，吸引了解决问题的人 ―― 不只在软件界，或者其他创造性的工作中，问题的魅力是一个比只提供金钱还更有效的推动因素。

如果运用传统的管理结构只是为了激励被管理者的动机，那么这也许是一个好的战术，但却是个坏的战略，短期内会赢，但在长期会输。

到目前为止，传统软件项目管理看起来有两点（安排资源，调整组织）比不上开源，似乎在第三点（动机）上苟延残喘，而被围攻的可怜经理，在监督的工作上得不到任何援助；而开源社群最强的一点就在于分散式的审校，这点胜过确认有无细节被遗漏的任何传统方法。

我们可不可以略去讨论定义目标是不是传统项目管理的额外付出呢？也许吧，但如果要这么做，我们需要一个好理由让我们相信︰管理委员会和运作计划在定义有价值和广义的目标时，要比开源世界的项目领导人和资深参与者更成功。

表面上看起来很困难，但并不是因为作对的开源社群（Emacs 的长寿，Linus Torvalds 谈论「称霸世界」以激励开发者的能力）造成的，因为定义软件项目的目标，是传统机制下的宣示性庄严。

软件工程中最为人所知的一个理论是︰有60%到75%的传统软件项目如果不是未完成就是被使用者所拒用。假如这个数字范围和真实状况很接近（我尚未遇过有经验的经理人在争论这个数字），那么就有更多的项目没有遵循目标发展，而目标如果不是（a）不切实际就是（b）错了。

这点更甚于其他问题，在今天的软件工程世界，「管理委员会」（management commitee）这个惯用语令听的人脊背发凉 ―― 即使（或者特别地）听者本身就是管理者，只有程序员会如此的日子早已过去了；管理者桌上现在都放有「呆伯特」（Dilbert）漫画⁵。

因此，我们对传统项目管理者的回应很简单︰如果开源社群真的低估传统管理的价值，那为什么你们当中有这么多人鄙视你们自己管理的作为呢？

既存的开源社群又再次突显出这个问题 ―― 因为乐趣在我们所做的工作中，我们有创意地游戏着，已经以惊人的速度带来技术上，市场占有，和心灵分享上的成功，我们正在证明我们不只能写出更好的软件，而其中的乐趣也是一项资产。

在这一篇文章第一版发表后的两年半，我所能提供的最基本想法，已不再限于开源的视界，但毕竟对许多在过去这些日子身陷诉讼而清醒的人而言，这些想法似乎都是合理的。

甚至，我想提出一个对于软件更深广的认识（也许对每一种造创或专业的工作都适用）在最适挑战 ―― 不会太容易而令人厌烦，不会太困难而难以达成的工作中，人们会获得乐趣，一个快乐的程序员的条件是︰工作量不会太轻，也未被定义不良的目标和压力下的摩擦过度压榨。享受乐趣确保了效率。

相对于在你的工作过程中，如果有恐惧和强烈的厌恶（即使如呆伯特漫画中表达出的变换或讽刺方式），那就表示这个工作过程是失败的。乐趣、幽默、和游戏性是真的资产，这也是我前面为什么写出「快乐的游牧民族」这个名词，而 Linux 的吉祥物是隻人见人爱的企鹅也不仅是个笑话。

将来的事实会证明开源最大的成功之一就是它告诉了我们︰如玩游戏般地工作是从事创造性工作最经济、最有效率的模式。

第十三章 结语︰网景公司拥抱市集！

当你真的在影响历史时，那种感觉真的很不一样…

1998 年 1 月 22 日，大约是我第一次发表这篇文章之后七个月，网景公司公开声明他们计划要释出通讯家族（Netscape Communicator）的原始代码，之前我对这件事情的发生一点头绪也没有。

网景的执行副总裁兼首席技术官 Eric Hahn 寄给我一封电子邮件，内容简要如下︰「我代表网景公司的每一个人，向你致谢，因为你帮我们成为第一家做到开源的公司，你的思想和著作是我们做出这个决定的原因。」

接下来一个星期，我接受网景公司的邀请，搭飞机到硅谷参加他们长达一天的策略会议，参与会议的有该公司顶级执行者和技术人员，我们一起设计出网景公司开源的策略及版权，也做了些计划，希望能对开源社区有长远而正面的影响，就如同我之前所说，这件事来得太快，以致于我们定出的策略和版权还不太明确，但在几周内，细节应该可以交代清楚。

网景公司愿意提供一个真实大型的试验，在商业世界中测试市集模式，因此开源的世界正面临著一个危机，假如网景的行动不成功，那么开源的观念在商业界也许就会被鄙弃，在十年内大概不会有公司再碰它。

另一方面，这也是一个空前的机会，华尔街和其他地方对这件事的初始反应是谨慎地正面评价，我们拥有这个机会来证明开源是有益的，假如网景藉此行动而重新获得实际的市场，那么它将引发软件工业中一场迟来已久的革命。

明年（1999）将会是非常有意义而且有趣的一年。