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:
- a successful business (at least, to the best of my knowledge) and;
- 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
“Open core” businesses offer a free, open source version of their software and a paid version with additional proprietary features that would be a pain to replicate (e.g. authentication support). In the not-too-distant past, the idea of raising venture capital for a such a business would have been viewed as absurd (“you just…give it away?”). But today, there is a new “open core” company announcing a massive fundraising round seemingly every month. Companies like Elastic, D2iQ (formerly Mesosphere), and GitLab have raised >$100M each. Some open core companies have even successfully raised money on the public markets, like MongoDB and Cloudera. I think the reason these kinds of businesses are so palatable to traditional investors is that they look pretty much like any other SaaS business because they can make money from recurring revenue for their enterprise product; the open source core is more-or-less a marketing expense on par with any freemium SaaS product. I think when most people think about the prototypical “open source business model,” open core is what they’re conjuring.
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
All of the open core businesses I know of share one thing in common: they sell to software engineers. A terrible way to start a business that sells a product to software engineers is to cold call them at their desk and pitch them on it. First of all, they probably don’t even have a phone at their desk (if they even have a desk). Secondly, in general they hate being pitched stuff. They would much rather buy something after going through the same due diligence they apply to every other new technology they adopt: go to an open source repository, skim the documentation, play with it, and start to form conviction that it solves a real problem of theirs. For those engineers that work at a large enough company and are trying to integrate that software with a sufficiently complex system, the proprietary features of the “enterprise” version of that open source technology will be attractive, and they’ll self-select as qualified sales leads. The beauty of the open core technology is that it’s simple to explain and palatable as a business model for precisely the audience it’s aimed at. And never underestimate the branding power of “open source” as a catalyst for word-of-mouth referrals —among engineers I find that it’s generally cooler to recommend an interesting open source project to a colleague than to recommend some proprietary software.
Model Two: Systems Integration
Perhaps the most famous open source software company of all time is Red Hat, the makers of the Red Hat Enterprise Linux distribution. I grew up near their headquarters in North Carolina and would often drive by their big building off the side of I-85 with an unfortunate fedora logo and think to myself, “what’s that all about.” Well, it turns out that was about building a business that sold to IBM earlier this year for $39 billion (with a “B” y’all). Cash money.
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.
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
Whereas open core companies often bear the brunt of funding R&D investment in their core tech for a long time until the project reaches maturity, systems integrators are usually built on open source projects that have already reached such massive scale they don’t have a single “owner” of the project anymore. While it’s important for the company to maintain good standing in the community of engineers who use the open source technology they are building on, they benefit from an effective R&D budget many orders of magnitude larger than their own. Whether they have a good year or a down year doesn’t affect the overall enhancements that they wind up benefiting from; the drumbeat of development goes on no matter what is happening inside the company. And for a profitable company with a significant amount of revenue coming from professional services engagements (which are notoriously volatile), being able to rely on consistent product improvements and maintenance regardless of available R&D budget is an incredible luxury.
Model Three: Constellation of Value-added Libraries
Someone please find a better name for this business model. My name for it is about as catchy as a Bach minuet.⁷ But it’s also one of the most common types of companies I see springing up, so I have to at least try go give it a name.
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
I think a fair criticism of both the open core and systems integration models is that they have somewhat dubious claims to building a true technical moat. Sure, it would be hard to replicate their businesses but you’ve got almost everything you need to do it right at your fingertips — and you’re legally allowed to try. The nightmare scenario is that AWS will simply launch a compatible service that threatens to destroy your business overnight. But that’s not really the case with this third category — sure, there are building blocks (in the form of software libraries) that have been open-sourced, but there’s a huge gap between that bucket of tools and the secret sauce of the product you sell. In the meantime, you theoretically grow the overall market in the long run by making entry into your niche easier for the average software engineer.
🚨Bonus🚨
Model Four: Blockchain
You didn’t expect it, because I only said I’d cover three business models, but I’ve got a surprise fourth business model for the heroes that actually read to the end of the blog post. I can’t just write a whole blog post about commercializing open source software without mentioning the B-word…after all, it has turned at least a few open source software developers into the other B-word — billionaires.
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 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 theory, value accruing to the protocol creators is inherent to blockchain projects as long as the protocol creators design it that way. This is a huge innovation in the open source business model generally — the idea that you can monetize usage of your open source code without having to sell services/support or up-sell to a proprietary version is pretty exciting in my opinion. Suddenly incentives between software engineers and users are truly aligned; there’s no concept of holding features back in order to keep them as part of the commercialization story. I personally find this advantage of the structure of blockchain projects to be the most compelling reason why they’re worth investigating.
In Conclusion
I think at some point in my schooling I was taught to end essays with a section titled, “In Conclusion,” so here it is. I would love to learn about other open source business models I didn’t cover in this post, or how badly I butchered the explanation of blockchain technology, or simply how much you love me personally. So please, if you have thoughts, drop me a line on Twitter (@mouthofmorrison) or send me an email at jrmorrison.jrm [at] gmail [dot] com!
[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.
