释放源代码：Mozilla的故事

Jim Hamerly，Tom Paquin，Susan Walton 著

章远琳 译

洪峰 校

1998年2月23日，Netscape发表了两个声明。第一个声明在CINet报道中称：“在一种史无前例的运动中，Netscape Communications公司将会把Navigator浏览器拱手相让，这证实了过去几周内业界中的传闻。”

而另外一条消息则是：“在将Navigator浏览器出让的同时，要将下一代communicator套件的源代码公之于众。”

将浏览器出让的决定并不令人感到奇怪，但是公布源代码的做法确实让业界为之一震。该条消息出现在世界各地的报纸上，甚至连开源软件社团（Open Source community）为此也感到惊讶。从来没有一家大的软件公司将其拥有版权的代码公开过。Netscape的做法究竟意味着什么？

我们已经决定转换游戏的领域，而且也不是第一次这样想过。我们总是从这个领域以外得到过很多的想法，这一次Netscape为建立一个更好的Internet环境以到达一个新的层次作出了贡献。1994年当Netscape最初没有限制在Internet上分发其早期的浏览器版本时，就有人说：“他们真是疯了！”，而现在当Netscape提到“释放源代码”时，人们仍然像从前那样评价他们。

这个问题的讨论将开源公告比喻成一个正常运行的火车。在经过几个月对于是否要将运行包免费分发的讨论后，在令人难以置信的24小时里，大家达成了一个协议，也就是将源代码公布于众。

无论对于业内人士还是业外人士，这个举动都是非常迅速而令人奇怪的，它反映了几个不同思路的融合之处。Netscape的执行官们正在讨论一份由Frank Hecker起草的白皮书，在白皮书中Frank描述了一个即将到来的前景。他提倡将Netscape的源代码免费公布。Frank已经完成了他的工作，引用Eric Raymond的文章——《教堂和集市》告诉人们如何将部门规划推及到整个机构——从工程到市场再到管理，在这篇二十多页的著作中很好的得到了全面的讲述，他称从中得到了源泉和动力：

当最初Netscape第一次将Navigator通过Internet网络让用户不受限制地下载时，许多人认为这种做法与传统意义上的商业化软件的赢利模式是背道而驰的。并且询问我们如何能够通过“将我们的软件公布出去”来赢利。当然，现在这个策略在Netscape的快速增长过程中，是一个关键性的成功因素，并且被视为是一场成功的革新，而目前少有软件公司以一种或多种方式来效仿我们的做法。于是随后而来的问题是：将来是否我们要重复这种做法，仅仅是只有这一次将源代码公布于众？

在工程领域也有相似的看法。许多的Netscape雇员都有过同开放源代码运动相互关联的工作经验。而且因为Communicator的代码同Java和HTML紧密相连，大多数人认为有一个明显的事实：这不是一个非常大的跳跃。Java的特性本身就引入了更开放的观点来看待发行源代码。因为它是跨平台的，在编译成类文件之后可以成为独立与机器的可执行代码，每一个可执行的二进制类都像是一台虚拟机。这一努力的结果之一是程序员可以反编译可执行代码，并将它转换回源代码。而浏览器的“观察源代码”（view source）命令使得HTML成了一种普通的方言。许多人相信Netscape应该具备这一功能，而不是放弃它，应该鼓励这一点，如果可能的话，甚至应该从中受益。

许多学术思想是在出人意料的瞬间合并的。在多次会议中，对这一建议的反应在几分钟内从发愣、震惊变成了点头同意。大多数讨论很快地从“我们是否应该”过渡到“什么时候。”大多数关键人物认为我们应该快速向前进，确定最终日期，实现目的。在元月份，Netscape向网络界作出了承诺：Comminucator的源代码在1998年的第一季度发布。Netscape的这一承诺是极其严肃的，而且Project Source 331随即启动。这一切努力都是为了让Netscape能在1998年3月31日提供源代码。

接着我们便开始真刀真枪地干了起来。

生米煮成熟饭

Communicator源代码的主体在Netscape公司被称为“Mozilla”。Mozilla最初是由Jamie Zawinsky和公司在开发Navigator时杜撰出来的一个词。小组方式正在以近乎狂乱的节奏创建一个功能要比Mosaic要大得多的庞然巨兽。最后这一代码的正式名称称为Navigator。后来，这一大绿色恐龙成了公司的一个笑话，接着成了一个公司的吉祥物，最终成了一个公共的符号。现在这一名称的用法更加通用了，用来指从Netscape Navigator衍生出来的开源web浏览器。说法改成了“释放壁虎”。

在代码第一次准备好公布之前，要完成的工作量是惊人地巨大。由于事情已经表面化，他们将自己分成几类，各司其职。大家都感到接下来的三个月将用于以Netscape公司都知道的那种近乎狂乱的节奏来解决问题。

最大的问题是包含在浏览器中的第三方模块的处理。Communicator的源代码中包括了不少于75个第三方提供的模块，我们需要与所有第三方代码的版权所有者打交道。我们安排了由工程师们组成的小组和布道者，让他们访问每一家公司，并向他们推销Netscape的开源观念，希望他们能成为我们的同志。他们所有的人都听说过Netscape公司宣布的开源决定，现在每一个公司都要作出选择：他们的代码可以被删除，或者被替代，以二进制形式发布（将它们保持在编译过的状态），或者以源代码的形式与Communicator一起发行。由于情况复杂，许多第三方的承包商情况比较特殊，所以每一家公司所消耗的时间也是长短不等的。没有一个普适的方案适用于所有的情况。

为Project Source 331制定一个最后期限是一个基本考虑。这一最后期限需要艰难的选择。当然第三方开发人员参加进来是可能的。规则是你要么在2月24日前宣布接受条件进入，要么是从源代码中被清除掉。当然我们一开始就设置这一最后期限是不难的，但是如果我们敲打墙壁与他们争吵，则他们会觉得我们那样做是让人难以忍受的。当时间一天天过去时，一些代码必须被清除掉。

Java是一种专有语言，所以它必须被清除出来。我们指定了三个工程做“Java切除手术”——也就是说，浏览器必须在没有Java的情况下创建、编译和运行。由于原来的整个代码都是与Java紧密集成的，这个手术的难度是很高的。而且给他们设定的目标是在3月15日之前将源代码搞好，以便腾出最后的两个星期的时间用于测试。可怜的工程师们必须在极短的时间内在浏览器内将所有的Java代码理清楚。

彻底清理代码是一项巨大的工程。刚开始时，许多人感到在最后期限前要完成这一工程是不大可能的。但是在多次会议中，大家的热情不断高涨，并形成了战略，车轮开始转动起来。开发组扔掉了他们的整个工作负荷（大部分代码是在为下一代的浏览器开发的），每一个人的任务变成了外科手术。我们不仅纳入了（或者删除了）每一个要解决的第三方模块，而且为代码编辑了所有的注释行。每一个模块的责任都分配给了小组，然后由他们去擦洗。

开始时一个伟大的革新是，我们决定使用Intranet的bug报告系统作为任务管理员。“Bugplat”是Scopus的名称，这是一种错误报告程序，它的前台是HTML界面。这是一个极好的工作流管理系统。一旦新的任务出现，系统便开始报告，输入是简单的HTML表格。一旦得到bug的报告，系统立即设置优先级别，接着便决定相应的人员来解决问题，而且立即围绕这一bug创建一个邮件列表。一旦一个任务（或者一个bug）被解决后，所有相关的邮件列表和优先级别将被停止，而且从视野中消失。工程师们可以跟踪他们的模块的进展，并且通过登录到Intranet上观察工程开展的情况。

删除加密模块是工程师小组的另一项艰巨任务。不仅政府要求所有的支持加密的代码必须清除掉，而且每一个调用它的句柄都需要编写。小组的一项特有工作是与NSA（美国国家安全局）保持经常的联系，以管理合规性（compliance）之类的事情。

创建许可证

与代码大清洗同等重要的事情是创建许可证。第一步是要解决一个大问题：现存的任何许可证是否都适合开源软件？没有一个人想起草一个新的许可证，但是每一个人都意识到必须有一种许可证可以适用于所有第三方的代码，使得这一工程可以运行在企业水平上。现有的专有版权的软件没有一个是按照自由软件的许可证发布的。

一组开源软件社团的领导，包括Linus Torvalds、Eric Raymond、Tim O’Reilly被邀请去参加Mountain View校园。他们对企业领导、律师和程序员发表了演讲，他们谈到了他们代表什么，并且与一些小组谈到了他们愿意面临的一些问题。他们花了大量的时间与Netscape的法律小组讨论了现存的许可证——他们既谈到各种不同类型许可证的力量，也谈到了它们引起的问题。这些顾问还起着著名的创意班子的作用。

在得到这些顾问的意见和Netscape法律小组的指导原则后，一个小组开始深入研究现存许可证协议，试图判断是否有一种许可证可以Mozilla的要求。首先讨论的是GNU General Public License，GNU Library General License和BSD许可证，我们花了很长时间考查并总结了这些许可证解决的问题和引起的问题。与过去应用这些许可证协议的代码不同，Netscape现存的代码基（Code Base）具有独立的环境。一个最棘手的问题是，在代码中使用了相当多的第三方元件，而这些东西受专有的许可证协议的约束。显然，我们需要创建一种环境，在这个环境中，这些和其他一些新的商业开发人员可以贡献他们的代码给Mozilla，而Mozilla的许可证可以保护他们的商业利益。

BSD许可证更加宽容，它只要求版权持有人原封不动地出现在代码中，但是这对Mozilla的开发是不充分的。它会让开发人员承担这样的风险：对代码的改进不会返回给他们或者社团的其他人。仅此一点就是一个很大的问剧，因为它对开源开发努力长期地存在下去很关键。

另一方面，GPL的要求又使它在这一工程不受欢迎。GPL是“不健全的”，当把它用在一段原始的代码中时，任何其他与原始代码一起编译的代码也必须受GPL的约束。这一点对商业软件开发人员是不可理喻的。例如，GPL可能会要求一个编译进了属于商品版本的Communicator第三方的元件也要按照GPL来发布，有些事情超出了Netscape的能力，因为Netscape不能控制这些第三方开发商，并且Netscape也在自己的其他产品中使用了一部分Communicator的代码（诸如服务器端的程序）。因为Netscape没有立即发布那个代码的计划，所以GPL对这些产品的不健全作用将会对Netscape和其他公司构成相同的问题。GPL的一种改进，LGPL显得更加开放或者限制更少，最接近满足于Netscape商业开发的要求，但是它还是与GPL一样含有太多的商业陷阱。

经过一个月的拼命研究、讨论、并且与自由软件社团的专家和辩护者开会之后，如同公众的推测那样，小组决定搞出一种新的许可证来解决这一特殊问题。Netscape Public License（NPL）出现了，它试图在商业企业推广自由软件开发和保护自由软件开发之间达成一种妥协。制定这一个为下一步开源软件许可证的过程花了一个月的时间。

还有一个非常之处就是，Netscape Public License（NPL）开始时是以由公众可以对它进行贝塔版本测试的形式提出的。我们在netscape.public.mozilla.license这个新闻组提出了这一许可证的草稿，并请求大家进行公开评论。大家反馈的意见好坏参半。这份许可证草案的有一节像是一块打火石，引来了最多的批评：NPL的一部分条款向Netscape提供了特别的权力，让Netscape在它的其他产品中使用这些受NPL约束的代码，但是那些其他产品却不受NPL的约束。它还允许Netscape发布NPL的修订版本，最引起争议的是，受NPL约束的代码再授权给第三方时的条款与NPL是不同的。有些人提出的反馈意见说，仅凭这一点实际上就让开源软件社团不能接受NPL。

3月11日，jwz（Jamie Zawinsky）出现在netscape.public.moziIla.Iicense新闻组中，他写的部分内容如下：

首先。我感谢你们提供了大量的反馈意见。这些意见对我们是极有帮助的。我们在认真听取了大家的批评之后，提出下面的意见。

你们在下个星期将会看到第五节已经经过了大幅的修改，或许我在这里不应该发表过多的评论（我不打算设置一个不正确的期望值），但是。你们大家都讨厌的那一部分的内容现在已经很清楚。

3月21日，许可证的修订稿发布了，过是没有先例的。反响巨大：“我告诉他们这是令人不快的，但是他们听进去了！我简直不敢相信！”大家意识到这是一个真正的开源工程，尽管开源工程并不是从这里起源的。新闻组中的讨论一直在帮忙指导这一过程，而不是对它的结果提供评论。后来持续不断的讨论语调一新，而且人气旺盛。

对NPL贝塔版本的批评使许可证小组回到了起草委员会。他们找到了一种方案，可以让Netscape在吸引自由源代码开发人员的工作不偏离目标，和满足公司的商业目的之间取得了一种平衡。结果是经过修改的NPL第二次发布了，名称为Mozilla Public License（MozPL）。除了NPL包含对Netscape提供附加权力的修改内容之外，NPL和MozPL是等同的。

1998年3月31日，所有的代码都在NPL的许可证形式下发布了，而且对代码的改进也是在NPL许可证形式下发布的。新开发的代码将按照MozPL的形式发布，或者按照任何与之相兼容的许可证形式发布。如果对源代码中包含的文件进行改动，将被视为是修改，将受NPL的约束。这消除了网络界很多人的疑虑：不含任何原始代码或者根据原始代码修改的代码的新文件将不被视为修改，而且不受NPL的约束。这样得到的代码可以受任何相兼容的许可证的约束。GPL与NPL或者MozPL是不相兼容的。GPL在一开始就设计得与任何其他的许可证都不相兼容，因为GPL在它的边界上禁止增加任何限制或者更远的许可。所有用GPL软件开发的代码必须回到受GPL约束的范围内。另一个小问题是GPL坚持当你发行受GPL约束的代码时，你发行的代码必须是完全完整的。但是NPL没有这一限制条件。

新闻组中的讨论为我们坚定信念，带来了一个重要的内容：开发人员需要Netscape允许在对bug的修改代码和新的代码之间作出区分。显然，如果一个人说：“我排除了一个bug，并对你的程序作了一点小的改进”，而另一个人说：“我为你的程序增加了新的特性”，那么你听到这两个人的说法后会产生不同的感觉。大多数人感到排除了一个bug不算什么，它的价值通过贡献出除错代码本身就得到了体现。但是新的代码却完全不同。一个完成了很多新工作的人不想看到有人会利用他的代码去牟利。

NPL和MozPL都是设计用来鼓励在Mozilla代码基上进行开放的开发，但是从一开始，我们的头脑中就有另一个目的。Netscape愿意成为第一家公开它的专有版本代码的大公司，因为它想吸引更多的公司在开源环境中进行开发的兴趣。创造一个气氛使得大型的赢利的组织采纳这一模式并跻身于这一运动是最重要的。在大多数开源许可证中的法律基础对于公司合作是一个大的障碍。有了Mozilla之后，许可证的问题成了它本身必须解决的问题。

通过公开今后版本的源代码，我们希望它能鼓励网络上的整个团体在浏览器市场上产生新的革新。我们的想法就是让全世界有才华的程序员玩味我们的代码，用他们的创新能力不断地为浏览器奉献新的生机，即使前途艰险，荆棘丛生，也能鼓励每一个人勇往直前。

Mozilla.org

以前投入到开源工程的人已经意识到，必须要有一个地方来存放代码。在Netscape宣布释放源代码后的那天晚上，Jamie在InterNIC上注册了一个新的域名，并且就如何发布已开发项目的工作拟定了一个方案。于是，Mozilla.org就这样诞生了。

所有成功的开源软件工程部遵循一个模式，这并非是设计上的需要。也就是说，要有一个人或者小组做协调工作。无论什么人对他们关心的代码做了什么工作，都会引起他们自己的兴趣。一天下来之后，他们可能会对一些代码作出一些小的改进。但是一个月过去之后，当软件的新版本发布之后会出现什么情况呢？这时的情况可能比较复杂：他们当初的修改方案对于开放可能已经过时了，还可能需要回到原来的出发点——甚至更糟糕的是，因为软件本身可能也已经变了。

结果是，开发人员想将他们的补丁包含在主要的发行版本中。如果只有一堆源代码出现变动，而且有一批人围绕着这堆代码工作，那么最终会有一个人站出来说：“我想收集一批补丁的代码，并且搞出一个发行版本来。”当第二个人问：怎样将他的补丁加入到下一个发行版本中时，第一个人会说：“我不知道我的补丁还会有谁要，所以我会把代码提供给那个人。我相信会对它作出改进。”随着时间的推移，那个人会成为维护者。

对于这个开源工程而言，马是套在马车的前面。mozilla.org的人从一开始就认为并且将自己设定为维护者的角色。因为总是需要一某种方式产生这一角色，所以我们决定创造出一个基础结构以成为清算中心。

在接下来的几个月中，rnozilla.org开始成了一个组织，并且得到了资金支持和设备，启动了邮件列表，并且为开始必要的工作扫清了障碍。任务只是让组织从头开始，并有效工作。关键是一旦源代码发布之后，在运作时应该有一个中心的储存点。如果我们不作准备的话，那么六个月以后，我们得寻找其他某个人来做这件事。大家都知道Netscape不会守株待兔。

释放了源代码意味着Netscape将与Internet协同工作。当时需要接受一个关键概念：Netscape客户产品开发小组（Netscape Client Product Development Group）和mozilla.org不是同一个组织。Mozilla.org的目的是为全世界围绕这一软件的所有人充当协调人。而Netscape客户产品开发小组的目的是发运产品——基于Moilia代码的Netscape产品。因为两个基本点小组都为同一个产品工作，所以他们的利益可以有所重叠。但是mozilla.org后面的小组知道，如果Internet上的人看到这个组织之后说：“啊，这些人心里只有Netscape，他们只是发运Netscape产品而已”，那将是灾难性的。这意味着mozilla.org没有达到充当一个好的维护者的目的。因此必须将“Netscape客户产品开发小组”和“mozilla.org”两者隔开，并且让网上的人知道这个情况。

垂帘的后面

当一个开发人员改进了代码并且提交出来后说：“嘿，mozilla.org，请采用我的代码吧！”会出现什么情况呢？Mozilla.org最重要的一个角色是制定一个标准，以确定可以接受什么样的代码，以及不能接受什么代码。我们必须将这一问题转化为好几个子问题。首先而且最重要的是，代码的优点何在，代码真的好吗？第二，代码是否满足NPL许可证的要求？我们决定，不接受不能满足NPL许可证的贡献者提供的代码。如果不这样做的话，那么情况将会和修建万里长城一样，每一个人将会陷入没完没了的法律认可事务中，而且潜在的问题也会相当地多。

由于Mozilla采用了高度模块化的代码基，每一个主要的模块，例如Image Library（图像库），或者XML解析器，有一个指定的“拥有者”（owner），这个人最了解代码，他可以仲裁什么东西应该进入模块，而什么东西不应该进入模块。

许多模块的拥有者是Netscape的工程师，但是也有一些来自网络世界的五湖四海。当一个模块的拥有者决定进行修改时（例如，向Image Library增加一个API），他的修改草案将寄往Mozilla.org，以便在发行版本中含有修改过的内容。如果在贡献者和模块拥有者之间出现了不同意见，那么Mozilla.org将扮演仲裁者的角色，并作出最终的裁决——当然他总是会注意，如果他的某一种做法妨害了公平竞争，那么他将会被大家瞧不起而被忽略掉，而且将会出现某个人替代他的职位。

Mozilla.org必须坚持让Netscape内部的开发人员和在网络上的人们都可以对代码进行改进。在公司内部工作的人可以在Web上，而且可以从所有的平台、在任何时间进行存取。这是由Bonsai和Tinderbox这些工具完成“tree control”的。

Bonsai这个工具可以让你对一个档案的内容进行查询。它就像国书馆的前台，你可以对你工作过的代码进行检查，或者查看由其他人完成并加入了什么代码。在后台，Bonsai经常地运行代码，检查代码树。如果树折断了的话，那么它会发出一个红色旗标，在问题得到明确以前，停止更多的代码进入档案。你可以将日志拉出来对某个特定时间期间的问题进行踉踪。这一工具以前只是被Netscape内部的开发入员采用，但是后来被mozilla.org拿来供全世界所有的开发人员使用，而且在任何平台上都可以利用浏览器来直接使用它。

如果你的开发人数超过十人，而且没有工具的话，那么情况马上会失去控制和爆炸。在Tinderbox后面有一种理论，Tinderbox是一种让可能潜在爆炸局面得到控制的程序。Tinderbox是一种探测工具。它允许你查看在代码树中正在发生的事情。它显示谁检查了什么（通过询问Bonsai），什么平台建立成功，什么平台已经垮掉，并且精确地告诉你它们是怎样垮掉的，建立成功的文件的状态，以便你可以跟踪并找出究竟是什么原因导致破坏的出现。

1998年的愚人节

在1998年三月底前的一个半星期，最终期限马上就要到了。大家都感到需要开一个庆祝会来祝贺代码的发行，但是当时什么也没有做。为了保留这一工程的其余部分，邀请公众进入Netscape没有设防的世界的举措，将是一个破天荒的事件。

在一次会议上，Jamie列出了一份计划，准备租用旧金山的一个夜总会，邀请全球的人，并通过Internet进行广播。“你是说邀请非公司雇员来这个庆祝会吗？我们可是从来没有这么干过啊！”为了让项目的其余部分富有新意，在一阵停顿后，大家的反应是......“为什么不这样做？”

庆祝会没有被很快忘掉，Jamie租用了The Sound Factory，这是旧金山的最大夜总会之一，而且时间定在四月一日晚上。晚会的主持人（包括Apache的创始人Brian Behlendorf）在晚会上散发了几千件恤衫，以及由NetObjects、Macromedia、Digital、Be、Wire和unAmerican Activities提供的软件和东西。

当晚上八点“Mozilla Dot Party”开门时，门口已经排起了长队。一个半小时后，能容纳两千人的夜总会场地被挤得爆满，而且夜总会建筑物的周围也挤满了人群。在夜总会的其他一些人离开后，晚会开始在八点钟放人进场，到晚会结束时，有3500多人进入了会场，包括一些自由软件的大师（例如Brewster Kahle，WAIS的创始人，以及Eric Raymond）。成百上千的人将手表调准时间，全球都为Mozilla祝福。虚拟与会者包括云集在荷兰阿姆斯特丹Waag城堡的人群，以及分布在挪威、加拿大的蒙特利尔、宾夕拉尼亚、北卡罗莱那、威斯康星、科罗拉多和阿拉巴马的人群。

在会场内部，三个投影屏幕以大约每秒60行代码的速度滚动地显示了代码。（按照这一速度，晚会将花至少七个小时才能显示完Mozilla的全部一百五十万行代码）。晚会的第二个节目由Brown Band（Netscape的一个极具个性的工程师）和专程从费城赶来赴会的Eric Raymond主持表演。他们上台后，分别独奏笛子，的确让全场观众大吃一惊。到晚会快结束时，一打刻录了Mozilla源代码的光盘和签名版本的光盘（上面有头天晚上Netscape Build Team和mozilla.org成员的签名和编号）被抛向了人群中的幸运观众。壁虎（lizard）被释放了！

作者简介

Jim Hamerly

Jim Hamerly是Netscape Communication公司客户端产品部门的副总裁。1997年6月，Netscape公司兼并了DigitalStyle公司，当时Jim是该公司的一个创始人、总裁和CEO。

在建立DigitalStyle公司前，他是Pages软件公司的副总裁、工程师。在该公司中，他负责管理公司的开发工作，包括桌面出版工具、WebPages和第一个所见即所得（WYSIWYG）式的Web创作工具。

Jim在同Xerox公司合作的15年中，参与了R&D和产品开发的各种活动，最近的工作是XSoft项目的执行总工程师，而该项目是Xerox公司软件部的项目，他负责四条产品线的开发。Jim获得过MIT、UC Berkeley和卡耐基梅隆大学的电子和计算机科学的学士、硕士和博士学位。

Tom Paquin

Tom Paquin最初加入了IBM研究部门为有关并行处理器的项目工作，并以从事位图图形加速器（基于AMD 29116）而结束，而该项产品随后被用于新型的PC上。在MIT和Brown大学完成了对X6和X9的修补工作后，他参与了卡耐基梅隆大学移植商业X11系统的部分工作。

Tom在1989年5月加入Silicon Graphics公司（SGI），在该公司他从事了并不如意的工程项目——集成GL和X。1994年4月，他加入了Jim Clark和Marc Andreesson工作的Netscape公司。他是最初的工程经理，他领导了他的小组发布了Mozilla的1.0到2.0版本。现在作为Netscape的一名成员，他从事的工作是mozilla.org的经理，问题仲裁者及其神秘政策的领导者。