维护者韧性提出一个令人不安的问题：这个项目能否承受失去其最重要的那个人？它所度量的模式——单个维护者实质上承担全部工作—— 是开源领域最常见的结构性失败模式，而这在提交数与星标中是不可见的。
- 类别：可持续性与治理（类别内占 30%）
- 在总指数中的权重：7.2%
- 指标键名：
maintainer_resilience - 当贡献者名单不可用时为
null
数值如何计算
| 组成部分 | 权重 | 判定标准 |
|---|---|---|
| 巴士系数 | 54 | v0.9.0 巴士系数曲线，换算为 54 分 |
| 提交分布 | 22.5 | (1 − 头号贡献者的提交占比) × 22.5 |
| 贡献者广度 | 13.5 | min(13.5, 采样贡献者数 × 1.35) |
| OpenSSF Scorecard：Contributors | 10 | Scorecard 的 0–10 结果，换算为 10 分 |
巴士系数（bus factor）是合计承担大部分工作的最小贡献者人数—— 即一旦离开就会使项目停滞的那部分人。
Scorecard 组成部分度量参与贡献的组织/公司，是关于机构韧性的有益补充信号。它同时仍是安全类的一部分；不可用或为 n/a 时在此处被排除。
曲线为何如此设计
巴士系数从 1 到 2 的跃升（10 → 28 分）是整个方法论中最大的单次增幅，因为它对应现实中最大的风险削减：一个存在单点故障的项目与一个不存在单点故障的项目之间的差别。超过 4–5 之后收益递减—— 一旦若干人真正分担工作，再增加人数改变甚微。
提交分布是对巴士系数的补充：一个项目在名义上可以有五名贡献者，而 95% 的变更出自一人之手。分布组成部分使这种集中度变得可见。
如何解读结果
- 高活力项目上的低数值是经典的单人维护者画像：今日高产，明日脆弱。
- 请与托管责任交叉阅读——组织背书可以缓解（但不能消除）该指标所度量的风险。
- 贡献者数据从仓库的公开历史中采样；机器人属于可观察记录的一部分，输入均在报告中回显。
- 对报告中显示的前十名贡献者，认证扫描还会通过一次批量请求收集其在 GitHub 自行公开的姓名、位置、公司和公开组织成员关系。这些补充资料不参与评分，并从公开 API 和 HTML 报告中隐藏；它们仅用于内部身份解析，不改变巴士系数的计算。
提升数值
- 将评审与合并权限授予至少一名额外人员——把巴士系数从 1 提升到 2 是可获得的最大单项收益。
- 主动分配工作：让评审与发布在多名维护者之间流转，而非经由一人。
- 将经常性贡献者转化为维护者；广度计入分值，而这条通道始于 社区健康。