开源：一种商业策略

Brian Behlendorf 著

徐六通 译

洪峰 校

在过去的1997年和1998年中，诸如Linux、FreeBSD、Apache和Perl的开源软件开始获得了一批新群众的广泛关注，其中包括工程经理、工程执行者、业界分析家及投资者。

这类软件的开发者欢迎这一关注，因为它不仅鼓舞了开发者的自豪感，也使得他们能向上层管理者及同伴们证明他们所做的努力是有益的（现在，这一点越来越关系到他们的薪金和职位）。

但是这些新的群众也有棘手的问题：

• 这真的是开发软件的新方法吗？

• 开源软件的每一次成功都是大环境中的侥幸获得，还是所有这些成功遵循着一个可重复的方法论？

• 我把珍贵的资金注入一个项目，而竞争对手却可以免费获得并使用同样的代码，究竟是为什么？

• 由黑客或计算机科学大学生发起的这种整体开发模式的可信度到底有多高？他们也许仅仅是恰巧把适当的比特组合在一起使某些东西能很好的工作而已。

• 这会使我们目前的软件构造及商业运作方法受到威胁或甚至遭到淘汰吗？

我建议将开源模式作为指导开发商业软件的一种确实可行的模式。我将列举出这种项目的先决条件，什么类型的项目采用这种模式有意义，一个公司在启动这样一个项目前应检查哪些步骤。本文运用于那些发布、销售和支持商业软件的公司，也适用于那些在商业过程中将某一软件作为核心组件的技术公司。

一切有关平台

我的的确确是一个开源软件开发方法的执著爱好者，确实有这样的情况，即开源方法可能没有给投入方带来任何好处。对这种模式即使采取一种折衷方案，回报也绝不会有所保证。一个恰当的分析需要问问自己作为一个公司，你的长期目标是什么？以及你目前竞争优势又在何处？

让我们以应用程序接口（APIs）、平台以及标准作为讨论出发点。为了本文的目的，我将把APIs（如用于构造客户模块的Apache服务器API），类似HTTP的在线协议，以及操作系统的约定（如Linux组织系统文件的方式，或NT服务器的管理方式）归入到一般性的术语“平台”之中。

Win32，由Microsoft定义并提供给所有Windows95/NT应用开发者的整套例程及工具的集合，就是一个平台。假如你打算为人们写一个在Windows上使用的应用程序，你必须使用这个API。假如你打算写一个操作系统使其能运行原本为MS-Windows编写的程序（如同IBM曾经为OS/2所作），你必须实现完整的Win32 API，因为这是Windows应用程序能够运行所必需的。

同样的，公共网关接口，或“CGI”，是一个平台。CGI规范允许Web服务器开发者编写在Web服务器后台运行的脚本和程序。CGI与Win32相比是一个非常非常简单的平台，当然其功能亦更少些。但是它的存在对于Web服务器市场而言是极重要的，因为它使得应用开发者能编写可移植代码，而程序可在任何Web服务器的后台运行。除了复杂性的数量级大大降低之外，CGI和Win32之间的一个关键性区别是：CGI规范不为任何人所拥有，它仅仅是大多数Web服务器实现了的东西，使得它们可以相互运行对方的CGI脚本程序。只是在使用了若干年之后，IETF（Internet工程任务组）才认为值得为CGI定义规范作为IETF正式的RFC。

一个平台本质上定义了一个软件，可以是任何软件，如像Netscape Communicator这样的Web浏览器，或Apache。平台使得人们能在一个软件上构造或运行另一个软件，因而也非Internet领域所特有，像HTTP和TCP/IP这样的公共平台确实促进了Internet的爆炸性增长，但在单机环境中平台也已越来越多的作为一个要素加以考虑，无论是一个服务器的环境，还是一个最终用户的客户环境。

在Apache项目中，我们非常幸运，依靠早期开发的内部API，我们可以区别内核服务器功能（处理TCP连接，子进程管理，基本HTTP请求处理功能）和几乎所有其他高层功能（如日志、CGI模块、服务器端的Includes、安全配置等）。有了真正功能强大的API，又使得我们可以放手把其他大的功能模块，如mod_perl（将Perl解释器绑到Apache中的一个Apache模块）和mod_jserv（它实现Java Servlet API），交给不同的授权开发者。这样把内核开发从建造一个“庞然大物”的担心中解放出来，以便将更多的精力投入到维护和改进服务器内核上。

有些商业运作是建立在拥有软件平台的模式上的。这类商业运作可以对使用该平台进行收费，无论是基于标准软件安装，还是基于每用一付费（pay-peruse），或者其他模式。有时平台是具有版权约束的，有时对于公共消费方面缺乏书面描述而变得有些模糊，有时它们发展的太快，由于非技术原因，其他试图提供该平台者没能跟上步伐而被市场认为是技术上“落后”的，即使它可能与程序设计无关。

这样的商业运作模式，虽然对拥有该平台的公司有潜在的短期利益，但有悖于业界任何其他公司的利益，有悖于技术进步的整体速度。竞争者可能有更好的技术，更好的服务，或者更低廉的价格，但因为他们不能访问该平台，从而不能利用该平台带来的好处。反过来讲，顾客们变得依赖于某个平台，当价格上涨时，他们被迫在两者之间作出选择：或者支付少量费用以保证在短期内继续使用该平台，或者花费大量的金钱以转而使用一个不同的平台，即使从长远考虑，这样可能更节约金钱。

计算机和自动化越来越成为日复一日的商务活动中必不可少的基本要素，以至于明智的商务活动不应该依赖于单一的供应商为其提供最基本的服务。具有对服务的选择权不仅意味着有选择的自由，一次选择也必须是能够做出的。改换的费用是自由选择的一个重要方面。如果改换软件时并不需要改换平台，则改换的代价可以保持最低。这样，从顾客的利益出发，他们总会要求所配置的软件是基于非专有的平台之上的。

这一点对于许多人而言很难做出形象化的解释，因为经典经济学，如我们在高中所学到的供求曲线，是基于这样一个概念：销售的产品具有一个相关规模成本——即卖出十倍产品对于卖家而言其原材料的成本也大约在十倍这一数量级上。没有人曾预见到软件业所展示的戏剧性的规模经济，生产一个软件产品所做的投入和那些购买并使用的人们的数量之间几乎没有任何直接的相关性。

实现在线协议或API的开源软件的“参照体”（reference body）比起两三家独立的非开源的实现来，对于该平台的长期健康发展更为重要。为什么是这样的呢？因为一个商业实现总是可以被一个竞争者所买断，将其撤出市场，从而摧毁了标准是独立的这样一个观念。它还可以作为一种学术的理论框架，用来比较不同的实现方案及其行为。

有些机构像IETF和W3C，他们或多或少为多方标准开发提供论坛做了卓越的工作。总的来说，他们在为Internet的运作方式制定高质量的体系结构是颇为有效的。可是，一个标准的长期成功，及这样一个标准的广泛使用，则不在他们的职责之内。他们无权强迫成员机构生产软件去实现他们所忠诚地定义的协议。有时，唯一的用途是证明为什么一个特定的实现是正确的这一工作本身。

举例而言，在1996年12月，AOL对为其客户访问Web站点而定制的HTTP代理服务器作一小小的改变。这次“升级”伴随着一个小小的曲解（a cute little political twist）：当时Apache才诞生几个月并且实现的是新的HTTP/1.1规范，当AOL用户访问由Apache 1.2服务器到创建的Web站点时，他们得到的是这样一条通告消息：

“UNSUPPORTED WEB VERSION”（不被支持的Web版本）

“你所请求的Web地址，在AOL支持的版本中不可提供。问题出在Web站点而非AOL。这个站点的拥有者使用的是不受支持的HTTP语言。如果你经常收到这样的消息，你就要在关键字PREFERENCES下将Web图形首选项设成COMPRESSED。”

从这一“升级”的警告，Apache的内核开发者圈定并分析了情况。向AOL技术组发出的询问得到下面的解释：

“新的HTTP/1.1 web服务器对于HTTP/1.0请求原本应该产生HTTP/1.0响应却产生了HTTP/1.1响应。现在通过阻塞这种响应我们就可以阻止这种错误的增生扩散，甚至变成一种事实标准的趋势。但愿这些Web服务器的作者能修改他们的软件使得仅仅当提交的是HTTP/1.1请求时才产生HTTP/1.1响应。”

不幸的是AOL的工程师们处于HTTP/1.1响应与HTTP/1.0客户或代理端不反向兼容的错误假设下。其实不然，HTTP稍作修订即可做到反向兼容。但是HTTP/1.1规范太复杂，尤其是1996年底的那个HTTP/1.1文档，以致于不彻底读懂它会导致人们得出相反的结论。

所以我们Apache开发者有这样一个选择——我们可以回过头来对HTTP/1.0请求给出HTTP/1.0响应，或者我们可以遵循规范。Roy Fielding，我们小组中的“HTTP警察”，清楚地向我们证明了此时软件的行为是正确且有益；还可能会有这样的情况，当HTTP/1.0客户端发现服务器支持1.1版时可能会希望升级到一个HTTP/1.1对话。还有一点也很重要，即应该告诉代理服务器。即使它所看到的第一个通过代理去往原服务器的请求是1.0版，原服务器也可能支持1.1版。

最后决定，应该坚持我们的论据并要求AOL去修改他们的软件。我们怀疑他们的软件中HTTP/1.1响应导致问题的原因很可能是这一部分臃肿的程序设计问题而非协议设计的问题。我们的决定是有科学依据的，特别是在那时Apache占有网上40%的Web服务器，而其中部分Apache 1.2运行得非常好，所以他们必须决定是修改其编程错误更容易些，或者干脆告诉他们的用户说Internet上约20%或者更多的Web站点不能通过他们的代理服务器进行访问。12月26日，我们在Web站点上发布了详细的辩论文章，不仅通告了我们自己的用户群，也发给了象CINet和Wired等几家大的新闻社，以证明我们行动的正确性。

AOL决定修改其软件。与此同时，我们宣布提供“补丁”给那些想要解决但未解决AOL这样问题的站点，这就是为AOL把响应降至HTTP/1.0的补丁程序。我们坚持这是一个“非正式”的补丁，不提供技术支持，也不会作为正式发行中的缺省设置。

有许多别的例子表明其他HTTP产品的供应商（包括Netscape和Microsoft）与Apache均有可互操作性问题；在多数情况下，供应商必须做出选择或者加把劲纠正错误，或者避开会因此引起不可操作的那些站点。在大多数情况下，一个供应商实现该协议时不很正确，但在其客户机和服务器之间是一致的。其结果是一个实现在供应商自己的产品上工作得很好，但与别的供应商的客户端或服务器之间就工作得不太完美。这甚至比AOL的情况更微妙，因为对大多数使用该软件的人来说，错误可能不太显眼或影响不大——这样长期处于分叉上的错误（或构成问题的其它错误）一直到很晚才会被发现。

假如没有开源和像Apache那样广泛使用的Web服务器，完全可以想象得到一个小小的不兼容性会相互重叠加而越演越烈，再加上相互谴责或类似Jedi的恶作剧（mind tricks）（“我们在实验室从来不会出现这种情况......”），而对于“我用X提供的浏览器连接Y提供的服务器时会有问题”的回答是：“好吧，用Y提供的浏览器一切就会正常”。这一过程的结局是我们最终会有两个（或更多）World Wide Web：一个是基于X提供Web服务器的，另一个是基于Y提供Web服务器的，而每个只能与相应供应商的客户程序才能正常工作。

这种反标准的做法，历史上有很多先例，“锁进”（locking in）策略被很多软件公司作为基本的商业惯例。

当然，这会给网上的每个人带来灾难——Internet内容提供者（ICP）、Internet服务提供者（ISP）、软件开发者，以及任何一个需要用于HTTP进行交流的人必须去维护两套不同的服务器才能达到目的。当技术的消费者倾向于“合二为一”，而执拗的市场则倾向于“革新，求异，领导业界，定义平台”时，会阻止任何一方试图共同修改他们的协议。

事实上，我们确实看到过这样的灾难——客户端的JavaScript。在不同浏览器，甚至同一浏览器的不同测试版中，其行为差别如此之大，以致于开发者必须编一段代码来检测不同的修订版，然后再做出相应的行为——这导致用JavaScript开发交互界面时增加了大量的开发时间。直到W3C的介入并做了有关文档对象模型（DOM）的基础工作后，我们才真正看到了为建立JavaScript多方标准而作的努力。

在今天的商务世界中有一种自然的力量，当一个规范由封闭的软件公司实现时，就会与标准背道而驰。即使是对公共规范的一个意外的误解，如果不及时纠正，也会出现背离或偏差。

因此，我认为把你的服务或产品建立在基于标准的平台上对于你的商务过程的稳定性是大有裨益的。Internet的成功不仅证明了公共平台是如何促进方便的通信的，它也迫使公司更多地思考，怎样为介入通信市场的各方创造价值，而非试图从网络本身获取价值。

分析开源项目的目标

作为一个公司你所需要问自己的是，在什么程度上你的产品实现一个新的平台，在什么程度上为了你的商业利需要维持该平台的所有权。你们的全部产品和服务中有多少，进而你的收入中有几成是基于该平台的或不基于该平台的。这或许你能用具体的数字来计算一下。

譬方说，你是一家数据库公司。你销售能在多种OS上运行的数据库，你分别销售图形管理软件包、快速开发工具、人们常用的公共过程的库等等。你销售按年度的技术支持。升级需要购买。你还提供类。最后，你有一个庞大而有力的咨询小组为顾客实现你的数据库。

譬方说，你的收入大致分配如下：

• 40%－数据库软件的销售

• 15%－技术支持

• 10%－咨询

• 10%－快速开发工具

• 10%－图形管理工具

• 10%，过程库/该数据库上的应用程序

• 5%－手册/类

乍一看，建议将数据库软件免费发放会觉得很可笑。这意味着你的40%的收入消失了。如果你的公司幸运的话，你会有所盈利的，如果更幸运些，你可能会得到20%的利润率。而这40%将把这一切化为乌有。

当然这是在任何因素都不改变的假设下。但是，如果你把这一项去掉，别的项就会变化。数据库这类应用并非公司把它从CompUSA的货架上取下，把CD放入机器中，然后不闻不问就了事了的。无论给操作系统（数据库）定多高的价格，所有别的收入项目依然有效，而且也是必需的。事实上现在有比以前有更多的自由可以给这些别的服务定更高的价格了，而以前当顾客购买数据库软件时，软件的价格吃掉了通常他们所能支付的一大块。

所以光从表面看，如果免费的或低价位的特性能引起数据库系统成倍的发布，而用户照样会从你的公司购买咨询和技术支持、开发工具和库等等，你会看到总的收入将增长20%。更有可能的情形是有三四倍新的用户了解到你的软件，与此同时购买你别的服务的比例较低（或者因为人们就喜欢使用免费版本，或者你的竞争对手正为你的产品提供这类服务）。但只要购买率不是太低，你可能已为公司提升了总的收入。

再者，基于许可证的实施，你可能看到你的软件开发成本的降低。比如，你会喜欢看到错误被热心的顾客搞定。你还会喜欢看到，顾客将自己的代码加入到项目中，因为他们希望看到自己的代码作为完整发布中正式的一部分，从而给你的软件带来革新。所以总体上，你的开发成本会降低。

还有一种情况，对于一个类似上例的产品/服务混合体，免费发布该产品无助于竞争对手在你其余的收入空间里与你竞争。或许早已有许多咨询顾问用你的工具作集成；独立的作家为你的软件著书；你鼓励别的公司已为你的库编写代码。源代码的可用性只会在边缘处上有助于竞争者能为你的代码提供技术支持，但作为原开发者，你的人人要与之竞争的品牌就会有了一个庇护所。

当然，前方并非仅仅充满着美酒和鲜花。在这个过程中有的成本是很难直接冲抵收入的。例如，支持这种努力的基础建设的成本，虽不很高，也会消耗系统管理和技术支持人员的大量精力。还有开发人员与公司外部人员通信联络的成本。以及以公开方式开发代码的额外开销。将源代码进行公开检测的准备工作可能会有很高的成本。在所有这些工作完成之后，你的自由软件产品可能不会被标上“市场需要的”。在本文后面我将阐述所有这些方面的问题。

评估项目的市场需求

对一个公司而言寻求开放源代码作为拯救一个特定项目的方式是很诱人的。但可能一败涂地，也可能为一类产品带来好的结果。想要启动一个开源项目是没有千篇一律的理由的。如果一个公司是真想采用这种模式，就需要研究决定开源的产品策略要获得成功究竟需要什么条件。

首先要对竞争空间作一分析，无论是商业竞争者还是自由软件竞争者，也不管其规模有多小。通过将你的产品所提供的功能拆分成可分离的“块”（可以分别进行捆绑、销售或开源），从而仔细确定什么是你产品所能提供的。类似的，也不要排斥将提供相同功能的自由软件和商业软件进行组合。

让我们继续上面数据库供应商的例子。比如说，供应商的数据库产品实际包括三个部分：核心SQL服务器、备份/事务日志管理器、开发工具库。该供应商不仅要将其产品功能与像Oracle和Sybase这样的巨头进行比较，与像Solid和Velocis这样虽小但正在成长的商业竞争对手进行比较，而且还要与MySQL和Postgres这样的免费数据库进行比较。这样的分析可能得出结论表明，公司的SQL服务器仅比MySQL强一点，而且是在一处从不被认为是竞争优势的，仅仅是为与别的数据库供应商保持一致的一个必要特征上。备份/事务日志管理器没有自由软件竞争对手，而开发工具库不如Perl DBI实用程序好，但没有Java或C的竞争对手。

这样这家公司就可以考虑下列策略：

1. 用MySQL取代核心SQL服务器，然后将核心SQL服务器的功能与备份/事务日志管理器进行打包，在提供并支持免费Perl库的同时，销售Java/C库。这就能驾驭由MySQL包及为它增加了附加代码及插件模块的难以置信的库所带来的冲击，这仍允许你拥有你认为有专利的代码，或可申请专利的代码，或仅仅是你认为好得足以成为竞争优势的代码。你的公司能够在市场上扩展MySQL的部署规模。

2.将核心SQL服务器的额外功能加入到MySQL中，然后设计备份/事务日志管理器作为一分立产品进行销售，使其在优先支持MySQL的情况下能支持多种数据库。这种潜在的收入较少，但会使你的公司受到更多的关注，并且可能获得更广泛的用户群。另－方面，这样的产品更容易作支持。

3.走一条相反的路，对核心SQL服务及库维持商业产品策略。但对能支持多种数据库的备份/事务日志管理器作开源策略。这会降低这－部分的开发费用，并且是导致你的商业数据库成为市场领先的一个因素。这也会消除你的商业竞争者开源带来的竞争优势，尽管同时也消除了你的某些优势。

这些都是可采纳的有效方法，另一个方法是：

4.不与MySQL或Postgres或任何现有软件包捆绑，而将核心服务器作为完整的产品并开源，但为它提供商业性技术支持。将备份/事务日志工具以非开源正式销售，但将开发工具库开源以鼓励新用户。这种策略带有更大的风险，因为像MySQL或Postgres这样流行的软件包，已经存在有相当的时间了，而许多开发者本能地不会将一个工作正常的数据库替换掉。为达到这一点，你必须证明它具有比人们正在使用的系统更大的优点。或者速度非常快，更灵活，更容易管理和编程，或者含有丰富的用户愿意尝试的新特性。你还必须花费更多的时间恳请对该项目的关注，你也许必须找到一种方法把开发者从竞争产品上拉走。

在恰巧这样的环境中，我并不主张第四种方法，因为MySQL确实已有了一个良好的开端，有许许多多的附加程序，以及非常广泛的实际用户群。

可是，开源项目越来越失去动力，或者因为核心的开发小组并没有主动地进行开发，或者软件受到了在关键的体系结构方而不能满足新的需求的挑战，或者产生该需求的环境已不复存在或改变了侧重点。当这种情况发生时，显然人们会寻找别的选择，引入代替物并倍受关注的可能性是存在的，即使它并不直接显示出比现状（the status quo）有什么优越性。

分析需求是最基本的。事实上，通常是需求产生新的开源项目。Apache是由一群共享NCSA web服务器补丁程序的Web master发起的，他们认为替换补丁就像棒球上许许多多的皮块一样，是低效而且易出错的，从而决定在他们的补丁基础上做一个独立的NCSA服务器发布。在初期介入的主要人员中无人再介入此项工作，因为他们想要销售以Apache为基础的商业服务嚣，尽管这肯定是一个介入的合理的理由。

所以为特定的开源项目做市场需求分析也涉及加入相关的邮件列表和讨论组论坛，浏览讨论档案，与你的顾客及其同事进行交流；只有边样以后你才能真正确定，是否有人愿意帮助你使得项目能有圆满的结果。

回顾Apache初期，我们当中共享补丁的那些人也将它们送回给NCSA，希望被安装上去或至少确认一下。这样我们至少在某种程度上可以确信当下一个发布出来时可以容易地升级。NCSA因其服务器程序员被Netscape抢去而受到不小打击，而像洪水般的email（电子邮件）使余下的开发者难以承受。因此，建造我们自己的服务器比起试图建立下一个更庞大的Web服务器来讲更是一种自我保护的行动。在你认清该方法的好处之前，从可以很容易实现的有限的目标出发是很重要的，而不要依赖于你的以占有的市场的项目上。

开源软件在软件谱系中的位置

要决定将你的产品线上的哪些部分或一个产品的哪些组件作开源软件，做一个简单的实验会有所帮助。首先，画一条线代表整个软件谱系。在左边，写上“基础设施”，表示实现框架和平台的软件，包括所有TCP/IP以下的部分和内核，甚至硬件。在右边，写上“最终用户应用程序”，表示一般的非技术用户使用的工具和应用程序。沿着这条线，放置一些点，写上相关的术语，表示你认为你的产品的每一个组件所处的位置。从上述例子，前端GUI和管理工具处于右边最远端，而管理备份的代码则处于最左端。开发库大约在中心靠右，而核心SQL设施又靠左些。然后，你也要把竞争者的产品画上，也按组件划分，如果你富于创造性，可用不同颜色的笔区分自由软件和商业软件。你可能会发现，自由软件趋于聚集在左侧，而商业软件则趋于右侧。

开源软件在软件谱系已倾向于基础设施/后端这侧。这是有其原因的：

• 最终用户应用程序编写困难，不仅因为程序员必须处理经常变化且非标准的图形的、窗口的环境，由于其复杂性而容易出错；而且还因为大多数程序员并非好的图形界面设计师，只有少数例外。

• 从文化的角度看，开源软件在网络软件和操作系统软件领域已经运作了许多年。

• 开源软件在增量式的修改获得回报的方面趋于非常成功，从历史上说，这意味着是在后端系统而非前端系统。

• 许多开源软件原本是由工程师在开发商业软件或服务时要解决一个必须解决的问题而编写的；所以在早期主要的用户是其他工程师。

这就是为什么我们看到大量的开源软件处在操作系统和网络服务领域，而很少有桌面应用领域的。

当然这也有一些反例。最大的例子是GIMP，即GNU图像处理程序，一个在特征上可以与Adobe Photoshop相比的X11程序。然而从某些角度看，这个产品也是一个“基础设施”工具，一个平台，因为它的成功归功于其完美的插件体系结构，已经开发出数十上百种插件使之能导入导出许多不同的文件格式并实现数百种过滤效果。

再看看你画出的软件谱系。在某个点上，考察你所能提供的产品及其竞争环境，并画一条垂直线。这条线表示哪些你做开源哪些你选择保留专有权之间的界限。这条线本身表示你的真正的平台，是你试图为之建立标准的左边公开代码和你想要驱动需求（drive demand）的右边专有代码之间的界面。

天网恢恢，疏而不漏

任何商业软件要介入到其他开源基础设施框架中都会是在开放领域进行再开发的一种强有力的推动力。就向某种自然的力量，当一个商业软件要立于两个强大的开源软件之间时，就会有一种压力要用开放的解决方案在这个缝隙上架起桥梁。这是因为只要有足够的资源每个间缝都能被跨越，并且如果这个缝隙小得足以由你的公司开发小组来跨越，它就有可能被一些有主动性的开发者来跨越。

让我们再回到数据库的例子：比方说你决定将核心SQL服务器（或置于MySQL上的高级功能代码）作开源软件，但你决定通过提供将数据库插入Web站点以创建动态页面的商业性，非源代码可用的驱动程序来获利。你决定数据库是该产品中损失的大头，所以你会为这个组件制定比通常利润高得多的价格。

因为将数据库连入Web服务器是很常见的且需要的事情，开发者会或者使用你的产品，或者寻找别的途径以从Web站点访问数据库。每个开发者都会被这样一个想能所激励，即尽最节约他们支付给你的金钱。如果有足够多的开发者结集他们的资源认为值得他们自己一做，或者单个天才开发者就是不想支付插件费用而又要使用那个数据库，这就有可能在某一天早上你醒来时发现你的商业软件已经有了一个开源的竞争者，从而彻底清除只有一个解决方案给你带来的优势。

这是一个更大的视图：依赖于关键部位的专有源代码作为你赚钱的方法已成为一种风险商业投资。如果你能通过支持“Web服务器+插件+数据库”这样的组合，或者提供管理整个系统的接口来赚钱，你就能保护自己免遭这类风险。

并非所有商业软件都有这样的弱点——这只是那些试图将自己挤入两个已经建立起来的开源软件所提供的功能之间某个位置上的商业软件所特有的。将你的商业软件提供的功能作为现有的开源软件功能的补充是一个更实在的策略。

捐献还是保留？

开源软件存在于许多标准的软件分类中，特别是那些侧重于服务器端的软件。显然我们已经有了操作系统；Web服务器；邮件服务（SMTP、POP、IMAP），新闻服务（NNTP）和DNS服务器；编程语言（Web动态页面的“粘合剂”）；数据库；各种网络服务代码。

在桌面系统方面，有文本编辑器，像Emacs、Nedit和Jove。

窗口系统像Gnome和KDE；Web浏览器像Mozilla。还有屏幕保护程序、计算器、支票簿程序、PIMs、邮件客户程序、图像工具——这一列表压在不断增长。

尽管不是每一类软件都有像Apache或Bind这样的杀手级应用（Killer Application），可能很少有商业软件没有可供选择的适宜的，即使是刚刚起步的开源软件。这对于Unix或Mac平台是如此，但对Win32平台则有些出入，主要是因为开源文化认为Win32平台的“开放性”不足以在其上进行开发。

有充分的理由表明应充分利用一个现有的，与你想要提供的软件属同一类的开源软件所具有的动力，通过将你的附加代码或强化功能贡献给现有的项目，然后着眼于在总体上有高质量的代码，在市场上占有领先的一代，或在公共平台的建立方面有所回报。在评估这是否是一个可接受的策略时，还需要检查一下许可证条款：

• 现有软件包的条款是否与你长期目标一致（copacetic）?

• 在该许可证下你能合法地贡献你的代码吗？

• 是否会鼓励足够的未来开发者？如果不是，开发者是否会通过修改许可证而愿意适应你？

• 你所贡献的代码是否足够通用，使之对现有项目的开发者和用户有价值？如果这些代码仅仅是实现你的专有代码的一个API，这也许不会被接受。

• 如果你贡献的代码段很庞大，你能否拥有与其他开发者“同等”的地位，应样你以后就可以直接做一些修补或强化工作。

• 其他国家的开发人员，你能与他们一起工作吗？

• 你的各国开发人员在协作环境中能与其他人一起工作吗？

满足开发者的需求也许是开源开发模式中最大的挑战，这不是技术甚至金钱所能解决的。每个开发者一定要能感觉到他们正在为项目做出有益的贡献，他们的事情有人关注，他们对于体系结构和设计问题的评注得到确认和尊重，他们的代码会集成在正式的发行中，否则应有确凿的理由说明为什么不。

人们错误地认为“开源软件能够工作是因为整个Internet变成了你的R&D和QA部门了！”事实上，一个天才程序员对于一组特定的任务所做的努力通常是有限的。这样，通常每一个人都会关注平行的开发努力是否会因为开发者之间对语义上的异议而停顿下来。另一方面，当有别人竞争资源时，改进过程反而会最好。所以如果有足够的天才，在同一领域有两个竞争的解决方案对于爱挑剔的大众来说并不是件坏事——在一个方案中没有考虑到的某个真正的创新，可以在另一个方案中作一尝试。

在SMTP服务器方面可以找到竞争是有益特征的奋力证据：长期以来，Eric Allman的“Sendmail”程序总是与每个操作系统一起发布的标准的SMTP看守程序（daemon）。其他的开源软件竞争者也紧随其后，像Smail或Zmailer，但真正第一次分化其用户群的是Bernstein的Qmail软件包。当Qmail走上屏幕时，Sendmail已经20岁了，并且也显现出它已老了；它并不是为90年代后期的Internet而设计的，现在的缓冲区溢出及拒绝服务攻击就像西雅图的天气经常下雨一样，是家常便饭的事。Qmail在许多方面都有根本性的突破——程序设计、管理，甚至对于一个SMTP服务器而言什么是好的“网络行为”的定义方面。这一进展大大超越了曾经为Allman的Sendmail所做的一切。

这不是因为Allman及其小组不是好的程序员，也不是因为没有有活力的第三方贡献者；而仅仅是因为有时候一个根本上的分歧确实需要尝试新事物看看是否可行。基于同样的理由，IBM为Weiste Venema提供资金以开发“SecureMailer”SMTP看守程序，在撰写本文时，它已呈现出趋于流行的征兆。SMTP看守程序是一个定义明确且很重要的领域，足以支持多个开源项目；时间会告诉我们谁将是幸存者。

引导（Bootstrapping）

一个开源项目能兴盛的根本是该项目有足够的动力能够不断改进并能应付新的挑战。软件世界中没有一成不变的。每个大的组件都需要持续地维护和增加新的功能。这种模式的最大特点之一是它降低了任何单独一方必须承担的开发费用，因此为使该理论成为现实，你需要其他活跃的开发者。

在确定你的项目需求的过程中，你可能会与对此有足够兴趣的公司和个人合并以形成一个核心开发者小组。一旦你做出了一个决策，为该核心组做准备工作任务更艰巨；也许先启动一个无任何先决条件的讨论邮件列表。机会在于这个小组会有一些如何使之成为一个成功的项目的非常好的想法，并列举能使之为真的他们自己的资源。

对于最简单的项目，这个小组的关于他们会对你的产品作一尝试，以及他们是否乐意留在邮件列表中的许诺也许是足够的。可是对于更大的项目，你应该试图保持并扩展总的资源库的规模。

这是对一个中等复杂的项目，比如说为web服务器构造一个公共的购物车的插件，或实现一个简单协议的一种新型的网络守护神，这里是一个我所考虑的最小的资源集。我将描述所需的各种角色及其应具有的各种技能。

• 角色1：基础设施支持

  有人建立并维护邮件列表别名，web服务器，CVS（并发版本管理系统）代码服务器，bug数据库（bug database），等等。

  启动：100小时

  维护：20小时/每周

• 角色2：代码“首领”

  有人看护全部的代码并对实现代码的质量负有全部责任。集成由第三方提供的补丁程序，并对其错误及不兼容性进行修复。这些新开发工作之外的事情也由他们负责。

  启动：40-200小时（取决于要多长时间理顺代码以供公共消费）

  维护：20小时/每周

• 角色3：bug数据库维护

  在非免费提供“支持”时，很重要的一点是为公众提供有机的组织方式，将错误报告和问题通知服务器开发者。而在免费状况下，开发者当然没有义务回答他们收到的所有邮件，但是他们应该尽量地对valid合理的问题做出答复。错误数据库维护者应该是在技术支持的第一线上，它要时常检查所有递交的报告，清除那些最简单的问题，舍弃那些无头绪的问题，而将真正的问题转交给开发者。

  启动：只要足以了解有关代码的运作方式

  维护：10-15小时/每周

• 角色4：文档/web站点内容维护

  这在开源项目中通常无专职人员，通常留给那些真正想做些贡献的非主要程序员的人员或工程师；也有的干脆空缺着。但只要我们考虑这一过程，分配专职人员使得非技术人员能够理解并欣赏他们正在部署的工具，这对于广泛的使用是基本的。这有助于减少回答那些仅是不恰当的理解引起的错误报告，这也助于鼓励新人去学习他们关于代码的一些做法并成为将来的贡献者。在一个较高的层次上描述软件的内部体系结构的文件是必需的；而解释代码中主要的过程和类的文档几乎是同样重要的。

  启动：60小时（假定代码几乎没有文档）

  维护：10小时/每周

• 角色5：祝酒者（Cheerleader）/热心人（zealot）/传教士（evangelist）/策略家（strategist）

  这些人能够为项目带来动力，寻找其他开发者，促使特定潜在的客户来做尝试，寻找其他的会采用这个新的平台作为候选平台的公司，等等。这不单是市场人员或销售人员，因为他们必须稍懂得技术；且必须具有能在更高的视角看清该项目的作用的基本能力。

  启动：了解项目即可

  维护：20小时/每周

这里我们列举了五种角色代表了可能的三类全日制人员。在现实中，某些角色由一群共同承担责任的人组成，而有些项目在第一次发布的高峰过去之后，主要参与者平均每周花费少于5小时就可以生存下去。但是如果是公司的常规开发项目，在项目的早期开发者集中他们的时间和精力是必须的。

这五种角色还没有包括那些开发新项目的资源；这纯粹是维护工作。最后。如果你不能从对手和伙伴那里找到足够的资源涵盖这些基本的角色以及足够的额外的开发者做些基本的新的开发（直到有新的人员加盟），你可能要重新考虑你的开源项目了。

使用什么样的许可证？

你的项目决定采用什么样的许可证可能是件相当复杂的任务；这可能是你不太感兴趣但你的法律小组特别感兴趣的一类任务。已有许多文章及web站点涉及版权问题的细技末节；尽管如此，我想对我所见到的各种许可证的商业考虑作一简介。

BSD样式的版权

这是Apache和基于BSD的操作系统项目（FreeBSD、OpenBSD、NetBSD）所采用的版权，总体上它可以总结为“这里是代码，你想对它怎么做就怎么做，我们并不在乎，只是你试图这么做且销售它时请给我们信用”。通常对信用的要求会在不同形式中出现——广告，或README文件，或印刷的文档，等等。这已经导致了这种版权的延伸性方面的问题——即，如果某个人要发布一个捆绑的软件，其中包括40个不同的开源的模块，比如都基于BSD方式，他就得表明含有并显示的40个不同的版权信息。在实际中这已不是一个问题了，而事实上，它这已被看作是一个传播开源软件使用知名度的促进力。

从商业角度，这是加入现有项目的最好的一类许可证，因为不用担心将来使用或重新发行时的许可证或限制问题。你可以用自己的专有代码混合并配合该软件，并且仅仅发布你认为有助于项目的那些部分，从而有助于提高你的回报。这是我们为什么选它作为Apache的许可证的理由之一——与许多自由软件项目不同，Apache主要是由一群为他们的商业目的寻求更好的web服务器的商业web管理员（webmasters）发起的。那时原开发小组中可能没有人把目标瞄准在Apache上建立一个商业服务器，我们无人知道将来会怎样，只是觉得在开始时限制我们的附加功能是非常明智的。

这种许可证对于促进那些实现一个协议或公众服务代码的参照体（a reference body）的使用是非常理想的。这是我们选它作为Apache许可证的另一个理由——我们中的许多人希望看到HTTP存在下去并成为一个真正的多方标准，并且丝毫没有在意Microsoft或Netscape是否会将我们代码中的HTTP引擎或任何其他部分嵌入到他们自己的产品中，只要它能进一步保持HTTP是公共的这一目标就行。

这种开放程度是有风险的。许可证中没有任何激励以鼓励公司将它的强化代码贡献返还该项目。在Apache的历史上曾有这样的情况，有些公司已围绕它开发出许多技术，我们希望看到被返回到该项目。但假如我们的许可证授权强化代码可用于返还该项目，则这样的强化代码可能永远也不会有第一次出现。

所有这些意味着，策略上讲，项目需要保持足够的动力，即使代码保持专有会有价值，参与者将他们的代码贡献给项目会产生（实现）更大的价值。这是一个需要维持的巧妙的比率，特别是如果一个公司决定他们在一个派生项目上急剧增加大量代码；并开始怀疑潜在的回报是否与他们对项目的贡献成正比，比如：“我们都在做这个工作，没有其他人合并，为什么我们要将其共享呢？”对于这种情景，笔者也无能为力，只能说这样的公司可能还没有找出最好的方法来激励第三方的贡献，以帮助更有效地实现他们的工程目标。

Mozilla公共许可证

Mozilla公共许可证（MPL）由Netscape Mozilla小组为用于自己的项目而开发的。自从它发布以来的几年中，这是第一个新的许可证，并确实陈述了BSD或GNU许可证没有提到的某些关键问题。在开源软件许可证谱系中它与BSD样式许可证相邻。它有二个关键的不同点：

它授权对于“发行”的更改仍以同样MPL版权下进行发布，这样使得它可用于返还该项目。“发行”被定义为以源代码发布的文件。这是很重要的，因为它允许公司增加一个与专有代码库的接口，而不需授权其他的代码库具有MPL版权——只授权该接口具有MPL。这样，这个软件可以或多或少地组合到商业软件环境中。

它有些规定保护整个项目及开发者免受所贡献的代码中的专利问题的侵扰。它授权为该项目贡献代码的公司或个人释放全部在代码中可能涉及的专利权的声明。

这第二个规定的确很重要；但在写本文之时，它也包含一个大的漏洞。

关注专利问题是一件很好的事情（a Very Good Thing），但总是有这样的风险，即一个公司可能天真地将代码提供给一个项目，然后一旦那段代码被彻底实现，就会试图要求使用它的某种专利费。这样的商业策略可能是很可笑的不好的PR（专利权）并且非常丑陋，但不幸的是并非所有公司都看到了这一点。所以这第二条规定是为了防止出现这种情形，即有人偷偷提供那些他们明知具有专利的代码，从而令半道上的人们大伤脑筋。

当然它不能阻止这种可能性，即（另外）某个人拥有该项专利；目前没有提供这类保护的法律手段。我想要建议这项服务最适合于由美国专利与贸易局（the U.S. Patent and Trade Office）来执行，他们好像有权声明某些想法或算法是某人拥有的财产，因此难道不应该要求他们做些相反的事，证明我们提交的代码是免专利的，在专利诉讼中给予我一些保护。

就像我前面所说，尽管如此，直到1998年12月为止，目前的MPL中有一个漏洞。本质上，2.2节授权（通过“贡献者版本”定义）贡献者放弃对Mozilla任何部分的专利要求，而不仅仅是他们所贡献的代码部分的专利要求。看上去这也许不像是一个错误。要求许多大公司放弃整个软件包自然是件愉快的事情。

不幸的是，一些大的公司夹着一个世界上最大的专利公文包，针对这个遁词提出一个相当特殊的大问题。不是因为他们打算跟在Mozilla后面并提出版权要求——那只会是有勇无谋的。他们关心是因为Mozilla的有些部分实现了他们拥有专利的过程，从该专利每年可收到相当可观的美元——假如他们放弃对Mozilla代码的专利要求，那些为专利向他们支付美金的公司，可以简单地从Mozilla中取出实现同样专利的代码，并放入他们自己的产品中，这样就可以不需要上面所说的大公司的专利许可证了。假如2.2节单指所提供的补丁而非整个浏览器，当放弃专利时，这就不会是问题了。

暂且不论这一遁词，MPL是一个相当可靠的许可证。授权所有更变返还给“核心”意味着，重要的错误被搞定并且可移植的强化代码会返回到该项目中，同时增值的特征仍然可由商业实体来开发。这或许是用于开发最终用户应用程序最好的许可证，因为其中最容易涉及专利问题，并且导致项目分叉的驱动力也更大些。而相反，BSD许可证也许对于那些趋于“不可见的”或基本上是库函数的项目是最理想的，如操作系统或web服务器。

GNU公共许可证（GPL）

虽然，显然不是商业友好的许可证，不论你信不信，GNU许可证的有些方面对商业目的是极具吸引力的。

本质上，GPL授权强化、派生，甚至是嵌有GPL的代码的代码本身也在GPL下的以源代码形式发布。这种“viral”行为被开源倡导者们广泛地鼓吹，作为一种方式以保证代码自始至终都是自由的——即没有任何机会可以从可用代码和尚未公开的提交的资源出发，开发并分支出自己的版本以谋取商业利益。在那些对他们的软件实施GPL的人的眼里，他们宁可不要贡献者，也不要他们所贡献的不能像原来一样自由地使用的代码。当然这是学院派的一种爱好，有些倡导者声称假如Linux不是GPL的，永远也不会像现在这样壮大，因为分叉出商业目的的诱惑太大，所以必须保持大量人员统一的开发努力，以避免节外生枝。

因此初一看，好像GPL不能很好地与对开源软件的商业意图共存。传统的通过软件增值来赚钱的模式在这里是完全不可行的。但是、GPL可以是非常有效的途径去建立一个平台，使之能阻止别的竞争平台的建立，而这可保护你要求作为基于这个平台的产品和服务的“首要的”提供者。

这类例子有Cygnus和GCC。Cygnus每年通过将GCC移植到各种不同的硬件平台，并维护这些移植的GCC，需要做大量的更改。这一工作的绝大部分，根据GPL，都贡献给GCC发行，并且可以免费获得。Cygnus只对移植和维护进行收费，而非代码本身。Cygnus的历史及其在这方面的领导地位使之成为一个提供这类服务的标准公司。

假如竞争者准备要与Cygnus竞争，它也必须在GPL下重新发行他们所作的修改。这意味着竞争者没有可能在GCC框架上寻找一个商业化的技术点进行开发。也没有Cygnus间样的机会利用该技术。Cygnus已造成了这样一种环境，使得竞争者不能通过技术分化与之竞争，除非一个竞争者准备花费大量的时间和金钱，并且使用一个不同于GCC的平台。

另一种GPL用于商业目的的方法是作为一种技术“哨兵”，即将同样代码的非GPL版本用于销售。例如，你可能一个很好的在Internet上用于加密TCP/IP连接的程序。你并不在乎人们将它用于非商业用途，甚至是商业用途——你的兴趣是让那些想要把它嵌入到一个产品中，或重新发行进行盈利的人们为此而向你支付费用。如果你把GPL许可证加到代码上，这第二个用户群就不能做他们想做的事了，除非也将他们的整个产品定为GPL，而这是他们中许多人不愿做的事情。可是，如果把你的项目维护一个不同的分支，它不受GPL约束，你就可以以你喜欢的方式发放分支代码的商业许可证。虽然如此，但你必须要很谨慎，保证任何由第三方贡献给你的代码是显式地可用这个非免费分支；你可通过下列声明做到这一点，只有你（或受雇于你的人）会为该项目编写代码，或者（另外）你要从每个贡献者那里获得明确的许可证允许将他们所提供的任何部分嵌入非免费版本。

这种商业模式对某些公司是非常可行的——一个例子是在Berkeley的Transvirtual，它将这种模式用于一个商业的轻量级的Java虚拟机和类库项目。某些人会认为因这种模式而逃避的贡献者的数目会很高；并且GPL和非GPL版本会分叉；我认为如果你能很好地处理贡献者，或许甚至对他们的贡献提供资金或其他的补偿（毕竟它对你的商业底线是有帮助的），这种模式就是可行的。

在今后几年中随着人们发现什么可行或什么不可行，开源的许可证空间肯定会有所发展。简单的事实是你有发明新许可证的自由，许可证确切地描述了你想要将它放置的（BSD在右侧，而GPL在左倾lj所代表的）谱系中的位置。只是记住，你给与那些使用并扩展你的代码的人的自由度越大，他们做贡献受到的鼓励也就越大。

启动开源项目的工具

我们在Apache项目中有维护良好的，可供使用的一组工具，使得我们分布式的开发过程顺利进行。

其中最重要的是CVS，即“并发版本管理系统”。它由一组程序来实现一个共享代码仓库，维护一个更改数据库（每次更改均附有名称及日期）。这是非常有效的工具，允许许多人同时是一个程序的“作者”而不会相互影晌。这也有助于调试过程，因为可以做到一次一次地撤销更改，以寻找某个错误被导入的确切位置。每个重要的平台上都有一些客户，并通过拨号线或远距离的连接也能很好地工作。通过使用SSH在加密连接上实现隧道技术，保证远程连接的安全性。

Apache项目使用CVS不仅仅是为了维护实际软件，也为了维护我们的“状态”文件，其中有我们所有重大问题及注释、观点，甚至对每个问题的表决结果。我们也用它记录作为集体的决定的表决结果，维护我们的web站点文档，管理开发文档，等等。简而言之，这是该项目的资产和知识管理软件，它的简洁性看上去好似一个缺点——大多数这类软件是非常昂贵的且功能齐全——但在现实中，简洁性是CVS的一个非常主要的优点，CVS的每个组件都是免费的，包括服务器和客户程序。

一个开源项目的另一个要素是有一组为开发者及用户设立的讨论组论坛。这里用什么软件无关紧要——我们用Majordomo，但ezmlm或Smartlist或任何其他软件都是可行的。重要的是给每个开发部门有一个自己的版面，这样开发者能自己选择感兴趣的并恰当地与开发保持同步。为每一个项目创建不同的版面也是明智的，使得CVS服务器能把对CVS仓库所作的更改通过邮件发送给对应项目的版面，从而允许某种被动地浏览所有的更改。这种模式事实上对于维护代码标准及发现错误是很有效的。对于开发者和用户具有不同的版面，也是有意义的。如果你的项目足够大，甚至还可以区分核心开发者和其余开发者的版面。最后，公开提供所有版面的档案也是很重要的，这样新用户就能够搜索某个特定问题是否以前曾经被提出过，或者以前有些事情是如何阐述的。

错误和问题跟踪对一个经营得很好的项目而言也是基本的。在Apache项目中，我们使用一个叫做GNATS的GNU工具，它为我们工作得很出色，并处理了3000多条错误报告。你应该找一个工具、它允许多人解答错误报告，允许人们限定于处理项目中特定组件中的错误，并允许人们通过电子邮件来阅读并解答错误报告，而不是只能用一个web表格形式。错误数据库的更进一步的目标是它应该提供尽可能自动的、方便的服务，以便开发者解答错误报告（因为这对大多数开发者而言通常是零星事物），搜索一个特定的错误是否已经被报告过。实质上，你的错误数据库会成为有关项目及其性能的轶事知识的仓库。为什么一特定的行为是一个特征而非错误？对一个已知的问题有人谈论过什么吗？这类问题正是一个好的错误数据库应该寻求回答的问题。

开源方法“不”是每一类软件开发项目的魔弹。作这样一个项目不仅要有成熟的条件，而且在启动一个成功的具有自身生命力的项目之前，还有大量的实际工作要做。作为一个新项目的倡议者，在许多方面你必须装扮得有点像Frankenstein博士那样，这里掺点化合物，那里加点电压，这样才会给你的生活带来惊喜。祝你好运！

作者简介

Brian Behlendorf

Brian Behlendorf不是一般人想象中的那种黑客。他是Apache小组的一个创建人和核心人物。Apache是一个开放源代码的Web服务器，其在当今Internet上使用的Web服务器市场中，份额占有率达53%。这意味着自由软件在市场份额上远远超过了Microsoft、Netscape和其他一些商家。

Brian已经为Apache项目工作了四年，他主要的工作是帮助引导该项目的发展方向和协同小组中其他成员的工作。这一项目是以一个有趣的实验开始的，而现在模变成为一个设计精巧、功能全面的Web服务器。

他除了为本书撰文外，还对音乐有着浓厚的兴趣，而且他可能是仅有的一个能组织狂欢晚会或者在晚会上做DJ的人。他的Web站点http://hpereal.org汇集了大量高品质的音乐、狂欢晚会和俱乐部资源。他喜欢阅读，阅读一些近来计算机领域以外的知识，并且喜欢卡普拉的《物理中的道》和乔姆斯基的《秘密、谎言与民主》。

在1998年晚些时候，IBM宣称在其高端产品钱AS/400系列上支持Apache，这对于Apache项目来讲无疑是一个真正的分水岭。Brian评论IBM的此项举措时说：“高兴的是不只是我一个人想到会有这样的商业举动。这不仅仅是一种工作乐趣，而且是一种商业运作模式。越来越多的人们会发现开源在计算机领域中其实是一种很好工作方式，这种方式不仅能促进良性循环，而且成效斐然”。