# 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.


**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](/wiki/sustainability-governance).

## Metrics in this category

| Metric | Weight in category | Weight in overall |
| ------ | ------------------ | ----------------- |
| [Development activity](/wiki/development-activity) | 60% | 13.2% |
| [Release discipline](/wiki/release-discipline) | 40% | 8.8% |

[Development activity](/wiki/development-activity) measures whether code is
being written: push recency, weekly commit cadence over the last year, and
commit volume. [Release discipline](/wiki/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](/wiki/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](/wiki/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](/wiki/scoring-bands) ·
[methodology versions](/wiki/methodology-versions)