Tier 10/ 8
Best practices0/ 35

Is your EIP ready for open source?

Audit your repo honestly, as if you were an outside developer discovering it. Only tick what is true today.

Tier 1: 8 points missing

Tier 1 — The minimum to be open source0 / 8

Without these 8 points, your project isn't open source: it's merely public. This is Thursday's goal for every team.

  • LICENSE file with a recognized open source license (MIT, Apache 2.0, GPL, AGPL…)required
  • Repo publicly accessible, no invitation neededrequired
  • README that says what the project does and how to run itrequired
  • No secrets in the Git history (.env, API keys, tokens)required
  • Dependencies declared and pinned (package.json + lockfile, requirements.txt, Cargo.lock…)required
  • Runtime version specified (Node, Python, Rust, Java…)required
  • No absolute paths or hardcoded configuration in the coderequired
  • An entry point for contributors: open issues or a CONTRIBUTING.mdrequired

Tier 2 — Best practices

What makes a project not just open, but used, maintained and joined by others. Pick three things to work on, not thirty.

Git history0 / 6

An outsider should be able to read the project's history and trust what they find there.

  • Readable commit messages (no “fix”, “wip”, “final v2”)
  • Atomic commits: one intent per commit
  • node_modules / vendor / dist / .DS_Store / IDE files not committed
  • .gitignore present and complete
  • No large binaries committed
  • Main branch protected, everything goes through reviewed PRs

Documentation0 / 5

In 30 seconds, a stranger should understand what it is, how to run it, and how to help.

  • Installation instructions tested on a clean machine
  • Usage examples (and screenshots if there's a UI)
  • Detailed CONTRIBUTING.md: conventions, PR process
  • Code of Conduct
  • The documentation matches the current code

Usable by an outsider0 / 2

The ultimate test: someone else runs the project in under 15 minutes without asking you a single question.

  • .env.example provided
  • A docker-compose.yml that starts the project and its services (database, cache, mail…)

Tests0 / 5

Tests are a contributor's safety net: without them, nobody dares touch the code for fear of breaking everything.

  • Unit tests on the business logic (functions, services, isolated components)
  • Integration tests: modules working together and with their real dependencies (database, APIs, files)
  • Functional / end-to-end tests that replay the key user journeys (Playwright, Cypress, Selenium…)
  • A single documented command runs all the tests (npm test, make test, pytest…)
  • Tests run in CI on every PR, and a failing test blocks the merge

Quality and maintenance0 / 6

A project that can be neither tested nor updated won't outlive its creators.

  • CI in place and green
  • Linter / formatter configured, consistent style
  • Dependencies with no known vulnerabilities, Dependabot or Renovate enabled
  • No dead code or old_ / backup_ / test2.js files
  • External issues and PRs handled
  • SECURITY.md: how to report a vulnerability

Structure and modularity0 / 3

What is open should be reusable independently of the rest.

  • At least one reusable building block identified and isolatable
  • Business logic separated from infrastructure and UI
  • Semantic versioning, tags and published releases

Community and governance0 / 6

An open source project is first and foremost people who know where and how to help.

  • More than one person able to maintain the project (bus factor > 1)
  • Issue and PR templates
  • Public roadmap or vision
  • “Good first issues” written up to attract contributors
  • Identified maintainers (CODEOWNERS or a section in the README)
  • A place to talk (Discussions, Discord, mailing list…)

Send your audit

A summary PDF is generated from your answers: it downloads automatically and is sent to your coach at the same time.