Should You Open Source Your Product Before Shutting Down?

When you announce a shutdown, a certain kind of user always asks the same question: "Will you open source it?"

Sometimes it's a reasonable request. Sometimes it's not. Here's how to think through the decision.

Why People Ask

The people asking want one of a few things:

1. Self-hosting — to run the product themselves after you shut it down
2. Learning — to study how you built it
3. Forking — to continue developing it as a community project
4. Preservation — so the work isn't lost

These are legitimate reasons, and for some products — especially developer tools, community platforms, and niche utilities — releasing the code is genuinely the right thing to do.

The Real Costs of Open Sourcing

It's not as simple as pushing to GitHub. Consider:

Security audit: Your codebase probably has hardcoded credentials, API keys, or secrets that need to be removed before publishing. Shipping with even one secret embedded is a real problem.

Cleanup: Most production codebases have TODO comments, temporary hacks, and embarrassing shortcuts. You can ship it as-is, but expect that reaction.

Legal review: If you used third-party libraries with restrictive licenses, or built on top of proprietary SDKs, you may have licensing conflicts that prevent open sourcing. If you had investors, some term sheets require approval before releasing IP.

Ongoing support expectations: Once the code is public, people will file issues, ask questions, and expect responses. "We're not maintaining this" is a valid answer, but you'll still get pinged.

Competitive concerns: If you're building something next, think about whether your old codebase reveals architectural or business approaches you'd rather keep private.

When Open Sourcing Makes Sense

Developer tools. If you built a CLI, a library, or an API layer that developers integrated into their workflows, open sourcing it respects the investment they made in your tool.

Community products. Forums, social platforms, and community tools often mean more to their users than to the founders. Giving the community the tools to continue (even if they rarely do) is a generous act.

Games. As discussed in our guide on shutting down games, releasing server software or client code is one of the most goodwill-generating things a game studio can do.

When users have critical data. If users have years of data in your system, open sourcing lets them (or a technical community member) build an export or migration tool.

When It Probably Doesn't Make Sense

When the code is genuinely messy. Releasing truly embarrassing code is more harmful than helpful. If you're going to do it, at least spend a few days doing basic cleanup.

When there are legal complications. If you're not sure about the licensing situation, don't rush it. A license review can take a few days and is worth doing.

When it replicates proprietary algorithms or data. If your core IP is in the model, the data, or the algorithm, the UI code may not be interesting enough to release on its own.

When you plan to rebuild it. If there's a chance you'll relaunch under a new name, releasing your code helps potential competitors more than it helps your users.

The Middle Ground: Read-Only Archive

If you can't or won't fully open source, consider:

• Exporting user data and making it available for download
• Publishing documentation about your architecture and decisions
• Writing a technical post-mortem that captures what you learned
• Making the client-side code available (if the backend has IP you want to protect)

Something is better than nothing. The community remembers the effort.

How to Actually Do It

If you decide to go ahead:

1. Run git grep -r "password\|secret\|key\|token" and audit every match
2. Add a LICENSE file (MIT is the most permissive and widely understood)
3. Write a README.md that explains what the project is, that it's unmaintained, and links to your shutdown page
4. Archive the repository on GitHub so it can't receive new issues (or be clear in the README that you won't be responding)
5. Announce it in the same places you announced the shutdown

Label it clearly as unmaintained. "We're not fixing bugs or reviewing PRs, but you're welcome to fork it" is an honest and reasonable position.

The Default Answer

If you're unsure, open sourcing is usually the better choice. The upside (goodwill, legacy, utility to users) typically outweighs the downside. The code you shipped is what it is — releasing it doesn't change that. And the community that built their workflows around your tool deserves the best possible exit you can give them.