开发活跃度回答任何人对一个开源依赖提出的第一个问题：代码是否仍在积极编写？它读取仓库最近一年的推送与提交历史，并依次按权重奖励新近度、节奏与数量。
- 类别：活力（类别内占 60%）
- 在总指数中的权重：12.6%
- 指标键名：
development_activity
数值如何计算
| 组成部分 | 权重 | 判定标准 |
|---|---|---|
| 推送新近度 | 36 | 阈值与 v0.9.0 相同，换算为 36 分 |
| 提交节奏 | 36 | 最近 52 周中至少有一次提交的周数占比，× 人类作者系数 |
| 提交量 | 18 | 对数尺度；每年约 100 次提交即得满分，× 人类作者系数 |
| OpenSSF Scorecard：Maintained | 10 | Scorecard 的 0–10 结果，换算为 10 分 |
数值为加权和，四舍五入并限定在 1–100 范围内，并映射到一个 评级等级。缺乏数据的组成部分被排除，其余权重重新归一化（参见健康指数）。
Maintained 属于共享证据，并非扫描器自身提交历史的替代品：它同时仍是安全态势的完整组成部分。若 Scorecard 不可用或将该检查标记为 n/a，此组成部分被排除。
人类作者系数
节奏与数量统计的是提交，而机器人所做的提交，与维护者所做的提交计数完全相同。因此，依赖机器人每周开启并合并一次更新的仓库，读起来就像处于持续开发之中。
系统会检查最近 100 次提交的作者归属，并将两个统计提交的组成部分乘以该窗口内的人类占比，达到 40% 及以上即为满分。
两个条件必须同时成立。仅仅人类占比偏低，只说明项目大量使用自动化——而维护得最好的项目往往如此：一个拥有 59,000 星标的工具，约有四分之三的提交经由依赖机器人产生；而某个产品本身就是自动化版本升级的软件包注册表，比例更高。两者都有几天前的人类提交。因此折减还要求：超过 90 天没有任何人类提交过。真正标示一个项目由机器人维系的是沉默，而非自动化。
该间隔在提交窗口自身内部测量——最新提交与最新的人类提交相比——因此已存储的报告始终重算为同一数值，而不会随时间推移而漂移。
它不带来自身的加分权重——只能拉低数值，绝不会抬高——并且当提交样本不可用或少于 20 次提交时被完全跳过，从而不会依据过少的证据作出推断。只有带 GitHub App 身份的自动化才会被识别；在普通用户账户下运行的机器人仍按人类计算。
为何节奏的分量高于数量
一个一年中每周都有提交的仓库，比同样数量的提交集中在一次爆发中落地的仓库，是更可靠的维护证据。节奏度量的是持续的投入；数量采用对数尺度，正是为了让提交次数无法被灌水成高分——100 次与 1,000 次年度提交之间的差距在设计上就很小。
如何解读结果
- 新近度主导短期变化。一个停顿六个月的项目首先失去新近度组成部分；随着不活跃周数累积，节奏组成部分随之衰减。
- 确实存在真正完工的软件。一个稳定、功能完备的库可以在此读数偏低却依然可以安全使用——这正是开发活跃度只是加权指数中的一项指标、而非最终裁决的原因。请与 发布纪律及 响应能力交叉阅读。
- 单一仓库（monorepo）与镜像：活跃度读取的是被检验的仓库本身；发生在其他仓库中的工作不被计入。
提升数值
- 持续合并维护性工作，而非把长期分支攒到一起批量处理。
- 在项目确实需要维护之处，保持至少每周一次的真实变更心跳——依赖更新与缺陷修复均计入。
- 避免空洞的活跃：数量的对数尺度使得人为灌水提交几乎毫无价值。