Implementations of open source solutions are increasingly delivering enterprises compelling benefits over proprietary counterparts, with mature solutions available throughout the stack to provide advantageous flexibility and cut costs significantly. At the same time, incorporating any software into enterprise architecture almost always represents a long-term commitment that carries some level of risk. For example, if a dominant entity with heavy influence over a particular open source project decides to pull the solution in a negative direction – or ceases operations entirely – reliance on that component can quickly become a severe liability.
Accurately evaluating this risk means developing a thorough understanding of an open source solution’s licensing terms, the health of its ecosystem, and the business models of the commercial organisations attached to the solution. Identifying the risks these factors represent before committing can save your enterprise from the tremendous (but often avoidable) challenges of transitioning away from an OSS solution that’s no longer viable.
1. Know the open source licensing terms
Open source software utilises a rather wide variety of different licenses, each with its own permissions, conditions, and limitations on its usage.
Enterprises must first be aware of the risks of using software shared under “copyleft” licenses that require any iterations derived from the core project to also be shared openly – and therefore leave a business’ intellectual property open to exposure. Similarly, enterprises must also be careful in avoiding certain licenses that limit commercial use. I believe a just-as-important danger in using software licensed with copyleft provisions is that large businesses most often won’t contribute to open source projects under those rules, curtailing the potential strength and independence of that project’s community. In these circumstances, it’s common for the software to have a singular and unhealthy reliance on a single entity. One huge and obvious exception is Linux, which uses the popular copyleft GNU General Public License but thrives due to its broad value and the fact that enterprises don’t expect to customise it for their own benefit alone.
2. Know the ecosystem
The broader and more active the ecosystem surrounding an open source software solution, the less risk there is in adopting it. All open source projects evolve with time: a greater breadth of organisations depending on the software’s capabilities and influencing its growth ensures that it will continue to serve the needs of a broad user base. In contrast, software with a narrow set of influences may very well be pressed to serve narrow use cases – or even the commercial interests of a specific enterprise. In egregious examples, open source projects may be made to add features that provide no actual value aside from marketing appeal.
To check the health of an open source ecosystem, investigate these specific factors:
- Does an independent body own and govern the software? When control and future decision-making are in the hands of an independent foundation, it’s usually the case that multiple supportive organisations are involved, user value is championed, and the risk to your enterprise is relatively low.
- Do large, well-known, technology-driven organisations use the software? This is a signal of health, and makes it unlikely that your enterprise will need to do more than its fair share of upkeep on the project. Even with well-established projects, keep an ear to the ground to know if and when large organisations might move away from the technology, giving your own enterprise time to consider doing the same.
- Is the software used by a variety of businesses, such as consulting companies, managed service providers, and businesses with their own software products that depend on the technology? Deep buy-in from organisations strongly incentivised to see open source software succeed for them speaks well of its health, and further reduces the risks of relying on it.
3. Know the commercial interests of open source software providers and influential vendors
The unknown is full of risk, especially when it comes to the motivations of the vendors or managed service providers (MSPs) you depend on to deliver or support open source solutions (as well as those vendors with strong influence over its development and maintenance). By understanding these business’ motivations, you can identify if and where they may coincide with possible risks to your enterprise.
Here are some of the common business models in this area:
- Businesses building their own IP on top of free open source software (FOSS). Many companies provide “commercial” version of open source projects to with proprietary changes or to additional features (commonly referred to as open-core). These companies are motivated to promote and make beneficial contributions to the open source projects at the heart of their products. However, make no mistake about it that their first loyalty is to their own offerings, which can incentivise them to oppose the development of features in the freely available version that resemble their proprietary additions. Customers of these businesses may also receive less enthusiastic support when dealing with FOSS features as opposed to proprietary ones. And, the risk of vendor lock-in can be as serious as with any closed source software, even though these proprietary solutions are rooted in open source.
- Businesses offering open source software (while maintaining complete control). Other businesses will develop solutions and release the code as open source, even accepting external contributions. However, unlike with an independent foundation, this commercial company makes all decisions as to the direction of new features and releases. In these cases, risk should be assessed based on the strength of the external community around the software and the license terms of the software itself. Unless the license and community make an independent community-driven fork of the software possible, the risks that the provider could take the software in an unwelcome direction or remove access completely will always be present.
- Cloud providers. Major cloud providers offer lightly-managed versions of some better-known open source solutions, with the motive of drawing users to their own platforms. These businesses don’t take the driver’s seat when it comes to innovation, but they usually do contribute to projects to ensure bug-free experiences for their users. Cloud providers have been largely increasing their involvement in open source projects (fuelled by community pressure), and possess the resources and interest to balance businesses in sole control of open source solutions and fork software when necessary (Amazon Corretto is a powerful example of this).
- Managed service providers. Like cloud providers, these businesses are also motivated to win new users, with the difference that they have fewer resources but far more interest in the success of the FOSS solutions they deliver. Given this motivation and their capabilities, MSPs will often assist enterprises in testing and determining the correct open source solutions for their needs, and implementing customisations as necessary. MSPs can also signal ecosystem health, in that they often contribute to open source projects in proportion to the value of the project to their business.
For just about any enterprise preparing to commit to a particular open source software solution, the biggest risk factor is in not doing your due diligence. By understanding the software, its ecosystem, and its contributors and providers, you can vet solutions and select a prudent choice that will hold up over the long-term.
Ben Slater, CPO, Instaclustr
Image Credit: Wright Studio / Shutterstock