Scoring categories

Vitality

The Vitality category of the inspect.software health index — whether code is actively written and versioned releases actually ship. Weight: 22% of the overall index.

Methodology v1.13.0Updated 2026-07-13

Vitality answers the most basic question about an open-source project: is it alive? Code that stopped moving stops absorbing bug reports, security fixes, and compatibility work — and dependency on a dormant project is one of the most common, least visible risks in a software supply chain.

The category carries 22% of the overall health index, second only to Sustainability & Governance.

Metrics in this category

MetricWeight in categoryWeight in overall
Development activity60%13.2%
Release discipline40%8.8%

Development activity measures whether code is being written: push recency, weekly commit cadence over the last year, and commit volume. Release discipline measures whether that work actually reaches users as versioned releases — recency and cadence of published releases.

Scorecard's Maintained and Signed-Releases checks are also shared evidence in these two metrics. This intentionally lets observable maintenance and release provenance influence both Vitality and Security, with different weights.

The split is deliberate. A repository can show constant commits yet never cut a release users can adopt; another can ship tidy quarterly releases from a low-traffic default branch. Healthy projects do both, and the category rewards exactly that combination.

Reading the category value

  • A high Vitality with weak Governance often marks a fast-moving project carried by one person — cross-check maintainer resilience.
  • A low Vitality on a mature library is not automatically fatal: some foundational packages are genuinely finished and change rarely. The category reports observable motion; judgement about whether motion is required belongs to the reader.
  • When release data is unavailable, release discipline is null and the category renormalizes onto development activity alone — the report's notes say so (see the health index).

Improving Vitality

  • Keep the default branch moving: merge maintained work regularly rather than batching months of changes.
  • Publish versioned releases on a predictable cadence, even for small changes; recency and rhythm both count.
  • If a project is intentionally in maintenance mode, state it in the README — the record cannot read intent, but downstream users can.

Related: rating bands · methodology versions