一份 49 页的开源倦怠报告，最刺眼的不是“开发者很累”。这件事，写过代码的人大多不陌生。

刺眼的是账本。

JetBrains 2023 年调查里，73% 开发者说自己职业生涯中经历过倦怠。Tidelift 2024 年对 400 多名开源维护者的调查显示，60% 考虑过离开开源，60% 没有任何报酬。

很多公司每天跑在开源基础设施上。维护这些基础设施的人，却常常靠下班后的时间、责任感和一点不愿放手的良心继续撑着。

这才是报告真正戳中的地方：开源不是没有成本，只是成本被推给了最不该兜底的人。

报告把倦怠拆成六个诱因

报告由 Miranda Heath 撰写，资金来自 Sentry 的 Open Source Pledge。方法要说清楚：它不是一项精确测量 OSS 倦怠率的大型统计研究。

它做的是快速文献综述、57 份开源社区材料的主题分析，以及 7 位社区成员的深度咨询。

所以，它的价值不在于“算出一个全行业倦怠率”。它更像一次问题归档：把开源社区里反复出现的疲惫、愤怒和离场冲动，放到同一张桌上。

问题报告给出的要点
倦怠是什么身心能量耗竭，表现为动力下降、情绪枯竭、疏离和犬儒
证据来自哪里软件开发者研究、开源社区文章/演讲/讨论、少量社区咨询
六个诱因难以获得报酬、工作量和时间投入、维护工作缺乏成就感、社区毒性行为、过度责任、证明自己的压力
四条建议支付开源开发者、建立认可与尊重文化、扩大社区、为维护者发声

这些诱因会互相放大。

没报酬，维护者就容易变成“双班制”：白天上班，晚上修 issue。用户越多，维护越像客服和消防。社区越粗暴，成就感越薄。

一个原本因为兴趣开始的项目，最后变成一份没人签合同、没人付工资、但所有人都默认你应该在线的工作。

这不是个体心理脆弱。很多时候，是工作设计本身坏了。

真正的错配：公司拿收益，个人扛责任

我不太买账一种轻飘飘的说法：开源嘛，自愿参与，累了可以退出。

话没错，但只说了一半。

真正的问题是收益和责任严重错配。

“天下熙熙，皆为利来。”放到开源基础设施上，常常变成：利来到公司，责留给个人。企业拿开源做产品、降成本、提效率，甚至支撑融资叙事；维护者面对的是漏洞、兼容性、破坏性更新、用户抱怨和道德压力。

这不是说所有开源维护者都是无偿受害者。也不是否认赞助、基金会和商业化路径的成功案例。

限制也要讲清楚：报告本身不能证明每个开源项目都处在高危状态。开源生态差异很大，有些项目治理成熟，有些项目有稳定资金，有些维护者本来就不追求商业回报。

但结构性风险已经很清楚：关键依赖越像基础设施，越不能长期靠个人燃烧维持。

对不同人，动作也不一样。

相关人群这件事意味着什么更现实的动作
开源维护者和开发者不能把“永远响应”当成默认义务写清维护边界、降低无偿支持承诺、把赞助入口和治理规则前置
依赖开源的技术管理者不能只看 license、star 和 commit做依赖清单，标出关键库维护风险，把赞助、采购支持或替代方案写进预算

这张表不浪漫，但很必要。

维护者要学会把边界写出来。哪些问题不免费支持，哪些版本不再维护，安全漏洞如何响应，商业用户该走什么渠道，都应该明示。

技术管理者也别把开源当“天然免费的供应商”。如果一个关键库只靠一两个人维护，而你的业务每天都在调用它，那就不是社区风险，是你的工程风险。

要看的不是口号，是钱有没有进账本

报告提出“付钱、尊重、扩社区、替维护者发声”。听起来朴素，甚至有点老生常谈。

但老生常谈往往说明一件事：问题不复杂，难的是谁愿意结账。

接下来最该观察的变量，其实就两个。

一个是企业会不会把开源支持从“公益赞助”挪到“基础设施预算”。如果还停留在零散打赏、年底捐一笔、营销时发个声明，那就只是买心安。

另一个是技术团队会不会把维护者风险纳入依赖评估。比如关键库有没有多名活跃维护者，issue 是否长期堆积，安全响应是否明确，项目是否有资金入口和治理机制。

这些动作不华丽，但能改变结果。

历史上，铁路、电网、道路这些基础设施，都经历过从英雄式建设到制度化维护的过程。开源不完全一样，它更分布式、更自由，也更难治理。

相似的是另一件事：当基础设施足够重要，热情就不再够用。

软件行业过去很擅长享受开源红利。更少认真处理红利背后的维护成本。

开源精神不该被嘲讽。它确实创造了现代软件世界最慷慨的一部分。

但慷慨不能被默认成无限供给。维护者不是云服务，不会因为调用量上升就自动扩容。

这份报告对技术管理者的提醒很直接：别只问项目能不能用。还要问，它还能不能被人继续维护。

对维护者的提醒也同样直接：边界不是背叛开源。边界是让项目活久一点的条件。

开头那组数字真正说明的，不是开源快完了。恰恰相反，是开源太重要了，重要到不能再靠少数人的疲惫来兜底。