社区纠纷不断：程序员何苦为难程序员

2022-07-24 10:07

出品 | OSC开源社区（ID：oschina2013)

今年年初，我们报道“因为被多人侮辱大吼，Swift 之父正式退出 Swift 核心团队”。

诸如此类的“语言暴力”、“网络暴力”事件在开源社区乃至整个 IT 社区屡见不鲜。多个技术社区，都出现过创始人、重要维护者、贡献者因为感觉“社区氛围糟糕”、“受到伤害”而宣布退出的现象。更有甚者，还有科技公司领导被爆出叫嚣着让 80 后退出 IT 圈。后者可粗略视为是该领导过于偏激，且是少数案例，先不做过多讨论。但是在开源圈，怎么就这样了呢？

为了回答这个问题，本文梳理了以往的一些社区纠纷事件，发现许多矛盾发生在社区实际的管理者/层，与社区贡献者、参与者之间，双方的不满大致也可以归总成几类原因。

众口难调

从大教堂的开发模式转向集市开发模式之后，技术社区存在的目的便是为了聚众人之力，让项目更好。在集市模式下，开源社区给了个人极大的自由度，所有贡献者都可以畅所欲言，发表自己的想法，为项目作出贡献。随之而来的问题，便是如何协调所有人的意见。

社区的管理模也在一定程度上决定了社区日后的争吵风险有多大。当下的开源社区管理主要分成四种模式。一是由社区主导，采用自由贡献模式，“共识”是其前提，功能开发和版本发布等重要决策以社区共识为准。二是公司主导，由公司资助社区及软件的发展，相对来说，公司会拥有更多的实权。三是 BDFL 仁慈的独裁者模式，这是在社区模式的基础之上，社区中有一个“独裁者”的角色存在，他对一些重要决策有最终决定权，而非依赖社区共识。四是精英治理，在社区中表现突出、贡献最大的人被任命为管理团队，决策基于投票确定。

我们常见的纠纷事件，往往可以归总为“掌权者”和“贡献者”之争，这种争议更容易出现在“仁慈的独裁者”模式的开源社区中。其他三种模式中，许多纠纷的出现也是因为实际管理团队未扮演好自己的角色。

掌权者的不满

闻名世界的大型开源项目往往是某个“天才程序员”的作品，早期的开源社区一般都是“仁慈的独裁者”模式，独裁者饱受敬仰，比如 Linux 社区的 Linus、Ubuntu 社区、Python 社区。然而，天才似乎更乐于单兵作战。

对贡献不满

暴躁大佬 Linus 在评价那些没达到他个人标准的代码方面非常毒舌。曾有网友用了此前 Linus 在邮件列表中公开的一段回复，直指 Linus 在人际沟通中态度恶劣：“这也算是一个 BUG？你已经成为内核维护者多长时间了？还没有学会内核维护的第一条规则？我再也不想收到这种明显的垃圾，像白痴一样的提交…… ”

对于一直看不爽的 Intel，Linus 对其提交的代码也是口吐芬芳。2018 年初，为了修补 Spectre 漏洞，Intel 工程师提供了一个间接分支限制推测（indirect branch restricted speculation, IBRS）功能的补丁。Linus 当时就在邮件列表中公开指出 IBRS 会造成系统性能大幅降低，直言该补丁“就是彻彻底底的垃圾”。

不仅仅是 Linus，在崇尚“精英主义”的 BSD 社区，也存在明显的“鄙视链”。BSD 的第一版撰写者 Bill Joy 不愿意相信庞大的志愿贡献者者们，他曾说：“大多数人都是糟糕的程序员，让很多人盯着代码不会真正发现错误。真正的错误是由几个非常聪明的人发现的。大多数人看代码不会看到任何东西......不能期望成千上万的人做出贡献并都达到高标准。”

这种看法一直存在于 BSD 之后的发展中，FreeBSD 深度参与者 Marshall Kirk McKusick 就曾表示，90% 的 committers 所贡献的代码都不能用，还剩下的一小部分也需要被打磨。

遭遇信任危机

在 Python 社区，很多年内，Python 之父 Guido van Rossum 都是最有威信的那个人，他也被社区授予“终身仁慈的独裁者”的称谓。但在 2018 年，当 Python 社区探讨改进提案时，Guido 发现“现在有这么多人鄙视我的决定”。

因此，他不想再为 PEP（Python 改进提案）[ PEP 572 ] （https://www.python.org/dev/peps/pep-0572/）争取什么，并决定自己将逐步脱离决策层，不再领导 Python 的发展，休息一段时间后将作为普通的核心开发者参与社区。

有时，“仁慈的独裁者”也会因为“不作为”被指责。Ubuntu 创始人 Mark Shuttleworth 在社区中被戏称为“自封的仁慈独裁者”。事实上，Ubuntu 社区早期也确实是“仁慈的独裁者”管理模式。

然而，在 Ubuntu 社区蓬勃发展，各项业务步入正轨之际，Mark Shuttleworth 本人的工作逐渐与开发者拉开距离，Jono Bacon 等一些早期在 Ubuntu 社区中颇具名望的核心成员相继离开，Mark Shuttleworth 也很少在社区活跃。逐渐，有一些资深的 Ubuntu 开发者认为社区正面临“群龙无首”的尴尬局面，指责沙特尔沃思没有尽到“BDFL”的责任。一位前 Ubuntu 开发人员在 Ubuntu 社区中留言指责 Mark Shuttleworth 作为 BDFL “放弃了社区，对社区治理的崩溃保持沉默”，令人失望。

Mark Shuttleworth 面对职责也欣然接受，承认自己在这些方面确实做得不够好，并表达了“挫败感”。

没有回馈

开源项目最容易让人不满的点还当属“白嫖”，许多开源项目都是靠作者用爱发电，社区的汲取大于回馈，从而导致软件作者身心俱疲。

前段时间轰轰烈烈的 Apache Log4j2 高危漏洞事件，攻击者可以利用其 JNDI 注入漏洞远程执行代码，影响了众多项目和公司。此事也让 Log4j2 的作者受到关注与批评，Log4j2 的维护者之一 @Volkan Yazıcı 在推特上吐槽：Log4j2 维护者只有几个人，他们无偿、自愿地工作，没有人发工资，也没人提交代码修复问题，出了问题还要被一堆人在仓库里留言痛骂。

此前，PhantomJS 的核心开发者之一 Vitaly Slobodin 宣布辞任 maintainer ，不再维护项目，原因也是一个人发电太累：“我看不到 PhantomJS 的未来，作为一个单独的开发者去开发 PhantomJS 2 和 2.5 ，简直就像是一个血腥的地狱。即便是最近发布的 2.5 Beta 版本拥有全新、亮眼的 QtWebKit ，但我依然无法做到真正的支持 3 个平台。我们没有得到其他力量的支持！”

贡献者的不满

当社区随着项目生命周期的发展逐渐发生变化时，流程和规定上的改变不可避免，贡献者间交流的氛围也在不断变化中。贡献者对社区的不满往往是从社区发生变化开始……

对项目或社区不再看好

一位 Debian 的包维护者 Stapelberg 在 2019 年写了篇长文宣布自己要退出 Debian 的开发流程，逐渐减少参与 Debian 的维护和相关活动。主要原因便在于，他发现 Debian 整个开发评估流程非常迟钝。

举例来说，补丁的评估没有截止日期，有时候他会收到通知说几年前递交的补丁现在合并了。Debian 的一些维护者出于个人喜好拒绝合作，维护者给予的个人自由度太高对 Debian 构成了严重影响。

在他对 Debian 的开发流程沮丧程度超过阈值之后，他便宣布退出，写了文章，希望能激励 Debian 作出改变。

在 LLVM 社区，2018 年一位名叫 Rafael Avila de Espindola 的资深开发者（LLVM 编译器贡献排名第五）发邮件宣布决定与该项目分道扬镳。原因在于近几年的感受发生了变化，LLVM 日益庞大且变化缓慢，他也不赞成 LLVM 最近引入的社区行为规范。真正促使他做决定的是 LLVM 与一个公开根据性别和血统进行歧视的组织 Outreachy 进行合作，这让他感到非常不满。

除此之外，一些由公司主导的开源项目也会因为改变发展战略招致不满。

Qt 公司从 2021 年 1 月开始，将 Qt 5.15 作为仅供商业化的 LTS，现有的 Qt 5.15 分支将公开可见，但不会看到任何新补丁，只有付费账户才可以使用长期支持版本的 Qt 5.15 。

此举引起了社区的强烈不满，基于 Qt 开发的 KDE 社区的担忧。有用户在 Qt 官方公告下留言讽刺道：“所以，基本上您是在告诉所有忠实的开源用户，现在他们将仅被视为商业客户的 beta 测试者，并且作为奖励，他们将只能下载非 LTS 版本。你们真是太亲切了！”一位长期的 Qt 贡献者，来自英特尔公司的开发者 Thiago Macieira 表示，至少对于他在 Qt 中处理过的代码，他不会再参与修复、评论和审查后端错误报告。

反独裁

与每个社区都有一个人或者几个人的实际管理团队向对应的是，在管理不当时，贡献者会起身反抗“管理”。

几个月前，Rust 审核团队 (Moderation Team) 昨日公告称，他们已集体辞职且即刻生效。团队成员 Andrew Gallant 表示此举是为了抗议 Rust 核心团队 (Core Team) 不对除自己以外的任何人负责。

Rust 的管理者分为很多个团队，比如核心团队、审核团队、发行团队、库管理团队等等...其中，Rust 核心团队的权限最大，而且其他团队无法影响他们。Andrew Gallant 在公告中写道，由于核心团队在组织结构层面的不负责任，他们一直无法按照社区对审核团队的期望和他们自己坚持的标准来执行 Rust 行为准则。对于在这种情况下选择离开，他们表达了对大家的歉意。但从治理 Rust 的角度来看，他们别无选择。因此 Rust 审核团队认为除了辞职和发表这份声明之外，已经没有其他办法了。

如何让众人满意？

矛盾激化的后果只有一个：成员慢慢离开。如果社区和项目不做出改变，则很有可能导致项目走向衰落。既然长时间充斥着争吵与不满的社区难以持久，那么，该如何构建一个让更多人愉快参与的社区？

首先，无论何种治理模式下的社区，个人文明表达观点，遵守社区行为准则都是减少冲突的必要条件。但是，个人行为是非常不稳定的因素，就像 Linus 曾说要改改自己的暴脾气，却每每被各种言论刺激，重回暴躁大佬。

其次，便是通过治理框架有效地管理社区，多权分立、避免独裁，并且成员间相互约束，基于“共识”发展。具体来说便是有一份好的“手册（原则、准则等）”，以及一个让人信服、能公证管理的团队。

比如在 Apache 软件基金会中，便采用精英治理的模式。Apache Way 中对于决策、监督、执行等各方面都有明确规定：包括结构扁平，无论职位如何，各个角色间是平等的，投票权重相同，不允许有仁慈的独裁者出现；单个项目由自选的活跃志愿者团队监督，倾向在达成共识的前提下决定项目发展，不能完全建立共识则用投票等方式做出决策；整个基金会的治理模型基于信任和委托监督……

在开放原子开源软件基金会中，项目的毕业标准考核中也有类似的关于社区需符合“贤能治理”的规定：

OA-CO-40
【英】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.
【中】社区要符合贤能治理的精神，随着时间的推移，为项目增值的贡献者会被赋予更多的权利和责任

TOC 成员徐亮曾介绍，贤能治理这四个字是经过很多轮讨论确定下来的。在英文语境中，这个词是 meritocracy，并不完全是一个褒义词，“我们并不觉得用 meritocracy 形容社区是完全正确的事情，但是我们又觉得在开源社区中，所谓的能者上氛围是比较积极向上的，是社区能够健康运转的主要因素。”

在许多项目中，一方面大家是贡献者，另一方面，每个人提交的功能越重要，或者对项目本身做出了更有意义的贡献，就更有可能被现任维护人员选中去承担更重要的角色。通过这种方式达成的精英治理或是贤能治理，往往是希望能够让项目可以自己成长，更好地走下去。

Ubuntu 的创始人 Mark Shuttleworth 在遭到信任危机之后，便着手参与将 Ubuntu 转向经营治理的模式。目前，Ubuntu 社区也重新组建了由 3 名核心成员组成的管理团队，分别是 Ubuntu 社区代表 Monica Ayhens-Madon，Ubuntu 开发者关系负责人 Rhys Davies，以及临时社区经理 Ken VanDine。Ken 还将负责继续为 Ubuntu 社区寻找一位合适的社区总监。

最后，借用一个当下共识：开源比以往任何时候都更加重要。也因此，维护一个好的社区氛围，正尤为重要。

你最喜欢哪个开源社区的氛围？欢迎在评论区畅所欲言。

END

关于开源项目的 Yes or No

这里有最新开源资讯、软件更新、技术干货等内容

点这里 ↓↓↓ 记得关注✔ 标星⭐ 哦~

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。

来源: qq

点击查看作者最近其他文章