Back to blog
FILE 0xD3·OSS PULSE: REPO HEALTH SIGNALS MOST TEAMS DON'T TRACK

OSS Pulse: repo health signals most teams don't track

June 27, 2026 · oss-pulse, open-source, dependencies, security, devops

The question "is this dependency healthy?" comes up constantly in engineering:

GitHub stars and last-commit-date are the signals most teams use. They're proxies. They tell you what happened, not whether the project is healthy.

OSS Pulse is a tool I've been building to surface the signals that actually matter.

What OSS Pulse measures

Scorecard (A-F grading) Composite score from: issue close rate, PR merge time, release cadence, documentation coverage, test coverage indicators, and community health (stars trend, fork activity). The grade maps to an opinionated read: A means "healthy, I'd depend on this." F means "this project is effectively abandoned."

Bus factor analysis Minimum number of contributors who authored >50% of commits. CRITICAL: 1 contributor (the project dies if they disappear). HIGH: 2 contributors. MEDIUM: 3-4. LOW: 5+. Also surfaces stale contributors (no commits in 30 days) and the dominant contributor's share.

PR merge time FAST (<4h), NORMAL (4h-48h), SLOW (2-7d), STALLED (>7d). Projects with consistent STALLED PRs are a signal: maintainers are either burned out or have moved on.

Issue response time IMMEDIATE (<1h), FAST (1h-24h), SLOW (1d-7d), IGNORED (>7d), NONE (no responses). A project that doesn't respond to issues in a week has an availability problem.

Fork activity analyzer How active is the fork network relative to the upstream repo? Active forks = healthy ecosystem. Notable forks that are more active than upstream = the project may be effectively forked.

Release cadence ACTIVE (regular releases), SLOWING (gaps growing), STALE (>180 days since last release), ABANDONED (>365 days). Distinguishes between "actively maintained but doesn't release often" and "nobody's home."

Commit message quality Score 0-100 based on: subject line length (ideal 50-72 chars), imperative mood, presence of body (what/why), no trailing period, no WIP/temp/fixup commits. A project with consistent quality commit messages has engineering discipline that shows up in other ways too.

Dependency freshness Lag in days per dependency, CRITICAL/HIGH/MEDIUM/LOW severity, freshness score A-F. A project with 3-year-old critical dependencies has a security posture problem.

License compatibility Pairwise analysis across ~40 known SPDX incompatible pairs. Returns COMPATIBLE/REVIEW/INCOMPATIBLE with conflicting package names. Key incompatibilities: GPL-2.0+Apache-2.0, AGPL-3.0 in SaaS, BUSL-1.1+GPL.

Vulnerability scanner Deps checked against OSV database (batch API). Per-severity counts (CRITICAL/HIGH/MEDIUM/LOW), A-F grade, sorted findings with fixed-version hints.

Version constraint evaluator Evaluates package.json, requirements.txt, etc. constraints for: violations (current version doesn't satisfy), blocked upgrades (constraint too tight), pinned-but-outdated (would benefit from loosening).

SBOM export CycloneDX 1.4 JSON for any tracked repo. Merged multi-repo SBOM. PURL generation for npm/pypi/cargo/go/maven/nuget/gem/composer. NTIA minimum-elements compliant.

The composite report

All signals roll up to a RepoHealthReport:

Repository: httpie/httpie
Composite score: 84 (A)
Scorecard: 82 (A) [35% weight]
Maintainer health: B [30% weight] — 2 active maintainers, 0 stale
Stars momentum: GROWING [10% weight]
Vulnerability severity: C [15% weight] — 2 HIGH in dependencies
Dep freshness: B [10% weight] — avg lag 94 days

Risks:
- 2 HIGH vulnerabilities in requests dependency (fixed in 2.32.0)
- 3 deps with MAJOR version updates available

Recommendation: update requests dependency before next prod deploy

Who this is for

OSS Pulse is useful for teams that:

The SBOM export alone closes a compliance gap that previously required enterprise tools like Snyk or Mend at 10-100x the cost.

OSS Pulse is in early access.