Turning an AGPL panel into a product, in public
What it actually takes to fork an open-source project into something with its own name — the telemetry, the revenue placements, the naming, and the parts that went wrong.
GambaOS started as a fork of ClawPanel, an AGPL-licensed control panel for AI agents. This is a note on what turning it into an independently maintained product actually involved — written while it is still unfinished, because the interesting details get sanded off once something ships.
I am doing this alone, in evenings, as a side project. Treat everything below as one person’s experience rather than a methodology.
Why fork rather than build
The honest answer is that the hard part of a panel like this is not the idea, it is the surface area: agent runtimes, model providers, channel adapters, session management, scheduled tasks, logs. That is a lot of integration work that is mostly plumbing, and reproducing it from scratch to arrive at the same place would have been a poor use of the only resource I actually lack, which is time.
What I wanted to add was a point of view: that the two things which actually go wrong with self-hosted agents are network exposure and runaway cost, and that a panel should be built around noticing those rather than around listing features.
The AGPL makes this straightforward in one sense — the right to fork is explicit — and creates a specific obligation in another: whatever I do stays open source under the same licence. That constraint shaped the entire commercial plan, which I will come back to.
Removing things is most of the work
I expected to spend the first stretch adding features. I spent it deleting.
Telemetry. The upstream shipped usage analytics. I removed the code rather than adding a setting to disable it. This matters more than it sounds: “there is a flag to turn it off” and “the code is not there” are different claims, and only the second one survives a reader checking for themselves. Since the whole pitch involves asking people to trust a panel with their API keys, that distinction is the product.
Revenue placements. An open-source project needs to be funded, and the upstream had done the reasonable thing: sponsor slots, referral codes, a donation address, links to related products. All of it had to go, because a fork carrying someone else’s referral codes is not an independent product, it is an affiliate site.
The replacement is a data-driven slot that is currently empty — a list with nothing in it, rendering nothing. When I have partnerships of my own, adding one entry makes the UI appear. There is also a test that fails if any of the old referral codes reappear in the source, because the realistic way that happens is not malice, it is a careless merge months from now.
Naming. A fork keeps the original name in more places than you expect: config paths, application identifiers, storage keys, user agent strings, window titles, documentation. Renaming touched 174 files.
The part that needed actual care was runtime state. Existing installs have data written under the old identity, and an upgrade that silently loses someone’s configuration is unforgivable in a way that a cosmetic bug is not. So the runtime markers are recognised in both forms — old and new — and migration happens on read. It is unglamorous compatibility code that will need to stay for a long time.
Naming a product is worse than it sounds
I went through roughly two hundred domain candidates over six rounds. Almost everything pronounceable in the obvious semantic space — agent, claw, control, ops, panel — was taken, parked, or priced as a premium domain.
What eventually worked was abandoning the semantic space entirely and using a formula instead: a friendly, concrete word plus a suffix that implies scope. “Gamba” is Spanish for shrimp, and also reads as the Japanese ganbatte — roughly “give it your best”. “OS” covers a wider product line than “panel” does without committing to anything specific.
Two practical notes. Spelling matters more than meaning: I chose the spelling that native speakers of my target languages would type correctly on the first attempt, which ruled out several nicer-sounding options. And on budget, I registered the .com only. Defensive registrations and the .ai are things to buy once there is revenue, not before — a side project with four defensive domains and no users has optimised the wrong thing.
The commercial plan changed after research
The original plan was API resale: proxy model access, charge a margin. Looking into it properly killed it on two independent grounds.
Reselling provider tokens conflicts with the terms of service of the providers whose capacity you would be reselling. Building a business on a clause that could be enforced at any time is not a business, it is a countdown.
Separately, operating a service that routes mainland Chinese users to overseas models runs into China’s generative AI regulations. That is not a grey area to be clever about.
So the model is now: the panel stays free and open source, and the value that can be charged for lives in things that do not require me to be in the request path. Nobody’s tokens flow through anything I run, which is also a better answer to the question of why you should trust it with your keys.
What has gone wrong
I destroyed the git history. Moving to a clean repository, I initialised a fresh history rather than carrying the upstream’s. The immediate result is a tidy repo. The actual result is that I can no longer cherry-pick upstream security fixes — every one now has to be diffed and applied by hand. I kept a backup of the original history outside the repository, so it is recoverable, but this was a real mistake and I would not repeat it. Tidiness was not worth it.
The repository is private, which broke more than expected. A private repo on a free plan means no GitHub Pages, and Pages was going to host the update manifests the panel fetches. It also means the Releases fallback for downloads does not work for anyone who is not me. Both had to be rerouted.
CI is switched off for cost reasons. The build matrix covers three platforms including macOS, which bills at ten times the multiplier. On a private repository, a full push was consuming a significant fraction of the monthly allowance, so Actions is disabled repo-wide. That is a reasonable decision that also means there are no automated builds, which is the direct reason this site currently has a waitlist where the download button should be.
That last one is worth stating plainly: the site you are reading launched before the product it describes is downloadable. The panel works — I run it — but there is no packaged installer to hand you, and publishing a download link that 404s would be worse than admitting the gap.
What is next
Get builds out. That means resolving the CI cost question, setting up object storage for downloads, and deciding on repository visibility — which the AGPL settles eventually anyway.
After that, the two features this is all built around get properly documented, and the cost guard gets tested against a longer window of real usage than I currently have.
If you want to know when downloads open, the form on this site is that and nothing else. If you are doing something similar and any of the above saves you a week, that is the point of writing it down.