6 Lessons From the World's Best Open-Source Creators

Flagsmith has had a record-breaking last couple of years, experiencing over 250% growth since 2023. But building it into a successful commercial open-source business has been no mean feat. Along the way, I decided to reach out to some of the world's best open-source creators to hear how they’re building their businesses and learn from them.
The best part about the open-source community is that once a problem is solved, if it’s shared with the world, we don't have to solve it again.
Here are six lessons that I’ve learned from speaking to open-source creators on our podcast, and from my own journey building Flagsmith.
Lesson 1: The open-source community is amazing
Starting an open-source business is daunting. When we were building our product, one of my colleagues had the confidence to email open-source creators and ask them to come on the podcast so that we could hear their stories and learn from them.
And they did. We spoke to Heather Meeker from OSS Capital, who has been instrumental in open-source licensing. We spoke to David Heinemeier Hansson, who started Ruby on Rails. We spoke to Michael de Haan, who started Ansible.
This is what’s amazing about the open-source community. It really is a community, and people genuinely want to share what they know. There are resources to lean on and it pays to do so.
Lesson 2: Scratch your itch
We built Flagsmith because it solved issues that we were running into as developers. We were sure there must have been a Postgres of feature flags, but we couldn't find one.
Imagine you’re at the end of a sprint and can't deploy the software you’ve written because there's a bug somewhere that breaks the build. Or something prevents things from going live and you have to wait another week. Then the same thing happens again.
Two months later, nothing has been released. You know that the next release is going to break things because it's become monster-coded. This could well mean working the weekend trying to put fires out.
This was the problem we wanted to solve with Flagsmith and feature flagging. We saw this as an opportunity to build a solution and open-source it. This is what scratching the itch means. We built Flagsmith because it solved problems we wanted to solve.
Lesson 3: Choose the right open-source licence
One of the toughest problems we had was that we’re engineers, so we knew how to engineer software but we had no idea how to navigate open-source licence issues.
We knew what we wanted and what we wanted to defend against, but we didn't know what was best. And honestly, I’m physically incapable of reading legal documents. As soon as I hit the first run-on sentence, my brain stops.
The lesson here is that licence helpers and the open-source community are great resources. Deciding on the right licence boils down to looking at the different options and understanding what they mean for you, your project, your liabilities, and your business. It’s undeniably high stakes—companies have had major problems with people abusing their code and abusing their licences. So it pays to take the time to find the right option.
We chose BSD 3, but the right choice for your company might be something different. Take the time to understand the legal side and find the right licence for your project.
Lesson 4: Small teams can be a superpower
Flagsmith started off bootstrapped. When we started, we were building the company part-time. We had very limited resources and it was intimidating going up against massive closed-source companies.
The combination of small teams, open-source frameworks, and elastic infrastructure can be a superpower, though. We were able to serve billions of flags a month on our SaaS platform with three engineers.
Some of the advantages of small teams:
- High responsiveness - As a small team, you can talk directly to users, get feedback in real-time, and implement it. There aren’t huge processes and dependencies around shipping features into the product.
- Transparency - In a small team, everyone knows what you’re working on, and everyone can focus on exactly what needs to be done.
- Being able to pivot easily - If something comes up that people are asking for, you have the flexibility to move fast.
You can’t be a tiny team forever, but it’s also great to be a small team that’s up against heavily funded commercial competitors.
Lesson 5: Becoming commercial open source takes a long time
Getting to the commercial part of being a commercial open-source project is not quick. This is agreed upon by every open-source founder I’ve spoken to. There are years between the inception of the project and its becoming a business entity that stands up.
It took Flagsmith five years to reach $1M ARR, and we’ve been lucky to see immense growth since we hit this milestone. It took years before we were selling on-premises commercial licences for companies who needed data protection, flexible deployments, and human support. The good news is that we weren’t in a rush and have been able to build at our own pace.
It will take time, so make sure you’re building a project that scratches the itch (see above).
Lesson 6: Open source software is eating the world
In my opinion—and this is true for a lot of the people I’ve spoken to as well—open-source software and the cloud are eating the world. More and more software and tooling frameworks have become open.
We have new issues that come with the times we’re living in, but open source is a great antidote to some of the issues of the past (like paying $50k per CPU per year for a Java application server) and it’s on the rise for good reason.
Keep open source weird
The open-source community is growing fast. If we stick to our roots and continue to be a community that shares our learnings and helps one another, we can grow together.
Hopefully, these learnings help you in your open-source project journey. I’d love to hear what you’ve learned along the way, too.
Stay tuned for my new limited podcast series coming out in September, where I take a more in-depth look at the different aspects of building a commercial open-source business with founders and builders.
.webp)