魔法大锅炉
—— 何时开放，何时封闭
　
Eric Raymond (1999年六月)
[AKA]rover HansB iasc等翻译

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的市场份额时，秘密比特的收益开始下降。

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

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

　　10.4. 知晓何时放手

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

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

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

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

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