# Development activity

> How inspect.software measures development activity — push recency, weekly commit cadence, and commit volume. 13.2% of the overall health index.


**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](/wiki/vitality) (60% within category)
- **Weight in overall index:** 13.2% — the single heaviest repository metric
- **Metric key:** `development_activity`

## How the value is computed

| Component | Weight | Criteria |
| --------- | ------ | -------- |
| Push recency | 36 | same thresholds as v0.9.0, scaled to 36 points |
| Commit cadence | 36 | share of the last 52 weeks with at least one commit, × the human-authorship factor |
| Commit volume | 18 | log-scaled; roughly 100 commits per year earns full points, × the human-authorship factor |
| OpenSSF Scorecard: Maintained | 10 | Scorecard's 0–10 result, scaled to 10 points |

The value is the weighted sum, rounded and clamped to 1–100, and maps to a
[rating band](/wiki/scoring-bands). Components without data are excluded and
the remaining weights renormalized (see
[the health index](/wiki/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](/wiki/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](/wiki/release-discipline) and
  [responsiveness](/wiki/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](/wiki/release-discipline) ·
[Vitality](/wiki/vitality)