Understanding Open Source - Business Models For The C-Suite

OVERVIEW

As an executive leader, you may see open source software as a very attractive proposition to gain access to the latest technological innovation, maximize agility, and minimize cost. However, helping your team choose software to bake into your architecture is a long-term decision and it is important to understand all the implications of your choice.

NetApp® Instaclustr is 100% focused on open source software and have spent a lot of time observing how open source projects work and thinking about the implications. When evaluating a particular open source project there are 3 key areas that should be considered:

1. The licensing terms of the software you are using,

2. The health of the ecosystem surrounding the software, and

3. The business model of any commercial entities directly involved with the software

All of these factors can have significant future implications once you are committed to a software product

UNDERSTAND

The licensing terms

Firstly, let’s consider licensing terms. There are lots of good resources available explaining the different open source licenses that are in use (for example, here and here). Broadly the licenses can be divided in 3 categories: Permissive Licenses, CopyLeft Licenses, and Custom Licenses.

• Permissive licenses are those that allow broad, free use, and modification of the software with minimal restrictions on how the software can be used, modified, and redistributed. Apache 2.0, MIT License, and 3-clause-BSD would fall under this category.
• CopyLeft licenses on the other hand allow broad, free use but require that any modifications be made public under the same license. GPL and the Mozilla Public License are two well-known examples.
• Custom licenses are the licenses created by corporations for their own use. Such licenses are typically owned by open core companies that prevent others from using their software for deploying as a managed service and have become increasingly prominent over the last few years. Some of the examples for this would be Confluent Community License, Server Side Public License (Mongo), Elastic License, and Redis Source Available License. Each of these licenses contains its own set of terms and conditions which need to be thoroughly understood before making use of the software.

At NetApp, we favor the use of open source permissive licenses that do not contain a copyleft provision. While IP leakage risk is one factor in copyleft, the bigger factor is that many of the large companies that are essential in a strong, independent community for an open source project will not contribute to or use software distributed with these licenses. This increases the likelihood that maintenance of the software will be dependent on a single entity. Linux, which uses the GPL (GNU General Public License—a popular copyleft license), is clearly an exception to this rule and shows that where the software is sufficiently broadly applicable, and organizations do not expect to customize it for their own use, GPL can still be a successful community license.

Custom licenses are another area to be particularly wary of as each license can contain its own, peculiar conditions which need to be understood to ensure you are in compliance; there is also a greater risk of license terms changing over time (with new versions of the software).

UNDERSTAND

The ecosystem

Secondly, consider the health of the overall ecosystem surrounding the software you are intending to use. An active and broad-based ecosystem means more organizations with a stake in the usefulness and quality of the software you are using and a better chance that it will evolve in a way that suits a broad base of users rather than a specific use case or the commercial drivers of a software vendor (for example, adding features for marketing reasons rather than actual usefulness). Specific indicators to look for are:

• Is the software owned and governed by an independent body (for example the Apache Foundation or the Cloud Native Computing Foundation)? Where the copyright holder is a foundation, this generally ensures multiple organizations are actively contributing to the code base, and provides a decision-making mechanism that guides decisions based on technical and user value rather than commercial interests. This contrasts with the case where the copyright owner is a corporation and can exercise unilateral power over changes to the code and even future license changes.
• Is the software used by a variety of large, well-known organizations? The last thing you want is to be left as one of a small number of users of a significant piece of open source software, with all the burden of keeping it up to date until you can migrate away. When you use software that is also widely adopted by large technology-driven organizations (for example, the FAANGs), you can expect that they will share the burden of keeping the software up to date and, if you keep your ear to the ground, you’ll have a good sense of whether they are moving away from the technology, with plenty of time to migrate.
• An ecosystem of consultants and people providing integrated solutions also provides stability to the software.

UNDERSTAND

The commercial interests

Free Open Source Software (FOSS) IP builder/open core

These companies seek to sell software that is, at its core, free open source software, often owned and governed by an independent body. They will typically have their own proprietary version of the software that adds features, in addition to the FOSS version, which is kept closed source and often licensed for a fee that reflects the value of both the FOSS software and the additional features. Many companies following this model are very well funded and spend a lot of that money developing and promoting the core software, which benefits the entire community. However, their need to maintain sufficient differentiation for their proprietary version may lead to tension about what gets contributed to the core FOSS project, and reducing value of the proprietary product over time (as FOSS versions of the proprietary features are developed). It is also common to see a tension with these companies seeing themselves as sellers of licenses to IP, and customers seeing them as providers of support for the FOSS software and not getting the level of support they expect for the cost. There is also the risk of becoming unwittingly locked into the proprietary version of the software and having high switching costs if the vendor decides to increase annual fees.

Open source IP owner

These companies are similar to the FOSS IP builders but, rather than being based on FOSS that is owned by an independent foundation, they develop a code base and publicly release the source code. They may accept external contributions to the code base but at the end of the day they maintain complete control of the code and decisions about what features go in the open source version versus their proprietary version. License terms and overall strength of community are extremely important to evaluate when dealing with one of these companies. If the license terms and community strength do not make it likely that an independent community fork of the software could emerge, then your level of vendor lock-in with these providers is really no better than with closed-source software—the vendor has control of what work goes in what version and could make the open source version unviable whenever it suits them.

Cloud provider

The big cloud providers often provide semi-managed versions of popular open source software products. Their primary motivation is clearly to provide a service to their customers that increases the overall use of their platform. They generally won’t drive significant innovation in the products, but can be expected to contribute some level of bug fixing and so forth to maintain the quality of their offerings. Community pressure is however starting to increase the level of investment of the big cloud providers back to the projects they use. We view the presence of big cloud provider offerings as a great balance against dominant players in the IP builder or open source IP owner mode—they have the resources and interest to create and maintain a fork when necessary (for a great example see Amazon Corretto and the Open Distro for Elasticsearch).

Managed service provider

Specialized managed service providers (such as Instaclustr) have similar motivations to the big cloud providers in that they are interested in growing their own user base. While they typically have smaller resources, they also have more at stake in the success of the FOSS products they support. Unlike cloud providers that will be happy for you to shift between their many products to find the right fit, MSPs will be focused on making

the software you’ve chosen a success for you. A good MSP will have strong capability to fix and enhance the core FOSS to meet customer needs (and unlike cloud providers, be prepared to work with requirements at an individual customer level in many cases). A MSP that contributes to a project proportionally to the profit it makes from that project should be seen as a healthy player in an open source ecosystem. As MSPs are typically smaller players, you need to consider the health of the wider ecosystem for the products they support when choosing a product.

CONCLUSION

At NetApp, we evaluate all of these factors before offering an open source product on the NetApp Instaclustr Managed Platform. To share this work with the community, we have introduced the Instaclustr Open Source Certification framework, a rigorous testing and evaluation program for determining the suitability of open source software and their projects for production and enterprise deployment with reports available for free download.



Discover our open source Certification Framework