The middle class of open source software
Assessing the viability of building a business selling to open source project maintainers
It’s been a while! A huge thank you to the 169 new subscribers who have joined us since last time. I lead early stage investments in startups building the next generation of software and data infrastructure. This week, I did some back-of-the-envelope math to understand whether it’s possible to build a big business by selling software to open source project maintainers. TL;DR: not today, but that will change quickly.
If you’re interested in similar topics, drop me a line at email@example.com or on Twitter @rak_garg.
Confluent. Databricks. Canonical. Docker1. Red Hat. Mulesoft. Hashicorp. Elastic. Cloudera. MongoDB. Redis2.
The companies above have proven: you can build a massive company with characteristically high gross margins, ultra low customer acquisition cost, and legions of loyal community members, around an open source project. I’m lucky to work with several COSS founders. The question I wrestle with now is: can you build a big company selling to open source project maintainers?
In other words, are there enough projects with revenue-generating aspirations that it makes sense to sell tooling to those projects? Several problems exist in how open source is built, managed, and supported today, but two common frustrations I hear from my OSS maintainer friends are:
Poor visibility into product/framework usage analytics & telemetry
Hard to link Github activity (PRs, comments, etc) to community activity to product activity
Projects with low reach (crudely measured by stars) would ostensibly not have the dollars to pay for specialized tooling. Conversely, projects with ultra-high reach (Spark, Kafka, Ubuntu, Hadoop, etc) are more likely to have already invested in proprietary processes and tools to smoothen their path to ubiquity. Neither category is an easy wedge for a fledgling startup, which raises the question: is there a middle class that would be a better wedge?
Note on methodology:
The Github API rate limits the number of results that can be retrieved with each request, so it’s easier to make bucketized requests.
The vast majority of public repositories on Github have 0 stars, so the graph only includes repositories with ≥1 stars.
A small subset of Github projects aspire to become companies or generate revenue at all. If we generously assumed that 5% of projects with >500 stars have commercial aspirations, and we included the 220 companies3 that have >10 active contributors to open source tooling, we’d end up with 3,589 projects. This is the TANC (total addressable number of customers) for a company targeting open source projects.
And if we limit ourselves to projects with between 500 to 10,000 stars, we’d end up with 3,467 projects. To sustain $1B in annual revenue, there would have to be $288k generated annually from each project. This is far from easy. On the bright side, DevRel leadership teams seem willing to pay ~40-50k ARR for tools that ease their advocacy, outreach, and OSS efforts. If the number of addressable projects can grow by 6x or so, it becomes possible to build a generational, venture-backable business.
Conclusion & Next Steps
Open source is an oligopsony; there just aren’t enough buyers. But there are two cyclonic tailwinds:
Projects grow monotonically. Their star counts don’t decrease over prolonged periods of time. This means more projects will become buyers for specialized technology over time.
I’ll keep an eye on this distribution of projects from month to month and see how things are trending. If we see the TANC growing quickly, this could be a ripe, under-served, and soon-to-be massive market to build in.
Docker is a BCV portfolio company.
Redis is a BCV portfolio company.