Rust 核心团队“有毒”
11 月 23 日,Rust Moderation Team(审核团队)在 GitHub 上发布了辞职公告,即刻生效。根据公告,审核团队集体辞职是为了抗议 Rust 核心团队(Core team)在执行社区行为准则和标准上让自己不受制约。
审核团队并没有在公告中透露过多的细节。不过,根据审核团队成员 Matthieu M 在 Reddit 上的表述,导致审核团队直接辞职的原因是,其与 Rust 核心团队数月来一直不断恶化的矛盾。
两天后,Rust 也在内部博客上就审核团队集体辞职事件做出了回应,但回应中也并未提及审核团队所控诉的核心团队的问题是否真实存在,只是表示正在讨论和尝试对话,Rust 将致力于社区和项目的长期健康。
Rust 核心团队是否真如审核团队所控诉的那样“除了自己,他们不受任何人的监督和约束”?核心团队内部到底出了什么问题?
参与 Rust 开源项目长达六年的 Dragdu 写了一篇文章,通过他的亲身体会和观察,谈了他对 Rust 核心团队的看法,以下为文章全文:
我本来是不想写这篇文章,但在网上看到很多朋友在批评 Rust 项目的时候,方向好像有点跑偏。现在审核组已经辞职了,我觉得自己应该出来说两句。
以下内容是我对核心团队的切身体会与观察,虽然不一定跟审核团队的离开有什么直接关联,但我认为核心团队的很多系统性内部问题正是Rust项目矛盾的一种体现。
最后澄清一点,这些跟新任命的核心团队成员无关,所有问题都是项目内部长期存在的老毛病。
在进入正题之前,我先介绍一下自己的背景,这样大家应该更能理解我的体验和视角。过去六年来,我一直参与 Rust 开源项目,并拥有四年的 Rust 语言组织成员经历。在 2015 年第一次使用 Rust 时,我还是个学生,想为毕业项目找种新的实现技术。
负责任地讲,刚一接触 Rust,我就被它深深吸引,甚至有种窥见编程未来的感觉。这像是有人发现了我在程序中搞出的所有错误,并创造出一种能够消除这些错误的语言。可以说,Rust 为我打开了通往编程新世界的大门。
从 2017 年开始,我加入了 rust-lang 组织并为各个 Rust 版本编写发行说明。过去四年来,我每六周编写一次发行说明,也有幸接触到众多在不同层级和功能上参与 Rust 项目的社区同仁。每六个礼拜,我们的贡献名单都会再次壮大、社区新成员一直保持着稳定增长。
这让我意识到 Rust 语言不仅代表着未来,而且体现出社区整体创造独特成果的能力与意愿。Rust 项目不受个人或企业裹挟,而是由每一位社区成员所指引和把握,帮助大家通过参与贡献提升和成就自己。
Rust 核心团队“水太深了”
随着项目的发展,治理负担也成为我日常生活中非常重要的一环。项目如火箭般快速腾飞,社区领导和成员们已经筋疲力尽;特别是在 2018 年之后,我发现越来越多的老伙伴选择离开项目。
最初我以为这只是出于个人原因,但在跟他们实际接触之后、特别是在亲身接触 Rust 的领导工作以来,我发现这里面的水相当深。
下面我就具体聊聊自己在核心团队和 Rust 领导层中的经历。
2018 年Rust社区成立了“治理工作组”,着手解决组织内不断涌现的新问题。虽然出发点没有任何毛病,但从现实意义上看,这完全就是一场荒唐且尴尬的表演。
首先,跟其他团队不同,治理工作组在成立之后就一直保持着神秘色彩,根本不向其他团队或成员开放工作内容。虽然经过不断的催促与询问,工作组最终决定开放会议内容,但我发现身边的领导成员越来越少,最后只剩下我和另一位成员负责重启治理小组。
治理小组的一大宗旨,就是不会亲自做出治理决策,而是为核心团队和其他团队提供流程与建议。虽然这个思路听起来还行,但在实践中负责具体行动的团队(说的就是你,核心团队)往往对这些建议没有反应甚至抱有敌意,这时候就要出乱子了。
下面来看几个典型案例。
治理工作组在上一轮迭代中公开呼吁建立几个新的工作组。但直到我加入工作组的时候,部分申请仍然一拖再拖、看不到丝毫进展,因为某些有意参加的成员由于某些行为而被打上了“不受欢迎”的标签。
另外,整个工作组的努力基本都处于停滞状态,这种领导层面的冲突(涉及多位核心团队成员)令各个团队的工作难以推进,同时目标模糊、参与度低下。
核心团队倒不觉得有什么问题。
他们的做法既不是与申请者沟通解决方案,也没有尝试缓解这种对抗,而是选择直接无视问题并拒绝公开发表任何意见。
很多申请者已经被晾了一年多,最终我只能遗憾地提醒他们别再抱什么希望了。而且时至今日,核心团队也没有公开承认过他们这种不负责任的行径。
核心团队的运作是个大谜团
核心团队本身的运作方式也是个大谜团,Rust 基金会的成立本身就凸显出这一点。
虽然治理工作组在最初建立时雄心勃勃,但事实告诉我们如果没有核心团队的配合、治理小组压根别想解决任何问题。治理工作需要配合当然是对的,但核心团队是真的从来不配合。
我们一再要求解决不同阶段下最为重要的问题,但核心团队则不断驳回和忽视这些诉求。直到 Mozilla 解散了其 Rust 团队之后情况才略有改观,但项目核心团队仍然秘密行动,不受治理工作组或者组织内任何其他成员的影响。
核心团队还有另一种“可恨”的行为模式,就是拒绝承认组织的当前结构。
在治理工作组刚刚建立起,很多团队和工作分配方式已经过时,甚至根本没法从团队的 repo 中准确获取成员跟踪信息。我们当然需要把应有的组织结构与实存结构进行同步,初期工作也推进地很顺利,但到了核心团队这边则再次陷入僵局。
我跟参与同步的其他成员交流过,他们也表示看不懂目前的状态;他们愿意继续努力,但核心团队成员没有任何合作的意思,一切只能不了了之。
很明显,核心团队成员希望一直占据在项目中的优势地位,不接受任何形式的评判甚至是标记。核心团队成员甚至不愿把开源贡献校友纳入结构中,社区情绪因此陷入谷底。
核心团队对以往成员们的贡献没有给予足够的重视,甚至不愿予以信任。相反,他们一直在利用自己的职务贩卖服务、谋取私利。
我对这一切痛心疾首,但批评换来的不是改进、只是疯狂的排挤。
很遗憾,这些问题已经成为核心团队的常态。
2020 Rust All Hands 在组织上的失败就证明了这一点。在 2019 年的 All Hands 会议之后,核心团队就变得不感兴趣,Mozilla 也不愿意继续举办。这里向大家解释一下,All Hands 会议是面向 Rust 团队成员的线下见面活动,其最大的亮点是可以为手头紧张的贡献者提供往返车票和住宿服务。
而且 All Hands 活动一直就办得不好,最初几届会议承诺的预算和费用一直批不下来。会议组织的主要成本就是场地租金和贡献者们的往返车票。在一位核心团队成员的建议下,会议地点从德国柏林搬到了希腊塞萨洛尼基。这样场地租金确实更便宜了,但贡献者们的往返车票倒是更贵了。而且因为我们希望 All Hands 能专注于社区成员而非企业,所以很难拉到商业赞助。
最终,All Hands 会议终于陷入了尴尬的境地——要么收取门票费用,要么缩减受邀参会的贡献者人数。矛盾最终在组织方与核心团队的磋商中爆发了出来,核心团队坚持认为要么继续邀请所有贡献者、要么就取消活动。虽然这话说得挺漂亮,但主要原因是有一大批核心团队成员能享用到这笔差旅费。
总之,核心团队在任何问题上都会选择对自己最有利的选项,根本不会考虑更广泛的组织需求。
在这样的指导思路下,核心团队漠视 Palantir 员工继续参与 Rust-lang 的投诉也就可以理解了。这是一家劣迹斑斑、被实锤开发过间谍软件的公司,但多位成员对此表达的担忧都被核心团队无情驳回。
2020 年,George Floyd 惨案发生之后,我发现 Palantir 公司继续在利用监控软件跟踪甚至打击参与 Black Lives Matter 的社会活动家。我无法接受这一切,但核心团队仍然坚持给 Palantir 的员工们保留社区身份。
以上种种,仅仅只是冰山一角。
核心团队成员种种拒不配合、粗暴打压的态度,证明他们完全是把 Rust 当成了自己的专属品、甚至是豢养的“宠物”。
核心团队特别喜欢宣扬 Rust 项目没了他们不行,而他们提出的一切跨领域协作口号在我看来都只是假话、空话。
这是个完全自利的团体,只会坚定维持自己的派系、实施自己的目标,头脑中压根没有组织利益或者合作之类的概念。
我个人希望核心团队的成员们辞职,并彻底解散整个核心团队。
因为我认为在目前的环境下,Rust 社区成员们根本无法继续开发并创造良好的创新成果,因为我们的领导层“有毒”、烂透了,既不考虑成员利益也不会在必要时施以援手。
对于这样一帮家伙,你会将他们称为 Rust 的“核心”吗?反正我肯定不会。
参考链接:
https://hackmd.io/@XAMPPRocky/r1HT-Z6_t
本文文字及图片出自 InfoQ
你也许感兴趣的:
- 【外评】电脑从哪里获取时间?
- 【外评】为什么 Stack Overflow 正在消失?
- Android 全力押注 Rust,Linux 却在原地踏步?谷歌:用 Rust 重写固件太简单了!
- 【外评】哪些开源项目被广泛使用,但仅由少数人维护?
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗,Rust for Linux 项目内讧升级!核心维护者愤然离职:不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
- 【外评】Linux 桌面市场份额升至 4.45
- 【外评】作为全栈开发人员如何跟上 AI/ML 的发展?
你对本文的反应是: