Table of Contents
有关自由软件，人们经常问到的第一个问题是：“它能行吗？如何保持项目一直运行？谁来做决定？”我一直对关于知识界精化、合作精神、代码会说话此类的平淡回复无法感到满意。事实是这个问题很难回答。知识界精化、合作精神和运行代码只是其中的一部分，但它们对于解释日复一日的项目运转贡献不多，对于如何解决冲突什么也没说。
本章尝试展示支持成功项目的共同结构。 “成功”不仅仅指的技术质量方面，而且也包含了运行健康状况和生存性。运行健康状况是指项目将新代码和新开发者吸收进来，并对到来的bug负责的持续能力。生存性是项目独立于任何单独参与者或赞助商而存在的能力—考虑一下如果项目所有的创始成员离开后项目继续运作的可能性。技术成功不难实现，但是如果没有健壮的开发者基础和社会基础，一个项目就不能处理由初始的成功带来的成长，或者有魅力个体的离开。
获取此类成功有很多方法。有些涉及正式的管理结构，通过哪些争论被解决、新开发者被邀请加入（有时是离开）和计划的新特行等等。还有一些涉及不太正式的结构，但需要更有意识的自我克制，来产生一种人们可以依赖的正直氛围，作为事实上的管理形式。两种方式都产生相同的结果：一种由来已久的永恒感觉，由所有参与者都充分理解的习惯和程序作为支撑。这些特性在自我组织的系统中甚至比集中控制的系统更重要，每个人都知道一个坏苹果可以毁掉一桶，即使只是一会儿。
能将开发者绑定在一个自由软件项目中的必需组成部分，能让他们在必要时愿意作出妥协，是代码的分叉能力：也就是任何人可以使用一个拷贝并使之成为一个竞争项目的能力，被称为分叉。怪异的是自由软件项目的中分叉可能性具备比实际的分叉更大的动力，很少会发生。因为分叉对于每个人都不好（Chapter 8, 管理志愿者的the section called “分叉”会解释详细原因），分叉的威胁越大，越期望的人就越会妥协去避免它。
分叉，更确切说是分叉的可能性，是自由软件项目中没有真正独裁者的原因。考虑到在一个特定开源项目中听到某人被称为“独裁者”或者“暴君”是多么常见，这看起来是一个令人惊讶的断言。但是此类暴政是特别的，与一般意义上的字面理解非常不同。想象一下一个国王的臣民可以在任何时候复制整个王国，并搬过去按自己满意的规则统治。这与国王无论如何做，臣民都无法离开的情况是多么的不同？
这也是为什么即使项目不是完全按照民主方式组织时，在实践中，重要决定还是通过民主方式产生。可复制性暗指了分叉能力；分叉能力暗指了意见一致。也可能是每个人都希望与一个领袖不同（最有名的例子是在Linux内核开发中的Linus Torvalds），但那是因为他们选择如此，以一种非愤世嫉俗和非邪恶的方式。暴君没有项目的定身法。所有开源许可证都有一个关键特性，也就是在代码如何变更或使用上没有给任何组织更多的权力。如果一个独裁者突然开始做了一个坏的决定，就从此不得安宁，紧接着就是造反和分叉。除非，当然，很多时候不会到这一步，因为独裁者会首先妥协。
但仅仅因为分叉能力放置了一个上一个人在一个项目中发挥多少力量的上限，并不意味着项目的管理方式没有太大的区别。你不会希望每个决定都是某人要考虑分叉后的结果。那样会让人迅速疲倦，丧失真正工作的能量。下面两个小节会仔细检查组织项目平稳做出大多数决定的不同方法。这两个都是极端理想的例子；许多项目会处于中间状态。
慈善独裁者模型这一称号确实名副其实：最终的决定权完全取决于一个人，因为其人格和经验的力量，他被认为可以明智的运用这个权力。
尽管“慈善独裁者”（BD）是这个角色的标准术语，但是更应该将其视为“社区认可的仲裁者”或“裁判者”。通常来说，慈善独裁者并不会作出所有的、甚至大多数的决定。一个人很难拥有在项目所有领域中都能做出正确决定的专业技能，毕竟，如果对于项目的方向没有任何影响，有价值的开发者也不会在此停留。因此，慈善独裁者通常不会非常的独裁。相反，他们会尽可能的让事情在讨论和实验中顺其自然。他们自己也会参与讨论，但是作为某领域的普通开发者，他们一般会尊重拥有更多专业知识的领域维护者。只有当明显无法得出结论时，而且大多数成员期望有人能够指导作出决定，并让开发继续时，他们才会采取坚定的立场并说“这是我们前进的路。”避免使用命令作决定是所有成功慈善独裁者共同的特征；也是他们设法保持这个角色的一个理由。
成为一个BD需要许多特性的组合。首先，要对自己在项目中的影响有经过充分磨练的敏感性，这样可以保证自我约束。在一个讨论的早期阶段，一定不能过于确定的表达自己的意见和结论，以至于让别人觉得继续发生分歧毫无意思.人们应当能自由的放飞思想，即使是愚蠢的想法。BD也会不可避免的屡屡发表愚蠢的意见，所以这个角色也必须具备认可和承认自己作出错误决定的能力—尽管这是一个所有优秀开发者都应该具备的能力，但如果她要长期呆在一个项目，这一点特别重要。但区别是BD无法无视其信誉的长期损害。但资历尚浅的开发者不必如此谨慎，所以BD必须对批评或反对决定的语句小心措辞，对于词汇的分量十分敏感，不仅是技术上的，还包括心理的。
BD的技术技能不需要超越项目中的所有人。但她对于自己的代码工作必须足够精通，也必须能够理解考虑中的所有变更的讨论，但这还不够。BD的位置并不是通过恐怖的编码技巧获取或保持的。重要的是富于经验和全局的设计感觉—不必是根据要求生产好设计的能力，只需要有识别好设计的能力，无论是什么来源。
慈善独裁者经常是项目的创建者，但这只是一种关系，而不是原因。这类特性让一个人能够成功的开始一个项目—技术能力、说服别人加入的能力等等—也都是BD所需要的。当然，创建者开始就自动有了相关的资历，在成为慈善独裁者的方法中，是所担心的阻力最小的。
请记住，潜在的分叉会以两种方式出现。一个BD可以和其他人一样分出一个项目，确实有些人已经这样做了，这是因为他们觉得要将项目带领到大多数项目成员不希望的方式中。因为可分叉的能力，慈善独裁者是否有项目主服务器的root权限（系统管理员特权）并不重要。人们有时候会将服务器的控制能力当做对于一个项目的权力根源，但实际上这毫不相干。将某服务器上某人的提交密码添加或删除的能力只会影响存放在那个服务器上的项目拷贝。对于此权力的长期滥用，无论她是BD或其他人，都会致使开发转到其他服务器上。
无论你的项目是否存在一个慈善独裁者，或能够在一个较弱的集中式系统下运行良好，都十分依赖于谁在承担这个角色。作为一个普遍的规则，通常对每个人来说谁是BD非常的明显，然后就会如此继续。但是如果没有明显的BD候选者，项目通常会使用分散的决策过程，这就是下个小节所描述的。