Question

在对当前流行的模型投以怀疑目光的同时，我们看看是否能够建立起另一个模型——一个在经济学上的可靠模型，用来阐述开源合作的可持续性。

它要能经得起几个不同层面的检验。一方面，我们需要解释开源项目贡献者的个体行为；另一方面，需要理解那些支撑 Linux 或 Apache 这类开源项目合作的经济力量。

再一次，我们需要先推翻一个妨碍理解的流传很广的民间模型。因为在每次试图对合作行为做出解释时，Garret Hardin 的“公地悲剧”理论都会投来一片阴影。

在这个著名的理论中，Hardin 假想在某个村子里有一片公共的草地，每个村民都可以在这片草地上放牧，长期放牧使得土地退化、草皮损坏、到处都是泥坑，而草皮的恢复很慢，如果没有一个一致同意的（或者强制的）放牧权分配策略，就很难抑制过度放牧，出于自身利益考虑，每个人都会尽可能多和尽可能快地放牧自家牛羊，以便在公地退化成泥沼之前，从中获取最大价值。

大多数人有着和此类似的本能的合作行为模型。公地悲剧事实上来自于两个互相联系的问题，一是过度使用，二是供应不足。在需求端，公地鼓励“竞次”行为 ^[2] 而导致过度使用——也即经济学家所称的公益拥挤问题。在供给端，公地奖励了“搭便车”行为 ^[3] ——它打消或抑制了个体在开发新牧地上的投资意愿。

公地悲剧预言了三个可能的结果。一是公地退化为泥沼，二是少数有强制力的成员代表全村实施分配策略，三是将公地分割给村民，让每个村民自行保护（如围起篱笆）和管理自己那块草地的可持续性。

当把这个模型下意识地套用在开源合作上时，人们预期开源合作是不稳定的，而且有着很短暂的半衰期。由于显然没有什么办法能通过互联网强制分配程序员的工作时间，使用“公地悲剧”模型将直接得出预测：就像公地将会被分割那样，软件将会被分为很多块并闭源起来，回馈在公共代码池上的工作量会迅速减少。

经验表明，事实上的趋势与此相反，开源开发在范围和数量上的趋势，可以从每天在 Metalab 和 SourceForge（Linux 源代码站点的领头雁）上的提交数或每天在 freshmeat.net（一个致力于推介新软件发布的站点）上的通告数测算出来，它们都有着稳定而快速的增长。“公地悲剧”模型一定在某些关键的地方和实际不符。

一部分原因当然是因为使用软件并不会降低软件的价值。事实上，对于开源软件来说，使用得越广泛，就越可能增加其价值，因为用户会提供软件 bug 修复和功能补充（代码补丁）。反公地模型中，在软件上“放牧”越多，“草”反而长得越好。

所以，开源软件的公共利益不会因为过度使用而恶化，但这只考虑了“公地悲剧”中的公益拥挤问题，还没有解释为什么开源不会遭遇供应不足的问题。为什么明知道开源社区中普遍存在搭便车行为，人们也不会去等别人去做自己需要的东西，而且（自己）也不在意向公地做出贡献？

部分原因是人们需要的不仅仅是解决方案，他们还需要问题的及时解决。对于某个给定需求，几乎不能预期别人会在什么时候搞定它。对任何一个潜在贡献者而言，如果他从 bug 修复或功能增加中能获得足够的回报，他就会投入其中（即便所有人都搭便车也没关系）。

另一部分原因在于，对于公共代码的微小补丁，其公认的市场价值很难收取。假设我写了一段代码，可以解决掉某个烦人的 bug，并且假设有很多人愿意为这个补丁付钱，可我怎样向这些人收费？传统的支付系统有着很高的管理成本，这使得各种合理的小额支付成为一个实实在在的问题。

还不仅仅是难以收费的问题，可能更切中要害的是，通常情况下你很难定价。让我们做一个思想实验，假设互联网上已经有了理论上很完美的小额支付系统——安全，普及，零管理成本，现在，你写了一个叫做“Linux 内核若干修补”的补丁包，你如何定价？对于一个可能的购买者，在还没有拿到这个补丁的时候，他怎么知道该付多少钱？

这个问题很像是 F.A.Hayek 所提“计算问题”的翻版——它需要一个超能力（superbeing）存在：既能评估补丁的实用价值，又能可信地设定其价格以促成交易。

遗憾的是，我们并没有这种超能力，补丁的作者 J.Random（J.Random 用来泛指某位黑客——译者注）只有两个选择：坐等在补丁上，或者将其免费投入到公共代码池中。

坐等在补丁上不会获取任何收益。事实上，它会招致未来的成本——在系统每次新发布时，都需要将补丁重新合并到源代码中。从这种选择中获取的收益，其实是负值（并且会因开源项目发布的快节奏特点而倍增）。

如果积极一点，将补丁贡献出来，维护补丁的日常开销会转移给源代码所有者和项目团队中的其他人，而且这个补丁可能会在未来某个时候被他人改进，由于并不是非要作者本人维护这个补丁，他可以有更多时间满足自己对软件更多的个性化需求。这些好处不仅体现在补丁上，也同样适用于整个软件包。

将补丁投入到公共代码池中可能不会有什么收获，但会鼓励别人参与进来，并在某个时候解决 J.Random 碰到的问题。从表面上看，这是利他的，但从博弈论意义上讲，这是最大化的利己。

分析这类合作时需要注意的是，搭便车问题（由于缺乏金钱或等价补偿而带来的供应不足问题）并不是随最终用户增多而凸显的唯一问题（详见书后注释 1）。开源项目的复杂性和沟通成本基本上完全是参与开发人数的函数，大多数从来不看源码的终端用户实际上并不会带来什么成本，但会增加项目邮件列表上愚蠢问题的比例，好在可以通过维护 FAQ（常见问题）列表较为轻松地解决这个问题，而且通常大可不必理会那些明显没有读过 FAQ 的提问者（这些已经是通行做法）。

开源软件中真正的搭便车问题，其实更多体现在提交补丁时的磨合成本。一个潜在的贡献者，在黑客文化的声誉游戏（见“开垦心智层”一文）中，几乎没有什么赌注，在缺乏金钱补偿的情况下，会觉得“不值得提交这个修复，因为我不得不整理出补丁，写修改记录，还要签署 FSF 版权转让书……所以，贡献者数目以及（由此而导致的）项目成功程度，和项目对贡献者所设限制条件多少是强烈负相关的。这种磨合成本可能是政治上的，也可能是机制上的。总之，我认为这解释了为什么宽松的、无组织的 Linux 文化，比起相对严格的、有组织的、集中式管理的 BSD 文化，能吸引更多的合作能量（远不在一个数量级上）。这也可以解释为什么 FSF 在 Linux 兴起之后变得不再那么重要。

目前看来这些分析都没错，但它们只是对黑客如何对待补丁（在写好补丁之后）的一个事后解释，我们需要对问题的另一半做出经济解释，即 J.Random 为什么要写免费补丁，而不是通过闭源程序获取销售价值？是怎样的商业模式，造就了能让开源开发蓬勃发展的生态环境？