Code & Distribution
22% of overallAre the public repos finished products, and do people actually install the packages?
What it measures
We snapshot every public repo on the org and compute an average polish score (README presence and depth, license, description, topics, default branch, releases, archived ratio). We then look up all declared package sources — npm, PyPI, NuGet, RubyGems, Crates.io, Packagist, Go modules — and aggregate download counts.
Why it matters
Polished repos are how new developers form their first impression. Package adoption is the clearest proof that the code is actually shipping — a star is a bookmark, a download is a runtime dependency.
Sub-metrics
| Metric | What we read | Weight | Source |
|---|---|---|---|
| Average repo polish | README, license, description, topics, releases, archived flag | 50% | GitHub REST |
| Package adoption | Total downloads across all linked registries (log10-scaled) | 50% (if any registry is linked) | npm, PyPI, NuGet, RubyGems, Crates, Packagist, Go |
How it's weighted
Repo polish and package adoption count roughly the same. If an org publishes to no registries at all, the score leans entirely on how finished the public repos look.
Best practices
- Ship a README with a quickstart that fits in the first screen — install, import, one runnable snippet.
- Pin a LICENSE file at the repo root. No license = unusable for most teams.
- Add 3–5 topics so the repo shows up in GitHub search and on org pages.
- Cut tagged releases — even a one-line CHANGELOG beats nothing.
- Publish to the primary registry for your ecosystem, and link it from the repo's About box.
- Mirror to secondary registries where your users live (e.g. a .NET wrapper on NuGet, Python bindings on PyPI).
- Archive abandoned repos so they stop dragging the org's average polish down.