Why we rebuild in the open
Solved problems should not carry rent. The case for rebuilding closed products as transparent, self-hostable, MIT-licensed software.
There is a specific kind of software that shouldn’t be closed: the tool that solves a solved problem. Form backends. Gift-card infrastructure. Design audits. The hundredth CRUD-with-a-dashboard product. These are things the industry has collectively figured out a dozen times over — and yet every one of them ships behind a login wall with a monthly invoice attached.
oss.codes exists to take those products apart and put them back together in the open.
The thesis
Charging for hosting is fair. Charging rent on a solved problem is not. When the hard part is running the thing — the uptime, the support, the migrations — a subscription makes sense. But when the hard part is already behind us and the only moat is that the source is hidden, that’s not a business, it’s a toll booth.
So we rebuild. From scratch, MIT-licensed, with a live demo and self-host docs on day one.
What “in the open” actually means
It’s easy to slap an open-source label on a repo and call it a day. We hold ourselves to something stricter:
- Every commit is public. No private main branch that gets squashed into a public release once a quarter.
- Every decision is public. Architecture choices live in issues and discussions, not in a Notion nobody can read.
- Every rebuild ships runnable. If you can’t
git cloneit and have it up in five minutes, it isn’t done.
This isn’t charity
Open source built this whole industry. Rebuilding in the open is how we pay that forward — and, honestly, it’s how the best software gets made. More eyes, faster forks, no black boxes. If a solved problem is going to exist, it might as well exist for everyone.
Fork it, self-host it, or open an issue and tell us what to rebuild next.