Methodology
How scores are calculated
Every tool carries a derived GitHub score — not a user rating. It's computed from public repository signals and is built to resist the bought-star economy, then surfaced as an A+…D grade.
The formula
Score = round(100 · Q · A)
Q · Quality (0–1)
A weighted sum of project-health signals. Each signal is normalised to a 0–1 range (log-damped so a megastar repo can't run away with it), then multiplied by its weight. The weights add up to 100%.
A · Authenticity (0.5–1)
A multiplier that discounts bought-star / bot-stargazer patterns. It can only ever lower the score — a clean repo keeps A = 1.00; a flagged one loses up to 50%.
Quality signals (Q)
These add up. Each contributes points in proportion to its weight; together they form the quality subtotal.
Contributors & bus-factor
20%How many people commit, and whether the work is spread across them (a healthy bus-factor) rather than resting on a single maintainer.
Commit recency
20%How recently the default branch was last touched. Active projects score high; an abandoned repo decays to zero over a year.
Commit cadence
15%How many commits landed in the last 90 days — sustained momentum, not a one-off push.
Issue close ratio
15%The share of issues that get closed — a proxy for responsiveness and maintenance.
Release cadence
15%How many releases shipped in the last 12 months — a steady, dependable cadence.
Stars (log-damped)
15%Raw GitHub stars, heavily log-damped and deliberately low-weighted — stars are the most gameable signal, so they barely move the score.
Dependents / used-by is the one signal we don't score yet — GitHub has no clean public API for it — so its weight is shared across the others for now.
Authenticity (A)
Stars are easy to buy. Rather than trust them, we look for the fingerprints of inflated stars and discount the whole score when we find them. Two repo-level checks, no per-account snooping:
Star velocity
We sample when stars were given. Organic projects gather stars steadily; a sudden lockstep burst far above the repo's own baseline looks bought — and is discounted.
Engagement-to-star ratio
Real stars come with forks, issues, and pull requests. A repo with thousands of stars but almost no activity is a red flag. (Skipped below 200 stars — too small to judge.)
A flagged repo can lose at most 50% — the heuristics are deliberately conservative.
Grades
The 0–100 score is banded into a letter grade. Grade ≥ B is the bar that unlocks posting in a tool's forum.
Why isn't every tool scored?
When we can't compute a score we say "score unavailable" rather than show a number we don't stand behind. A tool is unscored when:
- It's an app. Hosted, closed products have no public repository to evaluate, so they carry no GitHub score by design.
- It has no linked repository. A catalogue entry without a GitHub repo URL has nothing to score.
- It hasn't been evaluated yet. Scores refresh on a schedule; a newly added tool stays unscored until the next run.
- Scoring couldn't complete. A private, deleted, or mistyped repository link is skipped rather than guessed at.
What this is built on
The score is a composite that borrows from established open-source-health research — the weighted-sum shape from the OpenSSF Criticality Score, signal definitions from OpenSSF Scorecard and CHAOSS, popularity-scoring prior art from libraries.io SourceRank, and the bought-star heuristics informed by the StarScout "fake stars" study and Borges & Valente's "What's in a GitHub Star?"
The exact weights and thresholds are a tunable v1 — we expect to refine them as we learn. That's why every score ships with the per-signal breakdown you can expand on any tool page: the number is always shown with its reasons.