Methodology

For every approved project we take a daily snapshot of public GitHub metrics: stars, forks, open issues, open pull requests, merged pull requests over the last 30 days, default-branch commits over the last 30 days, the latest release date, and the last push date. Open issue counts exclude pull requests; commit activity is the default branch.

When a metric is genuinely unavailable from GitHub, we store it as null — never as zero. A missing value and a real zero mean different things, and conflating them would distort every downstream comparison.

Each project has at most one snapshot per UTC day. A second successful sync on the same day updates that day’s snapshot in place (preserving when it was first created); snapshots from previous days are never overwritten. This history is what makes growth measurable.

To measure 7-day and 30-day growth on a score date D, we pick a baseline snapshot for each window: the most recent snapshot on or before D − 7 (or D − 30). If no snapshot is that old yet, we fall back to the earliest snapshot we have and record the actual observed window length.

We never project a short observation period as if it covered the full window. A project observed for three days is reported as a three-day window, not extrapolated to seven.

For each available signal we convert raw values into a cohort percentile from 0 to 100 using a midrank method, so equal raw values receive equal percentiles. A signal that only one project has receives a neutral percentile of 50.

Each percentile is multiplied by its weight. Because some projects are missing some signals, we renormalize by the total weight actually available, and require at least 60% of the total weight to be available before publishing a score. The result is rounded to one decimal place. There is no winsorization, machine learning, hidden heuristic, or manual bonus.

A project needs an earlier snapshot to measure growth, at least 60% of the signal weight available, and at least one recent development-activity signal to be eligible. Until then it is marked newly tracked with no score — we never assign a misleading zero.

GitHub activity is a proxy for momentum, not for quality. Stars can reflect hype; a slow commit rate can reflect maturity rather than abandonment. Small projects and niche categories have thin cohorts, which makes percentiles noisier. Treat these rankings as a starting point for discovery, not a verdict.