Fundraising for Open Source Startups

You can find an endless number of blog posts, conferences talks, and podcasts on fundraising for technology startups. Before you think about how to do it, think hard about why you want to do it. You don’t need to raise money to build a great, successful company. Most Venture-Capital-backed companies fail. That’s not a bug. It’s a feature of a system that depends on outliers. Power-law distributions dictate venture fund returns. The best-performing company is more successful than the sum of all other companies in a fund combined.

If you want to build an industry-defining company, you will likely end up taking Venture Capital. More money used wisely means more resources, more and better people, and a higher market share. Capital is abundant for early-stage startups right now, especially in the US. Additionally, to the well-known VCs (Benchmark, Sequoia, etc.), you have lots of small micro-VCs. Sector-specific funds. Scout funds. Professional angel investors and operator angel investors. AngelList launched the concept of “Rolling Funds” recently, leading to a Cambrian explosion of small funds over the next years. This concept commoditizes access to capital. Everybody who has access to an audience can raise a small fund. All of this is good for you as a founder. More funding sources means more choice, a higher likelihood of getting funded, and a more diverse and better investor pool. But, there’s a flip side to it: More bad actors and unsophisticated investors. I might follow up on how to best construct your funding round in this environment with a dedicated blog post. Regardless of the composition of the cap table, companies leveraging VC follow a similar trajectory.

Fundraising Is a Series of Step Functions

An investment announcement usually looks something like this: “Company x raises a $yM Series-something”. The first investment is generally called “Seed Round”, followed by “Series A”, “Series B”, etc. Nowadays, you can find more and more outliers. For example, a company that bootstraps then raises a large round once they have already achieved scale. Calling that “Seed Round” or “Series A” is misleading. The framework isn’t perfect. What matters is the logic behind the naming convention. Fundraising is a series of step functions. You make progress, achieve certain milestones, and leverage that to raise a funding round. Then you make more progress, hit more milestones, and raise money again. And so on. You must make sufficient progress. It must be a step function, and not just a small incremental increase.

The first time I remember hearing about this framework was back in 2012. We just raised our first investment for Codeship, and Carlos Espinal walked us, and a couple of other founders, through the step function concept. No successful company looks the same. There are many paths to success. Yet, on average, companies progress through roughly the same stages:

Founding Team: First, you assemble your founding team. Maybe you already have an idea, or even an initial product, perhaps not.

Validation: Ideally, before you write a single line of code, you validate your idea. You ask yourself (and your team): Is the problem you are trying to solve painful enough for a broad enough audience?

MVP (Minimal Viable Product): Once you have sufficient conviction that the problem is “real”, you start building. “Building” doesn’t need to imply writing code. It could mean mockups and designs, whatever helps you validate the problem and your proposed solution further.

PMF (Product-Market-Fit): At this point, you have a full-blown prototype, early users, and high conviction. Your approach for solving the problem works, and you can measure the excitement of your initial users (engagement/retention metrics, first revenue, virality, etc.). Listen to this podcast with Andy Rachleff if you want to learn more about PMF^[1].

Initial GTM (Go-to-Market): Achieving product-market-fit feels like magic. Most ideas don’t make it to this point. Yet, the majority of startups that achieved PMF won’t result in successful companies. Now you need to figure out how to acquire more customers than your initial user/customer base.

Scalable GTM: Growing beyond your initial users isn’t enough. To build an industry-changing company, you need to figure out how to grow efficiently at scale. Put $1 into the GTM motion and get many more $ back.

The above is a simplified but powerful view on how to build a high-growth technology startup. Various things matter depending on where you are in the journey. Your goals and objectives are different. The skills you need in your team are different, and also your fundraising depends on it a lot. If you want to learn more about the step function framework, I recommend this presentation from David Skok or this blog post from John Vrionis. Both are terrific and incredibly successful early-stage investors. Next, I want to get into the specifics of raising money for an open source business. Open source companies are still companies. All the above applies. But, there are some significant differences you need to keep in mind. Most importantly, you need to achieve project-market-fit before working on finding product-market-fit.

The Importance of Project-Market-Fit

Building a company around an open source project provides you with a considerable advantage in the context of the step function concept. The initial validation happens in public through the open source project. It also means that it takes you longer before you start building and offering an actual product. This is an important distinction. Product implies money. You create value, you charge for it. Even if initially, you let your early user try the product for free. If you diligently work with those first users, flipping the switch and charging for the product is relatively simple. Thanks to the ongoing feedback loop, qualitative and quantitative feedback (NPS, Sean Ellis Test, etc.), you know when you get closer to product-market-fit. You understand the value the product is creating for your users, and you can define a pricing model accordingly.

It’s different with open source. You don’t have a product for quite some time. You don’t need one, and you shouldn’t have one. It will distract you from what matters. Your focus should be on generating traction with the open source project. Get early users, spend lots of time with them, fix their issues, and achieve project-market-fit. You can measure project-market-fit similarly to product-market-fit. NPS or the Sean Ellis Test both work for open source projects as well. You will get incredibly valuable insights by interviewing all your early users. But, you can’t start charging by flipping a switch once you are confident that you are creating enough value. You don’t have a product. “All” you have is an open source project. That’s not negative - quite the opposite. In the long term, this provides you with a vast go-to-market advantage. In the short term, it means that it will take you longer to get to product-market-fit. First, you need to achieve project-market-fit. Only then can you start building your proprietary product (assuming you will use Open Core as a monetization model).

This requires immense patience from you as a founding team, your whole company, and your investors. Finding investors that understand this progression is crucial. If you try to jump ahead, you won’t reap the benefits of having a successful open source project. It’s one of the reasons why open source companies always seem to have a slow start. The advantages become apparent over time. Once you provide a proprietary product on top of your open source project, you can start scaling and growing your revenue at a breathtaking speed (take a look how fast MongoDB scaled their SaaS revenue). It’s hard to prove this by numbers because of the small number of public open source vendors (and the lack of historical data). I firmly believe it will become the “new normal” once some newer open source startups like Confluent or HashiCorp go public.

If it’s possible for you, you can also bootstrap until you have project-market-fit. Raising a seed round from great investors is significantly easier and doable with better terms if you can show that your open source project has already validated your idea. This option is particularly attractive if you are currently working on an open source project for a larger tech company and consider leaving and building a business around that open source project. The perfect time for leaving and founding your startup is after achieving project-market-fit (e.g., LinkedIn open-sourced Kafka in ~2011, and Confluent started in 2014).

Open Source Project and Proprietary Product Focus on Different Personas

Your proprietary product monetizes a different persona than your open source project early adopters. This is critical to understand. It’s the reason why finding project-market-fit doesn’t automatically imply product-market-fit. A few weeks ago, I wrote about a simple framework to determine which features should be open source and which capabilities should be proprietary. I recommend reading it. In a nutshell, the best approach is to open-source every feature that primarily creates value for the developer (or end-user). The monetization happens through manager/team or executive/organizational capabilities. Think advanced scalability, security, team/user/access management, or governance capabilities. Depending on your open source project, you might get some proprietary traction by simply offering it as a SaaS. This is an excellent first step, but not defensible long-term. If your differentiator is “running the project aaS”, other companies, including the large cloud providers, will do the same. Additionally, you need to build proprietary capabilities and serve the manager/exec persona.

The beauty of that approach is that you are moving up-market naturally. By definition, your open source project caters to developers. If you achieve project-market-fit, it implies that you create a lot of value for those developers. That will create massive tailwinds for your business because all those developers will bring the open source project into their companies. Once you see that happening, force yourself to spend a lot of time with the managers of those developers and other stakeholders in those companies. That will allow you to figure out what capabilities you need to add to your proprietary product to monetize them. It will also inform you about whether you can do a SaaS-only approach (much simpler) or if you need to offer a self-managed offering. B2D (Business-to-Developer) is one of the few outliers where modern, self-managed products are often required to sell large ACV (Annual Contract Value) deals. If you succeed, you will likely offer both - Self-managed and SaaS.

Long story short. Focus on finding project-market-fit before moving on to building a proprietary product. The proprietary product builds on the success and momentum of the open source project. Don’t try to jump ahead prematurely. Yes, it is slower but increases the chances of success in the long run. In terms of fundraising, plan accordingly. If you raise a seed round early on, make sure you have enough resources to get to project-market-fit and product-market-fit. Discuss this openly and upfront with your potential investors. If they aren’t aligned, they are likely a bad fit.

[1] H/t to Alessio Fanelli for mentioning it.