Sign in Subscribe

What CHOMPI's open-source exit teaches anyone who self-hosts

What CHOMPI's open-source exit teaches anyone who self-hosts

On 29 September 2026, the people behind CHOMPI announced two things at once. CHOMPI is a small sampler and tape-music instrument made by CHOMPI Club and sold by Chase Bliss. It is now discontinued because, in their words, "it would be too expensive to keep making them going forward." It is also now open source: the firmware source and the hardware files are on GitHub under the MIT licence, so anyone can build their own or keep an existing one alive.

That is a kind ending for a well-liked instrument, and the music press has covered it well. I want to look at the part that applies to the rest of us, the people running Docker stacks, home servers and local AI. You cannot count on a vendor to keep a product alive. When it goes, the only question that matters is whether you own a copy you can run yourself.

Why self-hosted alternatives matter before you need them

Products get discontinued. Community editions get dropped. Licences change with a new major version. Subscriptions get repriced and free tiers shrink. None of this needs a villain. Usually it is a company doing the sums and deciding something no longer pays for itself, which is exactly what happened with CHOMPI.

We saw the same shape of event in our own world when Portainer 3.0 dropped its community edition. People who had built their container management around it suddenly had a decision to make, on someone else's timetable. The ones who had already looked at self-hosted alternatives had a calm week. Everyone else had a scramble.

So here is the rule I work by: an exit plan is something you set up before you need it. Once the announcement lands, you are working with whatever you saved, exported and wrote down beforehand. Loyalty to a product does not carry it forward. A copy you can run does.

The exit-plan checklist

I run through this list for anything I self-host or depend on, paid tools included. It takes a few minutes per tool once you know where to look.

  • Is the licence one you can verify? Look for a LICENSE file in the repository, not a line on a marketing page. MIT, Apache 2.0, GPL and AGPL are well understood. A custom licence or "free for personal use" can change with the next release.
  • Can you run it yourself? A self-hosted option that needs the vendor's licence server or cloud login to start is not really yours. Check that it runs without an account, and ideally without internet access.
  • Can you export your data? Find the export button or the API endpoint and actually try it once. An export you have never tested is a guess.
  • Are the file formats readable without the vendor? CSV, JSON, Markdown, SQLite and plain database dumps open in plenty of other tools. A file that only one app understands is still a lock, even if it sits on your own disk.
  • Have you kept a copy of the installer or image? Pin a version and keep it. A tag on a public registry or a download link on a vendor site can disappear. For Docker, that means saving the image somewhere you control.
  • Is there a community that will outlive the company? Look at who commits to the repository, whether there are active forks, and whether users answer each other in issues or a forum. If every commit comes from one company, the project lives or dies with that company.

The image step is the one people skip, and it is the easiest. This is all it takes for a Docker image:

docker pull vendor/app:2.4.1
docker save vendor/app:2.4.1 | gzip > app-2.4.1.tar.gz

# later, on any machine:
gunzip -c app-2.4.1.tar.gz | docker load

Keep that archive with your backups, next to a note of the config and volumes the container needs. If you run a private registry, mirroring the image there works just as well.

What CHOMPI did right, and what it does not promise

The CHOMPI makers gave the files away before walking away. This was not a vague promise to open things up later. It is a public GitHub repository, CHOMPI-Club/CHOMPI, described as "All of the production files, hardware and firmware, that make up the CHOMPI Sampler". In their words, it is "everything you need to edit firmware, create your own firmware from scratch, and even physically build a DIY CHOMPI of your own", down to blank enclosure panels.

It came with a clear licence. The repository is MIT licensed, with trademarks excluded, and the CHOMPI artwork is left out of the release. That is easy to understand: you can use the code and the hardware design, but not the name or the art.

They also left a starting point. Alongside the files they released WAVE, a beta firmware that turns CHOMPI into an 8-voice wavetable synthesizer, meant as somewhere for open-source work to begin. They say plainly that it "probably has a bug or two", which I find more reassuring than a polished launch.

Files, a licence and a first step. That is a template worth copying. If every vendor did this on the way out, a discontinued product would hurt a lot less.

Now the honest half. The makers will keep providing support and repairs for existing CHOMPI owners, but they give no support for DIY hardware or firmware built from the files, and they will not be doing any more file updates. As they put it, "We're handing CHOMPI over to the community." From here, the project only moves forward if people pick it up.

That is true of every open-source release. Open source is an opportunity, not a guarantee. It means the work can continue, not that it will. The same goes for any self-hosted tool you choose as a replacement. The licence protects your right to run it, but somebody still has to maintain it, and one day that somebody might be you.

What to do this week

Do not try to audit your whole stack. Start with one tool and keep it small.

  1. Pick the one tool you would miss most. The one whose loss would ruin your week: your password manager, photo library, notes app or reverse proxy.
  2. Open its docs and its repository. Find the licence file, read the first few lines and write down what it is.
  3. Find the export path and run it once. Then open the result in a different tool to check it is usable.
  4. Save a copy of the version you run today. The image, the installer or the release archive. Store it with your backups.
  5. Write down what you would run instead. One or two self-hosted alternatives, plus a line on how you would move the data across.

Put the answers in a plain text file with the rest of your server notes. That is about twenty minutes now against a scramble later. Next month, do the next tool on the list.

If you would rather have help

Some tools are tangled into everything else, and planning the way out is a job in itself. If you would rather have someone plan that exit route, or migrate you off a rented tool onto something you run yourself, that is the work I do. You can see the details on my services page.

Fiverr: hiteshsaini459 · Upwork: hiteshsaini25