# 慈善独裁者 *慈善独裁者*模型这一称号确实名副其实：最终的决定权完全取决于一个人，因为其人格和经验的力量，他被认为可以明智的运用这个权力。 尽管“慈善独裁者”（*BD*）是这个角色的标准术语，但是更应该将其视为“社区认可的仲裁者”或“裁判者”。通常来说，慈善独裁者并不会作出所有的、甚至大多数的决定。一个人很难拥有在项目所有领域中都能做出正确决定的专业技能，毕竟，如果对于项目的方向没有任何影响，有价值的开发者也不会在此停留。因此，慈善独裁者通常不会非常的独裁。相反，他们会尽可能的让事情在讨论和实验中顺其自然。他们自己也会参与讨论，但是作为某领域的普通开发者，他们一般会尊重拥有更多专业知识的领域维护者。只有当明显无法得出结论时，而且大多数成员*期望*有人能够指导作出决定，并让开发继续时，他们才会采取坚定的立场并说“这是我们前进的路。”避免使用命令作决定是所有成功慈善独裁者共同的特征；也是他们设法保持这个角色的一个理由。 ### 谁可以成为一个慈善独裁者？ 成为一个BD需要许多特性的组合。首先，要对自己在项目中的影响有经过充分磨练的敏感性，这样可以保证自我约束。在一个讨论的早期阶段，一定不能过于确定的表达自己的意见和结论，以至于让别人觉得继续发生分歧毫无意思.人们应当能自由的放飞思想，即使是愚蠢的想法。BD也会不可避免的屡屡发表愚蠢的意见，所以这个角色也必须具备认可和承认自己作出错误决定的能力—尽管这是一个*所有*优秀开发者都应该具备的能力，但如果她要长期呆在一个项目，这一点特别重要。但区别是BD无法无视其信誉的长期损害。但资历尚浅的开发者不必如此谨慎，所以BD必须对批评或反对决定的语句小心措辞，对于词汇的分量十分敏感，不仅是技术上的，还包括心理的。 BD的技术技能*不*需要超越项目中的所有人。但她对于自己的代码工作必须足够精通，也必须能够理解考虑中的所有变更的讨论，但这还不够。BD的位置并不是通过恐怖的编码技巧获取或保持的。重要的*是*富于经验和全局的设计感觉—不必是根据要求生产好设计的能力，只需要有识别好设计的能力，无论是什么来源。 慈善独裁者经常是项目的创建者，但这只是一种关系，而不是原因。这类特性让一个人能够成功的开始一个项目—技术能力、说服别人加入的能力等等—也都是BD所需要的。当然，创建者开始就自动有了相关的资历，在成为慈善独裁者的方法中，是所担心的阻力最小的。 请记住，潜在的分叉会以两种方式出现。一个BD可以和其他人一样分出一个项目，确实有些人已经这样做了，这是因为他们觉得要将项目带领到大多数项目成员不希望的方式中。因为可分叉的能力，慈善独裁者是否有项目主服务器的root权限（系统管理员特权）并不重要。人们有时候会将服务器的控制能力当做对于一个项目的权力根源，但实际上这毫不相干。将某服务器上某人的提交密码添加或删除的能力只会影响存放在那个服务器上的项目拷贝。对于此权力的长期滥用，无论她是BD或其他人，都会致使开发转到其他服务器上。 无论你的项目是否存在一个慈善独裁者，或能够在一个较弱的集中式系统下运行良好，都十分依赖于谁在承担这个角色。作为一个普遍的规则，通常对每个人来说谁是BD非常的明显，然后就会如此继续。但是如果没有明显的BD候选者，项目通常会使用分散的决策过程，这就是下个小节所描述的。