LibreOffice 内斗升级：当基金会把核心开发者“请出门”，开源治理正走到危险边缘
一场不只是“吵架”的风波
开源世界并不缺争执，但 LibreOffice 这次的风波，刺痛人的地方在于：被推到门外的，不是路人甲，也不是偶尔提提意见的旁观者，而是一批陪着项目走了十几年、手里真的写过海量代码的人。
事情的导火索，来自 LibreOffice 背后的基金会 The Document Foundation（TDF）。根据 Collabora 联合创始人、也是 LibreOffice 长期开发者 Michael Meeks 的公开表述，TDF 方面通过成员资格相关机制，移除了一批长期贡献者的成员身份，而这将直接影响他们在基金会治理中的投票权与参与权。换句话说，这不是论坛封号，也不是邮件列表拉黑，而是对开源项目“政治权利”的剥夺。
如果你平时不太关注 LibreOffice 社区，可能会觉得这不过是基金会内部的老戏码。但问题恰恰在于，LibreOffice 不是一个小众玩具项目。它是全球最重要的开源办公套件之一，是 Linux 发行版、政府采购、教育市场和企业私有化部署中的常客。它的治理出现裂痕，影响的不只是社区情绪，还会波及开发节奏、企业合作、生态稳定性，甚至影响人们对“基金会治理是否天然比公司治理更公正”的想象。
从“谁在写代码”到“谁在做决定”
Meeks 的文章里，有一组很有杀伤力的数据。过去这些年，TDF 董事会中拥有开发背景的人越来越少，企业背景的代表也明显下降。相反，与基金会内部工作人员关系更密切的席位比重却上升了。这种变化乍看只是组织结构调整，实际上却在重塑一个开源项目最敏感的权力平衡：做事的人，和拍板的人，正在慢慢变成两拨人。
这在开源项目里是件危险的事。因为代码不是 PPT，功能不是口号。翻译、市场、布道、社区运营当然都重要，但真正决定 LibreOffice 能不能修掉顽固 bug、能不能兼容复杂文档、能不能在企业场景里跑稳的，最后还是开发者。一个办公套件不是社交媒体应用，背后有几十年历史包袱、文件格式兼容、跨平台支持、渲染引擎、宏系统、企业部署等一整套复杂技术债。没有长期在代码里打滚的人，很容易低估决策的技术后果。
更微妙的是，TDF 的章程原本就强调 meritocracy，也就是“贡献驱动的话语权”。这其实是 LibreOffice 从 OpenOffice 历史中学来的教训。很多老资格开源人都记得，Sun、Oracle 时代的 OpenOffice 曾因决策与贡献脱节而让社区失望，最终才催生 LibreOffice 的独立。现在如果 LibreOffice 自己也走到“真正干活的人被排除在外”的局面，多少有点历史讽刺——像是项目逃离了上一场治理危机，最后又在另一种形式里重演。
被赶走的是谁，为什么这事格外刺眼
Meeks 在文中列出了一份 LibreOffice 核心代码仓库的历史提交排行榜。这个榜单很“程序员”，但也很残酷：上面排在前列的，大量是来自 Collabora 的开发者，比如 Caolán McNamara、Stephan Bergmann、Noel Grandin、Miklos Vajna 等人。有人提交数超过 3 万次，有人十几年如一日维护复杂模块。你未必记得他们的名字，但你每次顺利打开文档、导出 PDF、处理格式兼容问题时，很可能都在间接受益于这些人的劳动。
所以这次争议最刺眼的一点，不在于“基金会有没有权处理成员资格”，而在于它处理的对象，恰恰是这个项目技术地基的一部分。尤其当官方回应把担忧指向“有人可能出于雇主利益而非基金会利益做决定”时，争议就更尖锐了。因为在成熟的开源项目里，企业开发者并不是什么原罪。恰恰相反，Linux、Kubernetes、Python、GNOME、LLVM，几乎所有大型开源项目都离不开企业资助的全职贡献者。问题从来不是“你拿谁工资”，而是“你的治理机制能否约束利益冲突，同时保留专业能力”。
把企业背景开发者天然视为可疑对象，听上去很理想主义，实际常常会把项目推向另一种极端：嘴上讲社区独立，手上却削弱最稳定的开发供给。LibreOffice 这种复杂基础软件，靠热情当然能活，靠热情一个人扛 25 年、累计 3 万多次提交，那就是另一回事了。开源最迷人的地方，从来不是大家不食人间烟火，而是有人愿意长期、专业、可持续地把热爱变成生产力。
这场冲突背后，是开源基金会的老难题
如果把视角拉高一点看，TDF 的这场风波并不孤立，它暴露的是整个开源世界都在面对的一道难题：基金会到底是为了防止企业控制项目，还是为了让项目更有效地运转？这两个目标并不总是一致。
过去十几年，科技行业很喜欢把“基金会治理”包装成一种更中立、更透明、更民主的模式。听起来没毛病，现实却复杂得多。基金会确实可以避免单一公司一言堂，但它也可能形成另一种权力固化：程序上很民主，实际上很排他；口头上讲平等，结果最核心的专业意见反而被稀释。尤其当选举延期、成员资格审查、董事会构成变化这些问题叠在一起时，外界很容易质疑：这到底是在做治理净化，还是在做选举工程？
Meeks 甚至直接用了“gerrymandering”这个词，也就是“杰利蝾螈式划区操控”，借来形容对选民结构的改造。这个说法显然带着强烈立场，但它之所以有传播力，是因为它击中了一个朴素直觉：如果一个组织开始系统性减少潜在反对者的投票权，那无论理由包装得多么制度化，都会让人联想到权力自我保护。
这也是为什么这件事对整个开源行业都重要。今天是 LibreOffice，明天可能就是其他基金会项目。很多大型开源软件越来越依赖企业工程师、基金会工作人员、独立志愿者三方共存。一旦三者的权力分配失衡，项目就会在“谁更代表社区”这个问题上反复撕裂。而比撕裂更麻烦的是，外部用户往往看不到治理细节，他们只会在几年后看到另一个结果：版本变慢、人才流失、生态分叉、维护质量下滑。
LibreOffice 接下来会走向哪里
短期看，这场风波未必立刻把 LibreOffice 打散。LibreOffice 体量够大，代码库够深，企业用户和政府用户的惯性也够强，不会因为一次治理争议马上崩盘。Collabora 也明确表示会继续推进 Collabora Office，把代码清理、CI 流程和开发协作继续做下去。这意味着，至少在技术层面，主力开发资源并没有凭空消失。
但中长期风险已经浮出水面。最怕的不是公开争吵，而是“公开还在，合作没了”。一旦基金会与核心开发团队之间的信任被打穿，很多事情都会变得别扭：路线图协调更难，代码合并更敏感，商业支持与社区版本之间更容易出现缝隙。最糟糕的情况不是正式 fork，而是事实上的“软分叉”——同一个项目名义上还在一起，实际上开发重心、资源流向、话语体系已经各走各路。
对普通用户来说，这件事也给了一个不太浪漫但很现实的提醒：开源软件从来不只是代码仓库，它也是组织、投票、章程、会议纪要、预算和人际关系。你今天装上的一个免费办公软件，背后并不是自动运转的理想国，而是一群人长期维系出来的脆弱平衡。技术社区最怕的，往往不是 bug，而是把最懂 bug 的人弄得心灰意冷。
我更关心的一个问题是：当开源组织高举“平等”时，是否会不小心牺牲“专业”？这不是说非开发者不该有话语权，而是一个复杂技术项目必须承认，深度贡献本身就应当拥有更重的治理分量。如果所有人形式上都一样，最后常常不是更公平，而是更容易让真正负责交付的人失声。
开源圈喜欢说“community over code”，但更现实的表达也许是：没有持续写代码的人，社区终究会变成一块漂亮招牌。LibreOffice 现在面对的，正是这样一个拐点。