Back in 2001 an ideological battle was raging: Linux and open source against Microsoft and proprietary enterprise software (the then-standard model). At the peak of the battle Microsoft’s then-CEO Steve Ballmer called Linux and its open source philosophy a ‘cancer’.
Almost 20 years later, open source is now an essential part of how enterprise software gets built and Microsoft is the biggest contributor. The industry remains a battleground but it has splintered into many different battles.
Open source is a strong commercial strategy as well as an ideology. The mix can sometimes be an uneasy one. It creates a complicated dynamic of open source and commercial interests. The mix can be subtle and it can tempt us into misunderstandings. Especially since much of the caustic rhetoric of the old days remains influential. It affects how companies evaluate open source tools to use and where they contribute valuable time and talent. Sometimes a company chooses a tool and then they realise it came with unexpected strings attached. Sometimes organisations get put off a tool by the old image about open source and what it represents.
Let's clear up the old misconceptions and better understand the new mixing of commercial and ideological motivations. The open source software industry is a dramatically different place than in 2001.
The GNU public license has been hugely influential with its concept that the end user be free to use and modify the work and any derivative work. It formed a big part of the Linux movement and the values embodied in it. But we should not think of all open source in terms of GNU. A lot of open source now comes from a different set of motivations.
Much of open source has a license or upgrade path that is designed to ensure a subset of users end up paying for the software. This software is funded by a company and the business model requires an upgrade path for the company to make money and keep producing the software. This means there will often be closed-source add-ons available for the open source product (at a cost) or the option of a paid-for hosted version. Many of the most well-known open source software products adopt this kind of commercial open source model, known as Open Core. Examples include Elasticsearch, MongoDB, NGINX, MuleSoft and GitLab and use of the model seems to be growing.
With Open Core, the open source part of the software is free to use. If a particular use case doesn't involve any of the functionality provided by paid-for add-ons, then there’s no need to pay anything. If it does, then users face a choice of whether to buy the add-on or fill the gap themselves. The mix of how much functionality is open and how much is a paid-on can vary a lot across tools.
(Image from Joseph Jacks.)
Often add-ons are targeted at high volume use cases. It’s common for enterprise add-ons to relate to permissions, security and monitoring at scale. The idea is that companies with smaller usage requirements can get started for free and move to paying only when they’re deriving a lot of value from the product.
The open core model can lead to confusion for users about whether and when their use case might lead into a paying customer relationship. Confusion often arises if the vendor is not clear about the boundary between the free and paid offerings. When the differentiation is clear to users then the prospect of paying for the product later down the line usually doesn't dissuade the user from upgrading.
Some companies prefer to confine their enterprise offering to hosted services, giving people the open source free for self-installation, while also offering the exact same functionality as the hosted service. Some companies offer enterprise add-ons on top of a self-installation open source. Some charge only for support and services around self-installed open source. Red Hat, the largest open source vendor, believes strongly in only charging for services and support. Hence we sometimes see criticisms from Red Hatters of the open core model.
My personal opinion is that the open core model can be good for everyone so long as it's done well. But we don't need to get into that debate here - the point is that many popular open source tools have a model that can involve becoming a paid user so this is something to be conscious of when evaluating tools.
Let’s take an example. The Kubernetes project has been a hugely successful open source project with a massive community. It has a vibrant open source culture and has benefitted many organisations. There is a commitment to open source in the culture of the Kubernetes project. Nonetheless, there are commercial motivations in the project and there have been from the beginning. At the time the project launched, AWS had an intimidating share of the cloud market and was way ahead of other cloud providers. The Kubernetes project effectively commodified container orchestration so that workloads could be run on any cloud, including but not limited to AWS. This was a victory for consumer choice. It was also a victory for Google, with their managed Google Kubernetes Engine offering then able to grow in market share. It was also a victory for Red Hat and their OpenShift variation of Kubernetes. This success factored heavily into IBM’s acquiring Red Hat for $34 billion in 2019.
That’s worth repeating. A company dedicated to open source was acquired for $34 billion. That’s not a one-off either. Consider that Oracle bought Sun Microsystems in 2009 for $7.4 billion after Sun had itself bought MySQL for $1 billion. GitHub’s status as a home for many of the world’s biggest open source projects was no doubt a factor in Microsoft’s $7.5 billion acquisition. Open Source is big business now.
The strategy Google used with Kubernetes is similar to its strategy with web products more generally. Google wants to keep the web open and force companies like Apple to follow open standards. The more open the web is, the more users that Google can reach with search, youtube, maps, etc. and that translates to revenue via AdWords and AdSense. We can think of chrome and android as funnels into search, Google's biggest earner.
There’s likewise a commercial motivation behind Facebook’s big contributions to open source data centre management. Facebook needs data centres and they represent a significant cost for the company. If they can drive down the cost of running data centres, then they can make more money. This general strategy is called Commoditising the Complement - you strengthen your offering by making a complementary product so cheaply available that it becomes a commodity.
These examples show us direct commercial motivations but often motivations are less direct. The goal can simply be to help a project grow faster than it would if it were closed-source. If the project is a technical tool that doesn’t offer a direct competitive advantage then it can make sense to open source it and benefit from the contributions of the community (who put in developer hours that you don’t have to pay for) and the reputation boost that can bring (which helps with recruitment).
The tech giants have a dominant role in most of the most popular open source projects. But that’s not to say that those projects aren’t run with community in mind or that there aren’t ideals in play. Commercial and idealistic motivations are now mixed together. Sometimes in harmony and sometimes there’s tension.
Surveys from the last few years show that for many developers open source contribution is no longer just for fun or personal interest. Many developers use open source tools in their day job and surveys have found that a majority contribute to the projects in some form. Companies are contributing to open source, especially the tech giants.
Stackoverflow surveys have found that up to 65% of developers contribute to open source and that the percentage is not very different for professional and non-professional developers. These same surveys also show that more and more developers have been contributing in recent years.
People who contribute to open source do so for a variety of reasons, making personal motivations hard to identify from surveys. One of the motivations is a developer's belief in the value of open source as a practice and a desire to be part of that. Developers are also motivated by personal and career development. The presence of more personal motivations does not mean that developers aren't in some way getting paid to contribute. Developers who work directly for open source companies are naturally paid to contribute. Developers who work for a company using an open source product may also contribute as part of their day job. A 2016 Survey found that 65% of companies were contributing to open source.