Three Models for Commercializing Open Source Software

One of my favorite public figures in the business world is Patrick O’Shaughnessy, or as I like to call him, the Oprah of EBITDA. If you like this blog post, then you’ll probably like his podcast, Invest Like the Best. Patrick’s super power is asking deceptively simple questions, and he recently posed one on Twitter that got me thinking:

There is no simple answer, because there is no canonical “open source business model.” If a business model is a company’s strategy for both creating and capturing value, then free and open source software only covers the first half of that mysterious equation. Deciding to publish and license your software openly is the easy part — the art happens afterward, when you try to capture some of that value.

I won’t even attempt to create a universal taxonomy of open source business models — I strongly suspect there are countless approaches that are tenable. What I know for sure is that I’m too lazy to try to even attempt to cluster them into meaningful categories. Instead, I’ve outlined three strategies for commercializing open source software that I’ve come across in my day job, helping companies analyze massive troves of geospatial data using machine learning. For each business model, I also picked a favorite company that I admire. In all cases, I think the company I highlight is doing an exemplary job of being both:

  1. a successful business (at least, to the best of my knowledge) and;
  2. a responsible steward of at least one open source project indispensable to the functioning of their business.¹

At the end of each section, I’ve included a note about one “differentiated benefit” — an advantage each strategy offers that is superior to the other strategies I outline in this piece.

Model One: Open Core

OmniSci

OmniSci is one of my favorite companies applying the “open core” strategy to the geospatial world. They make a GPU-accelerated database technology that can do some truly wild stuff like instantly visualize billions of GPS pings from cargo ships on an interactive web map.² The core of their platform, OmniSciDB, is a successful open source project licensed under the impressively permissive Apache 2.0 License — you’re allowed to take OmniSciDB, build on top of it, keep any modifications proprietary, and launch a direct competitor to OmniSci without ever giving them attribution! Seriously!³

OmniSci was founded by Todd Mostak, who built out the original technology while working as a researcher at MIT’s prestigious Computer Science and Artificial Intelligence Laboratory (CSAIL). Many open core technologies start this same way — a talented software engineer pours countless hours into a project they simply hope other engineers will find useful. When the project is well-received, they get an idea — what if I start a business around this?⁴

Differentiated Benefit: Organic Inbound Sales

Model Two: Systems Integration

Red Hat is the quintessential example of what I am calling the open source “systems integration” model—unlike the typical open core company, a systems integrator does not typically invent the underlying, massively successful open source project they are helping companies use (in Red Hat’s case, the Linux operating system). They do, however, almost always invest heavily in it and influence its development, and commonly employ a plurality of the most prominent maintainers of the project. But they are fundamentally not the owners of the underlying project — simply, they are major stakeholders.

Crunchy Data

In my neck of the woods, a great example of this kind of company is Crunchy Data, which helps enterprise and government clients integrate the fabulously popular PostGreSQL Database. If you’re a geospatial nerd like me, you know of the PostGIS extension to PostGreSQL, which handles spatial data.

While systems integrators do make money in the form of recurring subscription revenue, it’s usually for support not for a license to use the software. As Paul Ramsey (Crunchy’s Executive Geospatial Engineer and folk hero of the open source geospatial world) put it at a conference keynote I once attended (I’m paraphrasing), “In the proprietary model you pay a subscription to license the software and get support for free — in the open source model, you pay a subscription for support and get the license to the software for free.” That makes sense to me. Still, I would wager a significant portion of Crunchy’s revenue comes from professional services work — things like building custom applications on top of PostGreSQL, or extending it in unusually specific ways for clients, or even just consulting on how to replace proprietary systems with open source alternatives at a high level. These kinds of businesses tend to be bootstrapped and often never get beyond a few people — but they can grow very large if they have enough time to compound over time and the wave of adoption for the underlying technology is sufficiently large.

Unlike the typical origin story of an open core company, Crunchy was born out of a non-engineer’s frustration with expensive and cumbersome proprietary software (namely, Oracle’s database products).⁵ The founder, Paul Laurence, was practicing as a private equity lawyer before founding Crunchy Data — he realized that in order to displace the incumbent proprietary systems with better open source challengers, he would need to form an organization that could handle the technical support, liability, and licensing issues typical of the enterprise sales process.⁶

Differentiated Benefit: Intrinsically Distributed R&D

Model Three: Constellation of Value-added Libraries

Mapbox

One of my favorite examples of this kind of business is Mapbox, purveyors of fine web mapping software. You’ve seen their maps, even if you don’t know it — their clients range from Snapchat to Tableau to the New York Times. They aim their product at developers trying to build an app that just happens to need a map interface in order to make sense — which in today’s world of phones perennially in pockets is honestly kind of hard to avoid. They differentiate on beautiful design and ease of use, two things I admire a lot about them considering how complicated geospatial data really is under the covers.

Mapbox doesn’t have an open “core” per se. But they do have over 800 (!) open source repositories to their name, including some truly ubiquitous ones in the mapping world . Among other things, they created (and open-sourced) something called the Mapbox Vector Tile Specification, a framework that allows massive web maps to render seamlessly while retaining flexible styling options so you don’t have to sacrifice beauty for performance. They’ve built massively popular web mapping libraries for desktop and mobile as well as libraries for working with satellite imagery and OpenStreetMap data. They’re prolific — they ranked as one of the top 40 companies in the world based on public Github activity the last two years above open source heavyweights like Unity, Automattic, and Sandia National Labs.

Mapbox makes all of these useful libraries because they use them in their (very much proprietary) mapping platform. It’s not an “enterprise” version of an open source core — it’s a complete suite of products that Mapbox makes using those same open source tools. A huge part of what is withheld is the mapping data that is used to supplement those products, largely sourced from the OpenStreeMap database, which is a different blog post for a different day. But suffice to say, Mapbox doesn’t directly commercialize their open source work — and yet it’s inextricably tied to their identity as a company.

A quick word on their origin that might explain their maniacal commitment to open source despite fundamentally selling a proprietary product: originally, the founders of Mapbox were leading a consulting firm called DevelopmentSeed based in D.C. and focused on international humanitarian projects (DevSeed still exists and does great work!). I think the explanation for why they are so prolific as open source contributors is that it’s in their DNA — imagine being recruited to a firm under the auspices of building open source apps to help folks like USAID carry out work in the developing world only to pivot to a proprietary product whose early customers included Snapchat — talk about whiplash. In order to retain (and recruit) the best engineers for this new mission, I think it was part of the non-negotiable set of cultural values that they would continue their commitment to be good open source producers and maintainers. But that’s just a bit of speculation on my part!

Differentiated Benefit: Non-competitive Value Creation

🚨Bonus🚨

Model Four: Blockchain

I won’t (and can’t) go into much detail about what blockchain technology is or the many ways it can be applied. But one mechanism that can be built on top of a blockchain is a “token,” or a unit of value you can purchase (or earn through other means) and exchange. All of those transactions get recorded in the blockchain, i.e. the “distributed ledger.” If you create the “protocol” for how those tokens are created exchanged, you can decide how to allot them (and decide, if you want, to allot a bunch to yourself since you put in all the work to create the system). In this way, even a public blockchain project that is entirely open source can compensate the engineering organization that created it — as transactions become more frequent, the network grows, and the value of the tokens increases, the creators of the protocol are directly enriched for their work.

StreetCred

StreetCred is startup applying this concept to the mapping world — they incentivize the collection of place data (e.g. the name, location, and photo of restaurants) by allowing contributors to earn tokens. Interestingly, StreetCred’s CEO, Randy Meech, was previously the CEO of one of the most truly beloved open source companies of all time in the mapping, Mapzen. He wrote an incredible post mortem after that company was shuttered by its parent company, Samsung, just a couple years ago.

Differentiated Benefit: Direct Monetization

In Conclusion

[1] “Indispensable” here is the key word. The threshold for indispensability, in my opinion, is a company whose whole brand identity is tied to at least one open source project and customers/employees would be truly bamboozled should that affiliation suddenly be severed. I do not think of Google as an “open source software company” despite the fact Android and Tensorflow are some of the most important open source projects I know of. Still, they aren’t foundational to Google’s brand. If Docker suddenly announced they were no longer supporting their open source work, however, that would be a betrayal on par with my ancestor Torquil, the 17th century chief of Clan Morrison who turned on his own people and left to join the MacLeod clan, driving the Morrisons from from their ancestral lands in the process…anyway…damn the MacLeods!

[2] AIS, not GPS, I know. It’s a little known fact that AIS pedants always scroll to the footnotes, so I think I’m safe.

[3] This is not legal advice, and I am not a lawyer. I do occasionally play one online, though.

[4] Perhaps the most famous example of this is Databricks, the company formed around the Apache Spark project that kicked off the “big data” revolution. The seven cofounders (holy crap) were all early contributors to Spark and worked or studied at UC Berkley, mostly in the AMPLab. Since deciding they’d have a go of this whole “business” thing, they’ve gone on to raise $897M and are talking publicly about an IPO in the “not-too-distant future.”

[5] This is an interesting pattern to me. The founder of Red Hat, Bob Young, didn’t create the software component (Red Hat Linux) himself either — he acquired it from his cofounder Mark Ewing. Before Red Hat, he ran a computer rental business. It seems to me that non-technical founders tend to commercialize open source software with the systems integrator model, while technical founders tend toward the open core model. Counter examples are welcome!

[6] For more on the subject of how corporate procurement practices impede adoption of open source software, I wrote a whole blog post on the topic, Why Hasn’t Open Source Software Disrupted Esri?.

[7] My Dad more-or-less forced me to study violin for 10 years under the Suzuki method from the time I was 4-years-old onward. Heinous Bach stuff like this is why I hated it — talk about a snoozefest. Later, I taught myself guitar over the course of a few years, which was likely only possible because of the violin training, so I am grateful for it. But still. If you have a child and are considering violin, get them fiddle lessons instead so they can shred Devil Went Down to Georgia like Charlie Daniels.

Comedic relief at Umbra. Writing about maps and the people that make them. For inquiries: jrmorrison.jrm [at] gmail [dot] com