While open source development is not going to disappear, the future of commercial open source is not very promising. Cloud providers are adopting open source software without necessarily adding value, or supporting future development. No industry consensus exists on the best way to fund open source development. Many continue to believe that open source software should be free.
Redis changed the licensing of some of their enterprise modules to be licensed under the Apache 2.0+ Common Clause. These modules cannot be used as stand-alone commercial SAAS. This was specifically aimed at cloud providers.
The surrounding controversy has raised an issue that has been lurking in the open source community for a while. The best case for open source has been with software infrastructure, rather than software application projects. If cloud computing companies become the infrastructure providers for software, their market control might allow them to take over open-source projects, and sell those software services at a lower price point than companies who market open source services.
If this scenario comes to pass, is there any future for open source companies?
InfoQ: What is the business model behind developing open source software? Or to put it another way, what is the best way to fund open source development? What kind of software development is not a good match for open source?
Paul Dix: There are a number of models that I think can be successful. The first is what I call « open source exhaust. » It’s what comes out of a big company like Google, Microsoft, or Facebook when some software they’re developing is deemed not a part of their key intellectual property. This kind of software can be thought of as a liability on the balance sheet. Infrastructure software that you require to run your business logic at scale is a good example of this. It doesn’t provide the secret sauce that gives your business its value, but you can’t operate without it. So larger companies can open source it in an attempt to get other large companies and developers on board to defray the cost of continuous improvement and bug fixes. The participating companies also benefit by having developers outside their organization pick up these skills. They can be great fodder later for the hiring pipeline. Of course, this method doesn’t bode well for anyone attempting to create a business based on open source infrastructure software.
For businesses looking to have their primary revenue stream be associated with the development of some open source software project, their options are very limited. I believe the only proven model at this point is open core: the company develops closed source software that complements or adds new functionality to the open source software, which it then offers as either a hosted SaaS offering or as on-premise Enterprise software. Some OSS advocates would argue that companies that follow this model are not actually open source companies. Yet every open core example I can think of puts a much higher percentage of their development R&D budget to OSS than any of the big players. Elastic, Cloudera, RedisLabs, InfluxData and many others are open core, and a much higher percentage of their developers are creating OSS than the development teams at Google, Microsoft, Facebook, Netflix or any of the other large companies following the open source exhaust model are.
Open source infrastructure companies used to believe that they could monetize production support and tooling. However, the rise of the cloud providers and fully managed services has negatively impacted that model to the point that I don’t think is viable. As more evidence of the cloud’s continuing impact on open source infrastructure, see MongoDB’s recent announcement about their license change.
Lastly, for building a business, there are services and support. This is the weakest method for funding OSS development. The economics of this looks like a consulting organization, yet if you build a consulting team, you want them to have a high percentage of billable hours. This is directly at odds with having your team develop OSS software. If they’re writing OSS, they’re not billing. Any consulting organization would be better off picking up an already popular OSS project and offering consulting on it.
The last method is through free volunteer community effort. This doesn’t work well with large infrastructure projects. As a project gains popularity and complexity, it becomes too difficult to manage and push forward for a team of volunteers working during their nights and weekends. This model works for small libraries that can be built and mostly marked as done. Larger projects require some sort of sponsorship to survive and move forward.
Matt Klein: There are a variety of business models that have been tried. They all boil down to some variant of (the following are simplistic descriptions): Open core: A portion of the SW is OSS, while a portion of the SW is behind a paywall. SaaS: Run the OSS as a service on behalf of the customer. Services/consulting/support: Charge for various ancillary support and development that a customer might need to use the OSS.
Some business models are a combination of the above methods, and there have been substantial success stories with all of the above models.
In reality, there is no « best way » to fund OSS development since, what works is typically project dependent. Unfortunately, no matter which method, it’s not trivial to generate income on top of OSS because many users fundamentally believe that OSS should be free. In terms of what types of SW development are not a good match for OSS at all? The biggest thing that comes to mind are libraries. Some libraries are absolutely critical to modern systems, but it’s extremely difficult to generate revenue from OSS library usage. This fact has had serious real world effects. For example, the lack of development and resources put into OpenSSL for many years has lead to critical Internet infrastructure being built on top of a poorly maintained yet fundamental piece of SW.
Heather J. Meeker: The only thing you really can’t do with open source software is sell licenses to exploit it. But there is still plenty of room to make money in a private business developing open source software. You just have to know what you are selling, and what you are giving away. Pure open source businesses are quite rare — Red Hat is an incredibly successful exception. A pure open source business sells services — mainly maintenance and support. But it also sells quality control. Customers buy products, not licenses. You can make a business selling open source software packages if you put a lot of work into quality control and packaging. But then, effectively, you are selling reliance on your reputation. Most open source businesses make money with some variation on the « razor blades » model (famously and perhaps apocryphally attributed King Gillette) — give ’em the razor and sell ’em the blades. The razor is open source software. The blades take lots of forms. Some are upsell modules (often called open core), some are alternative rights (dual licensing of the same software, like MySQL), some are « widget frosting » (selling hardware that runs on open source, like may iOT products, and some are early access (an « embargo » model that sells access to code before it is publicly released). In a few of these models, you need to use other kinds of licenses, and that is where variations like Commons Clause come in.
InfoQ: Does open source software only make sense for enterprise developers, or is there a way for cloud vendors and open source providers to work together?
Dix: There might be, but it depends on the cloud vendor. There’s no requirement for the cloud vendors to work with an open source project. Indeed, Amazon seems content to pick up open source projects and offer them as managed services with no commercial agreements or development efforts to push the OSS projects forward. Google and Microsoft have some partnerships, but I’m not sure what those look like. Also, what happens when they decide there’s no need to continue to support some other company writing the open source? They can easily hire all the developers they need to push those projects forward. Their motivation to do so is to get developers paying for their hosting. Building out around open source is just a method to make sure that one of the other cloud providers doesn’t build a big development community around proprietary, closed APIs. The big three cloud vendors are in a knife fight against each other where the OSS infrastructure companies may just turn out to be collateral damage. For instance, Microsoft and Google are going to continue to push Kubernetes forward as the standardized Cloud API because it helps them deposition AWS (the market leader) and commoditize cloud APIs. How will the startups fare that are attempting to turn Kubernetes into a business? If it plays out like the Open Stack ecosystem, those startups will have all closed up shop within the next three years (although consulting on Kubernetes will be alive and well).
Klein: I’m not sure that I completely understand the question. Popular OSS will inevitably be used by both enterprises and cloud vendors. Additionally, cloud vendors will likely offer hosted products built on top of popular OSS, without necessarily contributing in a substantial way back to the project. The larger question IMO, is how to properly fund OSS development in a way that leads to community first development, while still allowing value to be extracted on top (via either open core, SaaS, services/support, or some combination). Unfortunately there is no consensus on how to do this. Personally, I believe that in the future SW foundations will have to play a larger role in providing a neutral home for critical OSS. The foundation’s additional responsibility will be to raise money to fund development and maintenance resources that can remain neutral while still supporting business interests on top (whether enterprise, cloud, etc.).
Meeker: The watershed moment we are experiencing, which resulted in Commons Clause and other alternative licensing models, is cloud providers adopting the software of smaller companies and making the software available commercially without adding material value, but not making any arrangement with the company to support development.
