3.16 开源项目结构中的产权分配规则

最简单的情况，就是项目只有一个产权持有者（兼维护者）。这种模式不可能闹矛盾：产权持有者做出所有决策，并承担所有的功劳与骂名。唯一容易出分歧的，只有继任交接这件事——要是初代维护者淡出或者没心思继续做了，该由谁接手项目产权。前文 (c) 点也提到，社群都不想看到项目被 fork，大家对此都有共识。基于社群达成的这类共识，衍生出一套稳定的文化规范：即产权持有者/维护者无法继续维护项目时，应公开将产权移交给他人。

稍微复杂一些的情况，就是一个项目有多个共同维护者，他们在一位仁慈独裁者（benevolent dictator，常缩写为 BDFL）领导下工作，整个项目的产权都归他。根据惯例，团体项目倾向于采用这种模式；它在像 Linux 内核或 Emacs 这样的大型项目上已经证明有效，落到决策权分配这件事上，它的效果并不比任何其他替代方案明显逊色。

BDFL 这套产权管理模式，大多是从单人维护模式慢慢演变出来的：创始人不断吸引外部贡献者加入，团队规模做大，制度也就跟着成型。即使产权持有者依旧是独裁者，社群内部也会因“谁做了项目哪些部分，获得什么功劳”产生新的争议。

在这种情况下，惯例要求产权持有者/独裁者有义务公平给予贡献者功劳（例如，通过在 README 或代码提交记录中适当地提及）。放到洛克产权模型里解释，道理很简单：只要你为项目贡献代码，就能分到一部分声望产权收益，这份收益有赞誉，也免不了背负争议。

顺着这个思路想就能明白：BDFL 并不手握项目完整、排他的全部产权。虽然他有权做出具备约束力的最终决定，但本质上，他是把整体声望产权里的一部分收益份额让出去，换取其他人投入开发。用农场分佃制（sharecropping）来做类比，实在是再贴切不过了，只不过贡献者的名字会永久留在项目贡献名录，就算后来不再参与开发，也能持续拿到一点声望产权收益。

走 BDFL 路线的项目，参与的人一多，自然而然会分出两类贡献者：普通参与者、共同维护者（co-developer）。想成为共同维护者一般有两条路：要么独自扛下某一个核心子系统，接管该区域的产权领地；要么当“首席修复官”（lord high fixer），常年排查、修复各类 bug。不管走哪条路，共同维护者都需要长期、持续投入大量时间，以此换取对应子系统的配套产权权责。

子系统产权负责人这个角色，是我们这套产权分析里的关键，值得好好聊聊。黑客们喜欢说“权威跟着责任走”（authority follows responsibility）。只要共同维护者接下某个子系统的维护工作，那么这块模块的代码实现、对外接口，就全都归他的专属产权领地管，只需接受项目总负责人（兼任架构师）提出的修正。能明显看出来，这套规则依托洛克财产权模型，在项目内部划出多块独立的产权领地；和现实里所有产权分界一样，它能有效避免各方因产权起冲突。

按照惯例，只要项目有共同维护者，手握整体产权的 BDFL 或项目负责人，做关键决定前都得和这群人商量。尤其是决定牵扯到某个人专属产权领地的子系统（也就是他长期投入、全权负责的模块），协商就更有必要。明智的领导者都清楚内部产权领地边界的作用，不会随便插手、推翻各个子系统产权负责人做出的决定。

而有些体量极大的项目，则干脆彻底放弃 BDFL 这套产权管理模式。一种做法是让所有共同维护者组成投票委员会，Apache 就是典型例子；另一种是轮值统筹制，项目整体产权的管控权，在资深共同维护者的圈子里轮流交接，Perl 开发团队就是这么运作的。

大家普遍觉得这种复杂的多元产权组织形式不稳定、难以运作。这一点很好解释，集体委员会设计本身就自带一堆众所周知的问题，黑客文化圈对此早有认知。但我认为开发者本能抵触委员会、轮值统筹这类架构，还有更深一层原因：这种模式很难套进我们分析简单场景时，下意识使用的洛克产权模型。在这类复杂团队里，不管是控制权意义上的产权，还是声望回报收益意义上的产权，都很难理清每个人对应的领地；内部产权领地边界模糊不清，除非整个团队配合默契、互相信任，否则产权矛盾几乎无法避开。