Flagon: We build software in the open.

Open is our default, not our exception. That covers the obvious stuff, the code, and the less obvious stuff: this handbook, the roadmap, and the reasoning behind decisions that didn't go the way anyone expected. The bar isn't "why should we open this?" It's "is there a real reason not to?" Usually there isn't.

What we open, and what we don't

Most of what we make is public: the product code, the tooling, the docs, the way we run the company. All of it out where you can read it, fork it, and tell us we got it wrong.

The short list of what stays closed is genuinely short: things that would put people at risk if they were public. Secrets and credentials, obviously. Private data that isn't ours to share. The occasional security detail we sit on until a fix is out. That's about it. If something's closed, we can tell you the reason, and the reason is never "competitive advantage."

When in doubt, open it

When we're unsure whether to open something, we open it. The cost of over-sharing is a little discomfort. The cost of a company that quietly keeps secrets is a company nobody trusts.

Building in public means the whole thing

Plenty of companies open their code and call it a day. We mean something bigger. Building in public means the roadmap is public before it's certain, the decisions are public while they're still arguable, and the mistakes are public after they've happened.

The mistakes part is the one that matters. Anyone will show you the wins. What makes the rest believable is showing the false starts: the feature we killed, the call we got wrong, the thing we shipped and walked back. A track record with the losses edited out isn't a track record. It's marketing. A lot of this happens through writing about the work as we go, losses included.

How the community steers

We build in Discord and on GitHub, out loud. If you use what we make, you can see what's coming, argue with where it's going, and file the bug the moment you hit it. That closeness is the whole point: the people using the thing usually understand it better than the people who planned it.

Steering isn't the same as voting, though. We listen hard and we build in the open, but we don't run the roadmap by committee. Decision-by-committee produces the beige average of what everyone asked for and nobody wanted. Someone still has to own each call and be able to explain it. The community shapes what we build. It doesn't get a veto, and we don't pretend otherwise.

Licensing: permissive by default

We reach for permissive licenses, MIT, Apache-2.0, that family, unless there's a specific reason not to. We want people to use our work without lawyering it first, including in ways we didn't think of and might not have picked ourselves. Freedom to use it is more valuable to us than control over how.

When a project calls for something more protective, we'll say so and say why, in the open like everything else. But the starting point is: take it, use it, build on it.

Why this is an advantage, not a giveaway

The reflex is to assume that opening everything hands your competitors a map. It mostly doesn't. Copying the code is the easy part. What's hard to copy is the trust that comes from years of showing your work, the community that sticks around because they helped build the thing, and the honesty that forces you to run a company you'd actually be comfortable explaining out loud.

That last one is the quiet benefit. It's a lot harder to make a shabby decision when you know you'll have to publish it. Working in the open doesn't just tell people we're trustworthy, it keeps making us the kind of company that's worth trusting. A competitor can clone the repo. They can't clone that.

More on the mechanics in how we build, and on the why in our values. If something here reads as hollow, tell us at hey@flagon.io and we'll fix the page or fix the practice.