本文目录导读：
“综合开源项目”中换人（调整维护者/负责人）的最佳时机，取决于项目治理模式、社区健康度和具体触发因素，下面从触发信号、最佳窗口、操作要点三个层面来梳理。
需要换人的典型触发信号
| 类别 | 具体信号 |
|---|---|
| 维护者层面 | 长期不活跃（3–6个月无 review/merge/issue 回复）、明确表示倦怠、失联、利益冲突 |
| 项目健康层面 | PR/issue 积压持续增长、release 停滞、安全漏洞响应超时、CI 长期红 |
| 社区层面 | 核心贡献者流失、fork 活跃度超过上游、社区信任下降 |
| 治理层面 | 基金会/委员会决议、原维护者主动提名继任者 |
| 外部层面 | 公司战略调整、许可证变更争议、被收购 |
最佳时机的判断框架
主动交接 > 被动替换
- 最佳：维护者自己意识到精力不足，在完全失能前 1–3 个月启动交接。
- 次佳：社区观察到活跃度下降，但维护者仍能配合过渡。
- 最差：维护者彻底失联后才被迫换人——issue/PR 积压、fork 分裂风险最高。
避开关键节点
不宜换人的窗口：
- 大版本发布前 1–2 个月
- 重大安全事件响应期
- 许可证/治理结构变更投票期间
- 大型企业用户迁移期
推荐窗口
- 发布周期结束后：一个 minor 版本刚 release，进入下一个开发周期前。
- 年度治理会议前后：有正式提名/投票流程的项目。
- 贡献者已稳定参与 3–6 个月后：继任者已有足够 context 和信任。
不同治理模式下的操作
BDFL 模式（如早期 Linux、Vue）
- 换人=创始人主动让位或指定继任。
- 最佳时机：创始人公开宣布 + 明确继任者 + 过渡期共同署名。
基金会模式（Apache、CNCF、Linux Foundation）
- 走 PMC/TSC 提名与投票流程。
- 时机由治理文档规定,通常在季度/年度选举窗口。
公司主导模式（React、Kubernetes 部分子项目）
- 需公司内部与社区双重沟通。
- 最佳时机：公司内部完成交接人选确定后，再公开以避免“空降”争议。
纯社区模式（如早期 Vite、Astro）
- 依赖贡献者梯度：contributor → reviewer → maintainer。
- 最佳时机：候选人在 reviewer 角色稳定 3–6 个月后晋升。
操作要点（无论哪种模式）
- 提前沟通：先私下与核心团队、主要下游沟通，避免公开突袭。
- 明确权限移交清单：仓库、CI、包管理器发布权、域名、社交媒体、邮件列表、安全联系人。
- 过渡期双维护：原维护者保留 1–3 个月“荣誉/顾问”身份，处理历史 context。
- 公开公告：说明原因（不必暴露隐私）、继任者背景、治理变更。
- 更新治理文档：MAINTAINERS、GOVERNANCE、CODEOWNERS 同步。
- 安全兜底：2FA、密钥、发布令牌轮换。
一句话结论
最佳时机 = 维护者仍有能力配合交接 + 项目处于非关键发布期 + 继任者已具备 3–6 个月社区信任积累。
主动、有序、有过渡期的交接，远优于失联后的被动替换，若出现安全响应超时或连续两个发布周期停滞，就应视为必须立即启动换人流程的红线。
如果你指的是某个具体项目（如 Vue、Kubernetes、某 Python 库），可以告诉我，我可以给出更针对性的时机建议。
