当开源维护成为全职工作：慕尼黑资助 libexpat 维护者的启示

开源软件的关键基础设施，往往由少数维护者在业余时间支撑。libexpat 维护者 Sebastian Pipping 在博客中描述了这种现实：过去大约 10 年，维护工作一直要和日常工作、家务、社交生活以及休闲时间竞争。现在，这种安排出现了一个重要变化：从 2026 年 8 月 1 日起，他将获得慕尼黑市政府的资助，全职维护 libexpat，最长 6 个月。

这件事的意义不只是“有人拿到了一份开源工作”。它还把一个长期存在的问题摆到了台面上：当一个项目被大量软件依赖，却没有稳定的维护时间和资金时，整个生态系统都会暴露在风险之下。

维护时间也是基础设施

开发者通常很容易看见新功能，却不容易量化维护工作的价值。依赖升级、漏洞响应、构建测试、发行版打包、文档更新、社区答疑和兼容性验证，都不会像一个新 API 那样显眼，但它们决定了项目能否持续运行。

当维护者只能利用晚上和周末处理这些工作时，项目会受到几个直接影响：

• 安全问题可能无法及时确认和修复。
• 版本发布容易被日常事务打断。
• 测试、文档和构建系统等“看不见的工作”持续积压。
• 维护者长期承受时间压力，最终可能选择退出。

因此，资助 6 个月并不只是购买代码提交量，而是在购买连续、可预期的维护能力。对于被许多系统间接使用的底层库，这种能力本身就是软件供应链的一部分。

公共资金为什么值得关注

这次资助来自慕尼黑市政府，说明开源维护不一定只能依靠商业公司赞助。公共机构同样可以把关键开源项目视为数字基础设施，并通过有限期限的资金支持，帮助维护者集中处理积累已久的工作。

这种模式有几个现实优势：

1. 资金目标清晰。 资助周期和受益项目明确，便于定义任务和验收结果。
2. 支持生态公共品。 项目可能被许多组织使用，但单个使用者未必有动力独自承担全部维护成本。
3. 给维护者一个可执行窗口。 半年时间足以完成安全审计、测试补强、发布流程整理或文档改进等连续性工作。
4. 降低单点依赖风险。 资助期间可以同时完善交接文档、自动化流程和维护权限，为未来引入更多贡献者创造条件。

当然，6 个月的资助也有边界。它不能自动解决长期收入、治理结构、继任者培养和项目所有权等问题。一次性或短周期资金更像是一个修复和转型窗口，而不是完整的可持续性方案。

可以怎样设计一份维护计划

如果一个组织准备资助某个关键开源项目，可以把支持方案写成可执行的任务清单，而不是只约定“持续维护”。下面是一个可改造的示例配置。项目名称、周期和目标均为示例假设，不代表慕尼黑市政府或 libexpat 的实际资助条款。

project: example-critical-library
funding:
  start: 2026-08-01
  duration_months: 6
  maintainer_capacity: full_time

objectives:
  - id: security
    description: "建立漏洞接收、验证、修复和发布流程"
    evidence:
      - security-policy.md
      - documented-release-process
  - id: quality
    description: "补充跨平台构建和回归测试"
    evidence:
      - ci-matrix
      - regression-tests
  - id: continuity
    description: "降低项目对单一维护者的依赖"
    evidence:
      - maintainer-guide.md
      - backup-maintainer
  - id: release
    description: "整理版本发布、变更记录和下游通知流程"
    evidence:
      - release-checklist.md
      - changelog

reporting:
  cadence: monthly
  include:
    - completed_work
    - unresolved_risks
    - next_month_priorities

配套的月度检查可以保持简单，例如：

#!/usr/bin/env bash
set -euo pipefail

required_files=(
  security-policy.md
  maintainer-guide.md
  release-checklist.md
)

for file in "${required_files[@]}"; do
  test -f "$file" || {
    printf 'missing: %s\n' "$file" >&2
    exit 1
  }
done

printf 'maintenance evidence is present\n'

这类清单的重点不在于增加行政流程，而在于把“维护得更好”转换成可以观察的结果：漏洞响应路径是否清楚，测试是否覆盖关键平台，发布是否可重复，其他人是否能够接手日常工作。

对维护者和使用方的启示

对维护者来说，全职资助提供了集中处理技术债务的机会，但最好把一部分时间投入到项目之外的可持续性建设，例如维护者文档、权限分工、发布自动化和新贡献者 onboarding。这样，资助结束后留下的不只是几个版本，还包括更健康的项目运行机制。

对依赖开源库的公司和政府机构来说，最实际的动作不是等待项目出现严重故障，而是盘点关键依赖并回答三个问题：谁在维护它、维护者是否有稳定时间、项目发生安全事件时谁负责响应。如果答案长期不明确，就应该考虑赞助、共同维护、提供工程资源或参与治理。

一次 6 个月的公共资助无法替代长期投入，但它证明了一个重要方向：开源维护可以被当作需要预算、目标和责任边界的基础设施工作。真正成熟的支持方案，应同时关注眼前的修复任务和资助结束后的连续性。