Atomico’s take on Open Source: our OS risk framework
As discussed in the previous post, there are many tailwinds that make Open-Source (OS) a very attractive distribution model for certain types of software, primarily DevOps, ITOps, Data & Analytics. However, not every product will benefit from being OS. Even if it could, running an OS-driven business has an additional layer of complexity.
We at Atomico often get asked “What do you look for when considering a Series A investment in an OS company? Github stars, usage metrics, revenue?”. The former quantum physicist in me alway tries to distill questions to the basics and find the smallest parts that can be answered easier. In this case, what helps us is a very simple OS Risk Matrix that we developed as a consequence of multiple conversations with successful and not as successful OS entrepreneurs. It not only allows us to wrap our heads around OS opportunities, but more importantly also could help entrepreneurs to prioritize their focus between financing rounds.
The “physics” are quite straightforward. It’s hard to quantify risk for early-stage companies, and even more complicated for OS companies. Beyond “traditional” business risks (unit economics, operations, etc.), OS companies have an additional layer of risk related to the specific requirements of the OS distribution model itself. Traditional risks hopefully won’t be the main bottlenecks for an early stage OS company (until Series B/C). However, one could ask, “Isn’t the beauty of OS that you ‘by default’ get easier distribution, bottom up adoption etc.?” The answer is that the OS model just shifts the risk from one layer to another.
In our view, there are 8 areas that it’s worth keeping in mind — some of them can be applied to any company (e.g. #1 — Thesis and #4 — Biz Leadership) others are attributed primarily to OS startups (# 6 — PCF, #2 — Thought Leadership). These areas are not independent, but as the company goes from one stage to another (for the lack of a better gateway, we could use financing rounds) it de-risks certain elements and therefore increases the likelihood of the company becoming a success.
For three types of fit I highly recommend reading a16z post that very succinctly introduces and describes it. In a nutshell, PCF is primarily about building an engaged developer community that loves and contributes to the development of the product, while PMF is more focused on building an engaged customer / user group that may not be active contributors to product development.
One can use this framework in many ways, but as an example, let’s say you just raised your Seed round and you are planning how to prioritise time and capital over the next 18–24 months (average runway between rounds). From the table you can see that it’s best to focus on #1, #2, #5 and #6 as the total risk reduction is maximised. This risk can be summarised as: “focus on working with your community and delivering them a delightful product”. Contrary to public perception, revenue is not a material driver at this stage in de-risking the company’s potential, but it becomes very important at/after Series A. The next serious step, for instance, is the transition from Series A to B where you need to demonstrate #3, #4, #7 and #8. That is about proving that you can create value not only for users, but also for the company and start assembling the team for scaling.
This matrix, of course, is a “spherical cow”, as in reality you’d very rarely see a perfect fit of achievements and company’s stage, and it is perfectly fine. What has to be taken in consideration though, is what risks are most likely to materialise vs others and therefore should have more weight in consideration. For instance, some types of tech are harder to productise than others, while for others it’s much harder to find a fruitful monetisation strategy. Understanding how founders think about these questions is the key to navigating the intricacies of investing in OS.
How much data is enough?
There is no unanimous answer here — e.g. 1000 stars for a data science project is very different from 1000 stars for a Java framework just because the underlying size of the community is different (worth reading a good article about benchmarking OS). Usually, at Atomico we look at 3 dimensions of data consistency:
- Within the same customer group — critical at Seed / Series A, as it’s important to understand how a homogenous group within a beachhead market reacts to the product.
- Across different customer groups — critical at Series A / Series B, as it gives a hint on who are the customers in general and how big could be the market.
- Across time — critical at Series B+ as it shows scaling potential, PMF and VMF.
Going from Unproven to Validated involves gathering data from all three dimensions, but with varying importance depending on the stage of the business. Going from Partially to Materially validated is all about the abundance of that consistent data. In any case, the thing that makes most sense is whether that data one has at hand is enough to confidently prove / disprove the hypotheses under consideration.
It’s not bad at all to have risk along any of the dimensions, but understanding where companies have the most risk helps us build a portfolio of playbooks, relevant advisors and talent that can increase the likelihood of success for OS companies. I mean things like thinking of types of products and their monetisation strategies, or navigating the early days of community building.
If you are building an OS company in Europe, please share your thinking on the topic and don’t hesitate to reach out to sasha@atomico.com.
