开源治理的模式

理”的思维明显是错的，任何开源项目都必然拥有自己的一套治理模型。多数情况下，这种治理模型隐含在项目成员的日常交互当中。结果就是，老成员可能把新生力量视为潜在威胁，新人则发现自己难以融入，甚至不知道该怎么立即参与、或者如何为贡献内容申请核准。

要在项目中建立治理模型，第一步就是设定一个存在改进空间的特定点位。我们可以回顾项目的变更历史记录，借此确定如何让自己的贡献成果赢得老成员们的青睐。随着贡献接纳量的增加，大家将逐渐在社区中累积起影响力。

“创始人/领导者”模式

“创始人/领导者”治理模型在新项目、或者贡献者较少的项目中最为常见。在这类项目中，创始个人或团体同时也负责项目管理，包括确定发展愿景、控制代码合并权限，并承担起在公共场合代表项目发言的权利。也有一些项目将创始人/领导者称为“传递的独裁者”。在这类项目当中，权利与权限的边界通常非常明确。而一切重要的项目事务，最终决策者都由创始人/领导者担任。

随着项目增长至一定规模，这种模型的局限性也变得显而易见。最终，创始人/领导者的个人偏好会与项目设计的最佳决策区分开来，这时候创始人/领导者反而成为项目决策中的瓶颈。在极端情况下，创始人/领导者模型可以在项目中创建一种“种姓制度”，因为非创始人会逐渐感受到自己根本无力改变创始人的意愿与思路。这种分歧可能导致项目分裂，甚至一旦创始人/领导者出于心理倦怠或计划内退休等理由而选择离开，项目也许会瞬间土崩瓦解。

对于采用这类治理模型的项目，大家可以首先浏览项目的通信邮件列表，或者访问讨论论坛与项目创始人/领导者建立初步联络，而后一一解决该如何提交贡献成果的问题。这会帮助我们对项目需求建立起全面了解，并据此分析自己最擅长、或者最适合在哪个方面做出贡献。另外，您需要明确理解创始人/领导者对项目的基本构想，否则一旦与构想有所抵触、我们提议的变更恐怕会被直接否决。在起步阶段，不要指望提出任何不利于创始人/领导者基本愿望的项目修改方案。

自我任命的理事会或董事会模式

认识到“创始人/领导者”模式的缺点，自我任命的理事会或董事会模型希望建立起更顺畅、更稳定的领导者继任制度，借此推动社区走向成功。在这种模式下，开源项目的成员可以任命多个领导小组来管理项目中的各项工作。此类小组可能包括督导委员会、提交者委员会、技术运营委员会、构建委员会或者董事会等。各个小组大多拥有自己的一部分决策惯例与继任规程。

如果项目缺乏赞助基础、而且很难建立起选举机制，那么这种自我任命理事会或董事会治理模型往往能够发挥良好作用。但请注意，如果自我任命的领导小组被项目社区所孤立、或者代表性不足时，这种模型的弊端就开始显现。在这种情况下，成员的甄选过程往往会引发激烈冲突，而之后建立的领导文化可能带来一定抵触。此外，社区成员可能觉得自己处于被挑选的消极地位，因此对贡献工作也许缺乏充分的积极性。

要在使用这种治理模型的项目中展开探索，我们不妨先从入门文档起步。首先需要明确，这种治理模型在较为成熟的开源项目中相当常见，因此社区往往会整理出比较全面的贡献者入门说明素材。请认真阅读这些材料，再结合项目的治理文档确定治理模式的运作方式。在大多数情况下，您都可以联系理事会或董事会了解项目贡献中的具体问题。组织内将有专人监督您的贡献，并回答您可能抱有的疑问。

选举人制度模式

一部分开源项目会采取选举人制度进行治理。例如

（编辑：牡丹江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!