Question

最一般的情况是项目只有一个所有者/维护者。这种情况下不可能有冲突，所有者做一切决定并独担所有的荣誉和责备。唯一可能的冲突是继任者问题——当所有者消失了或者不再有兴趣时，谁将成为新的所有者。社区此时还关心问题（c）即分支问题，这种关心在黑客文化中表现为移交准则：所有者/维护者不再维护项目时，应公开地将权利移交给某人。

最简单的非一般情况则是项目为“善意独裁者” ^[4] 拥有，其下有多位共同维护者。习惯上讲，项目团队偏好使用这种方式，Linux 内核及 Emacs 项目就很好地使用了这种方式，在解决“谁来做决策”问题上，该方式不比任何其他方式差。

通常，善意独裁者这种组织形式是由所有者/维护者组织形式（在创立者不断吸引贡献者的过程中）演变而来的。即便所有者仍然保持专断地位，这种形式也可能引入一定程度的争议：谁因为项目的哪个部分获得荣誉。

在这种情况下，习惯要求所有者/独裁者有义务公平地将荣誉给予贡献者（比如在 README 或 history 文件中适当地提及）。对 Lockean 财产模型而言，这意味着如果你对项目做出了贡献，你就会获得一份声誉上的回报（正面或负面的）。

按这个逻辑推理，我们明白善意独裁者事实上并不绝对拥有整个项目。虽然他有权做出强制性决策，但实际上是通过交易一部分声誉回报来换取他人的工作。这让人不禁联想到与之非常类似的佃农耕作，当然这点除外：即便贡献者不再为项目工作，其名字仍然保留在名誉表上，并能继续“赚取”一定程度的声誉。

当善意独裁者项目的参与者不断增加时，它倾向于发展出两层级的贡献者结构：普通贡献者和合作开发者。成为合作开发者的一个典型途径是承担起项目主要子系统的责任，另一个途径则是成为负责识别和修复 bug 的“最高修复官”（lord high fixer）。这两种情况下，合作开发者都是做出了大量和持续时间投入的项目贡献者。

在我们的分析中，子系统所有者是一个特别重要并值得深入研究的角色。黑客们常说“责任背后是权力”，一个合作开发者在承担起维护某个子系统的责任后，通常有机会掌控子系统及其对外接口的实现，其决策仅受项目领导人（同时也是架构师）的修正。我们观察到该规则有效地在 Lockean 模型上圈起了项目财产，它正如其他财产边界线一样起到了避免冲突的作用。

从习惯上讲，如果项目有合作开发者，“独裁者”或项目领导人应该在关键决策上征询合作开发者的意见，尤其当决策关乎某个合作开发者所“拥有”（也即投入了时间并为之负责）的子系统时。一个有智慧的领导者，会认识到项目内部财产边界的作用，不会轻易干扰或推翻子系统所有者做出的决定。

一些非常大型的项目则完全抛弃了善意独裁者模型，其做法是将合作开发者转为投票委员（如 Apache），或是在资深合作开发者内部轮流掌权，Perl 开发者就是这么组织起来的。

这种复杂的组织形式被广泛认为是不稳定和运行困难的。很明显这种困难主要来自于“委员会设计” ^[5] 以及委员会本身可能产生的问题，这些都是黑客文化在意识上所理解的问题，但我认为，黑客之所以发自肺腑地对这种委员会或者轮流坐庄的组织方式感到不舒服，部分原因是这种方式很难和黑客们潜意识中的 Lockean 模型相适应，Lockean 模型可以用于较为简单的情况，但如果用于这种复杂的组织形式，在分析所有权时，不论是控制意义上的所有权，还是声誉回报意义上的所有权，都有很多问题。在这种形式中，我们很难看到内部边界，并因此很难避免冲突，除非委员会内部享有极高水平的和谐与信任。