内容起源：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，那么开源跟行业的联合会是一个很重要的形式或者门路。咱们能够看到更多的开源的价值、社区的价值被挖掘被发现，包含有更多的业余经营人员，因为传统上咱们开源就是开发者本人进去做经营，然而当初咱们看到越来越多业余经营团队参加进来，让咱们的开源工作更加业余。包含咱们的许可证，因为当初许可证曾经很多了，很多许可证合在一起面临了兼容性问题，咱们的法律合规这块的治理，甚至包含供应链的治理等等，都会更加地业余。
总体而言，咱们认为以开源为代表的开放式生态绝对于传统闭源模式更具劣势 ，所以咱们当初看到开源只有进入一个畛域，基本上就会革新一个畛域，让这个畛域更加开源敌对或者更加凋谢。在这些趋势的整体推动之下， 咱们能够认为开源我的项目、开源软件会走向越来越凋谢，也走向越来越多的凋谢治理，因为真正只有凋谢治理，能力达到大部分或者绝大部分场景下开源我的项目背地社区对于生态的诉求、对于凋谢的诉求。