2022年1月9日，周末。全球无数开发者的终端突然开始疯狂输出乱码——每一个使用colors.js或faker.js的项目都中招了。这两个npm包每周下载量超过2000万次，被数以万计的企业级应用依赖。它们的维护者Marak Squires做了一件震惊社区的事：他故意在代码中植入无限循环，让所有使用这些库的应用崩溃。
这不是黑客攻击，也不是供应链入侵。这是抗议。Marak长期以来对开源维护者缺乏经济支持感到沮丧，在GitHub上公开表达了他的不满。在此之前，他曾因开源项目被商业公司无偿使用而发起争议，最终导致他的GitHub账号被封禁。
这个事件撕开了开源世界的一道口子。它揭示了一个被忽视已久的结构性问题：维护着全球软件基础设施的人们，正在以惊人的速度倦怠。
一组令人不安的数据
Tidelift在2024年发布了一份面向400多名开源维护者的调查报告，数字令人震惊：
- 60%的维护者没有获得任何报酬
- 60%曾经退出或考虑退出维护工作
- 44%认为开源维护给他们的生活带来了压力
- 43%感到自己被低估
这不是个例。2023年Intel的开源社区调查显示，45%的受访者将"维护者倦怠"列为最大挑战。2024年GitHub的调查显示，64.23%的开发者经历过或目睹过负面交互。
更深层的问题是维护者群体的老龄化。Tidelift的调查发现，45%的维护者已经在这个角色上工作了超过10年。与此同时，只有7%的维护者经验在1-2年，仅有2%不足一年。老一代维护者在老去，但新一代不愿接棒。
为什么？答案藏在另一个数字里：平均每位无报酬维护者每周工作8.8小时，热门项目的维护者则可能达到20-30小时。这是一份兼职工作的工作量，但报酬为零。
倦怠是什么：从心理学定义到开源场景
“倦怠”（Burnout）这个词被过度使用了，以至于人们常常忘记它是一个严格的心理学概念。1981年，Christina Maslach开发的Maslach倦怠量表（MBI）将其定义为三个维度：
情绪耗竭（Emotional Exhaustion）：感觉被掏空，没有精力，对工作产生厌倦。这是倦怠的核心维度，通常最先出现。
去人格化（Depersonalization）：对工作对象产生冷漠、愤世嫉俗甚至敌对的态度。在开源场景中，表现为对用户请求的不耐烦、对社区的疏离感。
个人成就感降低（Reduced Personal Accomplishment）：对自己的工作价值产生怀疑，感到无能和失败。
卡内基梅隆大学2020年发表在ICSE-NIER的研究首次将这个框架应用于开源社区。研究者发现，开源维护者的倦怠有其独特的驱动因素：
高频率的需求压力：bug报告、功能请求、文档改进、安全漏洞——这些请求源源不断。一个热门项目每天可能收到数十个issue。
有毒交互：用户以命令的口吻提出需求，对延迟响应表示不满，甚至进行人身攻击。研究者开发了一个分类器来检测GitHub issue中的有毒评论，发现大约每1000个issue中有6个包含明显的有毒内容。这个数字看起来很小，但考虑到维护者的心理状态，一次有毒交互的影响可能持续数天。
可见性带来的压力：GitHub上的所有讨论都是公开的。错误会被看见，会被截图传播，会影响维护者的职业声誉。这种透明度是一把双刃剑。
无边界的工作：没有工作时间，没有下班概念。issue会出现在深夜的邮箱里，周末的通知栏里。Anthony Fu在他的博客中写道：“GitHub通知是一个持续不断的负面信息流……阅读这些内容在精神和情感上都是消耗。”
经济悖论：8.8万亿美元与零报酬
2024年，哈佛商学院发布了一项关于开源软件经济价值的研究。结论是：广泛使用的开源软件的需求侧价值约为8.8万亿美元。如果这些软件需要从头开发，企业将不得不支付这笔天文数字。
讽刺的是，同一研究表明，开源软件的供给侧价值——即开发者实际获得的报酬——仅为41.5亿美元。
8.8万亿对41.5亿。两个数字之间差了三个数量级。
这就是开源的核心经济悖论：用户价值巨大，创造者价值为零。
Log4j事件是这种悖论的极端体现。2021年12月，这个被广泛使用的Java日志库被发现存在一个严重的远程代码执行漏洞。漏洞的影响范围之大，让美国网络安全与基础设施安全局局长Jen Easterly称之为"我见过的最严重的漏洞之一"。
然而，维护这个被数十亿设备依赖的项目的团队有多少人？16名无报酬的志愿者。
漏洞披露后，项目成员Volkan Yazici在Twitter上表示维护者们正在"无眠不休地工作"来应对危机。项目领导者Ralph Goers在修复漏洞的同时，需要处理来自全球的压力和批评。而他的赞助者数量？三个。总金额？几乎为零。
这不是孤例。2018年，ua-parser-js的维护者因为不堪重负而退出，将项目转交给了一个陌生人。这个陌生人随后在代码中植入恶意程序来窃取加密货币。尽管这个项目被无数大公司使用，它的资金池里只有41.61美元。
XZ后门：倦怠成为安全漏洞
2024年3月，微软工程师Andres Freund发现了一个令人脊背发凉的漏洞：XZ Utils——一个被几乎所有Linux发行版使用的压缩工具——被植入了后门。
调查结果揭示了一个精心策划的社会工程攻击：攻击者使用化名"Jia Tan"，花了近两年时间成为XZ Utils的可信贡献者。他提交代码、修复bug、回应issue、耐心建立信任。当原来的维护者因为倦怠和健康问题逐渐减少参与时，Jia Tan自然而然地接过了维护权限。
然后，他植入了后门。
这个案例揭示了一个被忽视的安全风险：维护者倦怠本身就是一种漏洞。当一个项目只有一两个疲惫不堪的维护者时，社会工程攻击的成功率会大大提高。攻击者只需要提供一点帮助，表现出一点善意，就能获得信任。
XZ事件后，Commonhaus Foundation等组织开始推动新的治理模式，旨在保护单人维护者免受倦怠和安全风险的影响。但这只是杯水车薪。
说"不"的代价
许多维护者最终学会了一项关键技能：说"不"。
Jeff Geerling在2020年发表了一篇题为《作为开源维护者说"不"》的博客文章。他描述了自己如何从一个试图回应每一个请求的热情贡献者，变成一个学会拒绝的人。他的策略包括：关闭低质量issue、拒绝过于宽泛的功能请求、限制自己的工作时间。
但说"不"是有代价的。用户会抱怨，会批评，会说"如果你不想维护，为什么不把项目交给别人？"
这种批评忽略了一个关键问题：把项目交给谁？
开源项目的维护权不是简单的交接。新维护者需要对代码库有深入理解，需要获得社区的信任，需要有时间投入。对于复杂项目，培养一个合格的维护者可能需要数年时间。而在这个过程中，老维护者已经被倦怠消耗殆尽。
Mike McQuaid在《开源中的权利感》一文中指出：“用户开始向维护者提出要求。他们表现出一种权利感，仿佛维护者欠他们什么。“这种权利感——entitlement——是倦怠的重要催化剂。
结构性困境：免费劳动的制度化
开源倦怠不仅是个体问题，更是结构性问题。
传统雇佣关系中，雇主和雇员之间存在明确的契约：工作换取报酬，加班换取加班费，额外贡献换取晋升。开源世界中，这种契约不存在。
软件工程师Kyle Rankin在博客中写道：“开源维护者本质上是大公司的无报酬外包团队。“这个说法可能有争议，但揭示了核心问题：企业从开源中获益，却不需要为维护成本买单。
这是典型的"公地悲剧”。每个公司都希望开源项目有人维护，但每个公司都希望别人来做这件事。结果是：每个人都免费搭车，没有人付费乘车。
2024年的调查数据显示，在约3亿家使用开源软件的公司中，只有约4200家参与了GitHub Sponsors。这意味着99.999%的公司在免费使用开源软件。
解决方案的探索
开源社区并非没有意识到这些问题。近年来，多种解决方案被提出和尝试：
GitHub Sponsors：GitHub在2019年推出的赞助平台，让用户可以直接资助维护者。2024年的数据显示，参与赞助的公司数量增长了20%，但绝对数字仍然微不足道。
Tidelift：这是一个订阅制服务，企业付费订阅后，资金会分配给参与计划的维护者。Tidelift宣称，其平台上收入最高的维护者已经达到了六位数年薪。但参与维护者的数量仍然有限。
Open Source Pledge：2024年由Sentry等公司发起的倡议，要求成员企业每年为每位全职开发者支付至少2000美元给开源维护者。截至2024年底，已有20多家公司加入，累计承诺金额超过130万美元。这是一个好的开始，但距离解决问题还很远。
企业雇佣：一些公司选择直接雇佣关键项目的维护者。Google、Microsoft、Red Hat等公司都有开源维护者岗位。Filippo Valsorda从Google离职后，成功转型为独立维护者，通过六个客户的赞助获得了与Google相当的薪酬。但这种模式需要维护者具备相当的知名度和谈判能力。
个人层面的应对
对于正在经历倦怠的维护者，开源社区也提供了一些建议：
设定边界：关闭推送通知，固定时间处理issue，不要让开源工作侵占生活。Anthony Fu建议"主动检查"而非"被动接收”：不要等通知推送过来，而是选择自己状态好的时候主动去查看。
降低期望：接受自己不能解决所有问题。开源软件是"按原样提供”（as-is）的，维护者没有义务满足每一个需求。GitHub官方的维护指南建议维护者明确这一点，并在README中说明响应时间预期。
培养社区：寻找合作者，分担工作。但这对单人项目来说很难——没有资源就很难吸引贡献者，没有贡献者就更难获得资源。
暂时离开：有时候，休息是唯一的选择。许多维护者在经历倦怠后选择暂停数周甚至数月，然后再回来。但这需要心理准备：离开期间，issue会堆积，用户会抱怨。
我们能否改变？
开源倦怠问题有解吗？答案取决于我们是否愿意改变。
对于企业：如果你使用开源软件，请考虑赞助维护者。Open Source Pledge的2000美元/开发者/年的门槛并不高，但它代表了态度的转变。如果你的公司依赖某个特定项目，考虑直接雇佣其维护者。
对于开发者：在提交issue之前，检查是否已有相同issue。在请求功能之前，考虑这是否是项目方向的一部分。在抱怨响应速度之前，想想维护者是在用业余时间免费工作。如果你有能力，考虑成为贡献者而非仅仅是用户。
对于维护者：学会说不。设定边界。你的心理健康比项目更重要。开源是马拉松，不是短跑——可持续的节奏比爆发式的产出更有价值。
尾声
开源软件已经成为数字世界的基础设施。从运行互联网的服务器操作系统，到你手机里的应用程序，开源无处不在。哈佛的研究告诉我们，这份基础设施价值8.8万亿美元。
但基础设施需要人维护。当维护者倦怠、退出、甚至恶意破坏时，整座大厦都会动摇。colors.js事件让数万个项目崩溃，Log4j漏洞让全球安全团队彻夜无眠，XZ后门几乎攻破了Linux的安全防线。
这些不是偶然事件。它们是结构性问题的症状。
开源的先驱们在几十年前设计这套模式时，可能没有预料到今天的局面。那时候，开源是理想主义的实验，是黑客文化的延伸。今天，开源是全球经济的支柱，是国家安全的关键。
但规则没有改变。维护者们仍然在用自己的时间、精力和健康，支撑着这个庞大的体系。60%的维护者没有报酬，60%曾经考虑退出。这个数字不应该被接受。
开源的未来，取决于我们是否能找到一种新的契约——一种让创造者与使用者之间的价值分配更加公平的契约。这不是慈善，这是可持续性。这是为了确保，当我们需要开源软件的时候，还有人愿意、并且有能力维护它。
参考文献
- Tidelift. (2024). The 2024 Tidelift State of the Open Source Maintainer Survey.
- Harvard Business School. (2024). The Value of Open Source Software.
- Raman, N., Cao, M., Tsvetkov, Y., Kästner, C., & Vasilescu, B. (2020). Stress and Burnout in Open Source: Toward Finding, Understanding, and Mitigating Unhealthy Interactions. ICSE-NIER'20.
- Maslach, C., & Jackson, S. E. (1981). The Maslach Burnout Inventory.
- MIT Technology Review. (2021). The internet runs on free open-source software. Who pays to fix it?
- Anthony Fu. (2024). Mental Health in Open Source.
- Open Source Pledge. (2024). Burnout in Open Source: A Structural Problem We Can Fix Together.
- Intel. (2024). Maintainer Burnout is a Problem. So, What Are We Going to Do About It?
- GitHub. (2024). Maintaining Balance for Open Source Maintainers.
- WIRED. (2024). The Mystery of ‘Jia Tan,’ the XZ Backdoor Mastermind.
- SonarSource. (2023). Maintainer burnout is real. Almost 60% of maintainers have quit or considered quitting.
- The Register. (2024). Open source maintainers underpaid, swamped by security, going gray.
- Mike McQuaid. (2022). Entitlement in Open Source.
- Jeff Geerling. (2020). Saying ‘No’ to burnout as an open source maintainer.
- jlowin. (2025). An Open-Source Maintainer’s Guide to Saying No.