How to Evaluate the Potential Risks in an Open Source Strategy

By Ben Bromhead, CTO, Instaclustr

While the distinguishing benefits of open source software are increasingly (and deservedly) winning enterprise adoption, it’s still critical to understand that open source is by no means synonymous with risk-free. By embracing OSS, enterprises can leverage everything from mature solutions to the most cutting-edge tools, preserve their flexibility by avoiding the lock-in associated with proprietary alternatives, and greatly reduce costs by using software that is often free to use in and of itself. That said, adding major software components to enterprise architecture means investing time and resources, and making a commitment that oftentimes represents some level of risk.

In troublesome instances, an organization with outsized influence over an open source project may ensure that the project shifts to suit its own needs over those of the project’s users, or may even cause a project to stop being available entirely. Recognizing warning signs and gauging the risks of such potential scenarios requires a thoughtful examination of the specific open source solution from several perspectives. This includes taking a close look at the software’s licensing terms, its community ecosystem, and the business models driving the organizations who are able to have the most influence over the project. By accounting for the risks of open source software before those potential issues become your reality, you can better avoid situations where you suddenly discover your reliance on a certain solution was misplaced (and which can prove costly to escape).

Evaluating open source licensing terms

Open source software licenses come in all shapes and sizes, and an awareness of the permission, conditions, and limitations of using each is central to making wise selections. For example, solutions shared through “copyleft” licenses require that any innovations an enterprise produces by building on top of the core project must also be shared as open source – creating the risk that the business cannot retain its own intellectual property. Licenses that limit commercial use can present a similar risk.

At the same time, any project with licensing that includes these kinds of obstacles for enterprises is unlikely to receive the robust support and level of contribution necessary for a strong, independent, thriving solution. With the major exception of Linux – which is incredibly widely-supported thanks to the breadth of the value it provides and despite using the copyleft GNU General Public License – such licenses often leave a project with a detrimental dependence on a singular organization.

Evaluating a project’s ecosystem

An open source solution with a healthy ecosystem presents little risk to enterprises adopting it: the project should remain active and the software available, even if some major contributor were to withdraw support. However, projects with less solid foundations do represent riskier propositions. Open source projects tend to evolve to meet the needs of its influencers; solutions with a broad userbase will continue growing to serve a breadth of use cases, whereas those controlled by a few will not. It’s not unheard of that OSS dominated by a single contributing enterprise will introduce features with no true value for users, simply to fulfill that business’ own marketing needs.

More specifically, in judging the ecosystem of an open source project, it’s helpful to check these criteria:

– Is the project owned and controlled by an independent foundation? If so, the solution is very likely low-risk, as a board representing multiple organizations will ensure balanced development that serves the project’s users and community.

– Does the solution count big name, technology-oriented organizations among its userbase? This is another key sign of long-term health, and also means you can expect large well-resourced organizations to contribute to the project’s upkeep, sparing your own enterprise from needing to do more than its share of the work. It’s also smart to pay attention to any moves made by these large contributors – if they have reason to move on from a project, it may be wise to join them before the ecosystem deteriorates more substantially.

– Do many different types of businesses use the solution (for example, software providers, managed service providers, consulting companies, etc)? The greater the breadth and depth of the ecosystem of organizations relying on the solution, generally the less the risk in your enterprise using it as well.

Evaluating the business models of organizations within a project’s ecosystem

Adopting an open source solution often means working with vendors, managed service providers, and others in the ecosystem that each have their own hopes for the future of an OSS project. The motivations of each of these various organizations can be understood by investigating their business models and the incentives inherent to what success means for those companies. In order to mitigate your own risk, it’s essential to recognize where these motivations are congruent with your own goals, and where they might differ.

Let’s take a look at four business models common to open source software ecosystems:

– Businesses that create intellectual property based on free open source software. These businesses offer their own “open-core” paid versions of open source projects, which come with additional features and other proprietary changes. As a result, they are incentivized to meaningfully contribute to the open source projects they build upon; the health of the project is symbiotic with their own. At the same time, these companies have a perverse incentive to keep the freely available version of the software from ever including the features that they charge a premium for. If they have the influence to steer the project in such a way, they likely will. For the same reasons, customers that rely on these businesses’ solutions may find that they are encouraged to use proprietary features and receive superior support for them, while being discouraged from relying on features of the free version. Customers should also be aware that they are at risk of vendor lock-in when using open-core solutions: at the end of the day, those solutions can be just as proprietary as any.

– Businesses that provide open source software, but retain sole control over the project. Many organizations find it advantageous to make their solutions available as open source, benefiting from external contributions and a supportive community. However, where there is no independent foundation governing a project, some businesses will exercise their total control over shaping new features and releases to make decisions that certainly aren’t what the broader community would choose. To assess the risk of such solutions, investigate whether the external community is robust enough to release and support an independent fork of the software (and if the software’s license allows for one). If so, it may be safe to continue using the software if and when it takes a turn for the worse or simply becomes unavailable. If not, those are major risks to be aware of.

– Cloud providers. The large cloud providers will host and lightly manage some of the more popular open source solutions, in an effort to entice customers by making their cloud platform a one-stop shop for meeting their needs. In general, cloud providers are motivated to contribute to projects to make sure their own customers will have smooth experiences, but they rarely act as innovators. That said, cloud providers are becoming more involved in open source projects, sometimes driven by communities pressuring them to apply their tremendous resources in ensuring balanced development of software that a single business otherwise controls. Communities have even called on cloud providers to lead software forks when needed to ensure a solution continues to serve common interests – for example, that’s the story of how Amazon Corretto came to be.

– Managed service providers. These companies have fewer resources than cloud providers, but similar motivations in that delivering free open source solutions grows their business. A key difference tends to be that for MSPs, that delivery is their business – meaning that they are much more deeply dependent on seeing the open source solutions they build themselves around succeed. Because of their drives to create happy customers that use both open source software and their own services, many MSPs will help enterprises compare and test-drive options to determine which OSS technologies offer the right fit, and will even customize solutions when needed. Open source projects with robust MSP adoption usually have quite healthy ecosystems, due to MSPs actively contributing and putting in as much value as they receive.

Overall, the greatest risk an enterprise can make is to adopt an open source solution without properly vetting it across several checkpoints. By thoroughly evaluating a project’s licensing terms, ecosystem, and the motives of businesses you may interact with within that ecosystem, you can make an informed OSS choice that keeps your organization’s risks at a minimum.

Ben Bromhead is the CTO and a co-founder at Instaclustr, which provides a managed service platform of open source technologies such as Apache Cassandra, Apache Spark, Elasticsearch and Apache Kafka.