Development activity

Development activity answers the first question anyone asks of an open-source dependency: is code actively being written? It reads the repository's push and commit history over the last year and rewards recency, rhythm, and volume — in that order of weight.

• Category: Vitality (60% within category)
• Weight in overall index: 13.2% — the single heaviest repository metric
• Metric key: development_activity

How the value is computed

The value is the weighted sum, rounded and clamped to 1–100, and maps to a rating band. Components without data are excluded and the remaining weights renormalized (see the health index).

Maintained is shared evidence, not a replacement for the scanner's own commit history: it also remains a full component of Security posture. If Scorecard is unavailable or marks the check n/a, this component is excluded.

The human-authorship factor

Cadence and volume count commits, and a commit made by a robot counts exactly like a commit made by a maintainer. A repository whose dependency bot opens and merges an update every week therefore reads as one under continuous development.

The newest 100 commits are checked for who authored them, and the two commit-counting components are multiplied by the human share of that window, reaching full marks at 40% and above.

Two conditions must hold together. A low human share alone means only that a project automates heavily, which the best-maintained ones often do — a 59,000-star tool runs roughly three quarters of its commits through a dependency bot, and a package registry whose product is automated version bumps runs higher still. Both have human commits days old. So the discount also requires that no human has committed for more than 90 days: it is the silence, not the automation, that marks a project as sustained by its robots.

The gap is measured inside the commit window itself — the newest commit against the newest human one — so a stored report always rescores to the same value rather than drifting as it ages.

It applies no additive weight of its own — it can lower a value, never raise one — and it is skipped entirely when the commit sample is unavailable or smaller than 20 commits, so nothing is inferred from too little evidence. Only automation carrying a GitHub App identity is recognized; a bot operating under an ordinary user account still counts as a person.

Why cadence outweighs volume

A repository with a commit every week for a year is more dependable evidence of maintenance than the same number of commits landed in one burst. Cadence measures sustained attention; volume is log-scaled precisely so that commit count cannot be inflated into a high value — the difference between 100 and 1,000 yearly commits is small by design.

Reading the result

• Recency dominates short-term change. A project that pauses for six months loses the recency component first; the cadence component then decays as inactive weeks accumulate.
• Genuinely finished software exists. A stable, feature-complete library can read low here while remaining safe to use — this is why development activity is one metric inside a weighted index, not a verdict. Cross-read with release discipline and responsiveness.
• Monorepos and mirrors: activity is read from the repository being inspected; work happening in a different repository does not count.

Improving the value

• Merge maintained work continuously instead of batching long-lived branches.
• Keep at least a weekly heartbeat of real changes where the project genuinely needs maintenance — bug fixes and reviewed dependency updates count, and so do automated updates as long as human work continues alongside them.
• Avoid empty activity: the log scale on volume makes synthetic commit inflation nearly worthless, and commits authored by automation are discounted once they crowd out human ones.

Related: release discipline · Vitality