3.15 从产权看冲突的三大根源

在围绕开源软件的冲突中，我们可以归纳出四个主要问题：

• 谁有权对项目做出具有约束力的决策？

• 各项功劳归谁、各类过错由谁承担？

• 如何减少重复劳动，并防止非官方分支版本复杂化 bug 追踪流程？

• 从技术角度而言，什么是“正确之举”？

然而，如果我们重新推敲“什么是正确之举”这一点，它就往往不成问题了。对于任何此类问题，要么有被所有相关方接受的客观判定方式，要么没有。如果有，那就万事大吉，人人受益。如果没有，则问题最终都会落脚到 “谁拥有最终决策权”。

因此，一套项目冲突的化解理论，必须回应三个问题：

（a）设计决策的最终定夺权在谁手上，

（b）如何认定贡献者的功劳以及如何分配功劳，以及

（c）如何防止项目团队与产品分化出多条独立分支。

产权惯例在解决（a）、（c）两类问题时作用十分清晰。惯例确认了项目产权持有者有权做出具有约束力的决策。我们之前也观察到，社群惯例还会形成很强的约束，抵制通过 fork 来稀释产权的行为。

值得注意的是，即使抛开声望博弈，单从黑客文化中纯粹的技艺模型来看，这些惯例也合情合理。在这种观点下，这些惯例与其说是为了防止声望激励被稀释，不如说是为了保障工匠依照自身思路落地设计构想的权利。

然而，技艺模型不足以解释黑客关于（b）问题（即谁因何事获得功劳）的惯例——因为纯粹的工匠不关心声望博弈，也没有动机去关心功劳的归属。为了分析这一点，我们需要将洛克的财产权理论再推进一步，既要分析项目之间的冲突与产权运行规则，也要拆解项目内部的同类问题。