Releasing an Open Source Project

For making a repository public for the first time — a new project or a formerly private one. Ordered so that nothing sensitive is exposed before the scan, and nothing is announced before it's usable.

Goes straight to the people who keep this checklist current. No account needed.

Describe your situation — plain language is perfect

Assembled only from these vetted items — every kept item traces back to the original.

Before anything is public

Scan the entire git history for secrets, not just the current treeUse gitleaks or trufflehog. A key deleted in commit 50 is still sitting in commit 49, and bots scan newly public repos within minutes of creation.
Rotate every credential the scan findsTreat found as compromised. Rewriting history is not enough — you cannot prove no one has a clone.
Purge private data from history if previously private repoInternal hostnames, customer data, colleagues' emails, embarrassing commit messages. git filter-repo does this; note it rewrites every commit hash, so do it before anyone else has cloned.
Choose a license and add a LICENSE fileNo license means all rights reserved — nobody can legally use the code. MIT and Apache-2.0 for permissive (Apache adds an explicit patent grant), GPL for copyleft.
Verify your dependencies' licenses are compatible with yoursYou cannot ship GPL code inside an MIT project. Check transitive dependencies too — license checkers exist for every ecosystem.
Confirm you have the right to publish if employedMany employment contracts claim IP created on company time or equipment. Get written approval or use your employer's open source release process — retroactive permission is much harder.

Make it usable

Write a README with what it does, how to install it, and a working example — all in the first screenfulA visitor decides in about thirty seconds. A copy-pasteable example above the fold beats three paragraphs of philosophy.
Verify the install instructions on a clean machine or containerYour dev machine has invisible dependencies the README doesn't mention. A fresh container is the only honest test.
Add a CONTRIBUTING guide: how to run the tests, what PRs are welcomeThe second half matters most — saying what you won't merge saves contributors wasted evenings and you awkward rejections.
Add a SECURITY.md with a private reporting channelYou want vulnerability reports in your inbox, not in a public issue with a proof of concept attached.
Adopt a code of conduct if expecting contributorsThe Contributor Covenant is the de facto default; adopting it takes five minutes and deciding disputes without one takes much longer.
Set up CI running the tests on every pull requestContributors can't run your private test setup. Public CI is what lets you review a stranger's PR without pulling it down first.
Enable branch protection on the main branchRequire the CI check to pass; block force-pushes. Cheap insurance the day a second maintainer arrives.

Version and publish

Adopt semantic versioning and start at 0.1.00.x tells users the API may still change; 1.0.0 is a compatibility promise — don't make it before you mean it.
Start a CHANGELOG in Keep a Changelog formatWritten for humans deciding whether to upgrade, not a dump of commit messages.
Tag the release in git with a version tag matching the package versionv0.1.0 — tags are what let users and tooling map an installed version back to source.
Check the package name is available on the registry if publishing packageCheck npm/PyPI/crates.io before the name is in your README, docs, and announcement. Avoid names one typo away from popular packages.
Build the package and inspect exactly what's inside if publishing packagenpm pack --dry-run or python -m build, then list the contents. Packages routinely ship .env files, test fixtures, and junk — use an explicit include list, not excludes.
Enable 2FA on the registry account before publishing if publishing packageA hijacked publisher account is a supply-chain attack on everyone who installs your package.

Announce

Write the announcement around the problem it solves, not the implementation"I kept needing X, so I built..." travels; "a Rust library that uses..." doesn't, except to people who already wanted it.
Post where your users already are, then stay for the first few hoursShow HN, the relevant subreddit, the ecosystem's forum or Discord. Answering early questions in the thread is half the launch.
Respond to the first issues and PRs within a dayThe first week sets the community's expectations permanently. A fast "thanks, looking at it" costs nothing and keeps contributors.
Add repository topics and a one-line descriptionIt's how GitHub search and topic pages find you after the announcement traffic fades.

Essential is a lens, not a shorter list — the file is identical, every hidden step is one tab away, and the marker travels with the item into forks, personalized copies, and the .json.