开源共同体的治理模型
随着越来越多新的要素进入开源领域，如何建立一个高效的开源共同体，如何维护一个富有价值的开源共同体，逐渐成为每个参与者或多或少关注的问题。
Apache 软件基金会为每个项目提供了基础的治理原则，并在项目孵化到顶级项目的过程中通过孵化器导师的帮助建立起开源项目的治理模型，但是这一模型对每个具体项目在特定时期未必是最优的。同时，其他不在 Apache 软件基金会治理的项目，虽然拥有灵活设计治理模型的自由，却也时常陷入不知道该如何开始的窘境。
本文从开源治理的目的出发，介绍一个开源共同体什么时候需要考虑设计治理模型，然后讨论开源治理的原则，结合实例分析如何设计开源共同体的治理模型。这里所说的开源共同体，主要指的是围绕单一项目或单一主题项目群形成的开源共同体。
开源治理的目的
讨论开源治理的首要问题是，对于特定的开源共同体，当前阶段下是否需要治理。这个问题的解答可以从《社区运营的艺术》一书中对相同问题的讨论得到。书中认为，需要开源治理的主要原因包括
- 社区规模激增
- 冲突越来越多
- 资源多
- 商业利益
总的来看是两个问题。其之一是参与者和资源增加以后，维持开源共同体高效运转的挑战；其之二是不同背景的成员加入，不同要素进入之后，维护开源共同体的核心价值，也就是生产满足目标用户的高质量软件。
建立高效的开源共同体
开源共同体围绕开源软件而建立，其主要目的就是制造高质量软件，以满足目标用户的需要。这意味着生产代码、撰写文档、解答问题和市场营销都是开源共同体工作内涵的一部分。
项目启动阶段，尤其是功能尚未丰富的时候，交付核心功能是第一要务。这个阶段，往往项目参与者不过几个人甚至就是一个人的工作，也不会有太多的关注者和用户。这个阶段是不需要引入复杂的治理模型的，简单的项目创始人掌握所有权力并决策所有事务即可。没有核心开源软件创造价值而沉迷于设计治理模型，只不过是空中楼阁。唯一跟治理模型沾得上边的，就是留心并记录这个阶段当中软件开发的流程和决策惯例及案例。
随着项目核心功能的实现和迭代，产生的价值能够吸引到目标用户使用，更多的参与者被项目吸引或用户需求所推动着了解项目。同时，开源项目的成长也带来了对资源的需求，例如持续集成的基础设施，沟通渠道的维护，直接支持项目开发的资金捐赠的处理，围绕开源软件的活动和宣传的运营和开销，等等。新成员的加入带来沟通成本的提高，丰富的资源需要一定的流程和负责人维护才能合理得到使用。这个时候，设计一个治理模型以维持开发效率和决策效率，就是有必要的了。
治理模型通常体现为一个或几个治理机构及其职责和沟通方式。在维持高效的开源共同体的话题上，这些治理机构主要解决以下问题。
- 批准或拒绝新成员加入。特别地，你可能为成员定义不同的身份，例如一般成员、开发者或其他贡献者，等等。
- 解决冲突。
- 明确项目价值，落实开源共同体的核心价值观。
- 修改流程。
- 如果开源共同体日渐复杂化，治理机构可能需要派生出新的治理机构。
- 决定方向。
维护开源共同体的核心价值
如同前文所述，开源运动热火朝天引得越来越多新的要素进入这个领域，政治要素和资本要素就是其中不可忽视的两个。许多开源共同体都有商业赞助商和投资者。这些赞助商的员工当中往往有不少是开源共同体的参与者，通过参与做出对赞助商有利的贡献。有时候开源共同体只有一个赞助商，它可能就是一开始创立项目的企业。这种情况下，赞助商和投资者会主动寻求建立某种治理模型，以明确自己为开源共同体做出的投资所能得到的回报的预期。
例如，《社区运营的艺术》提到，Linux 发行版 Fedora 和 OpenSuSE 对应的赞助商 RedHat 和 Novell 在各自的开源共同体当中都通过制度保证了足够多的席位以推行任何他们想要推行的主张，而 Ubuntu 对应的赞助商 Canonical 仅在所有七名成员中保留一个席位且其他成员多数不是为该公司工作的。国内首个开源基金会开放原子开源基金会，其技术指导委员会的席位为主要捐赠人每家预留一位。TiDB 设计的技术委员会成员，必须是 PingCAP 员工、PingCAP 社区伙伴员工或社区项目代表。
反之，Apache 软件基金会则强调 Community of Peers 即共同体由个人组成，而非组织。Kubernetes 虽然会展示成员的组织关系，但是治理模型当中也不体现赞助商或投资者的特权。
《社区运营的艺术》提到，一般的志愿者社区，比如开源项目，赞助和投资方应该不参与治理机构。
我这样说并不是因为商业赞助是不可信的，而是因为与志愿者关联的社区往往是建立在所有成员的贡献之上的，而这些成员积极贡献的目的，就是保证他们的辛勤工作有助于同侪和社区的未来。
《People Powered》当中进一步解释了这个论点。
你的社区受到两个因素的驱动，一个是成员自身的利益，另一个支持社区获得更大的成功。除组织内部社区等极少数外，你的社区成员为社区工作，而不是为你工作。这常常使那些坚持“如果公司成功，社区也将从中受益”的公司受挫。这句话没错，但不重要。这不是大多数社区成员的想法，也不是社会经济运作的方式。
为了应对赞助和投资方的提案，协调开源共同体当中各方的需求以达到共同体利益最大化，避免分化，需要设计一个相应的治理模型。
开源治理的原则
不同开源软件的特点，开源共同体的成员组成和所处阶段的差异，都会影响治理模型的设计。我在 夜天之书 #18 Evolving Governance 和 夜天之书 #25 Evolving TiDB Governance 里已经讨论了特定开源共同体的治理模型设计权衡。
本文尝试从开源治理的原则出发，讨论根本的设计思路。开源治理的原则总的来说是以下两条。
- 开源共同体利益至上
- 摈除丑陋的形式主义
责任感
要想落实“开源共同体利益至上”的原则，必须保证治理机构的成员对开源共同体有一种真正切身的责任感。
与其说开源治理是制定一系列规则并任其自动运行，不如说是找到具备领导能力且愿意为共同体发展承担责任的优秀人才。开源共同体当中常见的角色 Committer 抛开其提交代码的权限，词源本意即“做出承诺的人”。
开源软件由志愿者开发，在志愿者环境中是无法强制一个人参与的。有些志愿者能够每天都投入到共同体工作中，而其他志愿者仅在情绪不错时参与工作。后者的贡献值得感谢，但是他们通常不能承担治理责任，也不具备领导能力。对于围绕开源共同体做出的重大决策以及合并补丁和发布版本等核心活动，掌握权限的核心成员必须维护开源共同体利益，必须显示出强烈的责任感和使命感。换句话说，核心成员要对自己的行为负责，当开源共同体为了完成某些任务而全力以赴时，核心成员必须腾出时间来为之工作。
《社区治理的艺术》提到，责任感是宝贵财富，它相当于你在社区得到的承诺宣言。一些成员会有这样的责任感，而另一些则没有。有责任感的人是宝贵的资源，你可以委以重任，但是不可以利用他们的责任感。
例如，我在多次和 Apache Flink 的 PMC Chair Stephan Ewen 沟通的过程中，都能感受到他对项目的热忱。这种热忱支持着他十多年来投入到项目的开发、发布和宣传当中。即使自己所创办的基于 Apache Flink 提供服务的公司已经被收购从而财富自由，即使面对诸多邀约有不少早期成员开始投入新的项目，他却始终坚持发展 Apache Flink 以满足用户的需求。例如，Linus 在 2022 年伊始就在合并提交到 Linux 项目的补丁。例如，Apache SkyWalking 的创始人吴晟和 ClickHouse 的创始人 Alexey Milovidov 都以快速处理开源项目当中的评论、议题和补丁著名。
项目的创始人通常是对项目抱有最高责任感的人。因此，在设计治理模型的时候，直接把创始人排除在外是不可接受的。《大教堂与集市》当中讨论“Locke 及土地所有权”的时候也提到过这个模型。然而，不少形式化开源的项目，指派了一个或几个所谓的“社区运营专员”来架设治理模型，往往就把创始人反而排除在外。这是彻底的形式主义，也是错误分工带来的恶果。
Zoom.Quiet 对此有过评论，
这其实才是最大的天劫。项目开始时，大家的目标是不言而明的，因为是小团队多年的相同愿望。但是，有新人进来时，才发现没有之前多年的共事根本无法简单说清。所以，有所谓专家或布道师来接替创始团队来解释时，核心成员如果不认同，嘴又笨，直接表现就是不活跃了。看起来，是更加专业的专家替代了土领导，可其实，社区已经空心化了。毕竟不是谁都有 Linus 的嘴炮能力。
不得不感慨，Linux 能成功，Linus 功不可没。《时代周刊》做过一个有些极端的评论，但不无道理。
有些人生来就注定能领导几百万人，有些人生来就注定能写出翻天覆地的软件。但是只有一个人两样都能做到，这就是林纳斯。
创始人的缺位会给开源治理留下很深的阴影。例如，Rust 项目的创始人 Graydon Hoare 并没有坚持做 Rust 项目，核心成员 Brian Anderson 和 Niko Matsakis 还有 Alex Crichton 等等都不在最高治理机构 Core Team 里。同时，Core Team 的人员更替并不谨慎，导致部分成员难以服众。这是前不久 Moderation Team 和 Core Team 矛盾的深层原因之一。
核心成员的传承也要基于责任感。例如 Apache 软件基金会现任董事会成员 Justin Mclean 和吴晟，都非常关注孵化器当中新项目的加入和成长，关注 ASF 项目面临的法务挑战，关注 Apache License 的采用情况，等等。例如 2020 年新加入 PostgreSQL 的 Core Team 的成员都是经年参与 PostgreSQL 共同体的志愿者。
可以说，只有核心成员对开源共同体有切身的责任感，才能践行“开源共同体利益至上”的原则，其他成员也才能信任这样的治理机构能够领导和鼓励共同体向前发展。
精英领导制
这里提到的精英领导制是一种组织管理体系，成员在共同体当中受到的尊敬和能够承担的职责，取决于他所做的贡献，而不是金钱、社会阶层和家庭关系。换句话说，就是“唯才是举”的理念。
要想落实“开源共同体利益至上”的原则，强调精英领导制是有益的。当然，对于这个词感到陌生的人，可以多谈论一些平等性，多提供一些成员如何通过自身的努力，去建立声望的例子。
精英领导制强调了对开源共同体的贡献是赢得权威的唯一方式。这种贡献的衡量与个人所绑定，与其所属的组织无关。避开资本要素的影响，使得开源共同体能够最大限度的接纳新的参与者，并通过对参与者贡献的衡量和他们与其他核心成员共同工作的方式来选拔新的核心成员。
不同于彻底的独裁治理模型，精英领导制实际上暗示着项目由多人共同治理，而加入治理机构的核心成员必须通过其贡献和工作方式赢得其他核心成员的认同。这种方式在 Linux 项目当中也被部分采用。虽然 Linus 仍然是名义上的独裁者，但是 Linux 的维护者列表早就突破了一千人。当然，他们并不享有和 Linus 一样的权利，但是他们获得对应职责的基础，也是对相应模块的贡献。
这样，我们就确定了项目所有权的分配方式，即完全通过贡献来衡量。衡量者是现有的核心成员。建立项目自然是最大的贡献之一，持续参与，软件重大改进，催化参与热情与质量，完善文档，代表共同体或项目发声，都是值得考虑的因素。
例如，PostgreSQL Core Team 现在和过去的成员做出的贡献在其 Contributor 页面上展示。
| 核心成员 | 主要贡献 |
|---|---|
| Peter Eisentraut | 构建系统，软件移植，文档及其国际化，持续的代码贡献。 |
| Andres Freund | JIT 机制，逻辑解码，数据复制，性能和可扩展性，修复 bug 和 review 补丁。 |
| Magnus Hagander | 完成向 Win32 系统的移植，鉴权机制，维护项目网站和基础设施。 |
| Jonathan Katz | 项目推广，版本发布新闻稿，维护网站，作为其他 PG 相关委员会成员的贡献。 |
| Tom Lane | 所有方面。其中包括评估缺陷和修复，性能改进，新功能落地。同时是优化器模块的责任人。 |
| Bruce Momjian | 维护项目 TODO 列表，处理补丁，代表项目在会议上发言。 |
| Dave Page | pgAdmin 的作者，维护项目网站和基础设施，以及安装包。 |
| Josh Berkus | 项目推广，用户群组推广，性能测试，调优和文档撰写。 |
| Marc G. Fournier | 协调员，管理项目网站，邮件列表，文件服务器和代码仓库，等等。 |
| Thomas G. Lockhart | 文档撰写，实现数据类型尤其是时间类型和几何类型，SQL 标准适配。 |
| Vadim B. Mikheev | 重大功能实现，包括 WAL 和 MVCC 等功能。 |
| Jan Wieck | 数据复制系统 Slony 的作者，实现了一系列重大功能。 |
可以看到，代码贡献是主轴，但也包括了维持项目运转和扩张的其他多层面的贡献。
精英领导制还有另一层含义，就是任何人都可以参与到技术讨论，技术实现和共同体决策当中来。虽然核心成员承担决策的职责，但是他们并不形成寡头政治。也就是说，核心成员的身份及其承担的职责是一种权力，而非特殊的权利。在一个健康的开源共同体当中，任何成员都可以做技术讨论，提交补丁，也可以就共同体发展话题提出自己的观点。技术最优的方案应当获胜，共同体利益最大化的决策应当通过。
精英领导制也并非是完美的。《精英的傲慢》一书当中提到，无论怎样强调“唯才是举”，精英的成功与天赋和运气等因素都是有关的。过分强调精英领导制，会助长赢得权威的人认为一切都是自己所应得的，对于没有赢得权威的人，则会感到屈辱和被排除在外。
《精英的傲慢》主要讨论的是社会问题，但是对于开源共同体这样一个特殊的群体，也是有启示的。我们前面强调了权力而非权利，即从根本上结构了共同体当中赢家与输家的关系。不过，不同身份的存在仍然有潜在的冲突风险，因此在选拔核心成员的时候，也要注重他对于权威的认知和个人的品质。
例如，《大教堂与集市》一书当中提到了谦逊的价值。
谈吐柔和也是有用的，如果某人希望成为一个成功项目的维护者，他必须让社区信服他良好的判断力，因为维护者的主要工作是判断他人的代码。谁愿意将代码贡献给一个明显不能正确判断自己代码质量的人？或者一个试图从项目中沽名钓誉的人？潜在的贡献者希望项目领导人在客观采用他人代码时，能够谦逊而有风度地说：“是的，这个的确比我的代码好，就用这个了。”然后将荣誉给予应得之人。
最后，由精英领导制建立起来的治理机构应当能够自省，以永远保持质量，代表开源共同体的前进方向。这不意味着要对每个成员限制任期，如果有人能把开源共同体治理得很好，应该允许他们一直干下去。但是，根据核心成员参与共同体各项活动的程度，工作情况的综合评价来判断是否应该取消某位成员的资格。
例如，PostgreSQL 共同体将在每年的 pgCon 峰会上发布新一年的 Committer 名单，不再活跃的成员将被移出。
坦诚沟通
开源共同体要想高效运转，坦诚的沟通是必不可少的。
例如，前文提到的取消核心成员资格这样的决策，如果没有事前沟通，不仅当事人基本不可接受，而且其他成员将笼罩在无形监视的阴影下。例如，前文提到的 Rust 共同体 Moderation Team 和 Core Team 的冲突，没有任何关于细节内容的披露，每个人都在说那里有一些问题，是什么问题不方便说，谁牵扯其中不方便说，后续要如何处理不方便说。这样的表现只会让人对这两个治理机构都丧失信心，无法信任他们做出的决定是公平的。
坦诚沟通依赖相应的渠道。Apache 软件基金会要求所有讨论都发生在邮件列表上，因而是公开可追溯的。我在设计 Engula 共同体的沟通渠道时，根据项目的特点，把 Single Source of Truth 设置成 GitHub 平台，包括 issue 和 pull request 以及 discussion 论坛。所有其他渠道沟通的结果，都必须回到唯一的渠道上再次确认。通过这样的设计，能够支持全球性开源共同体的异步协作，并且保证所有信息都是公开的，也就消除了关于决策缘由的顾虑。
实行坦诚沟通的好处不必多说，绝大部分人都希望得到真实的信息，收获真实的反馈。真实的信息帮助共同体成员为最大化共同体利益努力，真实的反馈帮助共同体成员正确地行事。不过在设计治理模型的时候，关于沟通有两个点需要强调。
第一个是坦诚不代表攻击性。《不拘一格》一书中强调坦诚沟通的重要性，但也提示组织管理者需要警惕“有才华的混蛋”。
如果周围全是聪明人，你可能就有危险了。有时候，有才华的人听到的赞美之词太多，就会觉得自己真的比其他人更优秀。如果有他们认为不明智的想法，他们可能会报以嘲笑；如果有人发言不够清晰，他们可能会翻白眼；他们还会侮辱那些他们认为天赋不如自己的人。换句话说，这些人就是浑蛋。
如果你在团队中倡导坦诚的文化氛围，就必须把这样的人剔除出去。许多人可能会认为“这个人确实很聪明，没有他不行”，但是，不管这样的人有多么出色，如果让他留在团队里，你营造坦诚氛围所付出的努力就不会有太好的效果。浑蛋对整个团队的效率有很大的影响，他们可能会将你的组织从内部撕裂。因为他们老是喜欢中伤同事，然后丢下一句：“我这是坦诚。”
对于开源共同体而言，这就意味着需要切实践行行为准则（Code of Conduct），对这类攻击性行为说“不”。
额外多说一句，不少共同体从 GitHub 或者推崇的其他项目当中拷贝了行为准则，但是核心成员可能都不知道行为准则当中写了什么。这是不可接受的。我在撰写 Engula 共同体的参与者文档的时候强调了行为准则的重要性，并认为如果一个人想要成为核心成员，必须了解和实践行为准则。否则任何的文档不过是一纸空文。
第二个是必要的隐私渠道，包括安全问题报告、违反行为准则报告以及选拔成员讨论等等。安全问题不必多说。后面两者涉及到对人的评判，在得到合适的结论之前不应该全部披露。
这是因为，根据精英领导制的精神，唯才是举的评判应该来自于现有的核心成员团队，而不是民粹主义式的公投。一个开源项目会发展成什么样子，取决于核心成员是什么样的。他们是最有话语权的一群人，应该对项目抱有切身的责任感。如果核心成员团队被腐化了，或者他们本来就抱持着其他目的，那么这个项目就完蛋了。核心成员承担项目所有权，为项目的发展负责。如果其他成员认为核心成员违背了开源共同体的核心利益，标准做法是发起分支。
不过，决议的内容应该公示并向共同体成员解释原因。这就意味着秘密推举新的核心成员是不可接受的，同样，以莫须有的罪名惩罚共同体成员也是不可接受的。
适应性
适应性体现的是“摈除丑陋的形式主义”的原则。也就是说，治理模型的设计应该倾向于适应开源共同体的发展，而不是做空中楼阁的设计。
大多数开源共同体需要应对三类问题，即综合治理，确定方向以及专业化治理。综合治理指的是围绕共同体的综合性话题做出决策，例如如何加入共同体，资源和基础设施的维护，工作流程，治理的改变等等。确定方向指的是围绕共同体的目标、愿景和当前焦点做出决策，例如开发软件所要解决的问题，目标用户，以及当前所要关注的特性集等等。专业化治理适用于开源共同体成长到一定规模以后，针对特定的专业知识领域需要专业的治理。例如，用户文档体积膨胀，而恰好有技术写作人才的参与。例如，Rust 的 Reddit 频道有自己的组织体系。例如，针对代码补丁的评审和缺陷的评估解决，也是专业化治理的一类。
对于一个刚起步的开源共同体来说，所有方向上的问题只需要一个治理机构来处理就够了。因为此时并没有太多的事情要处理，同时你也没有太多的成员能够参与到治理当中来。
不少设计开源共同体治理模型的人，盲目参考 Apache 软件基金会，或者 Kubernetes 等项目的玩法，货物崇拜式的对其治理模型进行像素级拷贝，最终发现并不适合自己项目的情况，而饱尝苦果。这其中最典型的就是引入多余的设计。预设具体的参与路径或治理细则，往往会导致无端的“运营成本”。随着项目的演进，参与情景的改变，预设前提不再生效，需要频繁修改，而并没有人实际践行。也就是说，所有设计和修改的付出都白费了。
《社区运营的艺术》提到，在理想的世界里我们不需要把治理放在首位，更不用说设置附加的分委会。每增加一层治理，你的社区就会丧失一些让大家易于理解的简单灵活性。只有在绝对必要时，你的社区才应设置附加的治理。
只有当现有的治理机构不能扩展或满足社区需求时，附加的治理才是必须的。然而，有些社区不太明白这个道理，决意设计空洞的委员会：无非就是使新委员会的成员感到很特别。
…他们希望有一个治理委员会。在他们眼中，治理委员会能带来各种有趣的东西：对项目的控制感、权利和权力。不仅如此，他们认为一个社区之为社区，真正的社区委员会是必不可少的。
胡说。
此类委员会的成立根本没有理由。社区委员会的存在是为了解决问题，但是如果整个社区相对比较小，就没那么多问题需要解决。创建这个委员会，你实际上增加了官僚主义的风险。
一个典型的例子就是单一项目阶段切分出许多模块团队，并为之建立起复杂的治理层级。我在此前讨论 TiDB 和 TiKV 的治理经验和教训的时候已经提到过，这种方式不过是割裂开源共同体而已。这种分割主要的缺点是很难切得恰到好处，出现问题讨论和修复带来的治理开销太大。如果不修订，实际情况一般是团队成员权限不足，核心团队不停兜底。
例如，早期 TiDB 将代码分成 DDL 和 Planner 还有 Execution 三个部分，那么数据库权限的问题谁来处理呢？一般性的并发实用函数，数据格式等等问题，谁来解呢？后来又把 DDL 团队泛化成 SQL Infra 团队以期兜底，但是实际上他们还是只处理部分问题。例如，TiDB 的 telemetry 模块目前就是无人负责的。
实际上，代码的关联是普遍存在的。哪怕是 Apache Flink 这样可以区分成 Runtime 和 DataStream API 以及 Flink SQL 的项目，也不需要单独区分出若干个团队来分散治理。Apache Hadoop 200 多名 Committer 完全依靠工作流程和负责任的态度，以相同的权力推进代码的演进。PostgreSQL 的 28 名 Committer 也没有再细分。
区分团队的项目，往往与不同的资源和关注点关联。例如，Apache 软件基金会下的每个项目都有自己的项目管理委员会，这其实就是某种意义上的团队区分，但是没人会觉得这增加了形式主义，因为不同的项目之前确实是不同的。
例如，Rust 共同体区分了若干个团队。虽然我对其中的 Release Team 保持怀疑，因为 PostgreSQL 可以很简单地由核心成员担任，ASF 项目通常也由志愿者根据发布手册担任特定版本的发布负责人，但是其他的团队区分是很清晰的。例如对于一门语言，编译器和标准库分开是没有问题的。中央资源库有独立的维护人员也是合理的，他们完全不需要关心编译器和标准库的问题。不过，我相信在真正出现这些团队独立的志愿者之前，也不需要分化出特定的团队。换句话说，因人设岗在开源共同体当中非常常见。同时，一个志愿者负责多项工作也是正常的，比如 Nick Cameron 就同时是编译器团队和开发工具团队的成员。
不要在没有人的时候首先架设出复杂的治理机构，因为没有人实际担任这些角色，空洞的治理体系是可笑的。同样，复杂的治理机构无法拯救空心化的开源共同体。比如，TiDB 有 60 余名 Committer 或 Maintainer 成员，但是真正处理 community 事务的人是不足的。前面提到的 Execution 团队的活跃成员全是 PingCAP 公司同一部门的员工，经过公司组织调整后工作重点改变，也就导致对应模块的治理立即缺失。空心化的开源共同体无法响应参与者，因为实质的有价值的回应来自于人与人的沟通，而非机械化的流程。
出于关注点不同的团队划分，还有一个值得考虑的问题是应当采用虚拟组织或者实际组织。Kubernetes 设计的 SIG 和 WG 就区分了这一点。SIG 作为实际与权限相关的团队，前面已经讨论过了。我在分析 TiDB 的治理模型的时候讨论过 WG 模型在 Kubernetes 共同体当中的采用情况。
Kubernetes 社区的影响力和专注于社区运营的人数保证你的 WG 有人关注，有人推送，有人宣传，再不济任务结束或者生命终结可以回收。另外，Kubernetes 的 WG 都是非常 General 的，例如可靠性工作组，命名工作组，策略工作组，等等。TiDB 和 TiKV 对 WG 的理解基本停留在功能特性小组的层面。这种需求通过项目内的功能设计提案和 tracking issue 等形式发起和追踪即可。
Rust 共同体当中也有同样的设计，例如最近 Nick Cameron 大力推进的异步编程工作组，这一工作需要协同编译器和标准库以及三方库等多方努力才能在 Rust 生态当中提供一个统一且高效的异步编程抽象和灵活适应不同负载的多种实现。
Engula 共同体考虑未来发展的时候，讨论了区分不同团队的思路。我在主题下回复的建议就是针对不同的模块关注点，可以尝试组织起不与权限挂钩的兴趣小组，针对特定的主题，可以组织起工作组。对于权限本身的区分，由于共同体规模并不大，适当扩充核心成员即 Maintainer 的人数达到复数即可。否则，在接口不稳定的情况下，跨越当下设定的模块的变更非常可能发生。另外，对于讨论中区分出来的日志、存储和计算引擎三个模块之外，部署逻辑、异步实用工具等等实际存在的功能又该归属到哪个团队呢？还是前面提到的，“切分主要的缺点是很难切得恰到好处，出现问题讨论和修复带来的治理开销太大。如果不修订，实际情况一般是团队成员权限不足，核心团队不停兜底”。
那么，什么时候应该考虑扩大治理机构的规模呢？这里提供几个方向性指标。
第一个是遇到瓶颈。
如果开源共同体当中的事务变多或变复杂，导致当前的核心成员团队无法处理，那么就有可能要考虑扩大治理机构规模。例如，Linux 的 1000 多名拥有部分提交权限的维护者，为 Linus 分担了大量与具体驱动或架构相关的模块的补丁审查。例如，C++ 委员会面临方向统合上的问题，于是成立方向委员会来应对。
不过，并非遇到的所有瓶颈都需要通过扩大治理机构来解决。比如，流程事务繁多可能是流程文档不足或者流程本身有形式主义的问题，通过改进流程或取消流程即可解决瓶颈。另外，PostgreSQL 绝大部分工作是由 7 名 Core Team 成员和 28 名 Committer 处理的，如果你的核心成员有同样的能力，那么可能也不需要刻意扩大规模。
我在参与 Engula 共同体的过程中也不断重复这一观点，即“如无必要，勿增实体”。如果当前项目创始人足以处理所有事务，那么就不需要形式主义地扩充成员，更不需要设计复杂的治理机构。大多数人认为治理既不酷也不有趣。我们的目的是，在保持想要达到的质量和客观性的同时，将治理的基础设施和文件的数量保持尽可能少。
第二个是关注点分离。
如果一个无关权限的兴趣小组或者工作组最终围绕特定领域形成了一个大的子共同体，这个子共同体可能需要一些特定的知识，而这些知识是核心成员所不知道的。这个时候，就可能需要把独立出这部分决策权。例如，Rust Team 有 Community 团队，Kubernetes 有 Community 团队，甚至你把整个 Linux 共同体视作一个整体，Linux Foundation 也是一个独立的团队。
关注点分离强调的是事后追认，也就是真的有分离的需求的时候，追认事实，而不是事先设计出空中楼阁式的团队，期待有人自告奋勇加入。这样做，最可能的结果是吸引到沽名钓誉的人工于心计地获得头衔。
另外，关注点分离也强调权限的独立。除非明确需要层级结构，例如 PostgreSQL 的 Core Team 对整个开源软件负责，因此它需要决策 Committer 团队的人员组成，否则你并不需要把所有的子共同体组织成一个层级结构，网络结构也是可行的。例如，Linux Foundation 实际上与 Linus 控制的开源软件共同体并没有层级关系。例如，StreamNative 公司建立的 Apache Pulsar 中文社区也不需要对 Apache Pulsar 的 PMC 负责。这种独立往往发生在分地区和语言成立的本地用户组上，或者围绕同一开源软件但是面向不同目标的群体之间。
总的来说，所有这些情况都超出了现有治理机构在时间、知识或技能方面的管理能力。事务的多少是判断是否扩大治理机构的正当理由。如果你只有少数几个特定领域的清楚，当前的核心成员努力一下就能处理完，那就不应该成立一个独立挂钩权限的团队。但是如果核心团队定期且重复地抽到一些请求，那么就有必要考虑成立新团队应对瓶颈了。当然，这不是唯一的解法。