开源之道按

说到治理，没有比政府更为擅长这个了，因为他们有几千年的经验可以借鉴，人性是复杂，尽管很多科学理论都证明了人类是天性趋于合作的，但是本能仅限制于近亲和血缘关系，要想做更大、更多的事，必须通过治理来实现，否则就陷于一片混乱。开源项目的发展也是同样的道理，因为涉及到人的劳动和协作，以及荣誉、成果的归属等。成功的开源项目如Linux、Hadoop、Kubernetes等是超越了大多数中国人的想象力的，在一个弱社会、信任度极低的社会中，没有强大的政府背书这几乎是不可能的事，而且还涉及到跨越国家、种族、时区等诸多组织力量。庆幸的是社会学家、实干家、开发者布道师们也在观察和总结这些背后的思想、方法论。OSS Watch 就是其中的翘楚！

引言

我们首先需要厘清治理模式是什么？治理模式描述了项目参与者可以承担的角色，以及项目内的决策流程。此外，治理模型还对参与项目的基本规则、项目团队和社区内的沟通和共享流程等的描述，换句话说，有效的治理模型，可以防止开源项目陷入焦油坑。本文会解释为何说治理模式是有必要的，对于在开源项目中采用治理模型相关的挑战方面的思考，且进一步的深入了解模型所覆盖的关键领域。另外还就关于治理模型的文档整理做了一些必要的说明。

为什么项目需要治理模式？

一千个人眼中就有一千个哈姆雷特，几乎是每有一个开源项目，就会有一个相应的开源策略，正因为此，关于项目的各项细节如政策、战略等，要准确无误的传递给对于项目有产出的潜在用户和开发者。一个清晰的治理模式可以让潜在的贡献者能够如何参与到项目中来，以及能够获得什么，甚至是提供哪些保护措施以确保大家的贡献始终是可用的。此外，它描述了有助于确保潜在用户项目可行性的质量控制流程，清晰简洁的开发沟通是开放式开发实现可持续性的最重要的步骤。

治理模式涉及范围颇广，从中心化的控制，无论是单独的个体还是组织（仁慈的独裁者），到基于贡献度认可的分布式控制，都会有所涉及。这中间有个类似光谱的范围，在这个范围内容的任何一点都会有相应的治理模式，而且随着项目的成熟，项目所选择的治理模式还会有所变化。下面一节图中所示的内容即是FOSS的项目示例，以坐标的方式所表达，该图还说明了这些项目是否鼓励来自广泛来源（市集式）的贡献，或者是否是仅针对一小部分人的专门贡献（大教堂风格）。关于贡献的模式的进一步的信息，请阅读 Eric Raymond 的大名鼎鼎的文章《大教堂与集市》，这里蛮耐人寻味的是，特定的治理风格并不会一定和某个贡献模式挂上钩，有的时候会出现，在项目的开始阶段，是采用的大教堂的仁慈的独裁者模式，但是随着时间的转变，项目的成熟，会转变为市集式的贡献或精英式的治理（或两者兼而有之）。

治理模式和贡献模式

Linux 项目就是 Raymond 提及的经典的集市模式，鼓励任何人都可以做出贡献，尽早发布，经常发布，该项目由其创始人 Linus Trovalds来治理，Linus 对发布中包括哪些贡献拥有最终的决定权。
GNU Emacs 是Raymond 论及的所谓的大教堂模式，由一个小的团队所组成的贡献者，而且发布的频率并不是那么的频繁，项目早期由 Richard Stallman 治理，不过值得注意的是，在Raymond 完成它的文章之时，Stallman其实已经不再管理这个项目了，而当前的维护者采用的是更加开放的贡献模式。
Apache HTTPD 项目是 Apache 软件基金会的项目，遵循正式的精英结构，Apache面向全球所有人，任何人都可以在上面贡献代码。
Apache OODT ，同样也是 Apache 软件基金会的项目，采用的是Apache精英模式，然而，它的开发模式是大教堂风格的，并不会积极的邀请他人作贡献。当这些核心团队成员觉得可以保证一定质量水平时，才会发布具体的版本。
Ubuntu 则是一个典型的仁慈的独裁者模式，即项目的把控者是其创始人和资助者：Mark Shuttleworth，然而，实际上的许多决定是由社区委员会和技术委员会决定的，而委员会的组成是由社区通过选拔来任命的，Ubuntu系统的核心部分是在 Canonical 内部开发，采用的是大教堂的风格，然而，也有社区社区的开发人员会被邀请去开发系统的关键部分，比如Ubuntu收集平台的核心应用程序。

市面上还在活跃的治理模式

我们来适当的分析一下这些典型的治理模式。首先，来看看Ubuntu 的治理模式，根据Ubuntu的描述，更加侧重于描述社区的结构以及与该结构的每个组件相关的职责，以及项目中决策过程的概要描述。Ubuntu项目是将开发人员信息和治理文档中的信息是分开的，但是其技术管理流程是被明确所记录的。

Apache 软件基金会为每个项目设置了两份治理文档，首先是基金会本身的治理文档，如组织结构的规定，另外的文档还专门介绍了诸如决策的关键过程的内容，然而，由于每个项目都是自由的，内部有一些限制条件，为了定义好各自的这些具体的变化，Apache软件基金会的很多项目都有自己的治理文档。有关示例，请参阅Apache Forrest治理说明。

我们列举的第三个关于治理模式的例子是关于Taverna项目，该项目是一个属于学术界内发展开源的例子，因此展示了一种在学术环境中发挥作用的模式。Taverna 的模式和上述Ubuntu以及Apache软件基金会一样，侧重于项目的结构和管理流程。

采用治理模式的障碍

尽管在启动的时候定义好治理模式是非常重要的，但是许多项目都忽略了这一点，其中当然有非常多的原因，这里列举几个最为常见的：

认为这个过程没啥必要，甚至还有些“繁文缛节”
担心该醒目会失去方向感
担心失去项目的战略控制权
认为项目还处于弱小的状态，暂时不会吸引到活跃的用户或开发者

虽然前三个问题都可能会遇到，但是只要运用恰当的治理模式这些担忧是很容易就消除掉的，然而，第四个问题确实非常主观的问题了，项目究竟多久算年轻？因为项目的任何潜在的贡献者都需要知道如何有效和积极的做出贡献，以及项目会如何处理他们的贡献。如果说一个项目没有这些问题的明确指导，那么大多数人都会离开，而不是加入。但是如果说这些早期的项目采用者被证明可以帮助指导项目走向成功，那么他们就有可能留下来，单打独斗的外部贡献者可能会对项目的可持续性产生重大影响，那么项目的发起人是特别珍惜这些人的存在的，几乎承担不起失去他们的风险。

在项目的早期阶段解决上述问题是有着明显的益处的，而且它们也不会成为治理模式的障碍。接下来就让我们一个个的深入讨论下。

繁文缛节

有很大一部分人认为治理模式简直是节外生枝，多此一举，但是事实上不是这样子的，只要仔细思考一下，治理模式并非大家想象的那样官僚行为，设计精良的话就可以带来很大的益处。目的是让模式尽可能的简单，还高效。治理模式并不需要事事都关心，实际上，它也不应该往那个方向去思考。相反，治理模式应该提供一种清晰透明的方式来指导项目管理的轻量级的方法。高度透明的方式可以吸引更多的人参与进来，这样的话，人们是可以看到项目是如何运转和进行的，那么人们就会考虑自己参与进去能够影响到什么。

特别需要注意的是，采用治理模式的目的是让人们参与做贡献变得更加容易，而不是起到相反的作用，它应该消除可能导致每个参与者浪费时间的不确定性。

迷失

担心治理模式会给不断变化的项目设置了障碍，之所以人们这么认为，大概是因为确实是有许多管理不善的开源项目在敏捷方面受到了一些限制。这是一种典型的误解，其实是没有找到问题的根源，而并非是由治理本身所带来的。设计精良的治理模式实际上是可以提高项目的敏捷性的，因为其可以做到让新来的贡献者如何在不干扰其核心目标的情况下为项目带来更多的可能性。治理模式还提供这样一种机制，即允许整个社区定义他们认为项目该往哪个方向发展，同时又能确保核心项目团队不会失去控制。关于失控的问题，我们将在后面一节进行专门的讨论，我们这里更加关注与愿景和方向。

开源项目的特性就是项目不可能是所有人拥有所有事，因此可持续项目的目标应该是为其核心利益相关者提供尽可能完整的解决方案，同时仍然对其他潜在利益相关者感兴趣。开源项目要随时准备好接受其它意外的投入，并且应尽可能的在未来的愿景和方向上满足潜在的内容。如此的做法可以明显增加项目在寻求可持续发展方面可以利用的资源，当然，我们也知道，那些个想无所不包、无微不至的项目几乎都失败了，因为过于分散的精力导致哪里都做不好。

解决的办法就是采用一种治理模式，让其提供在项目中明确定义和实施可接受范围的机制。模式的设计应该鼓励项目负责人可以摆脱那些浪费时间和资源的人和事，模式还应确保达成共识的人们能够以协作和建设性的方式进行高效的工作。基于如此机制的协作方式，在扩大项目范围的同时，并没有增加原始项目团队的需求。

失控

人们最大的担忧可能是治理模式会让持恶意的第三方控制了整个项目，毕竟，治理模式是希望通过为各方利益者赋予项目内各种权限，进而鼓励第三方的参与。这样的担忧是可以理解的，但是一个精心设计的治理模式是可以确保控制权仍然在保持初心的领导者的，比如，所有的决策都是由中心化的组织控制：如MySQL、SugarCRM，或者是所有的决策均是由社区自身进行的：如Apache HTTPD 服务、DoJo 。

在决定项目团队的控制权限级别时，还要慎重的考虑一下如何维持团队的工作。举例来说，如果该项目正在开发将会在商业上使用的高利润产品，那么在鼓励协作的同时保持控制有一些益处，例如，选择集中式的模式可以确保针对所选择的开发路线是牢牢掌控的，但是这么做会限制了可能对项目感兴趣的贡献者的广度和深度，因为他们的战略目标可能不同。

另一方面，如果项目正在开发一个本身是商业价值较低的组件的话，那么目标通常就是确保组件尽可能的被广泛使用。那么在这样的情况下，目标就是通过允许所有感兴趣和积极的合作伙伴参与战略规划等，进行最大限度的参与。

当社区被分裂（Forking)

这其实和治理本身所规定的内容无关了，那些从根本上不同意项目走向的任何人都有可能从新开始一个新的项目，治理模式的作用不是防止这样的事情发生。进一步，治理模式应清楚的定义好潜在的贡献者可能对项目的战略方向产生的影响。只有通过对社区的精心管理，开源项目的领导者才能保持”正常”，影响项目的走向，以这样的方式明确规定社区规则是这一管理过程的重要组成部分。

项目还处于早期阶段且太小

在这一小节，我们回到本章开始的时候所提到的关于项目处于早期，并没有吸引到第三方用户和贡献者的问题，这时人们总是认为毋需考虑这些问题。尽管很多人都是这么认为的，但是笔者则恰好持相反的意见。

定义合适的治理模式永远不会太早，离开治理模式，能够吸引到第三方的希望将变得非常渺茫。其中原因有下面几种：

潜在的贡献者会变得无所适从，不知道该如何下手
无法确定贡献会怎么发生
项目对于与第三方的合作显得并不严肃
以如此方式管理贡献的方式没有明显的保证，这对于原始的贡献者不是一个好的兆头

没有人知道哪些潜在贡献者会在什么时候冒出来，进而为项目做出贡献，因此凡事尽早做是没有坏处的，每一个错失贡献者的机会都是可耻的，会严重损害到项目的可持续性发展。还要时刻牢记，这是项目和贡献者之间的第一次接触，谁都知道，第一印象很重要。举例来讲，由第三方提供的错误修复可能会导致人们具有更好的用户体验，而这会进一步吸引更多的用户。这样就进入了一个正的循环，使得项目和贡献者更具吸引力。

一个常见的误解就是，对于自己的项目信心不足，以为没有必要把精力放在这些潜在的用户或贡献者身上，其实这是不应该的，在开源项目中，应珍惜每一位贡献者，它有可能是提高产品质量和可用性的关键人物。时刻要记得自己的主要目的是什么，贡献再少也是贡献。

另外一个亦颇为常见的误解是，以为自己的项目很小，根本无法应对大量的用户和贡献者的突然大量涌入，其实这是对于开发式开发不够了解所致：首先，即使是最大的项目也不会在任何时候吸引到超过少数活跃者的贡献者；第二，管理精良的社区在很大程度上是可以自治的，对于那些赋予成员很大权利的社区尤其如此。

–公众号（上）–

开放式开发项目如何做出决策？

采用开放式开发的项目中的决策机制，咋看起来是一个非常复杂的过程，而且还是上面提及的一些让人望而却步的内容，我们大多数人是心知肚明的，做出一个有效的决定是多么的不容易。记录决策的过程因此而成为治理模式的关键部分，这部分是值得专门花时间去探索的，应极力防止出现死锁的情况，这在开放式开发社区中是大忌。

开放式开发项目中的决策范围蛮广，从完全中心化的控制，到完全去中心化的发散，都有所涉猎，据观察各种结果，情况我们也是蛮熟悉的了，几乎所有的项目都是以集中的模式开始的，开始的时候只有少数的几个贡献者，很多情况其实只有一个人。那么在这样的情况下，所有的决策均是由这个小团队所作出的。对于一个小的团队来讲，集中决策非常的容易，这点非常类似于传统封闭式项目中的内容。随着项目的成长，越来越多的人开始愿意为项目做出贡献，那么这个时候，相应的决策过程也应该逐步的进行演变和进化。

仁慈的独裁者

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

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

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

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

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

精英制

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

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

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

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

如何制定治理文件

一旦你建立了自己要采用的模式，接下来要做到事情就是制定一份友好的治理文档，从而详细的说明制定决策和对贡献的识别等过程，下面的内容就是介绍一个创建项目治理文档的一般框架。该框架会描述要文档设计的主要方面，以及解释为什么这些内容是重要的，在最后，我们还给出了一些案例模板的链接。

一个典型的治理文档应包含如下章节：

概览
角色和责任
支持
决策流程
贡献流程

接下来我们将逐一讨论这几个主题，关于特定的案例，请移步看专门的文章：仁慈的独裁者模式和精英治理模式。

概览

治理文档的概览部分，应该提及的有项目的目标、项目管理方式等简要概述，而且要将它们适当的联系起来。另外就是一些关键的信息，如项目最终采用的许可证、版权的所有者、以及用户该如何参与项目的开发等。

概览要尽可能的简短，目的就是让观看的人们能够迅速了解他们参与项目相关的期望。

角色和责任

本节内容描述了项目中的正式角色及其权限。它还应该涵盖所需要的承诺水平以及每个寻求参与的角色。本部分的目标是明确谁管理项目、谁可以贡献、以及如何贡献，乃至于如果希望直接影响项目的话，该如何积极的表现。

定义角色的时候，可能都是大家耳能生详的名称，如“用户”、“贡献者”、“提交者”、或“项目管理委员会成员”。当然，也可以非常的具体，如“发布经理”、“测试经理”、“社区经理”、“产品经理”等等，通常情况下，所提供的细节越多，人们就越有可能识别出他们可以做出贡献的事情。谨记，请注意不要限制人们可以做出的贡献。例如，拥有“发布经理”头衔的人可能会觉得他们不适合协助管理项目路线图，这似乎是“产品经理”角色的一部分。出于这个原因，许多项目选择了描述各种活动的广泛标题。举例来讲，管理发布和管理路线图的任务可能均由一个角色来承担——如“提交者”，该角色中的个人将自行选择他们希望贡献的活动。

反过来讲，如果没有对某些人承担特定的责任可能会导致在特定活动领域就会缺乏贡献，当然，还需要与如下一些事实相平衡：指示社区成员执行已定义的任务这事不是总能行得通的，因为社区并非是雇佣关系，没有人喜欢被颐指气使。可以参考这份单独的关于角色的文档。

支持

本小节描述了关于项目内部的支持流程，对于绝大多数开源项目来讲，支持的渠道也是项目用户的主要联系方式，这些用户在未来可能会成为项目的贡献者，也可能成为商业提供商的客户，这些都是项目获得可持续性发展的关键之所在，开源项目尤其要照顾到这些用户。

治理文档的支持部分还应描述关于可用的支持渠道以及每种渠道的使用方式。它还应提供防止在多个渠道去提供支持，那样会导致过于的分散，过于分散的风险在于一旦某个单一的地方出现大量的问题，则会显得力不从心，因为，我们要尽量的去建设和寻求可以进行自我支撑的社区。

决策流程

对于开放式开发来讲，做决策的方式是项目成功的关键因素，一个过于耗时的流程会导致决策的延迟，从而导致整个项目的延迟，更为糟糕的是，这个流程可能会被忽略，进而社区的一部分权力被剥夺了。另外，一个定义不够明确的流程，可能会导致关于决策是否有效的争论，再次导致社区内的延迟和分裂。

决策过程的效率和透明度应该是治理文件中的主要重点。恰是这个决策的过程确保了潜在的贡献者，他们的努力将会得到项目公平的处理，并能够在未来保持价值。关于创建正确的控制结构的方法，在文章的前面我们有做过详尽的谈论。

贡献流程

本小节介绍人们应如何为项目做出自己的贡献，关于贡献流程的文档应该介绍各种类型的贡献是可以接受的，以及让这些贡献可以被管理的工具等，本节不应提供工具的完整描述，而应提供工具提供支持的过程的清晰说明。

与贡献相关的明确流程是必要的，原因有两个：

指导项目的贡献者
向潜在的用户保证，所有贡献的质量控制和法律监督足够强大，从而可以生产出可靠的、精良的软件

因此，治理文件的这一部分应描述项目对版权管理，编码标准和文档的期望。它还应该描述清楚贡献后会发生什么，包括当贡献被认为是不适合项目时所遵循的过程的详细处理。

总结

采用治理模式并尽可能早地制定项目治理文件对于创建开放式开发项目的成功至关重要。要记得，在项目启动的时候，对于做这些事情有着非常大的空间的。换句话说，如果项目已经启动了，再来做这件事，就恐怕步履维艰了。

然而，也没有必要从一开始就事无巨细的把项目治理模式给写完整了，其实设定一个大体的框架就足够了。另外，治理文件也毋须考虑未来每种可能的情景。具体的想法应该是从一个简单且易于管理的模型开始，该模型将向潜在的贡献者传递非常明确的信号。所谓成功的开放式开发的项目是需要那些能够为项目的发展而可持续的贡献的人们的，而且同时还要做到防止那些浪费时间的非同类人，以及耽误别人时间的人瞎掺和。

为了让项目的进展更有高效，治理文档要简明扼要、可访问、且易参考，应该侧重于决策的结构以及机制，但是前提是要足够的灵活，从而能够在日后随着社区的发展和外部世界交往频繁的复杂性时，做到从容应对。

治理模式的范围非常的广泛，从完全的集中控制，到完全的分布式，都有可能涵盖，理想的启动模型，如能够识别初始结构的模式，为公司或组织以外的第三方贡献者提供明确的向导，读者可以参考我们提供的关于仁慈的独裁者和精英制模板，对于开启是蛮有益处的，同时，OSS Watch 也可以帮助到你，移步这里，联系我们。

关于作者

Ross Gardler 曾担任 OSS Watch 的服务经理，是Apache 软件基金会的总裁

Gabriel Hanganu，是一位对开放社区的社会动态感兴趣的社会科学家，Gabriel曾是OSS Watch的社区发展经理。

本文由作者[Ross Gardler]() 和[Gabriel Hanganu]() 发表在oss watch上：Governance Models。经授权，在开源之道翻译共享。本文在Creative Commons BY-SA 4.0许可证下发布。欢迎转载！

（开源项目）治理模式

Thu May 23, 2019 | 9400 Words | 大约需要阅读 19 分钟 | |