How to Think About Investing in Open Source

Nadia Asparouhova
7 min readMar 11, 2016

--

I didn’t really want to write this post.

First off, I’ve never made an investment into an open source company. And secondly, even if I had, I have no idea what a “good investment” looks like. I don’t think anybody does, ever.

But I am a former investor who’s now wading into open source land, and it wasn’t easy to figure out, so I figured I’d share my humble process.

If you’re an investor wondering whether “open source” is a buzzword or a value-add, or a company wondering how an investor might think about your business, consider this a helpful set of heuristics.

Figure out what a company means by “open source”

The term “open source” tells you next to nothing about a company’s business model or desired growth trajectory.

That’s because open source itself is not a business model. All open source companies can be mapped to existing business models, and they’re actually pretty diverse.

When a company says they are “open source”, I start by breaking them down into two types:

  • The company is building an open source product (a lot of newer buzz is around companies like these)
  • The company is commercializing an existing open source project (the “classic” open source companies look like these)

The company has an open source product

You’ll see this type of open source company among consumer and SaaS (ex. developer tools) especially. In this case, the product itself is open source.

Consumer examples: Firefox (browser), Odoo (ERP/CRM), Wealthbot (wealth management)

SaaS examples: Sidekiq (background processing), Travis CI (continuous integration)

The key here is the company started an open source project. The goal is to learn what kind of business the company actually has, then figure out how being open source offers a competitive advantage, if at all.

Some things you might hear:

“We’re going to grow a community of developers to scale this product!”

If the company needs a big customer base to succeed, I think of their business as audience-based. They need a lot of developers using their product before the company can monetize. (For example, Meteor and OB1 might fall into this category).

Treat these companies like any other audience-based company. Ask them about their current traction, potential network effects, how they plan to grow their user base. If a company promises you, pre-launch, that they will leverage the power of open source to grow a huge community, I would be as skeptical as if Snapchat told you the same. An audience-based company without traction is just an idea.

“By making our product open source, we can crowd out the competition”

These will probably look like consumer businesses. Ask: who is their target customer? Does the product being open source help that customer in some way? (ex. Product is now cheaper, easier to implement, more customizable) If not, being open source doesn’t matter. The company needs to have the best product on the market. “Open source” is not necessarily a competitive advantage any more than “blockchain X” or “cloud Y”.

Differentiation is also important here. Is there “winner-take-all” potential? For example, there are many front-end frameworks to choose from, so it’s harder to predict which one will get popular, and less likely that one will emerge as The Winner. A company like Docker, however, was early to a new trend (containerization) and had higher barriers to entry. In that case, being open source helped Docker capture a new market.

“We’ll use the open source product to upsell into our paid product”

These companies can be likened to freemium or SaaS businesses. Does the customer need the paid product/features, or is the free product enough? What does the conversion funnel and churn look like? What does the marketing and sales side look like?

“Open source is more secure/transparent”

This claim about open source products, also known as “Linus’s Law”, is oft-repeated, even by developers, but dubious. (I explain some concerns in this post. Basically, just because people could theoretically review your code doesn’t mean they actually do.) On the other hand, perhaps it doesn’t matter whether it’s true or not, if the perception of security or transparency is what’s important to the customer. But if the company’s value derives from being more secure, tread carefully.

The company is commercializing a project

This type of company is more closely associated with enterprise and “classic” open source investing. In this case, open source is the market, not the product. The company is offering a commercial product to this market.

Examples: Automattic (Wordpress market), Nodesource (Node.js market), Red Hat (Linux market)

The key here is the company is commercializing an existing open source project. Some things to think about:

Research the market

Think about the open source project as the market, not the product. How stable is it? Is it growing? Are there companies using it? What are their pain points, and are they willing to pay? For example, BigSQL/OpenSCG supports the PostgreSQL market. Postgres, a relational database, has been around for a long time, but it’s been growing quickly in the past couple of years, including among companies. There is plenty of data around Postgres use that could help size BigSQL/OpenSCG’s market.

The market needs to be really big and stable

There are very, very few open source projects that are big and stable enough to support commercialization. The company needs a lot of people already using the project who are also willing to pay. It can be tough to distinguish what is a flash in the pan, what will be moderately successful, and what is here to stay. A rare example of a large ecosystem being created today might be Node.js and the proliferation of JavaScript.

Your risk variables are two-fold

To explain this, think about all the service providers for the on-demand economy that have cropped up in recent years (ex. taxes for 1099 employees, recruiting for on-demand companies). They’re inherently riskier investments, because both the company and the market it’s built on has to succeed. Ditto to enterprise open source.

For example, Git and Mercurial are two version control systems, both launched in 2005. GitHub built its business on Git, whereas BitBucket initially built its business on Mercurial. GitHub needed Git to succeed to have a monetizable market.

Consider supply chain risk

This is true for any company, of course: markets can change and ruin an unlucky company. Similarly, if an open source project goes under, the company won’t have a business anymore. This is what happened to Bitcoin. Community in-fighting killed Bitcoin, and likely took a lot of companies and investor dollars down with it.

One way to mitigate this is if the company founders have some stake or prominent role in the project it’s built upon. For example, Matt Mullenweg cofounded Wordpress/Automattic, and Dries Buytaert cofounded Drupal/Acquia. It’s more likely they understand the ecosystem well and have the ability to positively influence it. Relatedly, a company could sponsor the project or hire maintainers as employees. Engine Yard did this with Ruby infrastructure for several years.

Market trends to watch for

Zooming out a bit, what can we learn from the past two decades, and where might things go next?

Size expectations accordingly

Joseph Jacks of Kismatic wrote a great post tracking all the open source companies that have ever broken $100M in revenue. The list is not very long, and correlates with multiple conversations I’ve had about how “success” in open source probably looks like $100–300M in revenue, not Red Hat’s $1.5B. That doesn’t mean it can’t generate a sizable return (Joseph estimated the paper valuation of these companies was $25.4B), but it’s worth grounding our expectations in history.

The customer base is growing

As John Vrionis of Lightspeed recently noted, more companies use open source than ever before. This suggests there is a growing base of potential enterprise clients. But there are also many more individual developers building and releasing their own projects, which creates new opportunities for the developer tool market. We might start seeing more SaaS and B2C models than enterprise and B2B. These models will challenge our old assumptions about what it means to grow an open source business.

Counterintuitive ideas

The definition of “open source” itself is changing rapidly. It’s fun to think about what we’re assuming about open source that doesn’t have to be true.

Paid as default: Instead of thinking about open source as “free of charge”, what if open source is the value worth charging for? You could release a product that is closed source with a commercial license, then charge your customer for access to the source code or a more permissive license.

Acquisitions, not IPOs: Maybe revenue is wrong place to look to capture financial value. What if investors optimize for acquisitions rather than IPOs? Open source projects often create enormous value around technology, talent, or community. Big companies already find ways to “acquire” them (ex. Facebook/Redux, StrongLoop/Express), but often that just means the company hired the author to work on their project: pennies to the actual value. Perhaps there’s a win-win there for projects and investors.

Leveraging contributor dynamics: When we get down to it, many people casually contribute to open source to build their portfolio/get noticed or for social reputation. I haven’t fully thought this through, but it seems like those dynamics could be better leveraged to incentivize contributions to consumer-type projects. (h/t Arturo SánchezCorrea for planting this seed in my brain)

How to predict the future

Obviously, I don’t know what the future of open source businesses will look like, but I’d suggest following the breadcrumb trail of people.

That is, do your own research to really understand who’s behind these projects. Talking to developers can give you an unfair advantage in understanding a company’s customer potential, supply chain risk, or how a market is growing.

Ask HN. Email the project’s contributors. Read through the project’s mailing lists or GitHub issues to see how people treat each other and what’s being hotly debated. The disconnect between what developers think about a given project, and what the company tells you, will astound you.

I’m currently exploring better ways to support open source infrastructure. If you want to stay involved, you can sign up here to get updates when I post something new, or follow me on Twitter.

[Did I get anything wrong? Violently disagree? I’m learning too and would love your perspective. Please annotate and comment away!]

--

--