Open-Sourcing a Repository

Prepare a repository for public release so that an outsider with no prior context can build, use, and contribute to it, and so that nothing sensitive ships with it. Work through the steps in order; the secrets audit comes first because its outcome (keeping vs. recreating the repository) affects everything after it.

When to Use

• Making a private repository public
• Auditing an existing public repository for release quality ("make it official")
• Choosing a license for a project
• Setting up packaging, versioning, or release automation ahead of a public launch

When NOT to Use

• Routine development on an already-released project (no release event)
• Auditing third-party code for vulnerabilities (use a security-review skill)
• Publishing a package from a repository that will stay private, only the release-management steps apply; skip the rest

Workflow

Step 1: Detect the organization profile

bash {baseDir}/scripts/detect_org.sh

The script inspects git remotes and recent committer emails, and prints a profile name. If it prints trailofbits, read references/trailofbits.md now and apply its license policy, publishing accounts, and process notes throughout the remaining steps. If it prints generic, proceed with the generic guidance alone. If the user says the detection is wrong, trust the user.

Step 2: Audit for secrets, before anything else

A repository that has ever contained secrets (API keys, credentials, client data) should not be flipped public. History rewriting is error-prone and does not reach forks, caches, or CI artifacts. The reliable fix is a fresh repository: copy the current tree over, commit, and archive the old repository privately.