Nearly all modern software is based on open source. At VMware, we regularly create and contribute to open source projects, and many of our products are built on top of open source software. This allows us to provide to our customers more innovative solutions on a faster timeline, and at the same time makes our developers more productive. However, not every open source project offers the same benefits, and some projects have significant risks that should be considered when deciding which open source projects to embrace – and how hard to “hug” those projects. As in all things, a known risk is a managed risk and open source is no exception. In this blog post series, I’ll explain the different types of risk present in open source, starting with open source licensing risk. By learning about the risks, you’ll be better equipped to balance them by making more informed choices.
In a previous blog post, I talked about the benefits that open source projects gain by being under neutral foundations. In a best case scenario, an open source project will enjoy contributions and leadership from a diverse pool of collaborators, representing varying interests and use cases. When a single company controls a project, that diversity vanishes and user risk rises for the project exists at the whims of that company. When that company chooses a path that doesn’t align with the expectations or needs of the project’s users, there is little recourse – users are locked in to that company’s strategic vision for the project – like it or not. Those strategic shifts can be a technical change or lack of change, or something more abrupt, such as adoption or introduction of a new license type. While there is always an option to fork the open source project, forking requires a huge effort and a commitment to maintain the project over the long-term. This isn’t a viable solution for most users. It can help to consider the reputation of that company as a steward of open source projects, but always keep in mind that they can change their strategy at some later date.
We’ve seen this recently with several companies relicensing their open source projects. In 2018, Redis Labs and MongoDB became disenchanted with cloud providers who sold SaaS offerings based on their open source projects, but gave little, if any, support to the ongoing development. The solution in both of these cases was to introduce more restrictive licenses on their open source software projects.
In the case of MongoDB, they created a new license called the Server Side Public License (SSPL) that would be used for MongoDB, but would also be used for security patches for previous open source versions of the software. The biggest change is in Section 13 of the SSPL, which says that if you use the project in a software as a service offering, you have to not only make your source code and modifications available, but also the source code of the applications used to run the service. This could be problematic for anyone making software and services available on the internet, since this could be interpreted to mean that they would need to open source the code for their platform. In a more recent example, Elastic moved Elasticsearch and Kibana under the SSPL for similar reasons. It’s important to note that the SSPL is not an Open Source Initiative (OSI)-approved open source license. The OSI is a non-profit organization, which is generally recognized as the group who reviews and approves licenses that conform to a generally accepted definition of open source. This means that MongoDB, Elasticsearch and Kibana are no longer considered to be open source projects by those of us (including VMware) who adhere to the OSI definition of open source.
Situations like these increase your business risk and can impact your ability to deliver software. License changes require time from lawyers to help interpret these new licenses, which can be difficult in the absence of precedent for how challenges to these licenses will fare in the courts. If you want to continue using open source software, you may be left with the option of using a fork of the project or replacing it with another open source project that provides similar functionality. These time consuming options could delay your product delivery and decrease productivity if you need to spend extra time finding and implementing a suitable replacement.
Most business decisions boil down to an assessment of risk and making tradeoffs. It can help to think about project risks in light of how you’re using these projects within your business. If you build products on top of an open source technology, you want it to be as low of a risk as possible. On the other hand, if you are using an open source project as a small part of some non-critical infrastructure, you can accept more risk.
The takeaway is that open source projects that are controlled by a single company can introduce additional risks for your business. If given a choice between a project under a neutral foundation and one controlled by a company, the foundation project will usually be lower risk. (For more on neutral governance, see my earlier blog post about collaborative leadership and governance.) However, we all use open source projects that are controlled by individual companies, and we certainly have many that have originated within VMware, so this doesn’t necessarily mean that you should never use them. These projects should be considered carefully by weighing the benefits in light of the potential risks and then making a business decision about whether to embrace a particular project.
This is the first in a series about assessing the risks of open source software. Next, check out our blog post about contributor and organization risk.
Thanks to Jordan Madrid for providing this blog’s feature image.
