4.5 反向公地的正向循环

在以怀疑的眼光审视了一种广为流传的模式之后，让我们来看看能否建立另一种模式：可以解释开源合作为何可持续的、实事求是的经济学解释。

我们需要从几个不同层面上考察该问题。一个是为开源项目做出贡献的个体的行为；另一个则是支撑像 Linux 或 Apache 这样的项目持续合作的经济力量。

再次强调，我们必须首先破除一个广为流传、妨碍理解的朴素观念。每当我们试图解释合作行为时，加勒特·哈丁"公地悲剧"的阴影始终笼罩其上。

哈丁让我们假想一片由当地牧民共有的草场，他们在那里放牛。但是，放牧会破坏公地、踩踏草地、留下泥泞的秃斑，而这些秃迹斑斑的植被恢复得又很缓慢。如果没有公认的（且强制执行！）的放牧权分配政策来防止过度放牧，各方利益的激励将驱使他们尽快、尽可能多地放牛，力求在公地退化成泥沼之前攫取最大价值。

大多数人对合作行为的直觉都与此非常相似。公地悲剧实际上源于两个相互关联的问题：一个是过度使用，另一个是供给不足。在需求方面，公地状况鼓励了因过度使用而导致的逐底竞争，经济学家将此称为拥挤性公共物品问题^b。在供给方面，公地奖励了搭便车行为^c，从而削弱甚至消除了个体行动者投资开垦牧场的动机。

公地悲剧只预测了三种可能的结果：草场变成泥沼；某个拥有强制力的行动者代表村庄强制执行分配政策（共产主义式解决方案^d）；公地解体，村民圈出自己能够防守并可持续管理的地块（产权式解决方案）。

当人们不经反思地将此模型应用于开源合作时，他们认为开源合作不稳定、持续时间很短。由于没有切实可行的方法能通过互联网强制执行程序员时间的分配政策，这个模型的直接后果是：公地将会解体，各种软件片段会被封闭源代码，而反馈回公共池的工作量将迅速减少。

事实上，经验清楚地表明，趋势与此相反。开源开发的广度和数量趋势，可以通过Metalab和SourceForge（主要的 Linux 源码站点）的每日提交量，或者freshmeat.net（一个专门发布新软件广告的站点）的每日公告量来衡量。两者的数量都在稳步快速增长。显然，"公地悲剧"模型在某个关键方面未能捕捉到实际发生的情况。

部分答案在于，使用软件并不会降低其价值。实际上，开源软件得到广泛使用往往会增加其价值，因为用户会修复bug和增加新功能（提交代码补丁）。在这个反向公地里，草地越是有人放牧，它反而长得越旺。

这种公共物品不会因过度使用而退化，这解决了哈丁悲剧的一半，即拥挤的公共物品问题。但它不能解释为什么开源没有供给不足的问题。为什么搭便车行为在开源社区并不普遍，为什么他们不是等着别人来完成自己所需的工作，或者，即使自己做了工作，也不愿把成果回馈给公地呢？

部分答案在于，人们不仅仅需要解决方案，他们还需要及时的解决方案。预测别人什么时候能完成某项所需工作几乎是不可能的。如果修复一个 bug 或添加一个功能对任何潜在的贡献者来说回报足够大，那个人就会投入其中（此时其他人都搭便车的事实就无关紧要了）。

另一部分答案在于，对公共源码库的小补丁，其假定的市场价值是难以捕捉的。假设我写了一个修复某个 难缠的 bug 的补丁，并且假设许多人明白这个补丁可以变现，那我如何向这些用户收费？传统的支付系统的高昂开销，让通常合适的小额支付显得不合时宜。

更关键的一点可能在于，这种价值不仅难以捕捉，它在一般情况下甚至难以评估。我们不妨做一个思想实验：假设互联网配备了理论上理想的小额支付系统：它安全、普遍可访问，而且零成本。现在，假设你写了一个名为"Linux 内核杂项修复"的补丁。你怎么知道它应该要多少价钱？一个潜在买家，在还没看到补丁之前，又怎么知道付多少钱合理呢？

这几乎是F. A. 哈耶克的"计算问题"^e的哈哈镜映像，这个问题需要一个超人，既能够评估补丁的功能价值，又能够得到信任据此定价，才能保证交易顺畅。

不幸的是，存在严重的超人短缺，所以补丁作者J. Random Hacker^f只剩下两个选择：把补丁攥在手里，或者把它无偿投进公共代码池里。

把补丁攥在手里毫无益处。实际上，这反而会在未来产生成本，即在每个新版本中将该补丁重新合并到源代码库所需的工作量。因此，这种选择的收益实际上为负（并且会随着开源项目特有的快速发布节奏而倍增）。

更乐观地说，贡献者通过将补丁的维护开销，转移给源代码所有者和项目组的其他成员而获益，他也因其他人将来改进他的工作而获益。最后，因为他不必自行维护这个补丁，他有更多时间做其他规模更大的定制，来满足自己的需求。支持将整个软件包开源的那些论点，同样适用于补丁。

把补丁投进公共代码池可能一无所获，也可能激励他人的互惠成果，这些成果将来会解决J. Random的一些问题。这个看似利他的选择，从博弈论意义上讲，实际上是理性自利的最优解。

在分析这种合作时，重要的是要注意到，虽然存在搭便车问题（在没有金钱或金钱等价物补偿的情况下，工作可能供给不足），但是它并不随着最终用户的数量而扩展（详见尾注 1）。一个开源项目的复杂性和通信开销几乎完全取决于参与开发者的数量；拥有更多不看源代码的最终用户实际上不产生任何成本。这可能会增加项目邮件列表上蠢问题的数量，但通过维护一个FAQ（常见问题）列表，并坦然无视那些显然没读过它的提问者，可以相对容易地避免这种情况（实际上，这两种做法都很典型）。

开源软件中真正的搭便车问题，与其说在于其他方面，不如说更在于提交补丁的摩擦成本。一个在文化声誉博弈中没什么既得利益的潜在贡献者，在缺乏金钱补偿的情况下，可能会想："不值得提交这个修复，因为我得清理补丁，写变更日志条目，还要签署FSF的授权文件……"。正是因此，项目的贡献者数量（及其二阶效应，项目的成功）与每个项目让贡献用户需要跨过的门槛数量呈强烈的负相关。这些摩擦成本既可能是机械性的，也可能是政治性的。我认为它们共同解释了为什么松散、没有定形的Linux文化吸引的合作能量比组织更严密、更集中的BSD产出高出几个数量级——以及为什么随着Linux的崛起，自由软件基金会的重要性相对有所下降。

就解释范围而言，这些都很好，然而这只是J. Random Hacker创建补丁之后如何处理的事后解释。我们需要的另一半解释是，JRH当初是怎么能写出那个补丁的，而不是被迫从事可能为他带来销售价值的闭源软件开发工作。是哪些商业模式创造了可以让开源开发蓬勃发展的利基市场？