These days it is clear that open source software is the default choice for development and infrastructure. Whenever you look at programming languages, operating systems, modern database technologies or the whole cloud native space, open source solutions are among the leading choices, writes Peter Zaitsev, CEO and co-founder of database specialist, Percona.
As there is such a dominant open source position we often see companies marketing their software as “Open Source” even though it does not provide all (or any) of the benefits offered by truly open source software.
Peter Zaitsev, CEO, Percona
In this article we look at some common traps, and provide advice on how to avoid them.
What is Open Source Software?
Many people do not realise that the term ‘open source’ is not trademarked, so in theory any company can use this term to describe any kind of software. The only fall-out is the fear of media and user revolt, but generally not legal action.
If you look at the Open Source (and free software) Community there are three different organizations which provide definitions:
- Open Source Software (OSI)
- Free Software (GNU)
- Debian Free Software Guidelines (Debian)
While each organization uses different terminology – Free versus Open Source, and are slightly different in spirit, they are similar enough for our purpose.
When I talk to business leaders, looking to adopt open source software in their company, they ask me how to evaluate whether open source software really serves their purpose. Generally their purpose is (surprise surprise) to reduce costs, improve efficiency, etc.
Content from our partners
I suggest they ask themselves (or the vendor they plan to work) with following questions:
- The License – Does the license the software is shipped under fit the intended use of the software? Specifically, CopyLeft licenses may not be a fit when you plan to re-distribute combined work under a different, or proprietary, license
- What happens if you stop commercial relationships? If you started a commercial relationship with the vendor supporting or developing your software, what happens if you have to terminate the relationship? You want to ask this question to avoid being held “hostage” in pricing negotiations, and also because your vendor may cease to support your chosen software as a result of business changes or acquisition.
- What alternatives exist out there? If the software is truly open source you can always choose to continue its development and support in-house in a worst case scenario. In reality this it is not practical for many organizations, so having other alternatives, such as a rich ecosystem with multiple vendors, is great.
- Can you contribute? If you need to improve the software to better fit your needs, such as hardware support, or specific software integrations, you want to understand how to make it happen. Some software offers great extension possibilities or contributor programs. Others do not.
Open Source Traps
Let us now look at different ways that “Open Source” can be used to describe software that is not entirely in-line with the open source software principles described above.
“Open Source Compatible” Software
A lot of software these days states that it is “Open Source Compatible”, but does not claim that it is open source. For example, Amazon RDS Aurora claims to be compatible with MySQL or PostgreSQL, but of course, it is not open source.
When you hear “compatible” relating to open source, it typically means what I call “Hotel California Compatibility.” This means that it is easy to migrate from an open source solution to this proprietary technology, but it may be very hard to return because of the additional features that you may start relying on.
When you look at open source software deployed in the cloud by the vendor, even if the “core engine” is completely the same as the open source version, with no changes, the surrounding management interface is typically proprietary. This means that your team may start to strongly rely on it in their operations.
Avoiding the Trap: Don’t get me wrong, there is a lot of great open source compatible software out there, which can offer better performance or usability than open source software alone.
As long as you understand that it is proprietary software and you are fine with that, there is no problem. If, however, you want to leverage that “compatibility” and ensure that you can leave it for a fully open source alternative, you need to make sure that you are testing that in your application.
For example, if you want your application to be able to run on PostgreSQL, or Azure Database for PostgreSQL, in addition to Amazon RDS Aurora with PostgreSQL compatibility, you need to test functionality, performance, and management capabilities.
Open Core
Open core software refers to when there is an open source version of the product, often called “Community” and also a proprietary version of product with additional features, often called “Enterprise.” The community version can be more or less “crippled” to make sure that the enterprise version can be sold successfully.
Open core software is often marketed as open source software. For example, MySQL calls itself “The World’s Most Popular Open Source Database,” not “The World’s Most Popular Open Core Database!”
Enterprise versions of software often include a number of extensions and improvements which may be worth having depending on your circumstances. Yet, the “Enterprise” version of software is similar to “Open Source Compatible” software.” Ie, if your goal is to avoid software lock-in you need to be testing that you’re actually achieving this.
Avoiding the Trap: The most simple way is to avoid the Enterprise version, and stick to the Community version if you can.
You should explore the ecosystem for third party solutions that offer features which otherwise only exist in the Enterprise edition. If you’re dealing with popular software, alternatives are likely to exist.
If you look at MySQL for example, Percona Server for MySQL includes many Enterprise feature alternatives and is 100% free and open source. Percona is not the only company offering alternatives though. If you’re looking for an Enterprise Auditing Plugin alternative you could check out open source McAfee Audit Plugin for MySQL. Even if you can’t get all of the features you need from open source software, decoupling and using alternative vendors can often lower your costs and reduce lock-in.
Source Available
“Source Available” is a class of licenses which allow you access to the source code but have some restrictions compared to truly open source software. In recent years, many open source software vendors have chosen Source Available licenses to protect their business from disruption by large public clouds.
MongoDB is perhaps the most well-known for changing their license from AGPL to Server Side Public License (SSPL). This was not recognized as an open source license. Elastic, Confluent (Kafka), and Redis Labs have since followed, changing the licenses of some of their software from Open Source to Source Available.
It is worth noting that the Source Available class of licenses is very broad. Some of them can infringe on just a few of the freedoms found in Open Source licenses, others may provide little beyond the ability to review the source code.
More often than not. Source Available licenses are designed to restrict competition. This may be good for open source vendors, but it increases your chance of being locked-in, with no alternatives.
For example, if you’re looking for DBaaS deployment with MySQL or PostgreSQL you have many choices, from vendors big and small. If you look at MongoDB though, there are few alternatives to MongoDB Atlas (the DBaaS offering by MongoDB). Those that do exist require the cloud vendor to have a licensing relationship with MongoDB Inc. This is not dissimilar to how Microsoft SQL Server, or Oracle, is made available on various clouds.
Besides cloud restrictions, Source Available licenses may restrict you from choosing your preferred vendor to help you operate or customize such software.
Avoiding the Trap: Set your expectations correctly. A Source Available license is a proprietary license, as such you need to review it carefully to avoid getting into trouble.
Open Source, Eventually
“Open Source, Eventually” is a class of Source Available licenses which has a property of code becoming open source after a period of time. The BSL (Business Source License) used by MariaDB corporation for some of its products is perhaps the most well known example.
Vendors releasing software under a BSL license claim it is a better choice than Open Core because over time features make it into the Open Source version. In practice though, only outdated software becomes Open Source. This is often unmaintained and contains known security bugs by that point and, as such, is not really feasible for serious use.
On the other hand, with the Open Core model you typically get a smaller set of features, but these tend to be secure and well-maintained as it often serves as an onboarding ramp for the Enterprise version.
Avoiding the Trap: As with other proprietary software licenses, make sure you fully understand what you’re getting into.
Source Only “Open Source”
Because “Open Source” technically applies to the source of the program and not binaries, supporting documentation, or even full build scripts and environment configuration, you can fall into a trap here as well.
Differentiating on builds is quite acceptable in the open source community – in fact one of the respected open source ecosystem Titans – RedHat, uses availability of certified builds and timely updates as the core of its subscription offering, even though source code is available to everyone.
Avoiding the Trap: Even if software is open source, do not assume it will be easy for non-customers to install and maintain. Check it out carefully. For popular software there might be third-party builds and alternatives. For example, CentOS can mostly be seen as an alternative build of RedHat Linux, and its binaries are available without a subscription requirement.
Conclusion
I hope this article is useful and helps you better understand the pitfalls that can come with using open source software, as well as understanding whether software is truly open source, or just something which uses “open” or “source” in its marketing materials.
While there are traps to avoid, embracing open source as the default infrastructure choice for your enterprise will help you to save money, and provide more balanced vendor relationships, reducing or eliminating software vendor lock-in.
