本文目录导读：
衡量开源项目中“老将”（资深维护者/核心贡献者）的经验价值，是一个既关乎社区治理、又关乎项目可持续性的核心问题，下面从几个维度展开分析。
为什么“老将经验”难以直接量化
开源项目的贡献通常以 commit 数、PR 数、issue 回复量等指标呈现，但这些只反映数量，不反映判断力，老将的真正价值往往体现在：
- 避免踩坑：知道哪些架构决策三年后会变成技术债
- 隐性知识：了解某段代码为何写成这样（历史上踩过的坑）
- 社会资本：认识上下游维护者，能一个邮件解决问题
- 判断力：知道什么 PR 该拒、什么该合并、什么该推迟
这些都是难以用代码行数衡量的。
可参考的衡量框架
Bus Factor（巴士系数）
如果核心维护者被“巴士撞了”，项目还能继续吗？
- 老将价值 ≈ 项目对其的不可替代性
- 衡量方式：统计关键模块的“唯一决策者”数量
- Bus Factor = 1 的项目，老将价值极高但风险也极高
决策影响力（非代码贡献）
| 维度 | 指标示例 |
|---|---|
| 架构决策 | RFC 发起/否决数 |
| 社区治理 | 争议仲裁参与度 |
| 人才培育 | 带出的新维护者数量 |
| 生态影响 | 下游项目依赖其判断的程度 |
时间维度的复利效应
老将的价值往往呈非线性增长：
- 第 1 年：贡献代码
- 第 3 年：贡献判断
- 第 5 年：贡献方向与信任背书
用“贡献时长 × 决策质量”比单纯用 commit 数更接近真实价值。
开源项目的实践做法
显性化隐性知识
- 要求老将撰写 ADR（架构决策记录）
- 建立“为什么这样设计”的文档
- 这本身就是把经验转化为可衡量资产
分级治理结构
- 如 Apache 的 PMC、Linux 的 Maintainer 体系
- 老将价值 = 其否决权覆盖范围
财务化尝试
- 部分基金会（如 OpenCollective、GitHub Sponsors）按维护者角色分配资金
- 但通常仍是按角色而非按经验深度，这是当前的局限
传承指标
- 衡量老将的“带教产出”：新人成长为 committer 的数量
- 这是经验价值最直接的杠杆化体现
核心矛盾
| 矛盾 | 表现 |
|---|---|
| 可量化 vs 有价值的 | 最容易量化的往往最不重要 |
| 个人 vs 社区 | 老将价值高，但过度依赖是风险 |
| 短期 vs 长期 | 老将的决策收益常在数年后才显现 |
| 开源 vs 商业 | 企业赞助常按代码量，忽视判断力价值 |
结论性判断
衡量老将经验价值的合理方式,应当是多维度组合：
- 替代成本：失去他，项目需要多久恢复？（Bus Factor 视角）
- 决策杠杆：他的判断影响了多少下游决策？
- 传承产出：他培养了多少能独立决策的人？
- 时间复利：他的历史决策中有多少仍在支撑当前架构？
一句话总结：老将的价值不在于他写了多少代码，而在于他让项目少走了多少弯路、以及他离开后项目会走多少弯路，前者难以量化，后者可以通过 Bus Factor 和决策依赖度来近似衡量。
如果你在做具体的项目评估或治理设计,可以进一步讨论适合你场景的指标体系。
