Why we open-source what we can (and how we pick).
Open-source isn’t a marketing checkbox. Here’s our actual rulebook: how we decide what to release as FOSS, what stays internal, and which license we pick.
Most teams treat open-source like a marketing checkbox. Slap an MIT license on a weekend project, tweet about it, move on. We’ve tried to approach open source development differently.
Here’s the actual rulebook we use to decide what gets released, and what doesn’t.
Why we bother with open-source at all
Selfish reasons, mostly. Open-source code gets reviewed by strangers. Strangers find bugs we’d never spot. And once something is public, we write it better — knowing someone else might read it changes how you name a variable. (Funny how that works.)
But there’s a bigger reason. FOSS shaped our entire approach to software development. Giving some of that back feels right.
The 3-question test we run
Before any repo goes public, we ask ourselves:
- Does it solve a problem outside our company?
- Can we maintain it for at least a year without burning out?
- Is the code something we’d be okay debugging in front of 10,000 strangers?
If two out of three answer “yes,” we ship it. If only one, it sits in a private repo until it grows up.
What stays internal (and why that’s okay)
Not everything should be public. Our billing logic. Customer-specific configs. Glue code that only makes sense inside our stack. None of that helps anyone. Releasing it would just create noise.
Open-sourcing weak code is worse than keeping it private. You’re asking strangers to clean up after you.
How we pick a FOSS license
Default: MIT or Apache 2.0. Both are permissive, well-understood, and friendly to companies adopting the work. If a project could be forked into something predatory, we reach for GPL. That’s about it.
choosealicense.com is what we point new contributors to — a clean guide to comparing FOSS licenses.
A mistake we made (so you don’t have to)
We used to dump experimental code online with a “use at your own risk” README. Bad move. People filed issues. We ignored them. Trust eroded.
Now we tag experiments clearly, archive what we won’t maintain, and reply to issues within a week. Or close them honestly. Our contribution guide covers the rest — how we handle PRs and feedback.