堵俊平：开放治理是开源社区的终极之路 | DEV. Together 2021 中国开发者生态峰会

内容来源：2021 年 6 月 5 日，由 SegmentFault 思否主办的 2021 中国开发者生态峰会圆满落幕。会上，开放原子开源基金会 TOC 主席、华为计算开源总经理堵俊平发表了《开放治理：开源社区的终极之路》的主题演讲。

分享嘉宾：堵俊平，开放原子开源基金会 TOC 主席、华为计算开源总经理

速记整理及发布：SegmentFault 思否编辑部

我是堵俊平，来自开放原子开源基金会。今天给大家介绍一下关于开放治理的一些体会，包括我们开源社区应该走向何方的一个思考。我今天的命题叫做《开放治理：开源社区的终极之路》，看起来像一个论断，可能是一道证明题，但是我不打算把它变成证明题，后面大家可以看到这实际上是一个选择题。

开源社区有很多种方式，开放治理只是一条选择的路径。这条路径意味着什么？选择的代价是什么？成本又是什么？最后得到的结果是什么？我希望能够把它打开来看，然后让大家来看是不是一个好的选择，或者是最终极的选择。所以我会聊一聊关于开源，它的初心、本质是什么。我们也会看到所谓的开放治理，它的关键问题、关键路径是什么？后面我们会聊关于开放治理的一些业界实践，包括基金会（Apache、开放原子）的一些实践，最后我们再探讨开源的未来。这是整体的讨论思路。

开源的初心

我们先从一本开源界特别经典的书《大教堂与集市》谈起，相信在座的很多人可能读过或者听过这本书。这本书的作者 Eric S·Raymond 深度参与了整个 Linux 的开发过程，或者说作为旁观者以观察者模式看了整个 Linux 的开发过程。在 Eric 眼里，传统软件开发过程是所谓的教堂模式，就是少数能工巧匠一起构建一个宏伟的宫殿。但是，他在 Linux 开发者社区里面发现了一个有趣的现象——它更像一个市集模式，大家都是开放的参与，像一个乱糟糟的市集一样，但是最后一样可以开发出宏伟的教堂、圣殿，一个软件的宫殿。那是怎么做成的呢？为什么这种市集模式能成功？他有一个很重要的判断，就是说如果有足够多的人加入到 beta 测试者，或者有足够多的人帮助这个项目贡献代码来解决问题，那么所有的问题都会被发现，所有的问题自然也会有人解决。我们做开源项目，很重要的问题是人的问题，是贡献者的问题。我们一直说开源最重要的是把人汇聚，汇聚到社区里面，然后通过社区的力量把这些人放到合适的位置，驱动这个项目往前进。如果有足够的人的资源，这些人又以合适的方式来做事，那所有的事情自然也就迎刃而解。我们聊的所有关于开源的问题，无非就是人和事的问题，就是这两点。

回到这个命题，就是所谓的「开放治理」。我们为什么说开放治理是一个选择，或者是怎么样的一个选择？开放治理是什么？我们首先要聊清楚。从字面上来看，它很像一个文字游戏，可能大家有不同的理解。开放治理直观来看是用开放的方式来治理，还有人认为所谓的开放治理就是放开治理，就是不要治理，大家都是自由地来自由地去，自由地去做任何事情。当然，还有一些人认为开放和治理是两个层面，一方面要开放，一方面讲究治理：一边要有一些开放性的动作，另外要有一些治理的规则。实际上，我所理解的开放治理可能会更全面，指的是用开放的一种治理手段达到社区开放的成果，社区开放的成果反过来促进社区的繁荣，这是一整个过程，应该是说有过程、有手段、有结果，这可能是我们讨论的开放治理。那就回到了原始的问题，为什么我们通过开放治理的手段能够达成这样一个目的？我觉得可能要回到我们对开源的认识。

什么是开源？我们再重新回顾一下。如果大概在五年前、八年前问这个问题，可能所有的开发者会觉得开源就是指源代码的公开。但我相信，经历了最近三五年全球范围的开源浪潮洗礼，大家都认为开源不只是代码开放这么简单。其实早在很多年前，十几年前，我们有一个组织 Open Source Initiative（OSI）组织就定义了什么叫开源，大概有十条原则。

这十条原则规定了它是免费的代码分发，包括衍生品的自由使用，包括版权要有一些相应的归属，以及很多细节。但是它同样有很强的限制，告诉你开源不应该做什么，比如不应该歧视某一个人或者某个团体、不应该歧视某一种场景，或者不应该专门用于某一个产品等等。它有很多很多这样的规则，那这些规则决定了什么呢？开源实际上有很强的原则性的属性，这些原则性的属性是为了保证什么？保证我们想做的事情，开源想做的事，把人聚集起来做事，要有正确的方式，要让人能够团结起来。如果你的许可证、开源本身就暗含着很大的不公正、不透明，或者很多歧视性的法则，那开源就违背了我们最早的初衷，即把人聚集起来一起更高效地做事这一初衷。

从这一点上，我们一般认为开源有三个重要的因素。第一个就是代码，代码决定了项目的技术走向。从代码里能看到技术是否先进、性能是否高效、功能是否完善，甚至包括代码的质量、可读性、是否容易维护。所以从技术角度来看，代码是开源项目很重要的一个部分，是它的门面，也是它的里子。

第二个是许可证。许可证也非常重要，因为许可证决定了用户或者说开发者拿到开源项目代码后是否能够使用、以什么方式使用、是否能够分发、是否可以修改，以及做了修改和分发之后所承担的权责利。当前大家知道业界一个热点，有些开源项目变更了许可证引发了业界很大的动荡。为什么会引起这么大的风波呢？因为开源许可证的变更直接影响到了开源软件是否可以以合适的方式在市面上销售或使用，或者在市面上进行其他被授权的方式。许可证一旦变更，可能会对所有当前的用户、使用者，包括分发者造成很重要的影响，所以 License 也是非常重要的。我们有的时候甚至在刚接触一个项目时，先看的还不是代码，而是 License，因为 License 决定了项目社区对这个项目的实际定位，包括生态策略——是要构建强的主干避免分裂，还是希望分支能够更多，这个其实从 License 授权就可以看出来。

第三个因素就是社区。这个我们强调了很多，有一句话叫「Community over code!」，认为代码重要，但是社区更重要，或者是代码没有社区重要。因为代码是静态的，代表了项目当前的状况，但社区代表人，是社区里参与的动态的东西，也决定了代码未来的走向、未来的版本和未来无穷的潜力。如果你有一个不好的代码，但是你有一帮精英、很优秀的人在这个项目里面，那么代码迟早会一点点变好。但是如果你有很精致的代码，但是社区里厉害的人都走开了，那这个项目代码迟早会过时、腐烂。所以这是我们认为开源项目最重要的三要素：代码、许可证，以及社区。

这是三个重要的因素，在这三个因素之上，它的开放程度就决定了这个开源项目（实际上是开放，我们不能直接说开源，因为下面这个阶段只是代码开放阶段，严格来讲它还不能被称为开源项目）有三个层次。

第一个层次是代码开放（Source Available），即代码可被公开访问，但是在 Source Available 这个层次，代码是否可以被使用、修改、分发，这个是不确定的。所以说大家在网上如果看到一个项目只有代码而没有任何的 License，就意味着这可能仅供参考。因为项目代码的作者并没有把他的版权包括版权所归有的任何权利授予你，这个地方我们要小心。

第二个阶段就是所谓的 Open Source。Open Source 就是有公开代码，有被 OSI 组织认可的 License（许可证）授权你去使用，当然不一定所有的许可证都被 OSI 认可，比如 SSPL 或者一些其他的许可证。这个可能无法严格地定义成开源，它也是一种授权许可，规定了你拿到项目代码之后的权责利。

第三个就是我们今天重点探讨的 Open Governance（开放治理），就是关于我们社区是开放的还是紧闭的，如果是开放的，它是全开放的、还是半开放的。这是第三个层次，即我们希望有开放的社区，开放的治理 Open Governance。这是三个层次。

开源治理的关键性问题与因素

我们刚才说到了开源项目要不要开放治理是一个选择题，就是说要或者不要。但是我们首先要说，看一个社区是开放还是封闭首先有一个判断题。这个判断题来自于哪里，我们要看几个点。

第一个就是这个项目相关的政策和流程是如何制定的，比如这个开源项目规定了相应的代码提交流程、review 的流程、整个项目如何去决策、它的 roadmap 等等这些顶层的制度设计。这个权利是在哪里？一个项目背后一定是有这些相应的权力、组织的规则，这个规则如果没有开放出来，那就意味着背后一定有个人或者某一个组织在负责实际项目的推动运作，除非这是一个死项目，nobody care。否则只要是项目，不管它开源或者非开源一定有相关的决策流程，一定有相关的顶层设计规则。如果这个部分没有开放出来，那我们认为它还不能算开放治理。

第二个很重要的是贡献者在这个项目里面可以承担哪些角色。比如提PR，这是一种，第二种是 review PR，包括 merge PR，把这个PR真正合入，包括成为整个大模块的核心 maintainer，甚至是项目的 PMC（管理委员会）的一员，在项目的治理上有发言权、投票权。那么这些角色是否开放出来？除了这些角色分工明确之外，还有人们如何进入到这些角色当中，通过公开选举，还是通过投票选举。如何进入到这些角色当中，这个地方也是值得观察。如果有这些角色，但所有的角色通过组织内部指定的方式加入，那么认为它可能还不算是开放治理，因为很多人离开了组织之后，投票权或代码审核权可能自动流失，那么这个可能不能算是开放治理的典范。这里我们讨论了所谓的开放治理是个判断题，我们通过这些点可以判断一个项目到底是否进入开放治理阶段。

那回到刚才的选择题：一个项目到底要不要选择开放治理？项目的选择维度很多，就是它会看很多的点。

第一个它可能会去看价值因素，即项目背后的团队，尤其是很多初始团队，对于开源项目或者说开放治理的价值认可：它需不需要开放治理？它是不是只要用户生态就可以了，大家只要用起来就可以了？它需不需要外部的贡献者贡献他们的智慧、场景，贡献他们对开源社区的热情以及专业度？它需不需要这样一个开放的价值？

第二个是文化的因素。有些团队、有些项目可能认可这个价值，但是从文化的角度，比如说我们接不接受在相对不确定的环境下，对于项目部分地失去控制权，当然初始团队仍有影响力，我们说最初始的项目团队的贡献不管在任何项目当中都是得到认可的。但是选择了开放治理，我们认为就是纳入了外部的资源进来，在我们的整个开发流程当中也开放出来，允许外部不同的声音切入到整个流程里面，在有些人或者团队会认为这多多少少面临着某种无序，面临某种失控。

但是回到刚才讨论的那本书《大教堂与集市》里面，其实说的也很清楚，这种看似无序看似乱糟糟的状态背后是井然有序的，但是这种表面上的乱糟糟、表面上的热闹，大家在文化上是否能够认同，文化上是否能够兼容，我觉得这是很重要的问题。还有一个问题是人的因素，如果人本身没有开放包容的大脑，那即便你给他一个公平的规则或者开放的规则，大家也会想如何利用好这个规则去做一些不开放的事情。所以我觉得人的因素也很重要，这里面也会受到一些文化的影响。所以我觉得选不选择开放治理不是一个简单的技术因素，也不是简单的商业因素，可能几方面的因素都会有。这里面涉及到很多项目之外、技术之外的思考。

业界治理实践

我们看看业界的一些开放治理的经典例子。首先看全球最大的开源软件基金会 Apache，它下面有大概 200 多款开源软件，但是它的核心雇员其实很少，真正全职的雇员可能是个位数。但它有 700-800 名 member（会员），这些会员都是从一大批开源项目当中成长起来的开源界的老炮，这些人组成了基金会的基石。

这个基石里面呢，每年会有一次选举，选举九个人做 board，board 可能讨论一些顶层机制的问题。实际上，Apache 的项目治理完全是授权给每个项目自身的 PMC (Project Management Committee) 负责。这种充分的向下授权造成了整个组织的运作非常精简，所有关于项目的权利在 PMC 手里面，关于代码的决策权在 Committer 手里。这是 Apache 整体的基金会管理和开放治理架构。

在这种架构下，它其实是基于一个原则——Apache WAY 的开放治理。它的这种开放治理并没有说每个项目一定要怎么样，没有很细的规则，但是它要求你遵循一些原则，他们把这些原则总结成 Apache WAY。

Apache WAY 原则很重要，比如刚才说到的决策流程，它要求所有的决策透明公开，在社区的邮件组里面公开讨论，而且这些邮件组可以被搜索引擎搜索到，它有这个要求。它对社区也有很强的要求，就是说所有的人都以社区身份来参与，不要以背后组织的商业利益来参与社区，你只能以技术说话，只能以个人贡献者视角来讲，不要说太多企业背后的利益。

它还有一个重要的原则 Meritocracy，我们认为叫贤人治理或者叫精英治理，就是说它很认可每个人对于项目甚至基金会的贡献，你投入多少贡献以及贡献中反映多少能力，决定了你如何被授权。所以所有的开发者可以一步一步从外部的贡献者成为有代码合入权限的 Committer，再到项目管理者 PMC，再到整个 Apache 基金会的 member，它有一个很清晰明确的上升路线。你的贡献、你的能力以这种被提名的方式、被选举的方式来进行，这是 Apache 的开放治理。

另外一个基金会就是刚成立一年左右的开放原子开源基金会，我们也秉持着开放治理原则。

首先，我们的基金会管理跟项目治理是分开的。基金会有一套内部的管理制度，但是对于项目的治理是充分授权的，项目本身有自己的工作组或者 PMC。根据项目的特性（是大伞型的项目，还是相对颗粒度比较单一的项目），组建不同的治理结构。同样地，基金会的 TOC（技术监督委员会）是技术中立的，虽然来自不同的厂商，有的来自华为，有的来自阿里，来自腾讯，有的来自百度，但是大家在 TOC 的集体里面不以厂商背后的利益说话，我们所有的判断都来自于开源和技术中立的视角。

我们 TOC 主要负责两点：第一个，审核项目是否达到了孵化标准。第二个，当项目进入到孵化阶段，孵化一段时间之后，如果我们认可它的成熟度到了某一个状态，那我们就认为它可以毕业，成为可以大规模成熟推广的毕业后项目的状态。我们在 6 月 2 号正式发布了开放原子开源基金会关于项目孵化的白皮书，即项目毕业的标准，涉及代码文档、社区、代码分发，并对中立性、共识建立都有一些明确的要求，这里面至少有 4-5 个大的原则反映了开放治理的要求。

所以可以看到，不管是 Apache 基金会还是开放原子，我们都是把开放治理放在一个比较重要的位置上，因为我们认为这些基金会相对于厂商开源有一定的中立性，那中立性首先要保证的就是开放治理。

刚才说到开源项目的治理方式问题是一个选择题，实际上它有四种选择。

第一种是单一控制，可能是单独的一个人或者是某一个组织牢牢地控制住这个项目，这种方式没有外部的贡献者可以加入贡献代码。它的好处是对于组织和个人来说我可以跑得很快，在里面的控制能力很强，我只看中用户生态，并不太关注外部的贡献者如何加入这个社区。

第二种方式叫单一主导，就是说我的代码包括整个的管理，我是核心地牢牢地控制起来，没有开放出去，但是我可以接受外部的贡献，你可以无偿地给我贡献代码，我觉得有价值就合入，我觉得没有价值可能就不去合入。

第三种我们认为是开放治理的一种形态，叫社区主导形态。什么是社区主导呢？在社区里面，Committer、PMC 的权限是开放出来的，治理的权限是开放出来的，但是可能背后有一家或少数几家公司在社区有极大的影响力。比如 Spark 领域后面有一些公司，或者是 Google 的 k8s 社区，它可能还是有强大的影响力。

最后一个更高级的状态就是，不能说更高级啊，就是说更加开放的一种方式是完全的社区治理。一个大的项目可能有很多个公司去深度参与，类似于 Hadoop、OpenStack，可能没有一家厂商没有一家公司有完全的主导权，大家一起来影响这个项目，一起把项目往前推动。一般来说，这是社区比较成熟发展的阶段，在这样一个阶段里所有的上下游技术生态都已经完全成型，这样一种方式为多。

我们能够看到，社区的治理模式大概主要分为这四种。不同的社区治理模式，项目背后的社区的选择，它的目的、出发点可能也不一样，我们不应该说有好有坏，因为每一个项目都是独一无二的，每个项目的出发点，只要是开源，我们都认为这是欢迎的，这是一个勇敢者的游戏，都是好事情。因为开源相对于闭源软件开放性更好，不管是哪一种都是好的。但是这种项目治理方式背后的成本是什么？代价是什么？包括它取得的效果是什么？我觉得大家可能要很清楚。这样我们在真正做社区做项目的时候，才可以清晰地选择开放治理模式。

开源的未来

最后，谈一下开源的未来，关于开放治理的一些领域。

第一个，我们认为在长期的开源过程中，肯定不是只有一种模式，不是只有市集模式，也不是只有大教堂模式，这两种模式应该共存，甚至是你中有我，我中有你。即便是在大教堂模式里面大家还是可以看到社区的角色、技术人员的角色，根据你的专业度，根据你在这个项目中的投入不一样，大家也是有不同的授权，在一个集市中大家一起以这种教堂的模式来构建一个软件的宫殿或者生态的宫殿，这种情况也是有的。所以我们认为，如上所说的三种或者四种开源治理模式一定是共存的。

第二个就是我们看到一个趋势，最近开源跟云厂商之间出现一些不和谐的因素，这些不和谐的因素造成了有些开源项目、开源社区或者开源项目背后的厂商变更了许可证协议，我们认为这个矛盾肯定是存在的，这个矛盾更多的是云商业模式对开源的分发许可，包括分发发布或者开源的商业模式造成了一种影响。但是换句话说，如果这两者能够很好地结合，类似于 Databricks 这样的公司，开源社区做得很好，在商业化方面包括在云服务化方面做得也很好，对于这样的公司其实意味着更多的机会。所以我们认为开源和云的矛盾冲突不断地会出现，但是也不断地会消解。这种消解的方式有可能是开源会有更好的商业化路径或者方法，也有可能是我们后面会设计更好的 License，来更为清晰地保护开源贡献者有更多的权利。

刚才说到开源治理的模式此消彼长，仍然在探索当中曲折前进。包括开源社区的独特价值，刚才说到我们开发者社区，技术社区的连接，这些价值沉淀都会被认同，都会被不断地发掘。我们看到一些新的动向，比如近期看到开源跟行业进行了一些深度的连接，比如我们有些基金会针对某一个行业会有一个整合，因为开源最重要的是把社区、把人连接起来，同时在社区里面驱动这些人做事。如果行业需要一些更好的开源方案、更好的 solution，那么开源跟行业的结合会是一个很重要的方式或者路径。我们可以看到更多的开源的价值、社区的价值被发掘被发现，包括有更多的专业运营人员，因为传统上我们开源就是开发者自己出来做运营，但是现在我们看到越来越多专业运营团队参与进来，让我们的开源工作更加专业。包括我们的许可证，因为现在许可证已经很多了，很多许可证合在一起面临了兼容性问题，我们的法律合规这块的管理，甚至包括供应链的管理等等，都会更加地专业。

总体而言，我们认为以开源为代表的开放式生态相对于传统闭源模式更具优势，所以我们现在看到开源只要进入一个领域，基本上就会改造一个领域，让这个领域更加开源友好或者更加开放。在这些趋势的整体推动之下，我们可以认为开源项目、开源软件会走向越来越开放，也走向越来越多的开放治理，因为真正只有开放治理，才能达到大部分或者绝大部分场景下开源项目背后社区对于生态的诉求、对于开放的诉求。