Project-quality score
The ranking metric (“projectrank”) that best-of-generator computes for every entry in a best-of-lists list. It is a sum of points, not a normalised index, and the project says so: “The score only has a meaning when it is compared to the project-quality score of other projects.”
How it is computed
Read from src/best_of/projects_collection.py on 2026-08-10. Nine binary checks award one point each:
- homepage and description present
- a GitHub URL present
- a licence present, plus a second point if it is a common permissive one
- more than one release
- the latest stable release parses as semantic versioning
- that release is under 6 months old
- the repository was updated in the last 3 months
- the project is at least 6 months old
Everything else enters logarithmically — round(log(n)/2) − 1 for stars, forks, contributors,
commits, watchers, closed issues and monthly downloads; round(log(n)/1.5) for dependent projects and
recent (90-day) commits. Several of those terms subtract a point when the count is zero. Placings
are then relative: within each category, the 90th percentile of scores earns 🥇, the 60th 🥈, the rest
🥉.
What the shape of it means
The design is legible from the arithmetic. Logarithms flatten popularity — going from 100 stars to 1,000 is worth about one point — while hygiene facts (a licence, a changelog that looks like semver, a commit this quarter) are worth one point each and are free to earn regardless of size. A small, tidy, actively maintained project can out-rank a large abandoned one, which is exactly what star-ranking cannot do.
The reverse is also visible: the score cannot see a line of code. Nothing here reads the README for accuracy, runs the tests, checks the security history, or asks whether the software does what it claims. It measures the artifacts of a well-run repository, and a project can produce all of them without being any good. The generator’s own documentation makes the concession in one sentence: “This calculation is just chosen by experience. There is no scientific proof that this really reflects the quality of a project.”
Two structural biases follow from the metric list. Packages published to a registry collect download and dependent-project points that an application never can — a desktop window manager or an Android keyboard has no npm dependents — so the score reads libraries better than the end-user software this spoke is about. And the recency terms mean a stable, finished, correct project decays in rank simply by being finished.
Against ranking by stars
This is the corpus’s counter-example to openalternative, which sorts 500+ entries by star count alone. Applied to this spoke’s own sources, the difference is directional rather than proven — nobody has run it — but the terms say what would move: proton-wine-andrevto (34★, daily automated builds, permissive-licence and recent-commit points) gains where the star term barely registers, and ever-gauzy‘s 27,198 commits and closed-issue history finally count for something.
That is the useful claim and the limit of it: a better metric than stars is still a metric over repository metadata, and every question this spoke’s synthesis has open — does the privacy claim hold, who runs it, what happens when the maintainer stops — is invisible to both.