While more organisations are adopting open source software (over 95 percent according to Gartner), selecting and building an open source stack can be overwhelming, writes Justin Reock, Chief Architect OpenLogic, Perforce Software. There are thousands of open source solutions from which to choose, and it can be hard to know what questions to ask. Organisations may well lack the resources to do the necessary research in order to make the right decisions.
This matters, because many organisations subsequently find themselves running open source packages that don’t interact with each other well, or which do not deliver against performance expectations. In some cases, the chosen software may not even meet the intended use case requirements of the business.
Any of these potential mis-steps can introduce risk, lack of control, even security vulnerabilities.
Choosing an Open Source Stack: Why Curating the Technologies is Tricky
So why is it so hard to select and curate the right technologies for your open source stack?
Here’s some perspective: Earlier in my career, I worked in a team who had, among other responsibilities, the job of certifying the use of various open source solutions for use in production. As part of that effort, we drafted list of forty-two individual qualifications of the proposed software to consider.
I am not going to try to go through all those now, but here are a few examples: how quickly have bugs been addressed historically by the community? How quickly has the community responded in general to various requests? What is our perceived longevity of the existing community and the number of users — especially active users? We would also look at: coding practices, software quality, how long the software is likely to last, or will it be subsumed by something else? Given that enterprise software can have a life of 15 years, that matters.
See also: 7 of the World’s Top 10 Open Source Packages Come with this Issue…
I’ve mentioned some characteristics of the software that are specific to the community. The people behind the software are important when considering what technologies to trust for a business, and that includes project sponsors. It is a myth that open source software is driven purely by volunteers: in the majority of the best-known open source software tools there is sponsorship in the background, and that is a good thing. For instance, when we notice that the Cloud Native Computing Foundation has decided to get involved with or sponsor a project, we know that software has a strong chance of success (CNCF was behind Linux, Kubernetes and Prometheus).
So, clearly, there are a lot of factors to consider, which is part the reason for why things can go wrong. Another issue might be that a tech tool looks fine on day one, but it does not live up to expectations, because the community does not deliver. The direction of the technology may no longer be aligned against the use case and this is a common problem: open source software is typically purpose-driven, chosen to do a specific task, rather than enterprise solutions that are designed to address multiple requirements (the equivalent to a multi-blade Swiss Army Knife).
Best Practice
So, what are the secrets to building a solid, long-living open source stack? First, do not skimp on due diligence: spend the time questioning all the factors described (and many more), or work with a specialist who can carry out that work for the organisation, removing the need for in-house teams to suddenly have to divert time and effort into becoming experts about the open source software market.
Dig deep to find out about the community support, users, backers, activity, software quality, coding practices. While it can be tempting to get everyone up and running on a piece of open source software within hours (part of its beauty: download in the morning, be actively using it by lunchtime), it is often a false economy. Take time to build and scrutinise the use case — or possibly, multiple future use cases — for which the software is intended.
Also, it is important to understand that there are different categories of open source software, with different licensing models. This is a largely misunderstood area, even by — forgive me for saying so — many CTOs, who are not clear about the difference between copy-left and permissive licenses. It is essential to be very clear what the organisation is signing up for, because that has long-term implications. Copy-left licensing imposes software freedom, because contributors are obligated to push their changes back to software communities. Permissive licenses do not require that commitment, and so conversely prioritize business IP. Side-note: in my opinion, that does not make them any less ‘open’.
Take a hard look at how well the software is represented: when the collective knowledge of the open source community depends on contributors, they have little motivation to make sure that the accompanying documentation is sufficiently detailed. In the current climate, being able to keep remote workers productive is obviously essential, so look for open solutions that can increase remote efficiencies without adding additional support burden.
Read this: An Idiot’s Guide to Kubernetes
Integrations are everything. One risk of having so many home-grown open source architectures is the potential to have a range of tools that do not work well together, fully match desired use cases, or both. So, it pays to evaluate the different elements involved, such as: platform, database, middleware, application runtime and monitoring tools. It is vital to look at how well all those tools can ‘play nicely’ with other software elements.
As an example, Kubernetes is a good choice for an organisation moving from a monolith environment to a microservices substrate, because it has considerations for many other supporting technologies that will comprise a full solution. That interoperability is part of what has led Kubernetes to arise as the most popular container orchestration platform available. Another example might be a company migrating from Oracle JDK, because Oracle now charges for its Java JDK subscriptions. In that situation, OpenJDK is a good choice, because it has feature parity with Oracle JDK. These days, functionality does not have to be sacrificed just because you want to use community supported software.
Migrating to open source software — or changing existing open source software — is understandably daunting. However, apart from the expected increase in the use of this software, it is unavoidable that there are costs involved: even if the software is completely free, there are the financial implications of people’s time, not to mention redressing problems that occur. Getting in place the right framework to choose the right tools for the job will pay dividends, both in the short term and the future.
Justin Reock is Chief Evangelist, OpenLogic, with Perforce Software www.perforce.com. Its solutions include the OpenLogic Stack Builder.
