魔法大锅炉
—— 驳斥公用悲剧说
　
Eric Raymond (1999年六月)
[AKA]rover HansB iasc等翻译

5.驳斥公用悲剧说

　　质疑主流模式,看看我们是否能建立另一种模式----对是支撑起开放源码协作的原 因作出有力的经济学解释.

　　这个问题需要从两个不同的方面考查.一个方面是我们要解释那些为开放源码作出 贡献的人士的个体行为;另一方面,我们需要理解那种支撑象Linux和Apache这样的 开放源码项目的经济力量.

　　Hardin的著名寓言告诉我们:设想一个乡村农夫们拥有一片公用绿地.他们在那里放牧牲畜.但是放牧使公用性退化,撕裂草皮,留下泥泞,很难恢复.如果没有对分配放牧的权利达成协议(或约定)以防止过度放牧;所有牧主都还会赞成尽可能快的增加牲畜数量,以便在公共绿地变成泥潭之前榨取最大的利润.

　　大多数人使用象这样的直觉的合作模式.这事实上并不是对开放源码--他们是(供不应求的)自由骑士,而不是(被过度使用的)过剩的公共货物--经济问题的正确判断,不过,我在大多数未充分考虑的反对声后面都听到过类似的看法.

　　公共拥有的悲剧预言只会出现三种结果.一种是泥潭;一种是为了村民的利益,强制性的使用某种分配协定(共产主义的解决方案);第三种是公用被打破,村民各筑藩篱,保护自己的一小块草地(私有制的解决方案).

　　当人们本能的的将这种模式应用于开放源码合作时,因此预计它只有很不稳定的短暂的半衰期.因为没有明显的方法去强制在互联网上工作的程序员执行工作时间分配策略,这种模式就断言公用将会打破,结果是出现各种各样的封闭代码软件和反馈给公用的工作量迅速减少.

　　事实上,经验清楚的显示出了与之相反的趋势.开放源码开发的广度和深度(由Matalab和freshmeat.net的每日宣布的数据统计)在稳定增加.很明显,这些都得出"公用悲剧"模式无法描述事态的发展.

　　答案的一部分正是建立在软件使用并不降低其价值的事实基础之上.实际上,对开放源码软件来说,当用户被其修正和特性(代码补丁)把握之后,软件的广泛使用还会增加其价值.公用悲剧被颠覆了,越放牧,草长得越高.

　　答案的另一部分是基于很难收取那些为公用源码基础所作的小补丁的市场价值.假设我为一个恼人的bug写了个修正,而且有人认为这个修正值钱;我如何才能从那些人手里拿到钱?对于这种小额的,通常也是适当的付款,常规的付费体系如此昂贵竟成为真正的问题.

　　比起价钱不仅仅很难收取,也许如何定价还要难得多.让我们想一想,假设互联网上已经拥有理论上完美的小额付费系统--即安全,方便,又不需要更多手续费.而你写了个补丁叫做"Linux内核的某某修正".你该要价多少?在潜在购买者还没看到补丁时,他们又该如何判断值不值得为它付费呢?

　　我们的问题就像F.A.Hayek的"计算问题"在哈哈镜中的变形--它就象个超市,即要估价补丁的功能值多少,又要相信定价是合理的以促进交易.

　　不幸的是,超市方式有一系列的不足,所以补丁的作者----打补丁的黑客有两种选择:躺在补丁上收钱,或免费扔出去.第一种选择将一无所获.第二种也可能如此,不过或者它会促使其他人提供互惠的给予,以解决上面那位黑客所头疼的问题.第二种明显无私的选择,在这种游戏情况中,竞然事实上是自私的.

　　在分析这种合作时,自由软件的开发所面临的问题会很重要(他们可能会工作在清贫,或没有足够的回报的情况下),这并不是由最终用户的数量决定的.开放源码项目的复杂性和沟通所带来的成本几乎完全和参与的开发者的数量成函数关系;拥有更多的几乎从不看源码的最终用户对此似乎没有任何益处.这只会增加在项目邮件列表中无聊问题出现频率,但是建立一个相关的常用问题列表,不理睬那些显然不读FAQ的人(事实上这已经是通用做法),可以很容易解决这个问题.

　　开放源码软件的真正最重要的自由软件开发问题是提交补丁功能时的磨合成本.可能的贡献者在声望上小有收获（见《开拓智域》一文）,而没有金钱上的补偿,想着"根本不值得提交这个修订,因为我不得不打补丁,写修改记录,在FSF任务文件上署名...".因为这个原因,拥有大量贡献者(其次才是成功)的项目很强壮.与之相反的是,每个有许多相互有制约关系的项目都需要有从始到终的贡献者.这种磨合成本就像政治一样呆板.总之,自由软件项目本身可以向你解释为何松散,无组织的Linux 文化,比紧密组织且集中管理的BSD项目的努力,更能吸引合作能量的意向;以及为何自由软件基金会,也在Linux崛起时重要性相对的减弱.

　　这条路不管走多远都是好的.但是,这只是在黑客写了补丁并公布了这个补丁后的事后诸葛亮式解释.我们需要的另一半答案是对为何JRH最初会写这个补丁,而不是为拥有销售回报的封闭源码程序工作.作出经济解释.到底什么商业模式创造了开放源码开发繁荣发展的环境呢?