Methodology

ToolVitals is public software due diligence. We separate what a tool does from how much public evidence exists, then publish a score only when that evidence is strong enough.

Taxonomy

Categories are broad navigation buckets such as Finance, Security, and Developer Tools.

Use cases are comparison buckets such as Payment Processing, Personal Budgeting, API Testing, and Identity & Access Management. Rankings and alternatives use use cases, not broad categories.

Tags are facets such as self-hosted, api-first, open-source, and enterprise.

Openness class distinguishes OSI-approved OSS, source-available, fair-code, open-core, proprietary targets, and unknown-license tools. A GitHub repository alone is never treated as proof of OSI-approved open source.

Score States

Scored (verdict) means there is enough comparable public evidence to publish numeric ToolVitals scores and include the tool in rankings.

Evidence Watch (evidence_watch) means the tool is rankable in principle, but important evidence is incomplete. It remains visible and searchable, but its public score fields are null and it is excluded from rankings and movement feeds.

Not Scored (not_scored) means comparable open or source-visible evidence is unavailable, including proprietary targets and unknown-license tools. These tools are not assigned a zero: their public score fields are null.

Evidence Models

Open/source-visible tools lean on commit recency, sustained commit activity, contributor continuity, repository state, license evidence, and a small release-cadence signal.

Health Score

The health score estimates whether a project appears maintained. For repository-backed tools, commit recency contributes 35%, commits in the latest 30 days 25%, activity in the preceding 60 days 20%, active contributors 15%, and release activity at most 5%. Each signal uses fixed continuous curves with diminishing returns, so a larger project can remain distinguishable without making popularity a quality input.

Shipping Score

The shipping score estimates visible delivery activity. Recent commits contribute 50%, activity in the preceding 60 days 35%, contributors 5%, and release cadence at most 10%. Missing evidence is not converted into zero; incomplete evidence produces Evidence Watch instead of a misleading low score.

ToolVitals Score

The ToolVitals Score is a continuous 0–100 composite: 60% maintenance health and 40% shipping activity. Confidence and source coverage never add points; they determine whether the evidence supports a public verdict and can limit the top-line score. The internal continuous values are rounded only when persisted for a scored verdict, and 100 is reserved for exceptional, fully observed inputs.

Zombie Score

The zombie score estimates abandonment risk from repository evidence. It primarily uses last-commit recency, commit volume across rolling 30- and 90-day windows, continuity between those windows, active contributors, and an explicit archived-repository or shutdown signal. Operational service signals, popularity, docs, blogs, and social posting do not affect zombie risk.

Data Confidence

Every tool also gets a Data Confidence score from 0–100. This measures how much public evidence we have, not how good the tool is. A low-confidence tool may be healthy; it is just less transparent from public sources.

  • High Coverage means we have multiple strong public signals.
  • Moderate Coverage means we have enough evidence for a useful score, but some signals are missing.
  • Limited Data means the score should be read carefully because public evidence is sparse.

Status Labels

  • Active means the evidence looks healthy and current.
  • Warning means maintenance signals are mixed.
  • Zombie means repository activity indicates high abandonment risk.
  • Critical means commit and contributor signals indicate elevated maintenance risk.
  • Dead is reserved for tools with strong evidence of abandonment.
  • Data Pending means we do not have enough reliable evidence for a verdict yet; the score-state label explains whether that is Evidence Watch or Not Scored.

Public Sources We Use

  • GitHub API
  • SPDX-style license metadata and manual license overrides
  • Official changelogs, release notes, and RSS feeds
  • Package registries like npm and PyPI
  • Official websites and documentation for identity and source mapping, not as health-score inputs
  • Planned non-blocking enrichment hooks: OpenSSF Scorecard, deps.dev, ecosyste.ms, and OSV advisories

Why This Matters

Not every source-visible tool is OSI-approved OSS, and one commit alone does not prove sustained maintenance. Rankings order scored tools by ToolVitals score, health, shipping, confidence, and finally GitHub stars as adoption context. The goal is to make scoring fairer, clearer, and harder to game before a team bets on a tool.