本文目录导读：
“板凳深度”这个词在不同领域含义不同，如果你说的是开源项目里的板凳深度，通常指一个项目的可持续性、维护能力和抗风险能力——也就是当核心维护者离开或减少投入时,项目还能不能继续健康发展。
下面给出一套可操作的评级打分框架。
先明确：开源项目的“板凳深度”指什么
可以类比球队：主力下场后，替补能不能顶上来,对开源项目来说，
- 除了1-2个核心维护者,还有没有足够的活跃贡献者？
- 关键模块有没有多人熟悉？
- 治理结构是否依赖个人？
- 资金/组织支持是否多元？
- 社区能否自我运转？
评级维度与打分表（满分100）
| 维度 | 权重 | 说明 |
|---|---|---|
| 贡献者分布 | 25 | 是否严重依赖少数人 |
| 维护者梯队 | 20 | 有无明确的继任/多人维护 |
| 治理结构 | 15 | 是否有基金会、委员会、OWNERS文件等 |
| 组织/资金支持 | 15 | 是否有多家公司或基金会支持 |
| 社区活跃度 | 10 | Issue/PR/讨论是否持续活跃 |
| 文档与知识传承 | 10 | 新人能否快速接手 |
| 发布与流程自动化 | 5 | 发布、测试、CI是否不依赖个人 |
各维度具体评分标准
贡献者分布（25分）
看过去12个月贡献分布：
| 情况 | 分数 |
|---|---|
| 前1人贡献 >80% | 0-5 |
| 前1人 50-80% | 6-12 |
| 前3人合计 >80% | 13-18 |
| 前10人较均衡，无单一主导 | 19-25 |
加分项：
- 有多个公司/组织的贡献者
- 有非核心团队的常规贡献者
减分项：
- 某一人同时是唯一Reviewer和Release Manager
维护者梯队（20分）
| 情况 | 分数 |
|---|---|
| 只有1位维护者，无明确接替 | 0-5 |
| 2-3位维护者，但权限集中 | 6-12 |
| 有明确Maintainer/Committer分层 | 13-17 |
| 有活跃的继任机制，定期新增维护者 | 18-20 |
检查点：
- 是否有
MAINTAINERS.md、OWNERS、GOVERNANCE.md - 最近12个月是否新增过维护者
- 是否有维护者退出后的平稳交接案例
治理结构（15分）
| 情况 | 分数 |
|---|---|
| 无治理文档，BDFL模式 | 0-4 |
| 有简单治理文档，但实际仍一人决策 | 5-9 |
| 有基金会/委员会，决策透明 | 10-13 |
| 成熟治理，有选举、任期、冲突解决机制 | 14-15 |
典型正面例子：
- CNCF / Apache / Linux Foundation 托管项目
- 有 PMC、TSC、Committer 投票机制
组织/资金支持（15分）
| 情况 | 分数 |
|---|---|
| 无明确支持，纯个人项目 | 0-3 |
| 单一公司支持 | 4-8 |
| 2-3家公司支持 | 9-12 |
| 多公司+基金会+多元资金 | 13-15 |
风险点：
- 单一公司裁员或战略转向可能导致项目猝死
- 基金会托管通常加分，但也要看实际投入
社区活跃度（10分）
看最近6个月：
| 指标 | 健康信号 |
|---|---|
| Issue响应 | 平均 <7天有维护者回复 |
| PR处理 | 有外部PR被合并 |
| 讨论渠道 | Slack/Discord/邮件列表活跃 |
| 新贡献者 | 每月有新人首次贡献 |
| 情况 | 分数 |
|---|---|
| 长期无响应 | 0-3 |
| 偶尔响应 | 4-6 |
| 稳定活跃 | 7-8 |
| 非常活跃且包容 | 9-10 |
文档与知识传承（10分）
| 情况 | 分数 |
|---|---|
| 几乎无文档，靠口口相传 | 0-2 |
| 有基础README和API文档 | 3-5 |
| 有贡献指南、架构文档、Roadmap | 6-8 |
| 有新人上手路径、导师机制、录屏/会议记录 | 9-10 |
关键：
- 核心模块是否有不止一人能Review
- 是否有“bus factor”分析
发布与流程自动化（5分）
| 情况 | 分数 |
|---|---|
| 手动发布，依赖个人 | 0-1 |
| 有CI，但发布仍需核心人 | 2-3 |
| 自动化发布、测试、签名 | 4-5 |
总分评级
| 总分 | 评级 | 含义 |
|---|---|---|
| 90-100 | S | 极深板凳，抗风险极强 |
| 75-89 | A | 板凳深厚，可持续性好 |
| 60-74 | B | 基本健康，但仍有关键人风险 |
| 40-59 | C | 板凳较浅，依赖少数人 |
| 20-39 | D | 高风险，易因个人变动停摆 |
| 0-19 | E | 单点故障，几乎无板凳 |
快速评估清单（可直接用）
对任意开源项目,问这10个问题：
- 过去12个月，前3名贡献者占比是否 <70%？
- 是否有 ≥3 名有合并权限的维护者？
- 最近12个月是否新增过维护者？
- 是否有公开治理文档？
- 是否有基金会或多公司支持？
- 外部PR是否能在合理时间内被合并？
- 是否有贡献指南和架构文档？
- 核心模块是否有 ≥2 人熟悉？
- 发布流程是否自动化？
- 如果核心维护者消失3个月,项目是否还能运转？
每答“是”得1分,然后映射：
- 9-10：S/A
- 7-8：B
- 5-6：C
- 3-4：D
- 0-2：E
常见误区
-
Star多 ≠ 板凳深
Star只是关注度,不代表维护能力。 -
大公司背书 ≠ 一定安全
如果只有一家公司投入,战略调整时可能直接弃坑。 -
贡献者数量多 ≠ 健康
很多是一次性文档修改,关键还是看持续贡献和Review能力。 -
BDFL模式不一定差
早期项目常见，但需要逐步建立梯队，否则bus factor=1。
