Community health measures whether a repository is set up to receive users and contributors: the standard files that tell a newcomer what the project is, on what terms it may be used, and how to participate. These files are the difference between a codebase and a community.
- Category: Community & Adoption (35% within category)
- Weight in overall index: 6.3%
- Metric key:
community_health
How the value is computed
A weighted checklist of the standard files, each present or absent (the license row can also earn partial credit — see below):
| Component | Weight |
|---|---|
| README | 22.5 |
| License | 22.5 |
| CONTRIBUTING guide | 18 |
| Code of conduct | 13.5 |
| Issue template | 7.2 |
| PR template | 6.3 |
How the license is detected
License presence is checked once, from three sources considered together: the repository's own license metadata, GitHub's community profile, and OpenSSF Scorecard's published, tool-neutral License check. A file that any source sees counts as present — the sources disagree on roughly 1% of repositories, and a single unavailable endpoint must not report a license as missing.
The result is one of three states:
| State | Meaning | Credit |
|---|---|---|
| Standard | A recognized license, identified by SPDX code | 22.5 |
| Custom | A license file is present, but its text is not a recognized license | 16.9 |
| None | No source found a license file | 0 |
A custom license is a real license and earns most of the weight. It does not earn all of it: a license automated tooling cannot identify is a genuine obstacle to adoption, because policy tooling, corporate review and package registries all key off recognized identifiers, and a reader cannot establish what they are permitted to do without reading the text themselves. GitHub reports this case as NOASSERTION — a license it found but could not classify, which is not the same as no license at all.
The Scorecard result remains a component of the security metric; here it is one input among three, shown simply as License.
Why these files carry weight
- README and license are load-bearing. A repository without a README is unadoptable; a repository without a license is legally unusable in most organizations — no downstream legal team will approve a dependency whose terms are undefined. Together they carry half the metric.
- CONTRIBUTING and a code of conduct convert drive-by interest into sustained participation, which feeds directly into the continuity measured by maintainer resilience.
- Templates raise the signal quality of incoming issues and pull requests, reducing maintainer triage load — a small but real factor in the responsiveness a project can sustain.
Reading the result
- The checklist is scale-independent: a week-old project can reach 100 before its first star, and a famous project missing a license reads visibly incomplete. That is intended — this metric measures preparation, not traction.
- Presence is what is verified, not prose quality — see the measurement honesty note in signals, not warranties.
Improving the value
Every component is directly actionable within an hour:
- Write a README covering what the project does, installation, and a minimal example.
- Add a
LICENSEfile with a recognized SPDX license. - Add
CONTRIBUTING.md, aCODE_OF_CONDUCT.md, and issue/PR templates under.github/.
This is typically the fastest metric to move in the entire methodology.
Related: Community & Adoption · documentation