Open Source Startup Podcast: Why Feature Flagging Should be Open Source with Ben Rometsch
Building an open-source tool and going up against well-funded closed-source alternatives isn't straightforward. There are a lot of common hurdles and questions that crop up along the way. Flagsmith founder and CEO, Ben Rometsch, talked to Amanda Robson (Robby) and Timothy Chen on the Open Source Startup Podcast to cover some of those hurdles.
Tune in to hear about what we’ve learned from scaling Flagsmith, choices we’ve made about growing in the open-source space, and community building.
Listen to the episode:
On the OSS Startup Podcast LaunchNotes
Some questions covered in the podcast:
- Why build open-source feature flags?
- How do you fuel community growth in the open-source space?
- How do you grow your open-source tool in a controlled way and find an ethos for your growth?
- How do you get the developer marketing part right? e.g. Balancing needing technical content and DevRel and SEO and partnership marketing and all the other things (with a startup budget)?
- How do non-engineering teams (e.g. product teams) use feature flag software?
Why did we choose to build open-source feature flags?
Flagsmith started as a side project when we were looking for a feature flag solution on GitHub and couldn’t find the tool we needed. At the core, we build open-source feature flags for engineers like us. That’s the corner of the market that we’ve chosen to build around. The open source part is never in question.
This goes into all of the decisions around what we build, how we integrate with other specialised tools (like analytics tools), and so on. For example, we’ve chosen not to build deep analytics features, and instead, we integrate with specialised analytics and observability tools. This means that teams can have the right tools for the job without adding another decision point to their stack.
We also believe anyone should be able to run Flagsmith and use feature toggles without huge barriers, whether it’s for a personal project or an enterprise team deploying on-premises feature flags. We’re not tied to any cloud provider or tooling infrastructure; the only requirements are a database and an API. The platform is open and stays open, and teams can deploy it how they want, whether that’s for self-hosted feature flags or otherwise.
How do we continue to position as a tool for open-source feature flags as we grow—and as the space grows?
We’ve chosen to build slowly and as we’ve done that, we’ve been relentless about getting to know our customers and what their engineering teams need. We try to learn more about what they want, what’s working well for them, and so on.
We also try to look at the percentage of engineering teams that know about feature flags and to keep an eye on the addressable market. This lets us position ourselves in a rising tide as more engineering are using feature flags.
If we keep talking to customers and keep an eye on the space, we can continually polish the platform to improve the developer experience. This goes beyond features and revolves around also asking questions like:
- What’s the deployment experience like?
- What’s it like to load test it?
- What does security look like?
How do we look at developer marketing and growing an open source community?
This might not be a popular answer, but the most important thing for us has been building slowly. Flagsmith started as a side project while we were running an agency, so we weren’t a venture-backed company with time dependencies.
We had lots of time to grow the project, and open-source projects tend to have a linear growth pattern as well, so we chose to follow that growth rate.
At the start, our strategy was to just put out content that we felt developers would genuinely find helpful, whether that was technical content or business-related content that companies often—frustratingly—keep secret (like how we serve flags and the choices behind what we build).
We didn’t have a lot of funding, but we did have a lot of time, so the strategy behind this has developed slowly.
Tune into the podcast to learn more about how we chose to build feature flagging open source.
Relevant links
- Lessons Learned Along the Way to $1M ARR - to learn more about our experience building a bootstrapped company
- Our Flagsmith roadmap - to learn about upcoming features and the direction we’re going
- Rain customer interview - to learn how product teams are implementing feature flags alongside engineers
- More about who we are and why we're building the way we are
.webp)