Open-sourcing an old Unity game is not a button

Maintenance, not a relaunch

This month I re-shipped a game I first released in 2018. Glass Breaker is a small Unity arcade title: brick-breaker mechanics, one-finger controls, lasers, black holes, and a score that gets rude faster than it should. The 2026 update did nothing glamorous on purpose. It moved the project forward to a current Android build, shipped as an Android App Bundle, removed every ad, removed network access, and re-attested the Play Store data safety form.

Maintenance, not a relaunch.

When you keep an old project alive, people assume the next move is obvious. Put it on GitHub. It is eight years old, it is not a commercial secret, and nobody is reverse-engineering my brick colors for shareholder value.

I'm not going to.

Not because the code is precious. The honest answer is duller and more useful: open-sourcing an old game is not a button. It is an audit, an asset inventory, and a cleanup pass on a project that was built to ship a game, not to teach from a public repository. "Keep it running" and "publish the source" are different promises.

Here is where the cost actually lives.

The licensing reality of a 2018 indie project

The first wall is not technical. It is the licenses on everything that is not your code.

A 2018 indie game is rarely 100% hand-made. Glass Breaker was built like many small Unity games of its time: original game code, Unity project settings, engine packages, visual effects, audio, fonts, and small helpers that made sense when the goal was to ship a compiled Android game.

That last phrase matters: a compiled game.

Many asset licenses are perfectly fine for shipping a finished product and much less fine for redistributing the raw project. A Unity Asset Store package, a sound effect library, or a font license may let you include the work inside an APK or AAB. That does not automatically mean you can upload the source files to GitHub so anyone can download, extract, and reuse them.

So "just open source it" quickly becomes: find every third-party asset still in the project, confirm whether its license allows source redistribution, replace anything that does not, or strip those files and publish a repo that does not actually build.

The last option is honest, but not very useful. A non-buildable game repo is mostly a museum of missing files. The better option is a real art/audio replacement pass, but that is no longer open-sourcing the old game. That is making a new public edition of it.

Possible, yes. Worth doing for this project, no.

The real audit: old-project archaeology

The stronger story is older and more ordinary: Glass Breaker came back from the kind of backup every long-running developer eventually recognizes. An old Unity project. Old settings. Old assumptions. A live Google Play listing attached to a game that had to keep its install history, package name, signing path, and store compliance intact.

That is not the same job as cleaning up a fresh repo.

Old game projects carry sediment. Not dramatic sediment, usually. Just years of decisions that made sense at the time: Android settings from an older target API era, plugins and generated files that may no longer mean what they meant in 2018, player settings where one checkbox can decide whether the app appears with a launcher icon, architecture settings that affect which devices can install the game, manifest rules that must remove permissions without breaking the build, UI references that shift under newer timing, and save data assumptions that become visible only when a real player has old records on disk.

One of the small examples was the Android launcher itself. The build could compile, the game could run, and the Play upload could still fail the practical test that matters to a player: install it from Google Play and find the icon where Android expects it. Fixing that was not a heroic rewrite. It was manifest and player-setting work, which is exactly the kind of old-project detail that disappears from memory until the store, the device, or an existing install reminds you.

That is the part people underestimate. The hard work was not "can this compile?" The hard work was "can this old thing compile, install from Google Play, show its launcher icon, keep its data story honest, avoid network permission, preserve real scores, and not introduce a new crash while we modernize it?"

That is maintenance archaeology. You brush away just enough dust to make the artifact stable. You do not polish every bone into a productized SDK.

For Glass Breaker, the useful work was concrete: remove ads instead of replacing them, keep the game fully offline, fix the Android manifest so the app launches correctly from Play, verify the final build does not request INTERNET, harden leaderboard and checkpoint behavior, reduce mobile hitches from unnecessary saves, allocations, and object churn, and keep the code private so the source tree can remain a working project, not a public teaching object.

That is the real reason this is an article about maintenance rather than a victory lap about source code. The project did not need a public repo. It needed a small, careful resurrection.

The maintenance log

The work was easier to reason about once I stopped treating it as a relaunch and wrote it down like a maintenance log.

What survived: the core game loop, the one-finger controls, the score chase, the existing package identity, the Play Store listing, and the old local data that still had to make sense after the update.

What broke: Android-era assumptions around manifests, launcher behavior, target API requirements, generated files, and a few timing-sensitive gameplay paths that only became obvious on newer builds and real devices.

What was removed: ads, network access, stale store-data assumptions, unnecessary save pressure, and the permissions that no longer matched what the game actually does.

What was modernized: the Android build pipeline, App Bundle delivery, Play Store compliance, manifest behavior, data safety posture, leaderboard and checkpoint behavior, and the performance profile around allocations and object churn.

That list is also a useful sanity check for open source. If the maintenance log is mostly platform archaeology and asset ownership questions, a public repository is not automatically the best next artifact. Sometimes the most honest output is the working build.

Maintenance and open source are different promises

Maintaining a project and open-sourcing it feel adjacent. Both sound like responsible things to do with old software. But they are different commitments with different costs.

Maintenance is bounded. For Glass Breaker it meant: keep it installable, keep it compliant, remove ads, remove network access, and do not break existing players. It has a clear end state. Ship the update. Verify the build. Walk away with the artifact healthier than it was.

Open source can be bounded, but only if you are explicit about the boundary. Without that, it tends to create a support surface: the asset audit, the replacement work, a correct license, a buildable setup, documentation, and then the public questions that come with it. Issues. Pull requests. "Why doesn't this build?" from someone who did not read that the assets were stripped. The cost does not end when the repo becomes public. That is when it starts.

The cost-benefit split is simple: maintenance gives players a working, ad-free, offline game with bounded cost. Open-sourcing this particular game would create a partial repo or require a new asset pass, with lower value and open-ended cost.

That does not mean open source is bad. It means it is a promise, and promises should match the artifact.

I like open source when a project is built for it from the start: clean ownership, minimal licensed assets, no hidden build assumptions, and a reason for someone else to read or reuse the code. A tool, a linter, a small engine utility, a project hygiene checker: those make sense in public.

A 2018 mobile arcade game assembled to ship on Android was born to be played. Keeping it alive honors that. Publishing a half-stripped source tree would mostly honor a slogan.

Where this leaves Glass Breaker

Glass Breaker stays on Google Play, free and ad-free, with no network access and no in-app purchases. The source stays private, not because it is secret, but because the responsible version of "open source" is more expensive than the responsible version of "keep it running."

If you are looking at an old project of your own and feeling the pull to open it, do the asset inventory first. Then do the boring archaeology: build settings, manifests, package names, signing path, save data, platform requirements. You may still open it. But you will know what you are signing up for before you make the promise in public.

For this game, the promise I wanted to keep was simpler: keep it playable, keep it offline, and leave it better than I found it.