治理、fork 与退出：17 位贡献者、82% 的提交与一次改协议的代价

一个人维护的项目，最大的风险不是没人用，是只有你能发版。

一、17 位贡献者，一个能发版的人

2026 年 8 月，许砚做了一次「如果我不在两周」的演练。他把所有凭据、发布流程与 issue 权限写成文档，然后让一位长期贡献者按文档发一次补丁版本。演练在第 3 步卡住：对方有 triage 权限，没有发布权限；发布需要仓库 admin 与包仓库的 token，而这两样只有他一个人有。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

这个仓库一年有 17 位贡献者、1,637 次提交。前 3 位贡献者提交了 1,342 次，占 82.0%；其余 14 位合计 295 次，占 18.0%。这个分布本身不奇怪——大多数开源项目都是这样——但它意味着项目的连续性完全依赖前 3 位，而其中 2 位是「有空才来」。

「有空才来」不是问题，前提是他们的模块有文档。真正的问题是：这 2 位负责的模块，只有他们知道边界在哪；一旦他们离开，接手的人要读完全部提交记录才能理解为什么这样写。

bus factor 不是人数，是「关键动作有几个能独立完成的人」。 这个项目能独立发版的只有 1 人，能做 triage 的有 3 人，能改 CI 的有 2 人，能处理安全报告的有 1 人。四个动作里三个是单点，任何一个单点断掉，项目就会停摆。

停摆的形式不一定是崩溃。更常见的是「慢下来」：没人发版，issue 越积越多，用户开始怀疑项目已死，然后不再提 issue。这个过程没有明确的时间点，所以很难被察觉。

治理的第一个动作不是建委员会，是把「只有你能做」的动作列出来，然后逐个交出去。交出去不是放权，是先把流程写成文档、把权限设成可撤销、把回滚路径写清楚。

文档的标准是「一个没参与过的人能照着做」。他的发版文档有 14 步，每步都写了命令与预期输出；第一次演练时，那位贡献者在第 9 步卡住，因为文档里少了一句「先确认 tag 没有推送过」。补上之后，第二次演练 22 分钟完成。

二、提交分布与四个单点

把 1,637 次提交按人拆开，会看到三种角色：常驻维护者、阶段性贡献者、一次性提交者。三种角色的管理方式完全不同。

常驻的 3 位里，只有 1 位每周都在；另外 2 位按月出现，负责特定模块。这个结构的问题是：按月出现的 2 位一旦离开，模块会进入「没人懂」状态；而每周都在的那 1 位，正是你自己。

这个结构有个隐含风险：你自己的模块没有备份。别人负责的模块，你至少读过；你负责的模块，别人可能一行都没看过。把最核心的部分写成文档，比把边缘部分交出去更重要。

四个单点分别是发版、CI 配置、安全报告处理、包仓库凭据。前三个可以靠文档与权限解决，第四个只能靠凭据管理：把 token 放进团队密码管理器，设置两个管理员，每 90 天轮换一次。

提交占比高不是荣誉，是风险。 82% 这个数字说明项目还没有形成真正的协作结构；它只是「一个人写，其他人提意见」。想降低这个比例，最有效的动作不是招募，是把低风险的修复（文档、测试、依赖升级）明确标成「欢迎认领」，并给出合并标准。

合并标准要具体到「什么样可以合」。他写的是三条：有测试、不改公开 API、changelog 有一行。三条都满足就合，不需要额外的品味判断；这条规则让外部 PR 的合并率从 28% 升到 41.2%。

三、一次改许可证的四个后果

2026 年 9 月，许砚认真考虑过把许可证从 Apache-2.0 换成 BSL，理由是有一家云厂商把项目打包进了托管服务。他没有立刻改，而是先做了一次影响推演，把四个后果写下来。

第一个后果是 fork 数上升。设想中的变更公告发布 30 天，fork 从 214 涨到 287，增加 73 个，涨幅 34.1%。fork 本身不伤害项目，但它会分裂 issue 与文档，长期看会稀释社区。

第二个后果是 star 波动。star 从 4,200 降到 4,120，减少 80 个，降幅 1.9%。这个数字不大，但它代表的是「态度转向」：一部分人不会删 star，但会停止推荐。

第三个后果是客户询问。两家双许可客户里有一家要求书面确认「已购许可不受变更影响」。这类确认必须给，而且要写进合同附件；否则下一次续约会有争议。

第四个后果是新贡献者下降。变更前 6 个月有 11 位新贡献者，变更后 6 个月只有 5 位，下降 54.5%。这个数字最难量化，但影响最久：社区的新陈代谢靠新人，新人少了，两年后就没有常驻维护者可接。

新贡献者的来源也要看。11 位里，7 位是从 issue 开始、4 位是从文档错别字开始；后者虽然贡献小，但留存率更高，因为他们第一次 PR 就被合了。降低第一次贡献的门槛，比写一份漂亮的贡献指南有用。

推演之后他没有改。原因不是怕掉 star，而是第四项：一个只有 17 位贡献者的项目，经不起新贡献者减半。许可证变更是最后手段，不是第一反应。

改许可证的代价不在法律，在信任。 法律上你通常有权变更未来版本；信任上，你是在告诉所有贡献者「当初的承诺可以改」。前者一天能做完，后者需要两年恢复。

这也是为什么「改协议」应该放在最后。能解决同一个问题的其他手段包括：把托管服务做成更明显的差异化、给企业客户单独的商业条款、以及把商标使用写清楚。三种手段都比改协议便宜。

四、退出与继承：一份六件套归档清单

比「改协议」更常发生的是「不做了」。项目停更不可耻，停更却不说明才可耻。一个人维护的项目，应该随时能进入「可交接」状态。

六件都做完，项目才算「可交接」。缺任何一件，接手的人都要从零猜测；而愿意从零猜测的人，通常不会接手。

六件套里最容易漏的是第六件。继任说明不该只写「谁可以接手」，还要写「接手需要哪些账号、哪些权限、哪些外部服务」；一份清单，比一句「欢迎联系我」有用得多。

复算：
贡献者：3 + 6 + 8 = 17
提交：1,342 + 236 + 59 = 1,637
占比：1,342 ÷ 1,637 = 82.0%；236 ÷ 1,637 = 14.4%；59 ÷ 1,637 = 3.6%
其余 14 位：236 + 59 = 295 → 295 ÷ 1,637 = 18.0%
改协议：fork 287 − 214 = 73 → 73 ÷ 214 = 34.1%
        star 4,200 − 4,120 = 80 → 80 ÷ 4,200 = 1.9%
        新贡献者 11 − 5 = 6 → 6 ÷ 11 = 54.5%
单点动作：发版 1 人、triage 3 人、CI 2 人、安全 1 人

复算里最该记住的是 54.5%。fork 与 star 的变化是可见的、可恢复的；新贡献者的下降是缓慢的、几乎不可逆的。评估任何治理动作时，先问它对新人入口的影响。

这个判断标准也能用来评估其他动作：加一个贡献者许可协议、收紧 PR 合并标准、把 issue 模板变长，都会影响新人入口。不是不能做，是要把成本算进去。

五、行动清单与复算验收

• 列出「只有你能做」的动作，逐个写下当前有权限的人。
• 把发版流程写成文档，让第二个人按文档独立发一次版。
• 把凭据放进密码管理器，设两个管理员，定 90 天轮换。
• 统计贡献者提交分布，算出前三名占比。
• 把低风险工作标成「欢迎认领」，并写清合并标准。
• 做一次改许可证的影响推演，四项后果各写一个数。
• 补齐六件套：状态、许可证、安全、迁移、最后版本、继任说明。
• 每半年演练一次「维护者消失两周」，记录卡在第几步。

验收标准：任取一个关键动作，都能说出除了你之外还有谁能做、依据哪份文档、多久能做完。

前四条是「把单点拆掉」，后四条是「把退出写清楚」。如果只有一小时，先做第二条：文档写得再好，没人按它跑过一次，就还不是流程。

清单里最容易被跳过的是第八条。演练的价值不在于成功，而在于暴露「文档里少了一步」；真出事时，你不会有时间补文档。

使用边界与实操验收

82% 不是失败。 一个人维护的项目，集中度高是常态；问题不在于高，而在于没有为「高」做准备。

治理不等于开会。 一个人的项目不需要委员会、投票与章程；需要的是权限清单、文档与交接路径。

改许可证要慢。 法律上可行不等于社区上可行；先推演四项后果，再决定要不要动。

归档不是失败。 明确归档比假装维护更负责；用户需要的是「知道它不更新了」，而不是「每次来看都以为快更新了」。

继任者不会自己出现。 想交接，要在还活跃的时候培养；等到想退出时再找，通常找不到。

关键参考与核验范围

• Open Source Guides：领导与治理 ：用于核对维护者角色、决策方式与交接的常见结构。
• GitHub Docs：为项目建立健康的贡献流程 ：用于核对权限、模板与贡献指南的落点。
• Choose a License ：用于核对许可证变更时涉及的权利范围。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论一个人维护项目的贡献者结构、许可证变更推演与归档交接，不讨论基金会托管、商标转让与法律诉讼。

系列导航

• 上一篇：双许可与企业版：九家询价、两家成交与 4,800 美元
• 下一篇：开源项目验收：十项能力、四维评分与三种不该开源的项目
• 回到目录：一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护
• 相关阅读：独立开发者的资产韧性