5 月 26 日，C++ 专家、C 标准的两位官方编辑之一 JeanHeyd Meneide 发表声明文章称，自己不再在 RustConf 2023 上发言。

据描述，RustConf 2023 的组织者联系到他，让他接受从“主题演讲”降级为“常规演讲”。最初 JeanHeyd Meneide 以为这是出于日程安排的原因或者是找到了更合适的人选。

但事实并非如此。真实的原因是，Rust 领导小组部分成员对 JeanHeyd Meneide 的演讲主题表示不满。

JeanHeyd 的演讲主题是编译时编程他表示，这一分享主题的想法来源于他正在帮助的 Rust 基金会资助工作。他认为编译时编程是一个可能的未来，而不是确切的未来。因为他将主题定为：“可能的编译时反射的（非常快速）演练？” 。

JeanHeyd 感到不解。RustConf 的主题演讲通常涵盖与 Rust 项目的目标和需求相近和相距甚远的主题。主题演讲从来没有突然对 Rust 项目的目标方向有一个近乎“神圣”的指示，之前关于任何给定主题的演讲似乎也没有明确的目标来支持特定的结果或特定的未来。

此外，过去的 RustConf 主题演讲者和受邀演讲者也谈到了很多“异端”和相互竞争的观点。前几年（2022 年及更早）引入具有不同 / 外部观点的演讲者也是 RustConf 的明确政策，因此即使本主题演讲的内容并未得到 Rust 项目的明确认可，这只会增加其对至少预期和声明价值的吸引力。

在 RustConf 时间表和程序发布之前，JeanHeyd 多次明确表示我正在谈论的工作不会有 RFC（Pre-RFC”是我在与 Rust 项目领导层相关人员交谈时使用的确切措辞），这可能会使人们产生偏见，以及是否可以这样做。“在 RustConf 领导层内外与我接触的人都非常清楚地表明这个话题非常好。而且，他们之前已经开会讨论过我的工作，所以任何人都不应该对我的意图和目标感到困惑”。

“他们没有事先联系我，只是问我是否愿意放弃我的工作，以明确表示他们没有明确认可这个方向，这对我来说，最终是一种侮辱”，JeanHeyd 在声明中表示。

5 月 28 日，提名由 JeanHeyd Meneide 担任主题演讲人的 JT 发布了离开 Rust 的声明。他表示，之前的声明引发了不少猜测，因此发出了下面这则澄清文章：

先从我的视角向大家汇报一下事情的整个过程：

1. 向临时领导小组发出申请，物色 RustConf 的主题演讲人。

2. 我和 Manish 提出由 JeanHeyd Meneide 担任主题演讲人。JeanHeyd 是 C 标准的两位官方编辑之一、C++ 专家，也是一位优秀的演讲者。我们觉得他肯定能以外部专家的身份带来一段精彩的演讲。

3. 几天之后提议得到投票通过，JeanHeyd 被选为主题演讲人之一。

4. JeanHeyd 欣然接受了主题演讲邀请。

5. 在发布时间表之前，我们在团队会议上宣布 JeanHeyd 被选为主题演讲人。

6. 但据我所知，因为 JeanHeyd 在博文中曾对 Rust 进行反思，所以部分团队成员对选他作主讲人抱有强烈的意见 / 不满。

7. 这个问题被紧急提交给临时领导小组，但内部没有继续讨论临阵换将可能引发的后果。有人抱怨说一点点抵制不至于必须换人，但反馈没有得到回应。后续讨论的重点放在了团队成员的不满上，而且唯一的办法就是撤消 JeanHeyd 的主讲人身份。

8. 在未经过临时领导小组投票的情况下（JeanHeyd 是票选通过的主讲人），Rust 领导小组的某位成员直接联系了 RustConf 组委会并要求修改邀请信息。

9. RustConf 组委会决定等待一周再向 JeanHeyd 发出通知，留段时间让 Rust 领导小组好好想想。但临时领导小组压根就不知情。

10. 一周过后，JeanHeyd 得到了主讲人资格被撤消的通知。他做出了每个人都能理解的选择：宣布拒绝在 RustConf 上做任何发言。

11. 在通过 JeanHeyd 的博文得知他的主讲人资格被撤消后，我也立即退出了 Rust 项目。

再次强调，以上情况是我根据个人经历整理出的事件全貌，也许背后还有不为我所知的细节情况。若有其他消息出炉，我也会及时修订上述内容。

在我看来，选择离开的理由已经非常充分。Rust 团队羞辱了我所在领域的一位专家。作为组织，无论是 Rust 还是 RustConf 都几乎是在坐视这种对个人的赤裸裸针对，原因仅仅是几位团队成员感到“不满”。

这时候我能想到的只有“老子就是王法”……

Rust 的表现就如同一个残忍、无情的实体，丝毫不关注 JeanHeyd 的感受。表达尊重并不难，但夺走这份尊重也只在瞬息之间。这就是 Rust 的王法，Rust 就是这么干的。

之所以选择离开，是因为我能感受到 JeanHeyd 在不公待遇和背叛之下承受的痛苦和失望，这让我心碎欲裂。更让我辗转反侧的，是我自己亲手参与了这套体制的搭建。

但不就是撤消个主题演讲吗？

真这么简单吗？我觉得不是，Rust 团队习惯了践踏他人尊严，连领域专家也不例外。先邀请主讲人，再撤消对方受邀身份的作法毫无尊重可言。我还专门打听过之前有没有这种情况，朋友们纷纷表示从未听说。

通过这次事件，我也感受到了“有理有据”四个字的份量。JeanHeyd 不仅是 Rust 基金会的新近资助对象，还在 Rust 项目有着非常重要的贡献历史。JeanHeyd 曾经大力呼吁 Rust 的技术会议应该引入黑人代表。这话没错，Rust 的组织框架和会议活动几乎没有黑人代表的身影。

而我感受的不只是一个组织对于领域专家的冷漠，更感受到正是由于 JeanHeyd 直言不讳地批评 Rust 缺乏多样性，才招致今天不受尊重的结局。

制度是有记忆的，是有偏见的。如果制度内的每一分子不努力与之斗争，这些记忆和偏见就将长期存在。我的好友 Aman 说得很对，RustConf 不该缺少有色人种的出席。

我回顾了自己在这段历程中的所作所为，意识到自己完全可以做得更好。我总是优先选择斡旋，想要建立对话通道、获取信息并寻求妥协。但在了解到此次事件和自己的软弱之后，造成今天局面的一大原因明显就是斡旋太多、斗争太少。人们总在相互怀疑、人们总想寻求答案，并在浑浑噩噩中忽略了纠正错误的机会。

所以我想在补救方面贡献自己的一份力量：

我们需要的不是斡旋，而是坚定的责任。我们必须让人们担起责任、做出补偿，让那帮喜欢滥用权力的家伙退出领导团队，阻止他们赤裸裸地针对编程语言社区的专家。我们需要建立一个行事坦荡的组织，由此打造的项目和背后团队才能重拾已经失去的信任。

Rust 的残忍和无情必须被追责，下面这些问题需要有人给出答案：

• 未经领导小组投票的决策怎么可能落地？

• 撤消主讲人资格怎么就成了唯一的选项？

• RustConf 领导层为什么会同意这个决定，而没有保护主讲人？为什么 Rust 领导小组根本不知道有一周的撤消冷静期？

• Rust 团队对领域专家做出的公开侮辱，该由谁来承担责任？我们要怎么追究这份责任？

• 我们该通过怎样的保护措施防止类似事件再次发生？

• Rust 怎样保证不仅在当前，而且在未来长期保持负责的态度？

不久前已经正式退出 Rust 社群的 amos 认为，最近 Rust 已经发生了太多戏剧性的事件，比如整个 mod 团队辞职，比如商标草案引发广泛不满，也包括 RustConf 撤回 JeanHeyd Meneide 的主题演讲资格逼迫他选择离开等。

amos 也写了一篇文章对 JeanHeyd Meneide 被撤销主讲人资格事件发表了评论。以下评论全文。

这就是典型的好心办坏事，只是执行过程中出了纰漏。资源不够、流程不力、人手不足、时间太紧等等都可能引发问题，但这次的冲突看似只是个人矛盾。

不过个人矛盾永远不单纯是个人问题，否则我也会开掉“坏家伙”，为整个社区造福。这次冲突的起点是社群中的 4、5 个人。

首先得承认，他们并不是真正的坏人，而更像是……想走内部惯例，而非既定流程。也可能是他们负责的事太多，做不到尽善尽美。或者说，他们是一时被蒙蔽了双眼，没能全面了解情况……

这样的借口还能找到很多，总之出于某种原因（甚至具有一定的合理性），他们决定集体向某一个人施压。这可能是因为对立双方因为之前的旧事心存不满，也许是有不可调和的目标或技术观点，或者是对某些问题抱有不同的看法。

但无论如何，他们绝不像很多人猜测的那样怀揣纯粹的恶意。

好在 ThePHD 主题演讲撤回事件跟种族主义无关，但就怕外界误解了引发问题的原因，而官方也只剩下几周、甚至几天时间来做澄清。真不知道事件传播出去，会在坊间被解读成什么样子。

在大致浏览了内部讨论之后，我也基本放下心来，看到好人们仍然在为正确的目标而奋斗。这件事本身没做好、而且已经无法挽回，希望以后别再闹出类似的麻烦。

但其他不明真相的群众呢？如果他们只看到谣言、语焉不详的官方声明和被删除的 Reddit 帖子，会不会脑补出 Rust 发生内讧的场面？

其实我也有很多不满。我对 ThePrimeagen 的商标政策非常失望，也为“crablang”fork 浪费了大量时间而感到沮丧。希望相关人员能找到更具建设性的社区管理思路。

但正确的途径应该是“釜底抽薪”：让整个 Rust 项目变得更好，让整个 Rust 社区的沟通变得更好。

即使没有反馈渠道，也至少得想办法让人们重新对 Rust 项目的前景充满信心和乐观态度。多年以来，社区成员一直致力于 Rust 的研究和商业应用，他们有资格了解事情的真相。

另外，人们应该按自己选择的层级参与 Rust 项目。

我自己选择的是 Rust 培训（也可以说是技术布道），这是我的兴趣所在。尽管参与治理事务听起来更有吸引力，尽管很多人总说“工欲善其事，必先利其器”，但我真的志不在此。

如果 ThePHD 能和朋友们单独组织一场会议，我也会万分期待，但这不应该成为他们继续探索和展示自己研究成果（ https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generic-compile-time-introspection-in-rust/）的前提。

于是乎……

我决定加入“外部团队”（也可以说是离开「内部团队」，大家怎么理解都行）。

Rust 是个优秀的项目，我将继续贡献自己的一份力量，但从现在起将只使用公开可用的知识和内容。

我的“内部”知识很快就会过时，但至少现在的我还可以负责任地跟大家讲，很多不该走的好人还没走、而很多该走的人还留在社区内部。

我会一直关注事态发展。总之，要想让 Rust 项目继续保持良好发展，就必须建立问责制度。

5 月 27 日，编程语言领域的技术专家，在过去几年里一直致力于 Rust 编程语言开发的 Saoirs 从社区治理的角度撰写了一篇博客文章，对 Rust 项目本身和它背后的技术社区提出了反思。

构建美国政治自我认同基础的一段著名轶事，就是本杰明·富兰克林和伊丽莎白·威林·波维尔在 1787 年制宪会议（确立了美国目前的政府形式）之后的谈话。波维尔问美国需要什么样的政府，富兰克林的回答是“一个受约束的共和制政府”。

鉴于 Ruat 最近一直在谈治理 RFC，还在讨论中引用了“宪法”和“制衡”等内容，富兰克林的这句名言也许正适合用来反思 Rust 项目本身和它背后的技术社区。

上个礼拜，我发推文说有时候问题出在治理上，但多数情况下问题出在权力上。我想说的是在正式治理制度受其中暴露为缺陷的组织问题，通常都是组织成员以非正式的权力行使方式破坏组织治理规则的体现。

这也富兰克林名言的核心要旨所在：治理制度的好坏，取决于被治理者的行为，特别是其遵守约束的承诺。如果被治理者选择在正式流程之外采取行动，而且在破坏规则的同时根本不受追责，那治理制度就根本一文不值。毕竟制度本身只是一份描述性的程序文件，不会出动变成现实约束力。

在这里我不想谈 Rust 项目的具体管理细节，它需要的是一套正式的机制加以约束。这似乎也是 RFC 讨论中达成的普遍共识：不少著名贡献者对 RFC 的起草方式表达了担忧，但表示支持其落地，毕竟再怎么样也比当下的情况强。但我个人还是比较沮丧，因为 Rust 项目根本就不具备有意义的正式治理制度，明显也不清楚该做点什么来防止类似的问题再次发生。

这已经不是 Rust 鼓捣出来的第一份治理 RFC。之前的治理 RFC 早在 2015 年就已经通过，非常正式地描述了项目应如何治理。但随着时间推移，情况也在发生变化。到 2021 年左右，RFC 对项目管理方式的描述与实际运作方式已经几乎没有相似之处。核心团队虽仍存在，但一些重要团队根本没有代表，也不再发挥项目协调的作用。而且跟 Rust 项目关系密切、但如今鲜有提及和讨论的一个核心问题，正是当初的治理 RFC 是怎么失效消亡的、新的 RFC 跟之前的 RFC 有哪里本质上的不同、又该采取哪些措施阻止类似的失效消亡。如果不能回答这些问题，那投入这么多资源搞出新的治理 RFC 根本就没有意义。

从诸多方面来看，新 RFC 都是之前 RFC 的一种映射。核心团队应该像代表所有子团队的“委员会”那样发挥作用，而各子团队则掌握着大部分重要决策权。决策应以协商一致的方式做出，优先采取公开且正式的 RFC 流程。新委员会跟旧核心团队之间的主要区别，在于前者内的各成员将每年轮换，且建议的“任期上限”为三年（但这明显不是硬性要求，各子团队可以决定不更换代表人选）。另外，同一家公司所能雇用的项目成员数量也有限制（这项要求在 2015 年时根本不可想象）。

另一方面，委员会和审核团队间的关系也比之前 RFC 中的描述更为正式。之前 RFC 同样提到核心团队应该受到审核团队的约束（Aaron Turon 曾多次自豪地表示，审核团队中没有任何核心团队成员的参与，因此实现了「权力分立」）。但对于审核团队要如何运作，旧 RFC 并没有确切表达。如今新版本提到用“临时审核员”和审计制度为团队间的分歧提供富有成效的沟通渠道，这显然是在对 2021 年审核团队集体辞职做出的回应。

新的治理 RFC 一直在关注“制度”建设，这些机制明显是想限制委员会在项目中的权力纽带作用，确保其服从于作为协调对象的各子团队。但在我看来，旧制度崩溃的真正原因并不是正式领导机构滥用职权，而是几位主要利益相关者掌握着过于强大的隐性权力。他们通过正式制度之外的秘密渠道动用这种权力，架空了苦恼设计出来的这一整套治理结构，甚至形成了明确的“内部团队”和“外部团队”区分。他们对内回避冲突，对外将分歧视为人身攻击，并发展出一种不尊重“外部”人士并驳斥其贡献的腐烂文化。如果我的感受属实，那新的 RFC 有哪些条款能够阻止这种行为继续侵蚀治理制度，引导 Rust 重新回归健康活跃的状态？

新 RFC 在问责制、责任、透明度和项目领导角色所须承担的义务上做出了冗长的描述。虽然论述主要集中在委员会成员身上，但这份责任同样归属于所有项目领导者——无论其是否得到正式任命。更重要的是，这些条款本身是没有强制执行力的，唯一的落地方法就是由领导层自身主动贯彻。那 Rust 项目的领导小组是否会做必要的自我反省和个人成长，从而治愈项目顽疾并依据新规范推动 Rust 朝着更积极的方向发展？他们中是否有足够多的人能以坚定的态度处置不愿坚守这些规范的成员，把条款内容深深根植于项目文化当中，真正把约束要求转化为既定事实？这些都是亟待回答的现实问题。

又或者，这帮领导者还是会回到曾经的老路，交出自己不喜欢的工作、却不愿交出自己手里的权力？在我看来，之所以官方商标政策饱受诟病，体现的也许就是这份对“非技术”工作的冷漠态度。他们不愿意交权，也许是因为这份权力允许他们依照个人喜好撤消会议主讲人的资格。这里太多的也许，正是悬在 Rust 项目头顶的一柄风险之剑。

参考链接：

https://thephd.dev/i-am-no-longer-speaking-at-rustconf-2023

https://gist.github.com/fasterthanlime/42da9378768aebef662dd26dddf04849

https://www.jntrnr.com/why-i-left-rust/

https://without.boats/blog/if-you-can-keep-it/