活力回答关于一个开源项目最基本的问题：它还活着吗？停止变动的代码也停止吸收缺陷报告、安全修复与兼容性工作——而对休眠项目的依赖，是软件供应链中最常见、也最不易察觉的风险之一。
该类别承载总健康指数的 22%，仅次于 可持续性与治理。
本类别包含的指标
开发活跃度度量代码是否仍在编写：推送新近度、最近一年的每周提交节奏与提交量。 发布纪律度量这些工作是否真正以版本化发布的形式抵达用户——已发布版本的新近度与节奏。
Scorecard 的 Maintained 与 Signed-Releases 检查同时是这两项指标中的共享证据。这是有意的安排，让可观察的维护状态与发布来源证明以不同的权重同时影响活力与安全两个类别。
这种拆分是刻意的。一个仓库可以提交不断却从不产出用户可采用的发布版本；另一个可以从低流量的默认分支按季度交付整洁的发布。健康的项目两者兼备，该类别所奖励的正是这种组合。
如何解读类别数值
- 活力高而治理弱往往标志着由一人支撑的快速演进项目——请交叉核对维护者韧性。
- 成熟库的活力偏低并不自动意味着致命：一些基础性软件包确实已经完工、极少变动。该类别报告的是可观察的变动；至于变动是否 必需，判断权属于读者。
- 当发布数据不可用时，发布纪律为
null，类别权重重新归一化到开发活跃度之上——报告的注记会如实说明（参见 健康指数）。
提升活力
- 让默认分支保持流动：定期合并维护性工作，而非把数月的变更攒到一起。
- 以可预期的节奏发布版本化的发布版本，哪怕改动很小；新近度与节奏都计入分值。
- 若项目有意处于维护模式，请在 README 中写明——记录无法读出意图，但下游用户可以。