5 Areas to Consider When Building an Open Source Stack

Open source software has gone mainstream, propelled by the increasing maturity of many communities and tools working together with organizations seeking ways to deploy software faster and cheaper. According to Gartner Research, over 95% of them are deploying open source software, and while it brings many benefits, it also introduces a whole new set of challenges, beginning with choosing the right open source stack. There are multiple risks including disappointing software performance, tools that cannot connect well with others, surprise additional costs, lack of control and security problems.

Choosing the right open source stack is not easy. Many organizations lack the internal expertise to know what to look for or don’t have the time to research open source software sufficiently. Software engineers can’t be expected to become open source market experts overnight.

Some years ago I worked with a team that certified open source solutions to be used in production. We created a list of 42 necessary qualifications to consider, which is (at least part of) the answer: Start by knowing what questions to ask when selecting open source software.

Open Source Considerations

Here are five areas to consider when choosing open source software:

Time: While the ability to download open source and get it running fast might be tempting, it is better to invest in due diligence or think about working with an external specialist who can carry out the research. Take time in building the right solution for your use case(s). It is important to note that open source is often purpose-driven and chosen to perform a specific task; you may need to combine several different projects together to arrive at a complete solution.

The Backers: While volunteers play an important role in successful open source, the fact is that the majority of the most well-known tools have sponsorship. Having a committed backer with a strong track record is a good sign for both longevity and software quality. The example I often cite is the Cloud Native Computing Foundation, which is behind Kubernetes, Linux and Prometheus.

The Community: The commitment and responsiveness of the community are essential. Essential questions to ask include:

• How fast does the community respond to queries or bugs?
• How well do its members document and share collective knowledge?
• How active, large and stable is the community? Is it likely to be around long enough to support the required use case for which the software is being selected, or is the community and the software likely to pushed sideways by something else on the horizon?

The Different Types: Even some very knowledgeable CTOs do not properly understand the different types of open source, especially the difference between copyleft licensing and permissive licensing. Each has very different implications for an organization. The first requires contributors to share their changes with the relevant software community, while the second doesn’t make that obligation. Businesses are nervous about having to share parts of their proprietary source code and possibly their IP, though this only applies if the business modifies the code.

Unforeseen costs are implicit in all of the following categories:

• Time: could be wasted instead of saved if the solution doesn’t end up matching the use case.
• Solution updates: A project without “the backers” runs the risk of dying and not receiving any more updates, forcing a business to spend energy choosing a new solution. The same is true for the community.
• Legal ramifications: Businesses have faced expensive legal action if they modify and distribute copyleft source code without sharing it back.
• Availability and support: Will the organization be supported by a third party, the community and by its own team? Consider the potential costs of all of the options.

Software Quality and Integrations: It’s important to look at coding practices (do they align with the organization’s own standards?), usability and support for distributed resources. Above all, scrutinize integrations, because one of the biggest risks when building an open source stack is ending up with a bunch of tools that won’t work together or are not all aligned on the use case.

Examine integrations throughout the stack: platform, database, middleware, application runtime and monitoring tools. Look for solutions that have lots of backing and that are known to interoperate well with lots of other solutions, such as Kubernetes.  Concentrate on well-adopted language distributions such as OpenJDK, which can run tons of other enterprise-class open source on top.

It can be difficult, but choosing the right components for an open source stack will help make future curation easier and benefits clearer to see. Spending the time on research and asking the right questions from the beginning could save a lot of headaches in the future.