What Might Be Missing from Your Open Source Evaluation

When implementing open source software, look beyond the license terms to understand who is driving change on the software.

Guest Commentary, Guest Commentary

February 19, 2019

4 Min Read

Most enterprises considering an open source solution understand they need to rigorously evaluate the software’s licensing terms and gauge the long-term health of its community and ecosystem. What still happens less frequently – but is just as crucial to these risk assessments – is developing a thorough understanding of the business models governing the commercial organizations attached to each solution being considered.

You must discern the underlying motivations of the vendors or managed service providers (MSPs) you depend on to deliver or support open source software (as well as those vendors with strong influence over its development and maintenance). By acutely understanding these incentives, you can identify if, where, and how they may map to possible risks to your enterprise’s adoption and ongoing open source implementation. Don’t limit the assessment to licenses and community health.

Here are the business models you’ll encounter most often when vetting open source solutions:

1. Businesses that use free and open source software (FOSS) as the foundation of their own intellectual property. Be wary when organizations take FOSS projects and add a few features or other proprietary alterations in order to then offer their own commercialized, “open core” versions. While these businesses will actively support the open source project that forms the basis of their own offering (and are likely to contribute in useful ways), they can and will undermine the best interests of FOSS-version users if it serves their commercial motivations. For instance, they may work to block new free features that would compete with what they sell. Customers using these commercial versions often find themselves being steered away from existing free features by support staff and, in the worst cases, can find themselves ensnarled by vendor lock-in.

2. Businesses that maintain total control over the open source software they offer. If open source software is controlled by a commercial enterprise rather than an independent foundation, the risks can be higher of that software’s development taking a turn that its users won’t like. Businesses in this category will often accept external contributions to the open source software they control, but will still make all decisions on feature and release direction on their own. To mitigate risk when considering this type of open source solution, really look hard at the strength of the external community using the software and the software’s license terms. If the community is robust enough to produce its own independent software fork if need be – and the license terms allow for it – then there’s the possibility of the project going in a different direction if the maintaining business veers away from your best interests as a user.

3. Major cloud providers. Cloud providers will offer (and, in some cases, even lightly-manage) popular open source solutions as an incentive to use their platforms. They contribute to these open source projects in the ways we’ve come to expect: They usually don’t drive innovation, but help to eliminate bugs and increase the ease and quality of the developer experience they provide. But with open source communities often pressuring cloud providers to utilize more of their sizeable resources in supporting projects, many are becoming more involved. Given their benign motivations, cloud providers are often in position to help ensure the integrity of open source projects. For example, leading a fork when commercial players happen to drive open source software in a direction that doesn’t serve users.

4. Managed service providers.

MSPs are similar to cloud providers in that their commitment to open source software is driven by a desire to win over new customers, but different in that they command far fewer resources and have a much greater interest in seeing the solutions they provide succeed. Because of these drives, MSPs tend to help businesses first test out and strategize over open source solutions to find the best fit, sometimes providing custom solutions if needed. MSP involvement is generally a positive indicator for the health of an open source project’s ecosystem, since they’re active contributors that usually understand the value of putting in as much as they get out.

Bottom line: the biggest risk to adopting open source software in enterprise settings is not doing your homework – and that demands a deeper dive than only assessing licenses and community activity.

Ben Slater is the CPO at Instaclustr, which provides a managed service platform of open source technologies such as Apache Cassandra, Apache Spark, Elasticsearch and Apache Kafka.

About the Author(s)

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights