开源治理模式

仁慈的独裁者模式

所谓的仁慈的独裁者模式，是指那些对项目的整个生命周期中都保持绝对的控制，作为项目的绝对决策者，负责确定项目的总体方向，并在社区出现分歧的时候做出最终决定。随着越来越多的贡献者的加入，仁慈的独裁者会努力的确保这些贡献者的决定是符合项目的根本利益的，而不会被某个特定的个人或组织所左右。一个好的仁慈的独裁者能够做到在发生冲突的时候做到完美的平衡，这不是一个轻松的任务，在你打算要献身于此之前，还请三思，并认真阅读Karl Fogel先生的：我可以成为一个好的仁慈的独裁者吗？一文。

终身仁慈独裁者（英語：Benevolent Dictator For Life，缩写BDFL）是少数开源软件开发者所拥有的头衔。他们通常是某一项目的创始人，并在该项目社区出现争议时拥有最终的决定权。

当项目的团队还比较小的时候，而且用户的社区也比较小，这时仁慈的独裁者会按照传统的自上而下的方式来做出所有的决策。然而，随着社区的增长，这会变得越来越困难，很少有人能够完全理解所要解决问题的所有细节，因此，他们可能会对在不怎么专业的领域所做出的决定不是太有把握。随着项目规模和范围的扩大，人们对于不能有十足把握的模块也会增长，那么作为项目的带头人，就无法做到面面俱到。

基于如上原因，一个颇为高效率的独裁者会慢慢转变为协调者，或者叫做仲裁者，他们通常情况下，不会在辩论当中站队，Linux Torvalds曾经说过，“我宁愿看到的场面是有15个人为一个问题而争执的面红耳赤，而不愿意看到15个人分成两支队伍，每支队伍都只和自己观点相近的人说话。” 这就是Linus的高明之处，如果Linus偏袒了任何一方，那么都会影响到对面的一方，进而会发展到社区在共识方面的偏离。如果说独裁者本人有自己的主见，那么这是可以接受的，如果说在某些领域其他人更具资格的话，那可能就会得到一个次优的决策。

在中型或大型项目中，领导者通常会让讨论继续，并且只有在不太可能发生的事实中表明没有明显的共识出现时才表现出自己的偏好。因此，仁慈的独裁者会试图阻止毫无结果的辩论，但鼓励进行更为广阔的辩论。因为只有这样，人们才会觉得Ta是一名社区主席，而不是真正意义上的”独裁者”。

在为集中控制的项目撰写做决策的治理文档时，重要的是要表明决策权是集中的，而整个过程是通过分布式的社区辩论所做出的决定，如果不这么做的话，可能会让一些潜在的参与者敬而远之，他们担心他们的专业的意见不会被考虑。

精英治理模式

有些项目，正如我们上面所谈及的，是严格控制决策过程的，但是还有另外一些项目采用的是让整个社区去做出的决策，这样的机制会产生一种情形，那就是随着对正式决策过程的增加，会陷入一种无限期的死循环，问题一直悬而未决。

采样这样模式的社区，结构通常看起来要比仁慈的独裁者那样的组织结构更为的扁平化。事实上，通过积极而有效的贡献所赢得的声望，在社区往往拥有更为“响亮的声音”。这意味着仍然会有领导者出现，而他们必须去做一些和仁慈的独裁者一样的事情。那么这种通过贡献获得权威的模式我们就称之为精英模式。

精英模式尝试确保社区新来的参与者能够感受得到参与是非常受欢迎的事情。精英模式提供了一种良好的识别机制，如提高项目内部的可见性，让每个人都能够充分的发表意见，且会奖励那些做出有价值贡献的人（这点在示例的精英模式中有更为详细的讨论）。在做出决策方面，精英模式和仁慈的独裁者模式一样，通过倾听来自社区的声音，且要达成共识进而采取行动。其实，在许多情况下，根本就没有必要进行讨论，因为正确的路径是明摆着的。这样的话，有一个人来陈述意图即可，然后留出时间让人们反对就足够了。在没有异议的情况下，默认假设是整个社区都同意所提议的行动的，这样的决策我们称之为”懒人共识法”。

懒人共识也就意味着，在实践过程中，精英模式下的大多数决策都是以和仁慈的独裁者模式下运作的项目非常相似的方式进行的。这句话的另外一层含义就是说，一旦某位社区成员获得了定义行动方案，使用懒人共识法就可以让他们更进一步的走下去，正如仁慈的独裁者所做的那样。如果分歧无法通过讨论解决，这个时候就越发体现出两种模式的不同之处了，在精英的治理模式中，是要以投票的方式来打破这样的僵局的；在投票的过程中，社区中所有的成员都拥有投票权，但是否决权则只有那些获得足够资格的社区成员才能够拥有。