Code & Polish
22% of overallAre the public repos well-structured, and do real users actually depend on the packages?
What it measures
This pillar measures three things: how polished and well-structured the org's public repos are, how many people install the packages it publishes (weighted by package age), and how many other projects depend on those packages and repos.
We probe nine package registries — npm, PyPI, NuGet, crates.io, RubyGems, Packagist, Docker Hub, Homebrew, and the VS Code Marketplace — and only count packages whose metadata links back to a repo on the org's GitHub.
Why it matters
A polished repo with a clear src/ layout, tests, and CI tells a developer "this is maintained." A package with 10M downloads on a 1-year-old library is a much stronger adoption signal than 10M downloads on a 10-year-old library that's coasting on legacy users. Dependents prove other code is actually built on top of yours.
Sub-metrics
| Metric | What we read | Weight | Source |
|---|---|---|---|
| Repo health | Polish (README, license, topics, releases, archived ratio) + structure (src/lib layout, tests, CI, package manifests, docs) | 50% | GitHub REST + repo tree |
| Adoption (age-adjusted) | Sum of monthly_downloads ÷ log₂(age_months + 2) across all verified packages, then log10-scaled | 35% | npm, PyPI, NuGet, crates.io, RubyGems, Packagist, Docker Hub, Homebrew, VS Code Marketplace |
| Dependents | Count of packages and GitHub repos that depend on the org's top packages and repos | 15% (best-effort; skipped when probes time out) | npms.io · NuGet · GitHub /network/dependents |
How it's weighted
Repo health is the foundation (50%). Adoption is the proof point (35%) and is age-adjusted so newer packages aren't penalized for not having a decade of accumulated installs. Dependents (15%) is a best-effort signal — when GitHub's dependent network is slow or blocked we keep the rest of the pillar intact instead of zeroing it out.
Best practices
- Ship a README with a quickstart that fits in the first screen — install, import, one runnable snippet.
- Use a clear src/ or lib/ layout. A tests/ folder and CI config in .github/workflows visibly raise structure score.
- 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.
- Cut tagged releases — even a one-line CHANGELOG beats nothing.
- Publish to the registry your ecosystem actually uses (crates.io for Rust, RubyGems for Ruby, Packagist for PHP).
- Mirror to secondary registries where your users live (.NET wrapper on NuGet, Python bindings on PyPI, CLI on Homebrew, extension on the VS Code Marketplace).
- Link the package back to the GitHub repo in its registry metadata — we only count packages we can verify the org owns.
- Archive abandoned repos so they stop dragging the org's average down.