Docker, Mesosphere, Cyanogen, Elastic, Cloudera…

These days, it seems difficult to find a successful new open source project without an “attached business.” (There are many past open source projects that succeeded without a single business alongside them, and they become so important that their ubiquity makes them almost invisible: Apache’s web server, the Linux kernel, OpenSSL, GNU Emacs, perl, python, and many other programming languages, among others.)

As open source projects spread and become essential in every business, I wonder – why and how do new open source software projects often seem to twin with valuable startups?

At Bloomberg Beta, we invest in companies that make business work better – and it’s clear that’s impossible without a view on how open source software breeds businesses (and how it breeds new ways of thinking about business, though that’s a subject for another time).

The birth of businesses around open source projects is surprising because there’s a myth about open source – that it’s not owned or directed by anyone, that a “loose band of hackers” can make something that competes with the biggest corporations in the world. So how can open source projects spawn startups?

The myth about open source is (to some degree) real: the eyes (and keystrokes) of the many can make and maintain better software, faster, than closed software development. So open source often beats out proprietary software. Openness breeds trust – the same reason we open sourced the full investment manual for our fund. (It’s hard to imagine what Adam Smith would have thought of the capitalists sitting on top of a freely-offered product that anyone can copy and use for themselves, built by a coalition of the compensated and the volunteer.)

The reality, well known to technologists, is that (successful!) open source projects are led with a strong hand, and the most frequent contributors are most often paid to contribute to the open source project as their job (e.g., 80% of contributors to Linux are paid). The various open source licenses carefully parse aspects of ownership – and some licenses are more open than others.

So, open source projects twin with valuable startups because – without those startups – some open source projects may lack oxygen (in the form of paid contributors, and users who care about the development of the open source project). So then the question is, if successful open source projects may thrive when they’re twinned with valuable startups, how exactly does that work?

Docker is re-introducing many questions about the relationship between open source software projects and viable business models. (Look at Mesosphere, Cyanogen, Elastic, Wordpress, and Cloudera for other recent examples – and of course Red Hat as the pioneer.)

Good open source projects are fast, have active and engaged user bases (often developers building for themselves), iterate quickly in response to needs – just like a good startup.

For many years, the assumed business model of companies commercializing open source was enterprise services. Red Hat famously made it easier for large corporations to use the Linux operating system, as it helped them deploy and maintain the system more rapidly and more efficiently than they could do on their own. That model, with its reliance on selling time to service software, is hard to scale.

(The focus of this piece is about startups. Plenty of established technology companies use lots of open source software in meaningful ways, some – like Bloomberg, the backer of our fund – contribute to it and gain better software, a stronger reputation with talent, and are just doing the right thing.)

Surveying startups commercializing open source technology today, we may be seeing experimentation at a new clip. It’s too early to say which will work better than others – it’s early days for this. I see two types of models…

Wide Models

These add value to the broad swath of the community of a given open source technology by building better infrastructure, making it easier and more convenient to work with the technology (making it more accessible for a wider array of developers), offering differentiated features, etc. Basically, these tools make it easier, faster, and better for companies or developers willing to pay to use the open source technology.

Narrow Models

These focus on concentrating the potential of the specific open source technology around a specific business use case. These startups are born of the opportunity that arises when a specific industry or enterprise function could find significant value in the open source technology, but the associated community doesn’t necessarily have the interest or incentive to focus on that use case. Entrepreneurs fill that gap with their own modified version of the project designed with that specific type of user in mind.

There are many variations, and the list below is overlapping, imperfect, incomplete, and will invite (in success) many a rant. Nonetheless here is a walk through of…

… The Zoo of Open Source Business Models

Wide Models

The “Cleaner Shrimp”

aka Enterprise Service (they make it work for you)

Example:

Open source technology: Linux | Company: Red Hat

In many ways, this is the granddaddy of the open source business model. Take freely licensed software and build a slate of services around implementation and support that allow enterprises to get that open source software running, dependably.

The “Lioness”

aka Convenience SaaS (she goes out hunting)

Example:

Open source technology: Elasticsearch ELK stack | Company: Elastic

Software-as-a-service has revolutionized how software is deployed in the enterprise. In response, many of the modern open source business models are based not around on-site deployment and servicing, but around deploying and supporting the open source software through cloud based service(s). A perfect example is Elastic (formerly Elasticsearch), which helps business add a search and insight layer on top of their data and is available either for free or deployed as a service for a fee.

The “Cheetah”

aka Time-to-usefulness (you can do it in your own, it’s just harder)

Example:

Open source technology: Apache Mesos | Company: Mesosphere

Sure, you can set up Mesos on your own to manage your data center resources as if they were a single environment. If you’re in a corporate environment, though, there will be lots of pieces you’ll need to build to make it work. So it might be faster and less expensive to let Mesosphere do that for you.

The “Peacock”

aka Premium Features (adds on the glory)

Example:

Open source technology: Wordpress | Company: Automattic

Open source communities chose their own direction, and don’t necessarily develop the set of features that a commercial company layered on top would want to offer business customers. Given that, some companies give paying customers access to premium features. An example is Automattic, who in addition to offering a “Lioness” SaaS-style deployment model, offer premium templates for customers who want to customize their blog.

Narrow Models

The “Finch”

aka Use-Specific Fork (the beak fits the food source)

Example:

Open source technology: Linux | Company: Cumulus Networks

The beauty of open source software is that it can be refined and modified for specific use cases. One of the business model opportunities is to fork a piece of software and customize it for one of those use cases. An example might be Cumulus, which is a Linux solution specifically customized for data center & network hardware. Sometimes the commercial project can become more successful than the open source project (CouchDB was at risk compared to its commercial variants), putting the underlying technology at risk.

The “Remora”

aka Add-On (a company extends an open source project to make it their own)

Open source technology: git | Company: GitHub

One of the most popular modern open source business models is to sell companies a private version of the software, so they can use it within their corporate (organizational or server) walls. This is the model for one of Silicon Valley’s most essential companies, GitHub. GitHub has some “peacock-y” aspects – now-essential concepts like the pull request are missing from the underlying open source technology.

As our industry develops, we’ll likely develop better words for these models… share your feedback on this list, and let’s try to invent business models that help make open source software even better. I have skipped comparing and contrasting the merits of these models – their merits as companies, in terms of community support, or otherwise.

Once we see how open source works in software, we’ll see it elsewhere: Bloomberg open sourced the code for Paul Ford’s feature-length article on code itself in Bloomberg Businessweek, for example. Our investment fund open sourced our previously-internal operating manual for our fund, inspired by the Series Seed financing documents. Open source software and communities give us a model of a clear hierarchy of leadership over a project, with contributions open to anyone, and the results of everyones’ labors shared broadly. That way of working has many implications for open source beyond software and into the heart of how business (and much other human activity) gets organized.

Thank you to Nathaniel Whittemore for helping me get started on this too many months ago, and to Jesse Vincent, Charlie Robbins, Justin Erenkrantz, Kevin Fleming and others for helping me learn the very beginnings of what They Know about open source software and communities.