2026年CHAOSS指标：面向人类速度的贡献度量CHAOSS Metrics in 2026

CHAOSS项目在过去八年中，为开源项目的各项度量指标制定了严谨且与具体实现无关的定义：包括打开了多少问题、关闭这些问题需要多长时间、有多少不同的人提交了代码、依赖项有多陈旧。制定这些定义的目的是确保两个计算“问题响应时间”的仪表盘至少是在计算相同的内容，而发布的指标集已成为该领域最接近共享词汇表的东西。

这些定义大多起草于2018年至2023年间，当时的背景是贡献以人类的速度产生，安全建议每年每个生态系统仅数次发布，而一旦维护者停止维护，通常也不再提交代码。这三个条件正在发生变化，而许多指标的定义并未明确说明地编码了这些变化。其共同点是大多数目录中的计数都统计仓库事件，而这些事件之所以有意义，是因为过去产生一个事件需要付出一定的人力成本。一个问题需要某人花十分钟撰写，一个PR需要某人花费整个下午。这种互动的一侧的成本正在被移除，而另一侧没有，因此这些计数越来越多地衡量的是廉价事物指向项目的多少，而非社区本身的情况。

我按照目录大致排列的顺序，浏览了当前发布的指标集，并试图找出哪些指标最依赖于这些假设。这与《开源测量的谬误》和“中心性不等于活力”的研究领域类似，但这里针对的是特定的已发布指标集，而非一般的研究实践。

活动计数

CHAOSS指标的最大一组是仓库事件的计数和比率：新问题、关闭的问题、变更请求、接受的变更请求、代码更改提交、代码更改行数。它们始终是代理指标，但它们所代理的对象相对稳定：一个问题意味着一个人遇到了问题并花时间记录下来，一个变更请求意味着一个人做了些工作并希望得到审查。

当可测量的新问题中有相当一部分是由模型生成的准确程度不一的错误报告，以及相当一部分变更请求是可能编译也可能不编译的代理提出的修复方案时，这些计数就与其原本代表的对象脱钩。Daniel Stenberg 从接收端描述了这种情况在curl上的表现。总体数字上升，每个项目维护者的时间增加，而代表用户真正需要的比例下降。没有任何计数指标能区分这三种趋势。

“变更请求接受率”的原始框架将接受率下降视为项目对贡献者变得不那么友好的标志。但在接收到大量低努力生成PR的项目上，这一情况会反转：接受率下降是维护者在履行职责，而高接受率可能意味着他们放弃了审查。

响应速度

问题响应时间、首次回复时间、问题解决时长和关闭时间被视作衡量社区活跃度的指标，这些指标受输入端和输出端双重影响。若某项目此前每月收到20个问题，现在增至200个，即使维护者工作量不变，中位数响应时间仍会上升——因为分母由提交问题的用户决定，而非项目自身可控。反之，若项目接入AI分类机器人，为每个新问题自动发布初始分类，首次回复时间可降至秒级。尽管指标定义要求过滤机器人响应，但该过滤机制依赖机器人标签标注，而当前一代机器人的难点在于：账户是普通用户账号，且回复内容像自然语言一样无迹可寻。

当项目决定将大量生成性问题保持开放状态（而非逐个耗费维护者时间关闭）时，问题年龄指标会持续攀升。这种分类决策本身具有合理性，但指标解读将其视为衰退信号。

贡献者身份

贡献者、新贡献者、偶发贡献者、转化率及贡献归属均基于一个假设：贡献者身份对应真实个人，新身份出现即代表社区触达了此前未覆盖的对象。

若代理程序通过新建账户提交PR，或同一人操控多组带独立令牌的代理程序，系统会将其识别为新贡献者的爆发式增长。项目的"新贡献者"图表可能在唯一实际维护者停止查看通知的当月骤升。转化率本用于衡量首次贡献者是否回归二次贡献，现却暴露出更多真相——它也在检测那些本就不可能获得体验的首次贡献者。

CHAOSS目录确实存在"机器人活动"指标，旨在区分自动化与人工贡献。其定义基于标记为机器人或遵循类机器人调度规律的账户，能捕获Dependabot和发布自动化工具，但无法识别通过个人访问令牌在合理时段提交的编程代理。上周我曾用模拟RFC尝试用标准语言界定这一边界，结果发现这是个笑话：所有条款都依赖完全不会主动披露的操作者自愿配合，附录A也承认缺乏备用检测机制。指标过滤器与"MUST"条款同样面临困境——二者都缺乏可验证的基准。

风险与缺失

巴士因子和贡献者缺席因子通过计算对半数贡献负责的最小贡献者人数，并将低数值视为集中风险。这种算术方法虽合理，却无法识别“周末在伯尼家”这类案例：一个项目中缺席因子为1，即一名成员十八个月前离开，而当前统计的贡献是Dependabot合并及少量自动化生成的PR落在未受保护分支上。该指标将“一位活跃的维护者”与“一位已离职但权限仍有效的维护者”报告为相同数值，而后一种情况正变得足够普遍以值得关注。大象因子（基于雇主关联而非个人进行相同计算）则因大量无明确关联背景的贡献涌入而数据噪音更大。

不活跃贡献者统计的是曾参与贡献后停止的成员，这看似正是针对“沉默离职”问题的理想指标。但问题在于其触发条件是提交记录缺失——若维护者已将仓库配置为自动合并通过PR并离开，系统仍会将其列为合并作者。实际需要检测的是“判断缺失”而非“事件缺失”，而所有基于事件计数的指标均无法捕捉这一点。

Libyears

Libyears衡量项目依赖项距离当前稳定版本的滞后程度，按依赖树层级累加。该方法源自2015年ICSE论文中提出的三个依赖新鲜度度量指标，其中时间跨度是最粗糙的，也是唯一被广泛采用的版本：libyear.com将其封装为单一数值，Thoughtworks于2020年将其引入Adopt平台，Renovate将其展示在仪表盘上，CHAOSS则将其纳入正式指标清单。Renovate团队的Jamie Tanna本月撰写了关于该指标局限性的说明，指出人们过度依赖它时需重复的注意事项，并提出了一个基于语义化版本权重的变体。这篇博文促成了此次对指标清单的全面审视。

隐含假设是距最新版本越远风险越高，但即使2015年我也认为这不成立。软件不会随日历时间退化。当某个固定版本遭遇CVE公告、上游API废弃或维护者消失时才会成为问题，这些离散事件均有独立预警渠道。若已有安全通告数据和语义化版本范围，本质上已捕获了这些事件的信号，而仅用时钟时间到最新标签的距离并无额外价值。2015年的框架还默认最新版本是应追求的目标，但从xz到Shai-Hulud再到本月TanStack蠕虫的一系列事件表明，过去几小时发布的版本反而最可能含恶意代码。一年无安全警报的生产环境版本具有类似“低背景辐射钢”的质量，但Libyears却将其计作一年累积债务。

将每个依赖项的增量汇总为单个“此仓库落后47.3个libyears”会产生一个毫无实际意义的单位，隐藏了具体哪个依赖贡献了什么，让字符串填充辅助工具与TLS库权重相同，且其数值随依赖数量增长而非依赖状态变化而变化。Jamie也指出，JavaScript项目在相同任务下得分总会比Java项目高出一个数量级，因为生态系统更频繁地发布小型包。此外，该数值随上游更新而变动，与你自身行为无关——因此维护者一周安静、上游一周忙碌，在图表中无法区分。

计算方式为当前发布日期 - 已安装发布日期，因此停止更新的依赖项永远贡献零分。锁定在未维护库的最终2021版的项目，会比落后活跃维护库两个月的版本评分更高。《Bernie’s周末数据》显示十六个注册表中大量最常用包处于“死亡或无响应”状态。这些包首次重新出现在指标中时，是有人获取发布凭证并发布了复活版本，此时libyears才开始报告你落后并需要更新。若团队已将此数值接入仪表盘和自动合并策略，指标会引导他们恰好最慢应取的发布版本，而此前数年的沉默却被计为完美表现。

当自动化漏洞发现机制开始向无人能修复的包发布警报时，同样的盲区也会影响缺陷解决时长。这类时长的上限无界，任何聚合结果都会因窗口内不可修复警报的数量而被主导。

PyPI上的libyear包最后一次发布于2020年11月，ecosyste.ms未列出活跃维护者，Scorecard的“维护状态”检查得分为零，依赖它的所有项目均贡献0.0 libyears。

发布与变更

发布频率传统上解读为“高频代表活跃，低频代表停滞”。如今还需容纳两类项目：一类通过自动化发布流水线使每个Dependabot合并PR都触发补丁发布；一类刻意放缓以加入供应链防御的冷却期。同一数字可能因项目类型不同代表三种含义，但指标定义并未区分。

自我合并率旨在标记未经二次审核即合并代码的项目。若维护者本人审核并代理提交（使用其账号），系统视为自我合并；若开发者拥有独立账号则视为健康的两方评审，区别仅在于配置细节而非审核流程本身。

许可证

无论代码由谁编写，许可证关注领域和SPDX文档均以相同方式计算，因为查找并解析许可证文件是机械操作。但许可证本质上是版权授予协议，而无人工作者的代码是否拥有可授予的版权尚未明确。检测工具会以相同方式（不标注权利归属方）将OpenClaw实例无人值守生成的仓库报告为MIT许可证，与其他情况无异。

受影响较小

上游代码依赖、测试覆盖率及DEI工作组的大部分基于调查的指标更具鲁棒性，因其衡量的是工件属性或直接询问人类，而非统计事件。测试覆盖率的归属与测试撰写者无关，维护者的调查结果仍来自该维护者本身。

这属于现实世界的变化而非原始定义的缺陷，制定这些工作组本无法合理预见此类情况。但当前发布的目录中，仍无法区分人类行使判断产生的事件与代理程序遵循循环规则生成的事件——而进化与风险关注领域的几乎所有内容都默认依赖这一区分。如今该默认假设已失效，我认为这使得修订这些领域的必要性比常规发布周期所暗示的更为紧迫。