How to Open-Source Your Side Project Without Regretting It

You can open-source your side project without regretting it if you do four things before you flip the switch: decide why you are doing it, scan the whole git history for secrets and rotate anything you find, pick a license on purpose, and write down how much maintenance you are actually offering. Then make the repo public, set a small response promise you can keep with a day job, and judge it by strangers who use it, not by stars.

This guide is for people with a day job and a side project sitting in a private repo. It covers the pre-flight, licenses in plain words, the files a public repo needs, maintainer boundaries, a paid hosted version, what to measure, a made-up example, and a 14-day plan. Nothing here is legal advice. If money or an employer is involved, a short call with a lawyer is cheap compared to cleaning up later.

Why are you open-sourcing this side project?

Write the reason down in one sentence before you touch the settings. Each reason asks for different work, and most regret comes from doing the work for the wrong one.

• Portfolio or learning. You want people to read the code. You need a clean history, a clear README, and a license. You do not need to accept contributions at all.

• Trust for a developer-facing tool. Your users want to see what touches their data. You need readable code, a security contact, and a license their company can approve.

• Hoping for contributors. The hardest one. You need contribution rules and review time, and you will still do almost all the work yourself for a long while.

• A hosted paid version with open code. People pay for convenience. License choice and what stays private matter most (more below).

• Parking it. You are done and would rather the code be useful than rot. You need a license, an honest status line, and maybe an archive.

If you cannot pick one, pick "portfolio" and do the minimum. Adding promises later is easy; taking them back is not.

What will open-sourcing not do for you?

A public repo is not a launch. Flipping the visibility shows up as an activity event at most; it does not bring an audience. Open source does not bring users or contributors by itself, and it does not mean people will fix your bugs. Some people will ask for features you will never build. It is fine to say no.

What it can do: make your work easy to evaluate, let technical users trust you faster, and give the thing you built a permanent, linkable home. Good outcomes, just not a traffic spike.

What should you check before you make a private repo public?

This is the part people skip, and the part that causes real regret. Give it one evening. It is not a security audit, just making sure you do not publish things you never meant to.

Secrets in the whole history, not just the latest commit

Deleting an API key from today's code does nothing if it sits in a commit from eight months ago. Every commit goes public with the repo.

• Run a scanner locally. Gitleaks has a gitleaks git -v command that scans a local repo's history (its README says it uses git log -p under the hood). TruffleHog can scan a local repo with trufflehog git file://. and can also try to verify whether a found credential still works.

• Rotate, do not just delete. If a scanner finds a real key, revoke it at the provider and issue a new one. GitHub's own secret scanning docs say to rotate the affected credential immediately, and note that removing secrets from git history is time-intensive and often unnecessary once the credential is revoked.

• Consider a fresh history. My rule of thumb: if the history is messy and nobody needs it, start a new public repo from a clean snapshot and keep the old one private.

Once the repo is public, GitHub helps. Secret scanning runs automatically for free on public repositories and scans the entire git history on all branches. And according to GitHub's push protection docs, push protection for users is enabled by default and stops you from pushing secrets to public repositories. Treat both as a safety net, not your pre-flight.

People's data and internal details

• Test fixtures and seed files with real emails, names, or phone numbers. Replace them with obviously fake ones.

• Database dumps, logs, or screenshots committed "just for a minute".

• Internal URLs, staging hostnames, admin paths, and comments like // TODO ask Rahul at work.

• Your personal email in commit metadata, if you would rather keep it private.

What GitHub changes when you flip the switch

GitHub's page on setting repository visibility lists a few consequences worth reading before you click. When you change a repo from private to public:

• The code is visible to everyone and anyone can fork it.

• Actions history and logs become visible to everyone. Check old workflow runs for printed environment values or noisy debug output.

• Private forks are detached and turned into standalone private repositories.

• Push rulesets are disabled, and existing stars and watchers are erased.

And it is one-way: making it private later does not pull back forks or copies people already made.

Your day-job clause

If your employment contract has an IP or side-work clause, read it before the code goes public, because public code is easy to point at. The SideHunt guide on starting to charge for a side project while you have a day job covers what to look for. Short version: your own time, your own machine, and ask if the clause is vague.

Which license should a side project use?

Pick one on purpose. Here is the short version in plain words, based on the summaries at Choose a License, the site GitHub created to help with exactly this question:

• MIT. Short and permissive. People can use, change, and sell your code, including inside closed products, as long as they keep your copyright and license notice. Good default for portfolio code and small libraries.

• Apache-2.0. Also permissive, but longer, with an express grant of patent rights from contributors and a line saying it does not grant trademark rights. Some companies prefer it for that patent clarity.

• GPL-3.0. Strong copyleft. If someone distributes a modified version, they have to share the source under the same license. Running a modified version as a web service is not treated as distribution, which is the gap AGPL-3.0 closes.

• AGPL-3.0. Like GPL-3.0, plus the network part: if someone uses a modified version to provide a service over a network, they must make that modified source available. People pick it for hosted software so that anyone who changes the code and runs it as a service has to share those changes.

Two things trip people up. First, no license is not the same as open source. Choose a License's page on having no license explains that your code is under exclusive copyright by default, so others cannot copy, distribute, or modify it without risk. GitHub's terms let people view and fork a public repo, but that is not permission to reuse it.

Second, "source-available" is not open source. Licenses like the Business Source License (BSL) or the Functional Source License (which describes itself as a Fair Source license that converts to Apache 2.0 or MIT after two years) restrict some uses for a period of time. Neither appears on the OSI list of approved licenses. The Open Source Definition says a license must not restrict use in any field of endeavor, which is also why "free for non-commercial use only" is not open source. Source-available can be a fine choice; just do not call it open source.

My rule of thumb: MIT if you mostly want people to use it, Apache-2.0 if companies are your users, AGPL-3.0 if it is a hosted product and you want modifications shared back. If you are torn and it matters, ask a lawyer before the first outside contribution, because relicensing gets harder once other people own copyright in parts of the code.

What does a public repo need on day one?

Five small files. None of them needs to be long.

1. README.md that answers three questions in the first screen: what it is, who it is for, and its status (actively used, experimental, or parked). Add install steps and one working example. If you want the README to do some selling too, I wrote about why a GitHub README can outsell a landing page.

2. LICENSE in the root, with the full license text. GitHub's docs on licensing a repository recommend including the file, and its license detection works best when that file is simple.

3. CONTRIBUTING.md with what you will and will not accept. "Bug reports welcome. Small fixes welcome. New features: open an issue first, and the answer may be no." That one paragraph saves you awkward closing comments later.

4. SECURITY.md with a private way to report a vulnerability, like an email address. GitHub has a guide to adding a security policy that sets this file up from the repo's security tab.

5. Issue templates for bugs and feature requests. Ask for version, steps to reproduce, and expected versus actual. Cheapest triage you will ever do.

If you ship releases, keep short release notes too. MakerHunt has a good piece on writing a changelog that brings silent users back if you want notes people actually read.

How do you maintain an open source side project with a day job?

Set boundaries before the first issue arrives. People are mostly reasonable when expectations are written down.

• Make a response promise you can keep. "I check issues once a week, usually on weekends" is honest and enough. Put it in the README.

• Issues welcome, PRs by discussion first. A surprise 2,000-line pull request is a gift you have to review on a Sunday. Asking for an issue first keeps you in control of scope.

• Closing is allowed. Close requests that do not fit with one polite line, no apology essay. Close stale issues after a fair wait.

• Use saved replies. GitHub's saved replies are tied to your account, work in issues, pull requests, and discussions, and you can keep up to 100. Write three: "needs reproduction steps", "out of scope, thanks", and "closing as stale".

• Know the brake pedal. If a thread gets heated, GitHub's interaction limits let you temporarily restrict who can comment, open issues, or open pull requests, for 24 hours, 3 days, 1 week, 1 month, or 6 months. You can also cap how many pull requests a user without write access can have open at once.

Can you keep a paid hosted version if the code is open?

Yes. People pay for not having to run it: hosting, backups, updates. Open code does not stop that.

Keep private: infrastructure config, deploy scripts with real hostnames, environment files, billing keys, and anything with customer data. Do not keep private, if you call it open source: the core features. A crippled demo kills the trust benefit. Say in the README what the hosted version adds.

One more note: a license is about the code, not your product name. Apache-2.0 says outright that it grants no trademark rights. Letting people fork the code is not the same as letting them use your name, so add a README line asking forks to pick a different one.

Should you turn on GitHub Sponsors?

Optional, and do not expect it to pay rent. If people already use the project, a Sponsors button lets them help. According to GitHub's Sponsors docs, GitHub charges no fees on sponsorships from personal accounts, and up to 6% on sponsorships from organization accounts. You have to live in a supported region to receive money, so check the list on that page first.

What should you measure after going public?

Stars are a vanity number. They feel good and tell you very little. Watch these instead:

• Issues from strangers. Someone you do not know reported a bug, which means they used it.

• Forks with commits. Most forks are bookmarks. A fork with real changes means someone adapted it to their own use.

• Installs or signups from the repo. Add a ref or UTM parameter to the hosted-version link in your README so you can count signups that arrive through it.

• Questions that repeat. Three people asking the same thing is a README fix.

Check once a month. If after three months the only activity is you, that is useful information too.

When should you archive the repo?

When you are no longer going to maintain it, say so instead of letting issues pile up. Archiving makes a repository read-only for everyone. GitHub's archiving docs recommend closing open issues and pull requests and updating the README and description first. One honest line at the top of the README is enough: "This project is no longer maintained. It still works as of version 1.4. Forks are welcome." You can unarchive later if you change your mind.

A made-up example: Neha and Formsprig

Everything in this example is made up: the person, the product name, and every number. It is here so you can see the steps in order with concrete details.

Neha is a backend developer with a full-time job. On weekends she built Formsprig, a self-hostable form backend for static sites that emails you each submission. About 40 people pay for her hosted version. Her one-sentence reason: "Developers asked to see what happens to their form data."

Her pre-flight evening: Gitleaks found two old secrets from last year, a test email-provider key and a staging database password. She revoked both, then started a fresh public repo from a clean snapshot because the old history was full of half-finished experiments. She replaced three real customer emails in a seed file and deleted two old Actions runs that printed config values.

She picked AGPL-3.0, because the hosted version is the product and she wants changes in a hosted fork shared back. Deploy scripts and billing code stayed in a private repo. Her README says what Formsprig does, that it is actively used, how to self-host it, and that the hosted version adds backups and spam filtering. Her CONTRIBUTING.md says "issues welcome, PRs by discussion first, I reply on Saturdays."

After two months: 9 issues from strangers, 2 forks with real commits, and 6 hosted signups through the tagged README link. One stranger sent a fix for a time zone bug. She barely looks at the star count.

A 14-day go-public checklist

Times below are planning guesses, not measurements. Spread it over two weekends and a few weeknights.

Common traps

• Deleting a secret instead of rotating it. If it was ever committed, assume it is known.

• Scanning only the latest commit. History goes public with the repo.

• Calling a source-available license open source. Developers notice, and it costs the trust you wanted.

• Promising fast replies. A weekly promise you keep beats a daily one you break.

• A crippled open version. If the core is not in the repo, do not market it as open source.

• Letting a dead repo look alive. Archive it with one honest line.

FAQ

Can I make a private repo public and keep the commit history?

Yes, but scan every commit first and rotate anything a scanner finds. If the history is messy or risky and nobody needs it, starting a fresh public repo from a clean snapshot is simpler.

Which license for a side project is safest if I am not sure?

For most portfolio projects and small libraries, MIT is the common default because it is short and widely understood. If it is a hosted product you plan to charge for, look hard at AGPL-3.0, and ask a lawyer if the stakes are real.

Can I change the license later?

You can relicense code you fully own. Once other people have contributed code, you generally need their agreement, and old versions stay under the old license. That is why it pays to decide early.

Where to start this weekend

Write your one-sentence reason, scan the full history for secrets, and pick a license. That is one evening, and it removes most of the regret. Then add the README and your boundaries, and flip the repo to public when the scanner comes back clean.

When your open source side project is public and ready for people to try, you can list it on SideHunt, where other side-project builders go looking for things like it.