FOSS乌托邦与现实的距离

我见到和使用的所有优秀的开源项目，要么是由大型企业/组织牵头进行开发的，要么九成以上的代码都是由高水平的单一开发者编写的。这些项目与其说是开源，实际上更像是“公开源代码”，因为外部人员难以介入主要的开发流程。在“大教堂”与“集市”的对立中，这些项目显然更偏向“大教堂”那一方，尽管它们确实披着“开源”的皮。

我见到的那些广泛吸纳外部开发人员的开源项目，大多数人都可以在开发过程中插一脚的项目，普遍是垃圾箱起火级别的灾难。这些是真正的“开源”，在“大教堂”与“集市”的对立中，显然属于“集市”的那一方。

有了上述经验，就很难不对“集市”模式的实践产生意见。软件行业的现状已经证明了，“集市”模式并不适合大多数软件项目。

扪心自问，你维护过几个开源项目的分叉？你的分叉能够跟踪上游的进度吗？

大多数由个人/小型组织维护的分叉项目会在一小段密集提交之后变成一处遗迹：

即使对于因意见分裂而产生的，由原开发团队的部分成员所维护的大型分叉，往往也很难持续。证据是再显而易见不过的：市面上并没有几个软件在出现大型分叉后成功维持住并行开发的局面——不需要多长时间，就会有一方胜出。那极少数能够维持住并行开发的大型分叉，要么其上游是一个几乎不添加新功能的成熟项目，要么彻底脱离了对上游的依赖。

项目的主要维护者和“互联网上的随机外人”对项目的了解程度有天壤之别：若要写出“正确的代码”或者“战略编程”级别的代码，后者需要花费很多时间和努力来增进自己对项目的了解。遗憾的是大多数贡献者并不具备这种等级的开源精神或客观条件。

开源项目的维护者需要审查“互联网上的随机外人”发送来的拉取请求，然后有很高的概率发现大部分拉取请求是不能直接合并的。一个项目越是容易吸引低水平的开发者，就越是容易遇到这种拉取请求。无论是引导外部贡献者将代码改写以使其达到可以合并的状态，还是由维护者亲自上阵将改写代码，都需要投入时间和精力。构建在开源理念之上的沟通和反馈循环通常效率极为低下，以至于在很多时候都不匹配为之付出的努力，维护者值得把时间花在更有效率的地方。

外部贡献者和开发团队的目标之间存在差异是很普遍的现象，很多项目因此不需要功能层面的外部贡献。

对于开发团队真正关心的功能，官方实现往往又快又好。对于他们并不真正关心的功能，功能请求会在沉寂一段时间后被机器人关闭，拉取请求会石沉大海。或者更糟，一个匆忙的实现被合并，变成了软件的安全漏洞，在多次修复尝试之后仍在后续版本里回归，反正最后难逃被删除的命运。

如何在维护开源项目的同时保持优雅？优质解答：我不知道。

影响最深远的开源项目领导者Linus Torvalds恐怕也不知道。考虑到他管理的项目具有相当高的准入门槛，以至于像我这种小角色甚至不会考虑去做出贡献，他履行自己职务所需的能力已是常人难以想象的。即使在这些高门槛项目里，在信息传达到Linus眼前已经过多层过滤的情况下，Linus有时也会表现得刻薄残酷，在批评时极尽讥讽和侮辱——这种现象严重到以至于欣赏这些情绪宣泄已经变成一种乐趣。有相当比例的开发人员对Linus的情绪化持正面看法，乃至将其视作Linus良好声誉的重要组成部分（一定程度上是因为这些信息更有传播潜力），因为一个不存在Linus这类技术独裁者的世界相当容易想象：我们不会得到现在这种质量的软件，一切只会比现在更糟。对于管理者以外的人来说情况也类似，开源社区不是夸夸群，效率较高的交流方式往往是有毒的。

世界上确实存在着一些超人，能够在任何情况下保持心平气和，圆滑地处理好一切，我将之归功于天赋或药物。因为假如这种能力是可以传授的，或至少可以通过修行取得的，那么应该早就推广开了，毕竟世界上应该有很多人想要这种情绪控制能力。与此同时还应该注意到，这些超人很少处于技术领域的顶点——技术领域的顶点基本上是由充满毒性的自大狂所占据的，你看到的这些人之间的区别主要取决于公关实力的高低。这种相关性将我们引导向一个无法证明，但又似乎客观存在的规律：良好的开源精神和良好的精神状态就像鱼和熊掌般不可兼得。

除非你已经站在自身领域的巅峰圈层，不然你总有机会见识比你厉害的人：懂得比你多，想得比你深，做得比你好。最差的工程师与最好的工程师之间的差距不能以“10x工程师”来简单概括。在细分领域下，伴随着经验和专业知识的差距，工程师之间的差距可能远大于十倍。

仅就开源运动而言，有一种简单方式来分类具有不同技能水平的工程师：

然而，在开源社区里，缺乏自知之明的假工程师就好像是为了验证邓宁-克鲁格效应一样普遍存在。这些麻烦制造者往往还热衷于赚取“社交积分”，偏好留下缺乏有效信息量的文字，以及为了作出贡献而作出贡献。两类工程师之间实际夹着一个过渡阶段，被称作冒名顶替综合征，这些人往往不参与开源项目，反而危害性很小。

开源中最令人恼火的部分是，能被独立解决的错误、问题、误会，因为技能水平的差异而从假工程师身上错误地转嫁给真工程师。这纯粹是浪费后者的时间。若是人能做到首先怀疑自己，行事保持细心谨慎，那么即使在技能水平上有差异，大多数此类情况也应该是可以避免的。悲哀的是，这些本应成为基本素养的东西，实际上较为稀缺，而开源运动缺乏把假工程师拦在外面的有效手段。

不论你是否承认，但自由软件和开源软件这些概念在面向终端用户时，意义基本上相同——它们是“免费、安全的软件”的替代词汇。

“不付出就能有回报”在营销层面具有非常强的效果，大多数人无力招架这种诱惑。最典型的例子发生在游戏行业（同时也是软件业的一部分），最赚钱的游戏是所谓的“免费游戏”。问问自己这个问题，如果它不是免费的，你仍然会选择它吗？

有相当比例的“开源项目”，其“开源”标签作为广告的价值要远远大于“开源”作为模式的价值。这些人要么清楚地认识到这些项目一旦脱离原始开发团队就难以存续，只将开源作为领先竞争对手的一种营销手段；要么干脆使用自己定义的“开源许可证”，当一个“开源项目”不使用常见许可证时，不难想象其中的猫腻；一些原本开源的项目在更换为非开源许可证后，继续以开源名义混淆视听，你就知道“开源”二字的营销价值所在。

在人工智能领域，甚至“开放权重”现在也被称作“开源”。就像“源代码可读”不是开源一样，“开放权重”也不是开源。能从这种随意拓宽语义的胡言乱语中受益的只有那些指望将开源作为广告的人。

开源软件的丑陋一面经常被浮于表面的“免费”所掩盖。天下没有免费的午餐，学习、理解、利用、贡献开源软件都是有成本的。由于开源软件的文档更稀疏，纠错和获得支持严重依赖于社区，普遍存在没有经过实战检验的代码等问题，开源软件实际上经常产生意料之外的成本。当你决定依赖一个开源项目时，你就已经在承受这些成本。

开源软件唯一免费的部分在于维护者出于理想和使命感的自我奴役，而这很容易导向更大的崩溃。一个暂时运转良好的开源软件，并不意味着在未来也运转良好。维护者可能厌倦，放弃，失去维护的能力，能力不足，甚至只是突发恶疾决定毁掉原来还不错的项目。因此使用开源软件不仅有成本，还需要承担风险。商业软件由于显而易见的利益驱动，反而使其比开源软件有保障。

“但是开源维护者不欠你任何东西！”——希望当你因为供应链攻击和安全漏洞蒙受损失时仍然能自信地说出这句话。即使只是施舍的粥，往里面撒尿也是不可原谅的。人们对开源软件的盲目信任和滥用创造了太多往粥里掺尿的机会，导致任何一个使用外部依赖的软件都可能因此意外间接引入有问题的依赖项，从而祸害到依赖链条下游的所有人。这种信任危机从根本上增加了所有人继续使用开源软件的成本，到最后，所有原本轻快的东西都会因为一些不知道从哪里钻出来的“试图解决问题”的人的安全作秀而套上沉重的枷锁。

LLM的滥用让FOSS原本就存在的问题彻底且集中地爆发。如果说之前的开源软件尚且还留有一些利用价值，那么如今的开源软件已经完全失去了这种价值：通过代码来判断作者的技能水平和对问题域的了解的成本已经变得太高了。尤其是在2025年11月后发布的代码，已不再值得哪怕一秒钟的认真对待，只有把它们全都视作是垃圾来处理才有效率可言。

在我看来，FOSS已经名存实亡，社区的唯一出路是创建一个新的品牌，把那些仍然尊重代码质量的人团结在新的旗帜下——这还得是建立在这些人有能力战胜LLM编程导致的新一代worse is better的前提下。

直到LLM因为新的训练数据只剩下垃圾而模型崩溃之前，我认为FOSS社区没有翻身的机会。他们能做的最好的选择就是认可LLM生成的代码的价值，然后假装一切仍然顺利，最后像苏联一样在静默与窒息中消亡。