再谈 Rust 项目社群治理
上一篇文章《Rust 社群何以走到今天？》发布之后，得益于 Rust 社群的繁荣和成员的分享惯例，我收到了不少关于 Rust 现状的评论。
大部分评论集中在 Rust 项目社群的治理上，即 BDFL 和基金会会对 Rust 项目社群产生什么影响，以及 Rust 项目社群是否需要 Leadership 组织。
我在上一篇文章中引用了 Graydon Hoare 和 @withoutboats 等人的博文，展示了“遗老”们对 Rust 项目社群目前的一些看法，这不免让人理解成赞同他们的观点，希望 Rust 社群出现一个强有力的领导人，甚至希望 Rust 语言像 Graydon 设计的那样演进。
其实，上一篇文章主要想说明的只有两个观点：
- Rust 项目社群治理的核心特点是没有一个人（BDFL）或一个一致行动的团体（Apache Group）说了算。
- Rust 项目社群未来的发展会极大受到各大公司组成的基金会的影响。
我并不认为有 BDFL 就一定是好事或是必须，至少我所在的每个 Apache 项目社群中都不存在 BDFL 角色，它们也发展得很好。
而且，以 Rust 项目社群如今的状况而言，几乎不可能出现一个新的 BDFL 或者 Graydon “复辟”的情况。因为拥有《大教堂与集市》中提到的，由“开垦”新项目带来的自然所有权的人，绝大多数已经长期淡出 Rust 项目社群，其他少数几个人也无意于社群管理。对于新人来说，由于没有明确地所有权转让程序，想要赢得 BDFL 的地位，就需要依靠自己的贡献。而以 Rust 项目社群目前的领域范畴来说，这对个人几乎是一个不可能完成的任务。所以，Rust 没有 BDFL 将会是一个长期的现状。
进一步地，作为 Rust 项目最初的赞助者，Mozilla 甚至不在 Rust 基金会的白金或黄金赞助商名单上。这就意味着在公司影响力上，哪怕是 Rust 基金会的创始会员也没有天生的主导权。
从机制上来说，Rust 基金会目前并不参与 Rust 项目的开发，基金会的目的是提供 Rust 项目存续的资金支持，以及相应的人才培养和品牌宣传。
上一篇文章中提到的 Leadership Council 并不隶属于基金会，而是 Rust 项目社群的一个治理机构，其成员由各个 Rust 项目顶级团队组成，基本职责是协调跨团队合作以及针对 Rust 项目社群治理本身的一些问题。
在这之前，Rust 项目社群在基金会和 Leadership Council 的领域内发生过几起争议事件：
- Ashley Williams 曾经是 Rust Core Team 的成员，同时是 Rust 基金会筹建时的执行董事，但是后来前后从这两个组织中出局。
- Rust Moderation Team 因为跟 Core Team 的冲突，以集体辞职表达不满。如今，Core Team 本身被解散，而 Moderation Team 则由两位深度参与 Rust 核心开发的成员支撑。
Rust 社群的这些故事，除去缺少 Linus 这样的 BDFL 维持项目本身的有序运转之外，跟 Rust 社群总是期待一个两全的解法，以及过度期望所谓“专业人士”来解决问题的惯例是有关系的。
前者在 @withoutboats 的博文中有所提及：
我担心 Rust 项目从这个经验中得出了错误的教训。正如 Graydon 在这篇文章中提到的，Rust 开发团队坚持只要有足够的构思和头脑风暴，就能找到每个争议的双赢解决方案，而不是接受有时必须做出艰难决策的事实。Rust 开发团队提出的解决这种无休止的争议所带来的 burn out 的方式，是转向内部讨论。设计决策现在主要以 Zulip 线程和 HackMD 文档等未索引的格式进行记录。在公开表达设计方面，主要是在相关开发者的个人博客上发布。如果你是一个开发团队以外的人，那么你几乎不可能理解 Rust 开发团队认为什么是优先事项，以及这些事项的当前状态如何。
而后者则是一种社会高度分工以后常见的认识误区：其他人比我更专业，只要相信他们就好了；有其他人承担这项分工，我只要给予信任或者进一步给予金钱等利益，就可以完全把这些工作委托出去。
实际上，其他人未必有身临其境的人了解事情的原委沿革，不一定站在项目的立场考虑问题，甚至未必专业。对项目负责的人只能是深度参与的核心成员自己，这也是 Leadership Council 在成立动机中所提到的：
根据核心团队（Core Team）的经验，发现问题和开展实际工作本身，对于一个团队来说都太过繁重。这导致了不理想的结果，在某些情况下，还导致了倦怠。虽然有少量工作需要立即采取紧急行动，但绝大多数工作都需要由专门的管理机构进行跟踪和处理。
此前的 Core Team 和 Moderation Team 不仅相互之间缺乏沟通，甚至本身成员也相对独立于其他顶级团队，这导致本应作为协同社群反馈和各个顶级团队之间合作的两个独立团队，跟其他顶级团队之间也可能缺乏互信基础和合作机制。新的 Leadership Council 成立并以九个顶级团队代表为成员，期望在维持先前 Core Team 所要解决的问题的基础上，提高团队之间的协同效率。
对于基金会，可以明显的看到在机制上它相当于 Linux Foundation 之于 Linux 或是 Python Foundation 之于 Python 的形式，前两者在运行过程中间并未出现如同 Rust 社群这样的戏剧性发展。其原因部分在于它们有一锤定音的 BDFL 主导技术开发和项目团队合作，另一方面也是在这样长期的运作方式下，项目团队成员发展出一套自己解决问题的办法，而不是被不满意的现状困扰，转而祈求外部力量奇迹般的解决问题。
Rust Foundation 的性质是 501(c)6 行业联盟，这跟 Linux Foundation 是一致的，它们存在的目的除了写下来的维持 Rust 的存续发展，从性质上说是要为商业联盟中的成员企业服务的。相反，Python Foundation 和 Perl Foundation 的性质是与 Apache Software Foundation 相同的 501(c)3 慈善组织，纯粹是为项目本身的发展和公众利益服务。与此相匹配地，就是慈善机构型基金会往往在募集资金上不如商业联盟型基金会。
如前所述，由于 Mozilla 无法或不愿入局，如今 Rust Foundation 的四个创始会员分别是 AWS、谷歌、华为和微软。它们并没有像 Oracle 在 JCP 执行委员会中那样继承自 Sum 并再次发展得到的垄断权，甚至 Rust Foundation 本身也没有 JCP 那样直接指导语言项目技术发展方向的权限。但是，既然 Core Team 可以改组，Rust 社群整体对于基金会干涉项目发展存有期望，那么在未来社群治理的发展或者至少每次讨论当中，基金会就有可能发挥出自己的影响力。
当然，现在的主要问题恐怕不是担心基金会如何“窃取” Rust 项目的领导权，而是期望基金会的创始会员和其他赞助商先加大投入，哪怕就是奔着主导权来的，至少先把 Rust 的产业应用和语言发展，投入资源搞起来。但这是另一个话题了。
在基金会之外的另一个角度，也有人在呼唤唯一有可能成为 BDFL 的 Graydon 加入战局“拯救” Rust 项目社群。如前所述，由于 Graydon 本人已经淡出 Rust 社群很久，这实际上是几乎不可能的。
Graydon 本人对此的认识倒是比较清晰，他先后写下两篇博文对此做出回应：
其中第二篇已经在我的上一篇文章里展开介绍过，下面我会翻译第一篇。
译文之前说一点题外话。
Graydon 在第二篇博文里提出的对 Rust 的期待，在我上一篇文章发布后收到了推特上网友的讽刺。从 Graydon 本人列举出来的设计方向看，除了错误处理他更喜欢 Swift 的做法，其他的诸如绿色线程、语言级别集成的容器和迭代器、结构化类型等等，确实都是 Golang 的招牌特性。可以说，Graydon “在位”的话，Rust 恐怕就会发展成弱化的 Golang 而不是今天的 Rust 了。
另外，虽然试图“拥立” Graydon 重回 Rust 项目社群的呼声是不理智的，但是这些呼声的存在，侧面印证了前文提到的 Rust 项目社群总是期待两全解法，并总是寄希望于未知的专业人士神奇的解决问题的惯例。
Rust 项目如何走出当前的境况，我参与得不多无法给出意见。不过，我倒是乐意从开源社群发展的研究角度，来分析 Graydon 这样在卸任之后还持续思考和发生的例子：这确实是不可多得的考察对象。
在不能持续维护项目的作者里，Graydon 的案例非常有参考性。他思考了很多，也分享了很多。但是他没有“成功”。这比那些被“成功”掩盖了问题的例子，还有简单一句 burn out 解释所有问题的例子要有意思的多。
以下 Batten Down Fix Later 译文，“我”指的是 Graydon Hoare 本人。
在社交网站上，有人问我：“你是否希望自己是 Rust 项目的 BDFL？如果 Rust 项目有一个 BDFL，现在这些戏剧性事件会不会少一些？”
这是一个很难回答的问题。如果只看它表面的提问，我的答案是“不希望”和“不会”。但我认为它还间接地问了另一个问题，即 Rust 项目社群治理中是否存在某种原罪，或是致命缺陷，例如缺少 BDFL 的角色，而这正是其频繁发生内部政治问题的罪魁祸首？
关于这个问题，我可以分享一些我的观点，希望能简明扼要，或者至少具体一点。我认为有几个根本原因和一个主要的模式。
主要模式
我已经有十年没有参与这个项目了，所以我认为我说的任何话都需要谨慎对待。但我确实时不时地关注 Rust 项目的进展：这些年来，有不少人离开了这个项目，而且其中许多人的离开是不愉快的。很多人对参与这个项目感到后悔和怨恨。这令人悲伤。
我认为这些事情通常是这样发展的：
- 项目内部存在冲突。
- 这个冲突没有得到很好的管理或解决，至少没有以专业或健康的方式处理。
- 冲突并没有消失；相反，它以某种不专业或不健康的方式被表现出来：有时是一次性爆发，但更常见的是长期存在。
- 可能在经历了第三阶段的一段时间后，冲突的一方就离开了项目，而所有人都试图假装冲突从未发生过。
这里所谓的不专业或不健康的处理方式，我至少见过四种具体的形式：
- 利用非常规的力量：压力、社交影响力、小圈子。
- 利用外部正式权力：找某人的上司。
- 利用内部正式权力：与管理员进行交涉。
- 通过花费时间争论消耗对手的精力。
离开阶段常常显得有点突然，因为其原因不透明，并且也有几种不同的形式，通常对应到上述处理的模式：
- 因厌恶甚至为表抗议而辞职。
- 上司处理或解雇。
- 管理员处理或封禁。
- 由于精疲力竭或倦怠而退出。
理解模式
所有这些阶段都有可以理解的缘由。我不是说它们是“好”的，但可以理解。我理解它们是如何发生的，甚至可能对形成这些模式起过推波助澜的作用。
以下是一些背景事实，有助于理解为什么会出现上面这些模式：
第一，很多人只是习惯性地避免冲突。这可能是由于成长背景、个人创伤经历、固有的天性或其他原因。我自己就是避免冲突的人！应对冲突是困难且疲惫的，尤其对于没有报酬的志愿者来说。避免冲突通常看起来更容易。冲突回避是一种为了当下舒服一点，将问题推迟至未来应对的方式。
第二，Rust 如今形成了一种非常高风险的品牌。它似乎非常不可思议，经常吸引大量的互联网关注。它一度似乎被普遍崇拜，又被普遍憎恨。它感觉随时可能失败，但又感觉总是处于胜利的边缘。这在许多人中产生了一种自卫心理，我相信助长了这种心态的蔓延（我是一个焦虑的偏执狂），我确信这种心态是让许多人全身心地投入其中的原因之一。这可能是有趣和令人满足的，但对于许多人来说，它变得更重要。这些人为了参与 Rust 相关的事业付出了全部，将自己的职业或目标感、身份投入其中。自己的工作和未来往往岌岌可危！而且很多人也因过度工作、过度努力而真正精疲力竭。那些没有精疲力竭的人往往保留着一种内在的承诺，这使得缓和冲突变得困难，妥协变得困难，甚至公开承认问题也变得困难。
第三，Rust 最奇怪的文化规范之一（我可能有助于形成它，如果是这样，我向你道歉），是许多人都相信所有的冲突都是“虚假的权衡需求”，即冲突显示需要权衡的地方，都可以像 Rust 声称解决速度与安全之间的权衡问题那样，不用权衡地取得双赢。所有事情都可以实现双赢，如果你找不到这样的解决方案，那就是你没有努力尝试。我的意思是，如果真的能双赢，那当然很好，但是有时事情只能在合理的权衡甚至一定的冲突中形成决定！有些事情是零和博弈的。
第四，Rust 项目社群在管理或解决冲突方面没什么正式机构，考虑到 Rust 项目社群的规模，这个问题尤为突出。Rust 项目社群是互联网上的志愿者构建的，并在一个自身没有强大的正式架构的组织中孵化（Mozilla）。我推荐你阅读《无架构的暴政》这篇文章。Rust 项目社群中只存在着非正式的架构，或者执行严格的最终手段的正式架构，例如 moderators 或者外部干涉。
最后，这些非正式架构当中，有一种普遍存在于 Rust 和许多开源项目当中，这就是时间承诺的规范。《无架构的暴政》中也提到了这一点。热情的贡献者通常愿意并且有能力在项目上投入大量时间。然而，并不是所有人都能够遵守这种时间承诺。付出时间往往被明确激励：“真正做事的人有权做决策”。但是，这些决策往往会影响到许多其他的利益相关者，而“拥有最多时间的人”可能无法很好地代表这些利益相关者，或者可能缺乏完成这项任务所需的技能或知识。而“比其他人花更多时间”的做法也是一种相当不健康的处理冲突的方式：与其直接面对冲突，不如跟对方比拼时间投入，互相消耗精力。即使在正式架构内部，如果有“每单位时间贡献多少输入”的余地，这种做法也可以被采用。有些人会出现在每个会议上，推动相同的议程。这种做法行之有效，你能够按照自己的方式推进事情，但从社群角度上看，这并不是最好的方案。
修复问题
我真的不知道如何解决这些问题。如果我知道，我肯定会提出建议。我之前说过，我对助长一些模式感到相当负责。不过当然，过去的已经过去了。对项目来说，最重要的是未来。
我想我的主要建议是一个“不要听我的建议”的建议：“雇佣并听取那些在相关领域接受过培训的专业人士”的建议，其中“相关领域”涵盖了“一群编译器极客们”通常不擅长的一切。从项目管理到政治科学、金融、传媒、调解、人事管理。Rust 项目现在是一个相当大，而且非常分散的组织，人们长期以来一直在研究如何运行这类组织，甚至不同的专家研究其中不同的细分领域。应当听取他们的意见，而不是试图从某个第一性原则开始解决每个问题，也不要假装因为你们是一群互联网上的编译器极客就可以回避一个正常组织的所有机制。
我不知道新的治理体系在多大程度上具有这些专业人士的痕迹，也不知道它是否会在很大程度上解决上面提到的问题模式，但我可能会对结果感到惊讶。我在这些领域没有专业技能！如果一定要说，我喜欢“权力明确划分”、“任期限制”和“角色轮换以避免倦怠”这样的概念，以及透明决策；我喜欢设置某种利益相关者的代表和限制时间投入的机制。
我不知道社群是否承认现实中存在冲突，以及是否必须明确解决冲突。我不知道当前的治理模式和治理机构，在使项目中的权力职位，包括非正式的权力职位，对其行为负责方面，或在公开宣传以树立信心方面，是否做得足够。最主要的是：我不知道现在的治理模式，是否能够让那些不想全身心投入项目的人过上舒适的生活。
就我个人而言，我根本没有足够的精力，这一切对我来说都太沉重了。对于那些参与其中的人，我祝你们一切顺利。祝好运。
追加讨论：基金会
我想明确一点：据我所知，Rust 项目社群中的治理问题并不是 Rust 基金会导致的。每当社群中发生一些争议，总有一群人会把矛头指向基金会，这通常是错误的。
再次强调，我只是一个从旁观者的角度观察和倾听的外人。基金会通常似乎是房间里的成年人，当它做出一些表面上看起来奇怪的举动时，通常是因为它试图解决项目交给它的一些不可能解决的困境。
我认为基金会实际上只是想支持这个项目的存续，而 Rust 项目一直不是一个很容易支持的对象。
追加讨论：企业赞助商
此外，虽然 Rust 项目在一定程度上是由志愿者推动的，但它也在一定程度上是由企业赞助的，并且不仅是基金会成员的赞助。尽管有时我认为企业赞助会对维护者产生不良影响，导致维护者没有动力做那些琐碎的维护工作，但我认为 Rust 不会出现人们最担心的情况：企业在冲突或不受欢迎的决策中“购买影响力”，或者以其他方式操纵这门语言的发展。
这是一个可能存在的问题，但基金会的架构在设计之初，就花费了很大的精力来最小化相关风险。到目前为止，我认为我们没有看到这种情况。
追加讨论：最初的问题（BDFL）
为了更加具体地解释本文开头的“不希望”和“不会”的回答：我不喜欢受到关注或压力，当我在 2009 年至 2013 年担任项目技术负责人时，我接近极限运作，我离开的一部分原因是达到了这些极限并且有些崩溃了（以及公司对我燃尽的事实的反应并不好：参见“每个人都是人”）。我在本文中描述的人性缺陷，在我身上同样存在！
此外，我没有理由相信我会建立起强大或健康的正式决策机制、冲突管理机制或委派和扩展机制。我没有受过有关这些主题的任何培训，我完全是在 Mozilla 的角色中凭直觉行事。Mozilla 本身似乎对这些主题也没什么经验。我曾经试图在 Rust 的设计上进行一次“正式决策”，我试图用投票结果确定关键词命名的选择，但是结果非常糟糕：每个人都讨厌结果。
追加讨论：Moderation
我不了解 Rust Moderation Team 的故事。我从 2013 年其就不在 Rust 项目社群中了，因此，我不希望对他们过去的行为做出任何的评价或暗示，尤其是今天的 Moderation Team 已经不是过去的那一个了。在我看来，这是一个需要知晓内幕的人在其他地方讨论的主题。我想说两件事：
- 我写了最初的行为准则，且当时的行为准则更简短、更简单。我同意明确的社群规范和强制执行的能力通常是互联网社群所必须的。我不认为有管理员是一件坏事，也不认为管理员在谨慎和受监督的前提下行使权力是一件坏事。
- 我承认版主也是人。他们可能自己违反行为准则，也可能在处理其他人的违反准则行为是不够诚实。我认为这通常很少见，抱怨这种可能性的人往往没有站得住脚的理由，不过这些情况确实可能存在。要求对管理者的行为进行更严格的审查来避免这种监守自盗的可能性也算合理。根据我的经验，大多数好的版主愿意记录他们的决策过程，并解释决策的理由。
追加讨论：小团体和缺乏透明度
拥有志同道合的朋友是很棒的！关起门来做事情，不必向网络上的陌生人解释你所思考或说的每一件小事也是很棒的！这些事情本身并没有问题。实际上，这通常是许多人感到安全、舒适和愿意参与的先决条件。成为一个被审视的公众人物往往令人筋疲力尽，并且可能会排除那些被天性或环境所限的人。但一定程度的透明度是做出对他人产生影响的负责任决策的必要部分，也是权力行使的一部分。