Roadmap: Open Source

It’s no secret that open source is taking over the software development world. In just the past two years, there has been over $80 billion in liquidity value generated from the acquisition, merger, and IPOs of open source software-based businesses, so it should come as no surprise that the pace of venture investments into this space is growing faster than ever.

Much has been written about the dramatic shift in attitude towards open source in recent years—from the creation of the GNU project out of MIT back in 1983, to the launch of Github in 2008, through the acquisition of RedHat by IBM for $34 billion last year—so we won’t rehash the history of open source here.

One major development is worth emphasizing: once considered the cheaper version of closed source software, open-source software is now viewed as the superior alternative offering higher quality, better support, and more flexibility.

As decision-making power continues to shift to developers, companies large and small are more willing than ever to embrace open source software and all of its benefits into their production software. In fact, a major portion of the codebase of newly developed applications consists of open source software. Managed open source leader, Tidelift, reported in a recent survey that 92% of developers surveyed said their applications contain open source components.

As big believers in developer-centric businesses, we have been closely watching the rise of open source software and are excited about the potential win-win omnipresent in these businesses: value for the community and the entrepreneur.

So where exactly is open source creating value?

In the past few years, the world has seen open source software replace some closed-source incumbents, with enterprises ripping and replacing critical infrastructure with newer and better open-source alternatives. We believe this trend is only going to intensify as we see large software giants struggling to compete with a new kind of competitor who instead of spending hundreds of millions on sales and marketing, leverages a broad and vibrant community of users to penetrate the market. And developers are embracing technological shifts more and more rapidly such that even some of these older open-source winners are starting to be replaced by younger, fast-growing open-source projects.

We are seeing this same trend creep further up the software stack. Open source is not only limited to software infrastructure and data analytics but is getting adopted in areas that traditionally were completely dominated by closed-source software. Just as WordPress created an open source alternative to content management systems, new open source projects are coming after closed-source communications applications like Slack, data visualization tools like Tableau, and security solutions like Splunk.

What’s most interesting is how open source business models have evolved since the first generation companies reached maturity. Less than a decade ago open source was considered almost impossible to monetize. We all remember investors and industry experts saying that open source projects were a nice hobby but you couldn’t build a real business around them unless you were relying on providing support services that do not scale.

Open source companies grow faster than some cloud leaders.

Yet, new and innovative business models evolved and many of the top OSS companies today rely on an “Open Core” business model, where the company keeps all of the core functionality of the product open source, but only charges for a small set of premium, closed-source features. And when the open source business model works, it is among the best we have seen.

Once these companies turn on the monetization engine they are catapulted by the strong underlying community, and the journey from $1 million to $100 million ARR can be faster than some of the fastest-growing traditional SaaS businesses.

Below is a comparison of the growth rate of three of the top Cloud 100 open source companies and some of the fastest-growing SaaS companies:

From our recently announced investment in infrastructure monitoring solution Netdata, to front-end testing leader Cypress.io, to noSQL database ScyllaDB, and infrastructure management leader HashiCorp, Bessemer has been ramping up our OSS efforts the past few years.

But with 37 million (Million!) public repositories on GitHub today, how do we build conviction to make our investments? How do you find the needle in the haystack of countless open source projects—many with remarkable community activity—with the potential to be the next multi-billion dollar software business?

The Open Source Six: Good, Better, Best Framework

After meeting with hundreds of open source project creators, analyzing the top 10,000 public GitHub repos, and aggregating data across the most successful OSS companies of all time, today we’re excited to share Bessemer’s Open Source Six, a Good, Better, Best Framework for open source investing. True to the community-driven nature of OSS, we hope you’ll contribute any and all thoughts as we continue to accelerate our efforts across the category.

1. Team

Like any venture investment, it all boils down to the team. But the dynamics of open source allows virtually anyone to take an existing project and build a team around it. You might even see several different teams pop up around the same project at the same time.

We’ve found that the most successful open source companies are most often led (either as CEO or CTO) by the original project creator. Of course, this isn’t always the case, but it tends to lead to higher success rates: The clout in which project creators have over the project helps attract talent. But more importantly, their intimate familiarity with the project and simply their head start in thinking through the long-term vision gives project creators a material advantage.

When looking at the top 50 open source companies, it's the project creators who formed the company over 75% of the time!

Even better is when these creators manage to build a community of active contributors and maintainers around their project - often as employees of the company even if they aren’t focused on commercialization. This not only reduces the load on the project creator(s) but also establishes the most relevant and valuable talent pool for the company’s first engineering hires, and allows for more visibility and control into the product roadmap for both the OSS and commercial components. Building out the community’s development efforts not only gives the team an advantage at attracting and building a strong team, but it also often has the effect of guiding the project toward evolving into a business more quickly, an extra advantage over other efforts.

2. Origin

Open source projects can come from anywhere. The existence of GitHub allows virtually anyone to push a project into the ether and hope for a community of developers to form around it. Beyond individual developers, tech giants like Google, Facebook, Microsoft, and Netflix have been open-sourcing their internal projects frequently, resulting in some of the most proliferated OSS technologies out there including Kubernetes, Go, and Visual Studio Code. Similarly, some of the most advanced research institutions and universities are also major players in open source project contributions.

But where do the most successful open-source businesses usually come from? Interestingly enough, the OSS tools released by tech giants rarely result in standalone businesses being built. While technologies like Kubernetes have resulted in a massive transformation of cloud infrastructure, they haven’t resulted in large commercial successes, at least not yet. (Perhaps it is the instant, widespread popularity that prevents any single player from building a business atop of these corporate-released projects?) There have been ecosystems and companies built around these widely-adopted solutions, but it isn’t very easy for one player to emerge with a standalone, massive company when the technology gets pulled in so many different directions.

One might also think that a team of entrepreneurs setting out to build and launch an open source-based business is the more natural path to success. Perhaps counter-intuitively, we’ve found the opposite to be true. We see the most compelling companies derived from individual developers who started an open source project to solve their existing challenges, and then eventually built a meaningful business down the road. In fact, of the top 50 successful open source companies, more than half the time the project was launched long before a dedicated company was formed.

On average, top open-source companies were formed three and a half years after the public launch of the underlying OSS project after the project has received significant traction on its own.

We believe this is mainly because the project is typically built to solve an acute problem—and if a developer searches far and wide and can’t find an existing solution, chances are there are tens of thousands like them out there seeking the same thing. When an individual project creator can get his or her project to be widely adopted by others, that market ‘pull’ is often a great indication of broader business value to be built. This is a fantastic characteristic of open-source businesses—you can test for product-market fit with a broad set of potential beta testers prior to “taking the plunge” to form a company around the project. And you have a great idea as to the potential paths to monetization based on the nature of the community and usage patterns.

3. Early Adopters

Customers are always a great measure of a company’s success. Naturally, the more users and user growth a project sees, the more exciting the opportunity. But the myriad of open source repositories serves vastly different audiences, from backend devs to frontend designers. Each project category has its own unique OSS activity dynamics, which we go into in more detail below. One common thing we always ask is, “From where do a project’s early adopters come?”

There’s a big difference in the monetization opportunities if a project is in the hands of hundreds of thousands of dev shops and consultants than if it’s being used by teams of engineers at some of the hottest tech companies.

As investors, we prefer the latter, as early usage by the most cutting edge tech companies increases the likelihood of wide adoption later on. It goes without saying that companies can be built serving any of these audiences, but if the early adopters are those with recognizable domain names in their email addresses, there’s a certain validation around the business potential. After all, when a project solves an unmet need that corporations would rather offload than assign their own R&D resources towards, it’s probable that the company can command higher-value contract sizes from these larger budget organizations.

4. Project ownership

Most standard open source licenses allow for virtually anyone to attempt to build their own company and offerings atop of an existing project, though this is certainly changing in light of some aggressive practices by ecosystem giants. While this openness is where open source derives most of its value and growth from, it also means that any project could have a handful of teams vying to be the ‘business’ servicing, hosting, or building features on top of the project.

When meeting with open source companies, we always try to understand how much control the team has over the direction of the underlying OSS project. There have been successful businesses built atop projects with virtually no ‘ownership’ of the project roadmap and commits. The best-case scenario is when the team has full authority to guide the project’s roadmap, prioritize features, and approve commits. This certainly doesn’t prevent others from ‘forking’ the project, also known as replicating the codebase and allowing for autonomy in that fork’s direction. The emergence of multiple vendors may indicate a hot market opportunity that can result in multiple winners, like Cloudera, Hortonworks, and MapR all serving Hadoop. However, aside from the competitive dynamics, without a single clear leader of a given project, you might see a project get pulled in different directions by a number of different players, diluting the power of the crowd.

The way we see it, nothing beats having one primary vendor (usually the original project creators and maintainers) in control of the core community of contributors driving the long-term direction of the project.

5. Monetization

One of the most strategic decisions commercial open source companies make is how to design their monetization strategy to appropriately capture value from the right customers, while not limiting the open source product. Historically, many OSS businesses were built on offering support, services, and SLAs (e.g. RedHat), but most open source businesses today offer an ‘open core’ model, where they keep all of the core functionality of the product open source, but only charge for a small set of premium features. The best open source companies tend to leave as much functionality as possible in the open source version and only monetize a very small percentage of their user base, often less than five percent. This helps to encourage broader adoption in the open source community and, in turn, to populate the top of the funnel for the paid product with active users of the open-source variant.

The key to getting monetization right is figuring out the minimum set of features to gate in the enterprise version that will trigger enterprise customers to upgrade to the premium version as they adopt the product at scale, while still maximizing the value in the open source version for the broader community. 

As investors, we are most excited about companies that can monetize on a set of features that are mission-critical for customers that will deploy the product at scale. Ideally, companies can also sell into an existing budget by replacing another service for which the customer already pays. However, increasingly, budgets for open source products are less closely tied to replacing existing line items and are more focused on reducing the amount of time an internal engineering team will need to spend maintaining and managing the product.

6. Community

Community engagement is the lifeblood of an open source company. Community feedback and participation are critical to directing the project roadmap, fixing bugs, building new features, growing adoption, and providing support. However, achieving large scale community engagement is extremely rare. Out of the 37+ million public repos on GitHub, we have analyzed the top 10,000 (ranked by contributor activity), and we have identified less than 500 projects that we would consider to have ‘large scale’ community engagement. So about one in 80,000 projects reach this type of scale.

Even rarer are the successful open source projects with an affiliated company focused on commercializing the project. Out of the top 500 open source projects, fewer than 100 are associated with venture-backed companies commercializing the project. This is changing quickly though, and as a wave of open-source developers builds new companies, we want to help provide some benchmarks around what metrics we use to measure best-in-class engagement.

Measuring success for something as qualitative as a community is difficult, particularly given all of the different stakeholders and associated metrics.

Community engagement is the lifeblood of an open source company.

We are most focused on measuring users and contributors, as these are the groups that provide the most insight into the scale of the community. This is part of the reason why we tend to pay little attention to numbers like Github Stars, which is a bit of a vanity metric that often tends to spike in correlation with big press releases but does not reflect continual engagement.

In contrast, Users and Contributors represent the groups who are actively engaged with the project and rely on it. Users are notoriously difficult to measure, given the limited telemetry that most projects have on their users. Contributors on the other hand only represent a small subset of users, but they are much easier to measure, and this subset of users tends to demonstrate deeper engagement with the project by devoting time to providing feedback through ‘issue comments’, or occasionally contributing code to the project.

It is well-documented that in most open-source projects, the vast majority of development is done by a very small group of core maintainers, so we do not use contributors as a measure of how much development capacity the project has, but instead use it as a proxy indicator of how much adoption the project is seeing.

We define a contributor as any user that either provides feedback to the project through Github issues, issue comments or contributes code through pull requests or commits. Most emerging open source projects would be in the rare territory if they reached 100 unique monthly contributors on a consistent basis, and those projects that exceed 250 contributors per month would be approaching the performance of the most active projects of all time. We will discuss our analysis of top open source projects and our benchmarks for best-in-class community engagement in more detail in an upcoming post – stay tuned!

As investors, we know that these metrics only tell one small piece of the story, so we certainly don’t disqualify companies that only have limited contributor activity. However, we believe that strong community engagement is a key component of most successful open-source projects and therefore, we are much more comfortable investing in businesses that are built around robust communities.

Coming up

At Bessemer, we believe that we are still in the very early days of an open source software revolution, and we’re eager to partner with the best open source businesses at any stage and in any geography. If you are working on an open-source project or company and want to learn more about how we think about building and investing in these businesses, please don’t hesitate to reach out to Amit Karp (karp@bvp.com), Michael Droesch (mdroesch@bvp.com), or Ariel Sterman (asterman@bvp.com).