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.

Two Public Modes

Scored Intelligence means there is enough public evidence to publish a ToolVitals verdict score.

Evidence Watch means useful signals exist, but not enough to make a strong public claim. Evidence Watch tools are visible and searchable, but separated from top picks and alternatives.

Evidence Models

Open/source-visible tools lean on GitHub activity, release cadence, package freshness, contributor activity, website health, license evidence, and public release signals.

Proprietary targets are tracked mainly to support "open alternatives to" discovery. They are excluded from default rankings, open-tool pricing indexes, and top picks.

Health Score

The health score estimates whether a tool appears maintained and reliable. Missing optional signals are not treated as zero; scores are normalized across the evidence that was actually observed.

Shipping Score

The shipping score estimates whether a tool is visibly improving. Commits, releases, package publishes, changelog freshness, and product-update feeds matter most. Docs and blogs are supporting evidence, not a substitute for product motion.

ToolVitals Score

The ToolVitals Score is a composite score from 0–100 built from maintenance, shipping, evidence confidence, and decay-risk signals when enough public evidence exists. Higher scores indicate stronger recent evidence of maintenance and product movement. Hosted pricing is reported separately.

Hosted Pricing

Hosted pricing is tracked for open/source-visible tools with paid cloud offerings. Tools without pricing are not penalized, and proprietary targets are excluded from open-tool pricing rankings.

Zombie Score

The zombie score estimates whether a tool is still reachable and still being sold, but showing visible signs of product stagnation or maintenance decay. A zombie tool is not necessarily dead, but it may be a risky long-term bet.

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 there are visible signs of slowing down.
  • Zombie means the tool still exists, but multiple signals suggest stale product motion or quiet abandonment.
  • Critical means there are stronger signs of decline.
  • Dead is reserved for tools with strong evidence of abandonment.
  • Data Pending means we do not have enough reliable evidence for a verdict yet.

Public Sources We Use

  • GitHub API
  • SPDX-style license metadata and manual license overrides
  • Official changelogs, product-update pages, and RSS feeds
  • Status pages
  • Public pricing pages
  • Package registries like npm and PyPI
  • Docs and blog freshness checks
  • Website availability and response checks
  • SSL certificate checks
  • Domain expiry data when available
  • 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 not every quiet GitHub repo means a product is dying. The goal is to make the scoring fairer, clearer, and easier to trust before a team bets on a tool.