本文目录导读：
开源项目应对突发伤病这类变数，核心思路是降低对单点人物的依赖，并在事件发生后有预案可循,可以从几个层面来准备和应对。
日常预防：把 bus factor 降下来
开源项目最大的风险是 bus factor = 1，即关键维护者一旦出事,项目就停摆。
权限与角色分散
- 至少 2-3 人拥有合并 PR、发布版本、管理 CI/CD 的权限
- 使用 GitHub Teams / GitLab Groups 而非个人账号持有核心权限
- 关键密钥（签名密钥、npm/PyPI 发布令牌）使用组织级账户或密钥管理服务
文档化一切隐性知识
- 发布流程写成 checklist，任何人照着能走完
- 架构决策记录（ADR）保留“为什么这么做”
- 未完成的路线图、已知坑点及时写进 issue，而不是留在某人脑子里
建立维护者梯队
- 有意识地培养 co-maintainer，而不是等出事才找人
- 给活跃贡献者逐步放权：triage → review → merge → release
事件发生时的应急响应
立即沟通，稳定社区预期
- 在 README、项目主页、Discord/Slack 发公告：维护者因健康原因暂时离线，项目进入低维护模式
- 明确说明哪些事务暂停（如新功能）、哪些继续（如安全补丁）
启动临时维护者机制
- 由已有 co-maintainer 或信任的贡献者接管日常事务
- 如果无人有权限，走 GitHub 的 organization owner 恢复流程，或通过其他 owner 转移权限
分级处理事务
| 优先级 | 事务类型 | 处理方式 |
|---|---|---|
| 高 | 安全漏洞、严重 bug | 临时维护者尽快修复发布 |
| 中 | 依赖更新、CI 修复 | 批量延迟处理 |
| 低 | 新功能、讨论 | 明确暂停，冻结合并 |
寻求外部支持
- 基金会托管的项目（Apache、CNCF、Linux Foundation 等）可请求基金会介入协调
- 相关社区（如 Python Packaging、Rust Foundation）有时能提供临时资源
- 企业用户如果依赖该项目，可公开呼吁他们出人出力
长期恢复与制度化
借机重构治理结构
- 从“仁慈独裁者”模式转为维护者委员会
- 明确继任规则：多久不活跃视为离职，如何增补维护者
引入组织背书
- 加入基金会获得法律、财务、治理支持
- 或成立 Open Collective / GitHub Sponsors，让维护工作可持续
案例参考
- Node.js / curl：核心人物长期高强度维护，社区多次讨论 bus factor，最终通过基金会和多人维护缓解
- Vue.js：尤雨溪曾因健康问题减少投入，团队化和赞助模式帮助过渡
- left-pad 事件：虽是主动撤包，但暴露了单点依赖的脆弱性，推动社区反思
给不同角色的建议
维护者本人
- 提前指定 co-maintainer，不要等出事
- 用 GitHub 的 inactive maintainer 政策作为借口，主动放权
贡献者
- 主动承担 triage、review，减轻核心维护者负担
- 发现维护者长期不活跃时，礼貌地在 issue 中询问状态
企业用户
- 如果业务依赖某开源项目，考虑赞助或派人参与
- 内部保留 fork 和 patch 能力，避免完全被上游卡住
一句话总结：开源项目对抗突发伤病变数，靠的是平时把权限、知识、责任分散开，事发时快速沟通、分级降级、启动备份维护者，事后推动治理结构制度化，bus factor 不是统计数字,而是需要主动管理的工程问题。
