开发活跃度回答任何人对一个开源依赖提出的第一个问题：代码是否仍在积极编写？它读取仓库最近一年的推送与提交历史，并依次按权重奖励新近度、节奏与数量。
- 类别：活力（类别内占 60%）
- 在总指数中的权重：13.2%——单项权重最高的仓库指标
- 指标键名：
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 次与 1,000 次年度提交之间的差距在设计上就很小。
如何解读结果
- 新近度主导短期变化。一个停顿六个月的项目首先失去新近度组成部分；随着不活跃周数累积，节奏组成部分随之衰减。
- 确实存在真正完工的软件。一个稳定、功能完备的库可以在此读数偏低却依然可以安全使用——这正是开发活跃度只是加权指数中的一项指标、而非最终裁决的原因。请与 发布纪律及 响应能力交叉阅读。
- 单一仓库（monorepo）与镜像：活跃度读取的是被检验的仓库本身；发生在其他仓库中的工作不被计入。
提升数值
- 持续合并维护性工作，而非把长期分支攒到一起批量处理。
- 在项目确实需要维护之处，保持至少每周一次的真实变更心跳——依赖更新与缺陷修复均计入。
- 避免空洞的活跃：数量的对数尺度使得人为灌水提交几乎毫无价值。