Open source readiness audit

What this audit answers

The open source readiness audit asks whether a repository can be opened to the world—or, if already public, whether it lives openly well. It examines four parts together: legal and content cleanliness, a clear outsider entry path, organized participation, and an honest visible project pulse.

The audit detects pre-publication and ongoing-compliance modes. A mirror or fork that is intentionally out of scope can produce a documented no-op rather than a fabricated community-readiness judgment.

What Guard inspects

Guard reads the license and notices, package metadata, README and usage docs, contribution and intake paths, maintainer contact, conduct and private vulnerability reporting, versioning and release notes, maintenance signals, badges and entry links, and current-tree private or internal residue. Dependency-license compatibility is best-effort and always carries confidence and a verify-yourself boundary.

The audit is language-neutral. Documentation in Russian, Chinese, Spanish, or another language is not a finding by itself. Friction matters only when the intended public audience or official path is inconsistent or inaccessible to outsiders.

The 14 criteria

The scorecard covers license presence and conformance; dependency-license compatibility; project identity; internal infrastructure residue; private or personal content; README completeness; usage and interface docs; honest entry-point signals; contribution process; maintainer channel; issue and change intake; conduct and vulnerability reporting; versioning and release notes; and maintenance evidence.

Conventional filenames help discoverability but are not pass/fail requirements. A coherent answer elsewhere can satisfy the question; an empty CONTRIBUTING.md cannot.

How the score works

Applicable 0–5 criterion points are normalized to 0–100. Confirmed findings subtract 20 for critical, 8 for high, 3 for medium, and 1 for low impact, with total deductions capped at 35. Credit-only signals such as funding, governance extras, community chat, badges, or release automation cannot become penalties merely because they are absent.

Missing, non-open, mismatched, or contradictory licensing caps the score at 39. In pre-publication mode, blocking internal/private content or a high-confidence incompatible dependency license also caps it at 39; in compliance mode, already exposed private content or incompatibility caps it at 59. No working maintainer channel, or a README that fails the basic what/why/how-to-use stranger test, caps the score at 59. Widespread dishonest badges or entry links cap it at 69.

Limitations and boundaries

This is not legal advice, a secret-history scan, a deep privacy review, a CI/CD audit, a dependency-freshness audit, or a test-quality audit. It evaluates the current repository’s outside-world contract and flags where specialist or owner verification is still required. Private values and secret-shaped facts are redacted.

The audit is read-only and does not publish the repository, choose a license for the owner, or create public channels.

Improvements and reruns

Pre-publication work should remove blockers first: make the licensing decision explicit, remove or replace private residue, establish a truthful outsider entry, and document a reachable maintainer and private security channel. Ongoing projects may then improve contribution intake, release notes, maintenance status, or discoverability.

Legal choices, public communication, and disclosure policy stay owner-controlled. Rerun after the repository’s public contract changes and verify the current tree, links, metadata, and intended audience again.