开源社区怎么了
2011-01-11 08:51:02 
阿炯
陆首群：国人争当开源社区贡献者
纠纷不断：社区真的成为了一个肮脏的泥潭吗？
AppImage 被 OBS 项目组封杀
开源是梦想消亡的地方
陆首群：国人争当开源社区贡献者
2011年1月中旬消息，过去国际上一些开源界人士有一句口头禅：“中国人只是国际开源社区的消费者，不是贡献者”，这句实际而又贬义的话语压在国人头上有点喘不过气来。
国内开源界真争气！几年过去了，“中国人只是社区消费者”的形象正在悄悄地变化，开始(现在也只能说是开始)变成“既是社区消费者又是社区贡献者”。根据Linux(内核)社区(最典型的开源社区)的统计表列的数据，我们可以看到：
从2005年4月到2010年12月，从Linux内核2.6.11版本到2.6.37版本，共有51个国家，6779人，为Linux内核社区贡献了21万个软件包(Patch Sets)。表中所列Chinese(中国人)，我看还是翻译成“华人”更为确切(因为我们在查阅表列的“Chinese”统计中包含中国人和外藉华人)。Chinese的贡献名列第4(415个Chinese志愿者作出了贡献，贡献1万多个软件包，占总数的5.15%，居美、德、英三国志愿开发者之后，又位于俄、日、印、澳、荷、法等47国志愿开发者之前)。在作出贡献的Chinese中，海外华人(占极少数)和国内“外企”中的中国人(占大多数)加在一起占70%，国内“企业社区”的志愿开发者(中国人)占25%，国内“自由社区”的个体或业余志愿者(中国人)占5%；即在Linux(内核)开发中作出贡献的共计6779人，其中“华人贡献者”415人，在华人总数中“国人贡献者”394人(不计外藉华人)，在国人总数中，国内组织中和作为个体的国人104人(不计外企中的国人)。国人在虚拟技术、文件系统、设备驱动、进程管理优化、内存管理优化等方面作出了贡献。在国人贡献者中，Li Zefan(李泽帆)、Wu Fengguang(吴锋光)、Tao Ma(马涛)、Wei Yongjun(魏勇军)、Eric Miao(缪宇成)、Shaohua Li(李少华)、Bryan Wu(伍鹏)、Wang Cong(王聪)、Lai Jiangshan(赖江山)、Xiao Guanying(肖冠英)等均赫然名列表上。
我们要说，国人作为“开源社区贡献者”只是开始，国内的开源社区还有待继续扶持、整顿、完善和提升，但国人也不要妄自菲薄；国人更要自信、自立、自强，不要唱衰自己！
补充：2005年6月 Richard Stallman在巴西举行的“世界自由软件论坛”上作主题报告时指出：“一般讲我不认为GPL规则是Linux取得成就的主要原因，相反我认为那是由于在1991年那个时期，Linus Torvalds第一个找到了分布式开发软件的正确的社会组织形式”。
在这里Richard Stallman提到的“分布式开发软件的社会组织”指的就是开源社区。开源社区的开发机制是“集体开发、合作创新、对等评估、开放共享”，这是一种比传统商业企业封闭式开发更为先进的开发机制。开源社区的开发人员是分布在全球各地的志愿开发者(其中包括各有关企业专为开源社区无偿开发而组织起来的开发者队伍)。全球开源软件志愿开发者队伍泱泱大观已发展到约200万人。但开源社区70-80%的成果，是在各企业内部组织起来为开源社区无偿开发的“开发者”所作出的贡献。
纠纷不断：社区真的成为了一个肮脏的泥潭吗？
2022年3月消息，因为被多人侮辱大吼，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 ] 争取什么，并决定自己将逐步脱离决策层，不再领导 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 转向经营治理的模式。目前社区也重新组建了由 3 名核心成员组成的管理团队，分别是 Ubuntu 社区代表 Monica Ayhens-Madon，Ubuntu 开发者关系负责人 Rhys Davies，以及临时社区经理 Ken VanDine。Ken 还将负责继续为 Ubuntu 社区寻找一位合适的社区总监。
最后，借用一个当下共识：开源比以往任何时候都更加重要，因此维护一个好的社区氛围，正尤为重要。Linux 社区已经成为了一个肮脏的泥潭；这句话是 Linux 内核首席维护者、Linux 之父 Linus Torvalds 所言，原话是（The Linux community is now a dirty quagmire）。
AppImage 被 OBS 项目组封杀
2022年5月下旬消息，AppImage 是 Linux 的新打包方式，可以将应用程序打包成一个压缩的镜像文件，其中包含应用程序以及运行所需的所有文件。它免安装、可以跨多个 Linux 发行版使用，用户只需下载 AppImage - 双击即可运行应用程序。而 OBS Studio 则是一个有名的开源视频录制和实时推流软件，被广泛用于视频采集和直播领域。
早在 2020 年，AppImage 的作者 probonopd 和开发者 azubieta 就一直想把 AppImage 引入 OBS 项目：
在引入了基本构建后， OBS 项目管理员为该项目分配了一些测试人员，但尴尬的是：无论在 Arch Linux 还是 Ubuntu 上，关于 OBS AppImage 的测试都崩溃了，AppImage 的二进制构建似乎与 OBS 项目已部署的 Linux PPA CI 有些冲突。
OBS 团队对 AppImage 的调试一直持续到 2021 年 7 月，在多次调整 - 测试 - 崩溃的循环后，OBS 项目管理者乔尔・贝思克最终决定放弃 AppImage 的构建，并关闭了对应的 PR 。
AppImage 对 OBS 的可支持性有问题，而且普遍缺乏需求。OBS 项目团队目前没有能力承担另一个包生态系统的责任。但 probonopd 仍然坚持 azubieta 已经完成了 OBS 的 AppImage 构建，应当继续坚持调试。但这次贝思克就不留情面了，直接开怼：这 PR 最初是由 AppImage 开发人员，而不是我们 OBS 社区构思、开发和提交的。再次感谢您的努力，但我们目前对您的 AppImage 工具不感兴趣。
上述事件在 2021 年十月就已经告一段落了，按道理来说，自己的 工具被 OBS 社区拒绝了也不是什么大事情，毕竟 Linux 打包方式多种多样，各取所需嘛。但是，前几天 probonopd 又在这个 PR 下面回复了，这次的言论可谓是极致的” 阴阳怪气 “：
谁决定了社区不采用我的 AppImage ，有证据吗？
你说 AppImage 不是 OBS 社区构思开发的，那我看看你们的 Flatpak 打包是谁引入的，我猜是红帽或者 Gnome 社区呢，毕竟你们还引入了红帽的 Flatpak、Wayland、Pipewire 技术。
这应该跟红帽给你们捐了一万美金这件事没什么关系吧，嗯嗯，肯定没关系的。
这番怪怪的言论暗指 OBS 社区见钱眼开，对捐款公司的技术提供大力支持，而对自己的 AppImage 爱搭不理。这番话彻底把 OBS 社区的开发者激怒了，管理者贝思克更是直接在 OBS 项目中封杀了 probonopd：
禁止 probonopd 和他密切相关的 AppImage 开发者进入 OBS 项目，只要他负责这个项目，我们就不会直接与他或他团队中的任何人合作。因为他带来的只有骚扰，对我们遇到的技术问题没有任何有价值的建议或者帮助。
但是不会有人会因提及 AppImage 或提出 AppImage 构建需求而被 OBS 项目和社区排斥。也不排除未来某个时候 OBS 社区会支持 AppImage 包，只要有足够的用户需求，和愿意为之努力的开发者。
这里禁止的是人，而不是技术。
开源是梦想消亡的地方
2025年2月，拜读了《辞去 Asahi Linux 项目负责人》这篇文章，感触颇深。又一位才华横溢的开发者因维护开源软件的繁重需求而精疲力尽。
Hector Martin (marcan) 花了数年时间将 Linux 移植到 Apple Silicon 上 —— 这是一项令人难以置信的技术成就 —— 最终却因疲惫和幻灭而选择离开。
这样的故事在开源领域以令人沮丧的频率重复上演。充满热情的开发者创造了有价值的东西，免费与世界分享，然后看着他们的礼物变成吞噬他们生活的负担。最初的热爱逐渐转变为无偿的技术支持。用户提交错误报告时，仿佛他们是付费客户，要求立即修复和新功能，而自己却毫无贡献。Asahi Linux 团队在没有文档的情况下逆向工程了 Apple 的复杂硬件 —— 在企业环境中，这一壮举可能需要花费数百万美元 —— 然而，当用户的特定外设无法完美工作时，他们却抱怨不已。
开源的经济模式从根本上就是破碎的。大多数维护者从未因他们的努力获得一分钱，尽管他们创造的软件支撑着价值数十亿美元的公司和关键基础设施。少数通过赞助实现财务可持续性的开发者只是极少数，他们是 “精英中的精英”，其项目要么达到了极高的知名度，要么满足了关键的行业需求。
对于其他人来说，开源变成了一种单向关系：只有付出，几乎没有回报。你牺牲晚上和周末的时间来维护软件，而用户却将你的志愿工作视为理所当然。源源不断的需求逐渐侵蚀了启动项目的热情。最终，维护项目感觉像是一份无薪的第二职业，而不是一种充实的爱好。Marcan 的辞职并不是性格或承诺的失败 —— 而是一个系统可预见的结局，这个系统从维护者身上榨取价值，直到他们崩溃。他的故事应该成为对 “免费” 软件真实成本的警示。每个开源项目背后都是一个时间和精力有限的人，他们通常在没有报酬或认可的情况下工作。
除非我们从根本上改变对开源工作的价值认知和支持方式，这些项目将继续成为梦想破灭的地方 —— 在用户理所当然的要求、不可持续的经济模式以及随之而来的不可避免的倦怠中崩溃。幸运的是，并非一切都是坏的；GitHub 正在通过其赞助计划推动更多的赞助。Sentry 也有一个类似的项目，名为 “Open Source Pledge”。希望更多的公司能够效仿并支持开源社区，现在是时候回馈那些让开源成为可能的人了。
纠纷不断：社区真的成为了一个肮脏的泥潭吗？
AppImage 被 OBS 项目组封杀
开源是梦想消亡的地方
陆首群：国人争当开源社区贡献者
2011年1月中旬消息，过去国际上一些开源界人士有一句口头禅：“中国人只是国际开源社区的消费者，不是贡献者”，这句实际而又贬义的话语压在国人头上有点喘不过气来。
国内开源界真争气！几年过去了，“中国人只是社区消费者”的形象正在悄悄地变化，开始(现在也只能说是开始)变成“既是社区消费者又是社区贡献者”。根据Linux(内核)社区(最典型的开源社区)的统计表列的数据，我们可以看到：
从2005年4月到2010年12月，从Linux内核2.6.11版本到2.6.37版本，共有51个国家，6779人，为Linux内核社区贡献了21万个软件包(Patch Sets)。表中所列Chinese(中国人)，我看还是翻译成“华人”更为确切(因为我们在查阅表列的“Chinese”统计中包含中国人和外藉华人)。Chinese的贡献名列第4(415个Chinese志愿者作出了贡献，贡献1万多个软件包，占总数的5.15%，居美、德、英三国志愿开发者之后，又位于俄、日、印、澳、荷、法等47国志愿开发者之前)。在作出贡献的Chinese中，海外华人(占极少数)和国内“外企”中的中国人(占大多数)加在一起占70%，国内“企业社区”的志愿开发者(中国人)占25%，国内“自由社区”的个体或业余志愿者(中国人)占5%；即在Linux(内核)开发中作出贡献的共计6779人，其中“华人贡献者”415人，在华人总数中“国人贡献者”394人(不计外藉华人)，在国人总数中，国内组织中和作为个体的国人104人(不计外企中的国人)。国人在虚拟技术、文件系统、设备驱动、进程管理优化、内存管理优化等方面作出了贡献。在国人贡献者中，Li Zefan(李泽帆)、Wu Fengguang(吴锋光)、Tao Ma(马涛)、Wei Yongjun(魏勇军)、Eric Miao(缪宇成)、Shaohua Li(李少华)、Bryan Wu(伍鹏)、Wang Cong(王聪)、Lai Jiangshan(赖江山)、Xiao Guanying(肖冠英)等均赫然名列表上。
我们要说，国人作为“开源社区贡献者”只是开始，国内的开源社区还有待继续扶持、整顿、完善和提升，但国人也不要妄自菲薄；国人更要自信、自立、自强，不要唱衰自己！
补充：2005年6月 Richard Stallman在巴西举行的“世界自由软件论坛”上作主题报告时指出：“一般讲我不认为GPL规则是Linux取得成就的主要原因，相反我认为那是由于在1991年那个时期，Linus Torvalds第一个找到了分布式开发软件的正确的社会组织形式”。
在这里Richard Stallman提到的“分布式开发软件的社会组织”指的就是开源社区。开源社区的开发机制是“集体开发、合作创新、对等评估、开放共享”，这是一种比传统商业企业封闭式开发更为先进的开发机制。开源社区的开发人员是分布在全球各地的志愿开发者(其中包括各有关企业专为开源社区无偿开发而组织起来的开发者队伍)。全球开源软件志愿开发者队伍泱泱大观已发展到约200万人。但开源社区70-80%的成果，是在各企业内部组织起来为开源社区无偿开发的“开发者”所作出的贡献。
纠纷不断：社区真的成为了一个肮脏的泥潭吗？
2022年3月消息，因为被多人侮辱大吼，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 ] 争取什么，并决定自己将逐步脱离决策层，不再领导 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 转向经营治理的模式。目前社区也重新组建了由 3 名核心成员组成的管理团队，分别是 Ubuntu 社区代表 Monica Ayhens-Madon，Ubuntu 开发者关系负责人 Rhys Davies，以及临时社区经理 Ken VanDine。Ken 还将负责继续为 Ubuntu 社区寻找一位合适的社区总监。
最后，借用一个当下共识：开源比以往任何时候都更加重要，因此维护一个好的社区氛围，正尤为重要。Linux 社区已经成为了一个肮脏的泥潭；这句话是 Linux 内核首席维护者、Linux 之父 Linus Torvalds 所言，原话是（The Linux community is now a dirty quagmire）。
AppImage 被 OBS 项目组封杀
2022年5月下旬消息，AppImage 是 Linux 的新打包方式，可以将应用程序打包成一个压缩的镜像文件，其中包含应用程序以及运行所需的所有文件。它免安装、可以跨多个 Linux 发行版使用，用户只需下载 AppImage - 双击即可运行应用程序。而 OBS Studio 则是一个有名的开源视频录制和实时推流软件，被广泛用于视频采集和直播领域。
早在 2020 年，AppImage 的作者 probonopd 和开发者 azubieta 就一直想把 AppImage 引入 OBS 项目：
在引入了基本构建后， OBS 项目管理员为该项目分配了一些测试人员，但尴尬的是：无论在 Arch Linux 还是 Ubuntu 上，关于 OBS AppImage 的测试都崩溃了，AppImage 的二进制构建似乎与 OBS 项目已部署的 Linux PPA CI 有些冲突。
OBS 团队对 AppImage 的调试一直持续到 2021 年 7 月，在多次调整 - 测试 - 崩溃的循环后，OBS 项目管理者乔尔・贝思克最终决定放弃 AppImage 的构建，并关闭了对应的 PR 。
AppImage 对 OBS 的可支持性有问题，而且普遍缺乏需求。OBS 项目团队目前没有能力承担另一个包生态系统的责任。但 probonopd 仍然坚持 azubieta 已经完成了 OBS 的 AppImage 构建，应当继续坚持调试。但这次贝思克就不留情面了，直接开怼：这 PR 最初是由 AppImage 开发人员，而不是我们 OBS 社区构思、开发和提交的。再次感谢您的努力，但我们目前对您的 AppImage 工具不感兴趣。
上述事件在 2021 年十月就已经告一段落了，按道理来说，自己的 工具被 OBS 社区拒绝了也不是什么大事情，毕竟 Linux 打包方式多种多样，各取所需嘛。但是，前几天 probonopd 又在这个 PR 下面回复了，这次的言论可谓是极致的” 阴阳怪气 “：
谁决定了社区不采用我的 AppImage ，有证据吗？
你说 AppImage 不是 OBS 社区构思开发的，那我看看你们的 Flatpak 打包是谁引入的，我猜是红帽或者 Gnome 社区呢，毕竟你们还引入了红帽的 Flatpak、Wayland、Pipewire 技术。
这应该跟红帽给你们捐了一万美金这件事没什么关系吧，嗯嗯，肯定没关系的。
这番怪怪的言论暗指 OBS 社区见钱眼开，对捐款公司的技术提供大力支持，而对自己的 AppImage 爱搭不理。这番话彻底把 OBS 社区的开发者激怒了，管理者贝思克更是直接在 OBS 项目中封杀了 probonopd：
禁止 probonopd 和他密切相关的 AppImage 开发者进入 OBS 项目，只要他负责这个项目，我们就不会直接与他或他团队中的任何人合作。因为他带来的只有骚扰，对我们遇到的技术问题没有任何有价值的建议或者帮助。
但是不会有人会因提及 AppImage 或提出 AppImage 构建需求而被 OBS 项目和社区排斥。也不排除未来某个时候 OBS 社区会支持 AppImage 包，只要有足够的用户需求，和愿意为之努力的开发者。
这里禁止的是人，而不是技术。
开源是梦想消亡的地方
2025年2月，拜读了《辞去 Asahi Linux 项目负责人》这篇文章，感触颇深。又一位才华横溢的开发者因维护开源软件的繁重需求而精疲力尽。
Hector Martin (marcan) 花了数年时间将 Linux 移植到 Apple Silicon 上 —— 这是一项令人难以置信的技术成就 —— 最终却因疲惫和幻灭而选择离开。
这样的故事在开源领域以令人沮丧的频率重复上演。充满热情的开发者创造了有价值的东西，免费与世界分享，然后看着他们的礼物变成吞噬他们生活的负担。最初的热爱逐渐转变为无偿的技术支持。用户提交错误报告时，仿佛他们是付费客户，要求立即修复和新功能，而自己却毫无贡献。Asahi Linux 团队在没有文档的情况下逆向工程了 Apple 的复杂硬件 —— 在企业环境中，这一壮举可能需要花费数百万美元 —— 然而，当用户的特定外设无法完美工作时，他们却抱怨不已。
开源的经济模式从根本上就是破碎的。大多数维护者从未因他们的努力获得一分钱，尽管他们创造的软件支撑着价值数十亿美元的公司和关键基础设施。少数通过赞助实现财务可持续性的开发者只是极少数，他们是 “精英中的精英”，其项目要么达到了极高的知名度，要么满足了关键的行业需求。
对于其他人来说，开源变成了一种单向关系：只有付出，几乎没有回报。你牺牲晚上和周末的时间来维护软件，而用户却将你的志愿工作视为理所当然。源源不断的需求逐渐侵蚀了启动项目的热情。最终，维护项目感觉像是一份无薪的第二职业，而不是一种充实的爱好。Marcan 的辞职并不是性格或承诺的失败 —— 而是一个系统可预见的结局，这个系统从维护者身上榨取价值，直到他们崩溃。他的故事应该成为对 “免费” 软件真实成本的警示。每个开源项目背后都是一个时间和精力有限的人，他们通常在没有报酬或认可的情况下工作。
除非我们从根本上改变对开源工作的价值认知和支持方式，这些项目将继续成为梦想破灭的地方 —— 在用户理所当然的要求、不可持续的经济模式以及随之而来的不可避免的倦怠中崩溃。幸运的是，并非一切都是坏的；GitHub 正在通过其赞助计划推动更多的赞助。Sentry 也有一个类似的项目，名为 “Open Source Pledge”。希望更多的公司能够效仿并支持开源社区，现在是时候回馈那些让开源成为可能的人了。