I was introduced to open source, as a concept, when working with some very talented developers years ago. They all had “free software” (that’s what open source was called at the time)—simple utilities that they gave away for free, code and all.
The term “open source” replaced free software after a time, really to rebrand this concept to reflect a more commercially minded group that looked for the commercial possibilities in this emerging movement. This gave birth to Linux, MySQL, MongoDB, Puppet, etc. (all still widely used today) and the rise of enterprises that prefer, or at least use, open source software.
The attraction is more than it just being free. Those who choose open source technology do so to remove the risk of some vendors going under or being acquired by a company that may pull support, to name only a few negative outcomes. If this happens, they can take the code and move forward on their own.
Those already in the public clouds understand that open source software is part of the offering. There are two flavors: first, a third-party software system that runs in the cloud. Second, some version of open source that has been rebuilt and rebranded to be a cloud-native offering but is functionally based and dependent on the open source code tree.
Although there’s no charge for the software licenses, you do have to pay for the use of cloud resources, such as storage and compute. This has been driving some of the open source fanboys a bit nuts, considering that they are religious about free software being, well, free.
Moreover, another complaint from the open source community is that the cloud providers are leveraging open source software for financial gain but not actually adding value to the open source systems or supporting next-generation development of those systems. This gets to the heart of the issue: Public cloud providers are revenue motivated, and the open source communities are largely community motivated. Can these end goals coexist?
Take the Kubernetes container orchestration system (among other things), an open source project that’s hugely successful. Cloud providers, including Google, which launched Kubernetes, now offer this technology as a service. Of course, it’s been modified in ways that allow it to easily integrate with existing cloud-native services. And of course, the cloud providers charge for its use on their public clouds.
One side of the argument is that Kubernetes would not enjoy such great success were it not for public cloud platforms that provide the ability to quickly deploy it. On the other side, the open source community is concerned that the core values of open source dogma at the heart of Kubernetes and other open source projects may be abstracted out of the software running on the public clouds.
Both cloud providers and open source advocates are exploring ways to deal with this mismatch, such as using open core and dual licensing agreements.
The open core model is about selling not-for-free software, with most of the development done by a single company. However, the core of the system is open, and thus the code and the IP are accessible. For instance, a core integration engine is offered as open source, but you’ll have to pay for the connectors that are licensed by the company who developed the open core component. This model should be more lucrative and sustainable for the company developing the open core software, including when the public cloud providers leverage that software for usage-based sales.
Dual licensing agreements are like selling free software rather than non-free. The company that developed the software releases the software using a “copyleft” license like GPL (general public license). However, it can’t be integrated within proprietary products, else it violates the GPL. The company controls how its software is licensed within proprietary products, as within the public clouds.
Both sides need to figure out a good working relationship. I don’t see the popularity of open source software going away, and in no way will the use of public clouds wane during the next 20 to 30 years.
I do see a few things happening. First, the open source community is going to redo licenses to restrict some commercial use moving forward. Although this cannot be retroactive, cloud providers will eventually have to adopt the new model or fork the code. Open core and dual licensing agreements will also rise in popularity.
Second, we may see fewer open source success stories. Kubernetes has been a huge hit, but it’s much easier to list open source projects that have fizzled largely because of the public cloud and missed revenue opportunities for the open source vendors.
Has the cloud hurt open source software? If relevance and revenue are metrics, then yes, generally speaking. However, a huge symbiotic relationship exists now and needs to continue to exist moving forward. Cloud providers should take care to ensure that open source projects are incentivized to start and there are enough resources for them to stay afloat. It’s a huge part of the cloud innovation story.
Copyright © 2021 IDG Communications, Inc.