开源维护者的倦怠不是「不够自律」:一份关于无偿责任的结构分析

为什么这是一个值得认真对待的问题

开源软件构成了现代数字基础设施的大部分底层。从操作系统、Web 框架到加密库,大量被商业产品依赖的代码,由极少数人——有时是一个人——在业余时间无偿维护。这种结构在 Nadia Eghbal 为福特基金会撰写的报告《Roads and Bridges》(2016)中被概括为:公共数字基础设施像道路和桥梁一样被广泛使用,却几乎无人为其维护买单。

维护者的倦怠,正是在这种结构里反复发生的现象。它常被简化为个人问题——「注意劳逸结合」「多休息」。但这类建议回避了真正的来源:当责任是无偿的、工作量是无界的、而需求方又默认自己有权索取时,休息并不能解决问题,因为问题不在维护者的精力管理,而在关系的结构本身。

本文不提供安慰式的口号,而是尝试把这种倦怠的形成机制讲清楚,并在此基础上讨论个人层面可行——尽管有限——的应对。

「维护」是什么,以及它为何被低估

在公众认知里,开源贡献约等于「写代码」。但对一个有一定用户规模的项目而言,维护者的实际工作中,编写新功能往往只占很小一部分。更大的比例消耗在:回应 issue、审查他人提交的 pull request、回答重复问题、撰写与更新文档、处理安全报告、协调版本发布、调解社区争论。

这些工作有几个共同特征,使它们格外消耗人:

• 它们大多不可见。 一次漂亮的重构会被看见,而连续三小时礼貌地关闭重复 issue 不会。维护工作的产出常常是「什么坏事没有发生」,这种价值天然难以被外部感知,也难以被自己感知为成就。
• 它们是被动触发的。 维护者无法决定今天有多少 issue 涌入、多少是合理的、多少是无理的。工作节奏被外部需求定义,而非自己。
• 它们没有终点。 软件只要还在被使用,issue 就不会归零。这与有明确交付和结束的项目制工作有本质区别。

当一项工作既不可见、又被动、又无尽时,它对人的消耗方式不同于普通的「忙」。它更接近一种持续的、无法清空的待办压力。

三股力量如何叠加成倦怠

倦怠并非单一原因造成,而是几股力量长期叠加的结果。把它们拆开看,有助于理解为什么「休息」往往无效。

无偿的责任感

大多数维护者并未与任何人签订维护合同。他们最初只是分享了一段对自己有用的代码。但一旦项目被广泛依赖,一种隐性的责任感就会形成——「这么多人在用,如果我不修,就会出问题」。这种责任是真实的、却又是无偿和单方面的:维护者承担了类似职业义务的心理负担,却没有职业应有的报酬、边界和退出机制。

关键在于,这种责任感往往来自维护者自身的尽责,而非外部强制。这使它更难卸下——放手会触发内疚,而内疚比工作量本身更消耗人。

无尽的 issue 流

issue 列表是一个永远不会清空的队列。它的特殊之处在于,关闭一个 issue 并不会减少未来 issue 的产生速率;项目越成功、用户越多,流入越快。于是维护者面对的是一个结构上无法「完成」的任务。

心理学中关于倦怠的研究通常将其描述为三个维度:情绪耗竭、去人格化(对服务对象变得冷漠疏离)、个人成就感降低(参见 Maslach 等人提出的倦怠模型)。一个永远清不完、又看不到尽头的队列,几乎精准地命中前两个维度——耗竭来自工作量,疏离来自对源源不断的请求逐渐失去耐心。

用户的索取姿态

第三股力量最隐蔽,也最伤人。部分用户——尤其是把开源软件当作免费商业服务来用的一方——会以客户对供应商的姿态提出要求:催促修复、质问进度、对免费的工作表达不满,甚至带有攻击性。

这里存在一个根本的预期错位:用户感知到的是一个「产品」,而提供方实际上是一个没有报酬、没有义务的个人。当索取者的姿态与给予者的处境不匹配时,每一次互动都会留下情绪残余。GitHub 在 2017 年的开源调查中曾指出,负面互动虽然不算高频,但其影响不成比例——少数恶劣的交流足以让维护者考虑退出。这一点值得强调:倦怠不总是被工作量压垮,有时是被为数不多却反复出现的敌意消磨掉的。

为什么「多休息」是错的处方

把维护者倦怠归为个人精力管理问题,在逻辑上是错位的。休息能缓解的是疲劳,而倦怠的核心是关系的不对等与意义的流失。一个充分休息的人,回到一个责任无偿、需求无界、索取无礼的环境里,只会更快地再次倦怠。

这意味着,真正有效的应对必须作用在结构上——重新定义维护者与项目、与用户之间的关系。个人能改变的部分有限(结构性的资金问题需要行业和企业层面的解决),但并非为零。以下几类做法,指向的不是「更努力地坚持」,而是重新设定边界与降低维护的固有成本。

个人层面可行的边界设定

需要先承认局限:以下做法无法解决资金缺位这一根本问题,也不适用于所有项目。它们的目标是把不可持续的维护方式,改造成可以长期承受的方式。

第一,明确并公示项目的承诺边界。 在 README 或专门文档中清楚说明:这是什么、不承诺什么、维护投入大致是多少、不接受哪类请求。把隐性的、被假定的义务变成显性的、被声明的边界。这不解决工作量,但能改变用户的预期起点,减少错位带来的摩擦。

第二,把「无回应」正当化。 维护者没有义务回应每一个 issue,也没有义务为每一次催促道歉。设定明确的响应原则(例如:不保证响应时间、超出范围的请求直接关闭并附模板说明),并且不为执行这些原则感到内疚。内疚是责任感的副产品,而过度的责任感正是倦怠的燃料之一。

第三,降低维护的固有成本。 用自动化承接重复劳动:issue 与 PR 模板、自动化测试与 CI、机器人处理陈旧条目、常见问题的标准回复。这类投入的意义不只是省时间,更是把「被动应对」转化为「预先设定规则」,从而夺回一部分对节奏的控制权。

第四,主动构建治理结构,而非独自承担。 单一维护者(所谓「bus factor 为 1」)是项目最脆弱也最易倦怠的状态。引入共同维护者、明确决策与权限、建立可以委托的流程,既是项目可持续性的保障,也是个人卸载责任的途径。这一步往往最难,因为它要求维护者放弃部分控制——但拒绝放权,本身就是倦怠的一种成因。

第五,允许项目进入低维护或归档状态。 不是每个项目都必须永远活跃。明确标注「仅维护安全更新」「不再积极开发」「寻求新维护者」「已归档」,都是诚实且负责任的选择。把项目的生命周期说清楚,远比沉默地、内疚地拖着它更健康——对维护者和用户都是。

结论:这是结构问题,但个人并非无能为力

开源维护者的倦怠,本质上是一种结构性失衡的产物:社会与商业世界从开源中获取了巨大价值,却几乎没有为其维护建立对应的报酬与保护机制。在这个层面,真正的解决方案属于企业赞助、基金会资助和行业规范,超出个人所能掌控。

但在等待结构改变的同时,个人并非完全被动。可以做的,不是「更努力、更自律地坚持」,而是重新谈判自己与项目、与用户之间的关系:把隐性责任显性化,把无界需求边界化,把独自承担结构化。这些做法不会让维护变得轻松,但能让它从一种逐渐侵蚀人的消耗,变回一件可以长期、有尊严地做下去的事。

承认局限是这份判断的前提:边界设定缓解的是关系的不对等,无法填补资金的缺口。但在两者之间,维护者至少可以先停止用自己的健康,去补贴一个本不该由个人独自承担的系统。