开源项目的维护者疲劳：贡献越多，负担越重

一个公开项目的代码库看起来热闹：提案不断、问题单增加、贡献者名单变长。但把时间轴拉长会发现，真正决定项目能否持续的是另一类工作：确认问题是否能复现、判断需求是否属于项目范围、维持发布节奏、给新手解释贡献规范。这些工作不产生代码，却消耗维护者大部分精力。

贡献者越多，沟通成本越高。同一个问题被三个人从不同角度提出，维护者要做归并；一个看起来合理的改动，可能破坏下游用法，需要长期讨论。如果没有清晰的范围文档与模板化的问题提交要求，这些消耗会迅速超过代码本身带来的收益。

常见的缓解手段是把边界写下来。明确项目不做什么，比说明它做什么更重要：拒绝越界需求的依据一旦公开，维护者就不必在每一次讨论里从零开始解释。另一项手段是把发布流程自动化，让人只做决策而不做重复操作，减少维护者的时间碎片化。

志愿维护的结构性问题在于激励错位。写一段功能代码能获得可见的成就感，而处理两百条问题单几乎不会。部分项目通过轮值制度把维护工作分散，也有人把文档与议题整理算作正式贡献并公开致谢，这些做法无法消除疲劳，但能让负担更可预期。

对使用开源代码的团队，实际建议是把手维护者的工作负载当作选型指标之一。最近三个月是否有版本发布、议题平均响应时间、维护者数量是否只有一个，这些信息比星数更能预测未来的风险。把依赖当成需要长期陪伴的关系，而不是拿来即用的部件，选择会更谨慎。