Why I Didn't Open-Source My Second SaaS
By Anthony·January 16, 2021·7 min read
Let me start by saying that there's many open source projects that have successfully demonstrated that open-source can support a business, and I have great respect for them. I’m thinking of projects like Sidekiq, Sentry, and Matomo, but there's plenty more.
As a developer, I also prefer having access to the source code for the systems I rely on. That way, I can inspect it, and even patch it for my specific needs whenever the license allows.
I’ve learned a lot by reading code written by more experienced people than me, mostly from open source projects like Django, Finatra, Kubernetes, or React to name a few. Needless to say, I owe a lot to the open source community, and for that I will forever be grateful.
That said, I'm writing this from the angle of building a sustainable SaaS service as a solo founder. Your own context will influence whether my story is relatable to you.
Been there, learned a lot
I want to offer reliable software that I continue to maintain over the years, whether it’s open source or closed source, free or paid. However, I also need to be able to pay my bills. Ideally I'd build free, open-source software and still be able to afford a place to live (housing in Munich has gone insane). Unfortunately life's not that simple, and it doesn’t appear to work for most projects unless backed by established companies or those that happen to be at the right place at the right time. Donations could help, but odds are I won’t be able to support my livelihood with this model and continue to build and support the project.
So about three years ago I thought I had found the holy grail: I would develop the SaaS as an open source project that anyone could self-host, while offering a hosted version which I can manage for my customers. I assumed 90% of the users would just self-host it themselves, but it’d be a good enough compromise. So I went ahead, and built Traduora.
Needless to say, I was very naive to think that running a business is the same as running an open source project. Just because lots of people and organizations use your software each month, doesn’t mean you can automatically support your livelihood.
But business model aside, the main issue comes along in the form of expectations regarding your commitment as an open source maintainer. For some reason, many people have come to expect open-source maintainers to deliver the same quality in the same amount of time that an entire team at a company could, and they want it for free. I learned that nothing makes people disappear faster from a GitHub thread than asking them if they want to contribute the code changes themselves.
This particular project I’m talking about has been downloaded more than half a million times (Docker pulls + GitHub clones) over the past two years. While this helped me raise awareness about the project, it did not lead to a successful business model on its own as I had (naively) assumed.
What went wrong
Back then, I chose to open source the project alongside a SaaS offering based on the following assumptions:
- It would lead to a healthier codebase, as more eyes were looking into it.
- It would improve trust, as anyone can audit my code.
- It would reduce the support burden, as people can look at past issues, and participate in the discussion threads.
- It would help me drive growth, as marketing is not my strength.
- The community would help me build new features for their specific use cases.
Unfortunately, almost all points above were false assumptions in my case. And sometimes it actually led to the opposite result. I won't dive into each point, but the main issue that this created for me was: increased operational burden as a solo-founder. If I was working together with a small team, the story may be different.
That said, there are many people who did contribute to the project, and for that I’m very grateful. It’s just unfortunate that they’re by far the minority.
Also I made the mistake of trying to be everything for everyone. I was too focused on developing every feature, trying to give support to every single ticket, and I completely ignored the marketing aspects of it as I had no time for it. It also made it really difficult to understand which issues to prioritize, and which ones might lead to more people supporting the business.
Not only that, but things like backwards compatibility for those self-hosting, handling support requests via email and chat groups, providing assistance to those installing it on incompatible platforms, were just taking away too much of my time. I was a solo founder, wearing all hats, prioritizing everything that came my way. Looking back, I ask myself: how could that work?
So while the project was used by several organizations, I quickly realized that it wasn't going to pay the bills given the time I was putting into it. Very soon I lost what helped me push along the whole way: my motivation. I knew while the project was of relative success on the open source front, it would require massive effort on my side to turn things around operationally and business-wise. However, without motivation, it’s easier said than done. The spark had simply faded away.
I did learn a lot out of this experience, and that's also why I have a lot of appreciation for those who have managed to get it right. I once read that making software is only 30% of what makes a tech company, and while I cannot confirm that number is accurate, the idea behind it rings true to me.
In short, like everyone else, I only have a limited amount of time in this world, and I have a life with family and friends to live too. Over the years I’ve had to re-evaluate how much time I'm willing to allocate to supporting each project.
So it needs to be sustainable if I want to do this for the long-term. I do continue to support every project I open source, but have reduced the release frequency to about twice per year. The main exception is security issues, which I do try to handle as soon as humanly possible.
I really don't want to be that guy that cannot be relied on, but I have other things going on in my life, just like everyone else, and have to watch out for my health too. Running a business, contributing to open-source, getting everything to run on the latest M1 chips is fun stuff, but so is living a full life with your loved ones.
Pick your battles
Last year I launched a new service, Panelbear, which is what the rest of this post is about. In short, it's a simple performance monitoring + website analytics SaaS that I started last September. It's fully self-funded, but this time I’m not open sourcing it from the start.
In the past, when it came to running a business as a solo-founder, having it open source created too much maintenance burden for very specific feature requests. In particular from non-paying users, who sometimes sent me emails directly, demanding I look at their issue, or help them fix things “as soon as possible”.
I am now trying another approach, and so far it’s more sustainable in my case. I have a better idea of which features to prioritize based on paying customers, which surprisingly tend to be more respectful of my time when they needed support.
Not being open source from the start, means I’ve been able to pivot and reinvent features more easily, as there’s not many “breaking changes” to coordinate (except for public APIs and libraries), or self-hosted deployments to support. I’m able to move faster because there’s only one deployment environment to support (or two if you count staging).
It’s also much more sustainable to build and grow a product at a pace in which it’s “just a thing I do” along with other things going on in my life, while being able to cover your expenses. There’s a saying: “slow is smooth, smooth is fast”, which feels very fitting in this case.
I continue to open-source, when it makes sense
Don't get me wrong, I do rely on, and continue to contribute to many open-source projects. I would have never gotten this far without the amazing community that continues to build, and support all these projects on their own time.
It's not entirely out of the question if I might one day reconsider, and open-source new projects. But for now I'll mainly open up libraries, and utilities, with a much smaller scope. That way I can afford to provide support for them, and hopefully more people are able to contribute since the codebase is smaller.
One day I might write a blog post reflecting on my second SaaS. That's the joy of the journey, there’s always something to learn.