The pros and cons of open source for businesses

Open-source applications have firmly established themselves in the IT systems of large and medium-sized businesses. From dominating such segments as web servers, databases and analytics, open-source solutions are now also used extensively for containerization, machine learning, DevOps and, of course, software development. Many businesses are moving to open source for non-IT tasks, such as CRM, visual content production, and blog publishing. According to Gartner, more than 95% of businesses in the IT sector use open-source solutions, but even among non-IT companies the figure is above 40% and rising. And that doesn’t include the many cases where open-source libraries are used inside proprietary applications.

Choosing between open and closed source is far from easy: it’s not just a matter of paid versus free, or support versus no support. When deciding on any IT solution, businesses need to consider a number of important aspects.

Cost and schedule of implementation

Although there’s often no license fee for open-source solutions, implementing it isn’t free. Depending on the complexity of the solution, you may need to manage the IT team’s time budget, bring in expert consultants, or even hire developers who’ll constantly adapt the application to the needs of your business.

There’s also the hybrid licensing model, which allows you to use a community edition of an application for free, but the extended version with “enterprise” features still requires a paid license.

In addition, many open-source products aren’t supplied with full and/or up-to-date documentation or training courses for end users. For large implementations, this gap may have to be filled in-house, costing time and money.

The advantage of open source at the implementation phase is, of course, that it allows full-fledged testing. Even if you plan to deploy an open-source solution as managed hosting or with the help of a specialized contractor, conducting a pilot (proof of concept) on your own is far more effective than watching video demonstrations of proprietary solutions. You’ll immediately see how functional and applicable the solution is for your particular business.

When comparing open and closed-source solutions before implementation, it’s important to understand how much time is available for testing, and whether you have the option to change the product in its early stages. If deadlines are not pressing, and the answer to the second question is yes, then thorough testing of an open-source product makes sense.

Support cost

The day-to-day support and configuration of many industrial-scale open-source applications, as well as their adaptation to high workloads, require highly specific and in-depth knowhow on the part of the IT team. If that isn’t to hand, this knowhow will have to be bought — through either hiring experts or outsourcing. The most common types of outsourcing involve application-specific expert help (Red Hat format), or managed hosting optimized for a specific IT solution (Kube Clusters, WP Engine, or like format).

Of course, paid support is also standard for proprietary solutions; it’s not only open source that needs it. The costs, meanwhile, are comparable. As practice shows, annual technical support for a typical corporate open-source application is only 10–15% cheaper than for proprietary solutions.

Bug fixing, new features and scaling

Although mature open-source solutions are regularly updated with expanded features and fixes for bugs, it can often happen that developers don’t prioritize a bug that’s critical for a particular business. This is even more common in the case of feature requests. Here, you either have to sit and wait patiently, or spend your (in-house or hired) developers’ precious time on writing the necessary code. What’s good is that this is possible at least theoretically; what’s bad is that it may turn into a large and unpredictable expense.

Note that managed hosting takes the worry out of installing patches and updating applications, but can’t help with such individual tweaking. A company that has such a need essentially enters the development market, and must choose the format of the extension they create: a fork of the main software product or an addition to the main development branch in partnership with the original developers of the application. It’s here that the strategic advantages of open source come into play — namely flexibility of use and speed of innovation.

Integration and cross-platform support

For large-scale multicomponent solutions that actively exchange data, integration and compatibility with different platforms can play a major role in the choice of software product. The priority here is support of industry formats for data storage and exchange, plus well-documented application programming interfaces (APIs). Sometimes a single-vendor solution with closed-source code can meet these requirements better than a swarm of open-source solutions — even high-quality ones. But it’s always useful to estimate the cost of tweaking an open-source solution if it wins on other criteria and has passed the proof-of-concept phase.

Risks, security and compliance

Open source is often touted as being more secure. After all, if anyone can see the source code and fix bugs, it must be safer than a proprietary black-box offering, right?

As ever, the reality is more complicated. First, many open-source applications have millions of lines of code, which no one can audit in full. The large number of updates to this code only complicates the task further. That said, small doesn’t mean safe. For example, the Bash-based Shellshock vulnerability went undetected for 20 years!

Second, the problem of dependencies is acute, since applications and code have their own supply chain. An open-source application may use a third-party open-source library, which in turn links to another third-party library, and those tasked with checking the application itself are unlikely to check all the libraries. The risks of this chain have been demonstrated many times: a vulnerability in the free Log4j logging library affected thousands of large open-source solutions, impacting such grandees as Amazon, Cloudflare and Elastic; an attack replacing npm libraries with malicious namesakes worked on Apple and Microsoft; and an independent developer’s decision not to support the tiny left-pad library in the npm repository downed more than a thousand popular applications and sites (including Facebook) for several hours.

Source: xkcd.com/2347

Another issue with dependencies is licensing. Open-source licenses are quite specific, and no payment does not mean no copyright holder. The application itself and its libraries may come with various licenses, and violation of the stricter ones (Copyleft) is fraught with litigation. Similar to the well-established process of IT security audit and vulnerability mitigation, major users and developers of open-source software should have a similar process in place for regularly checking license compliance — ideally semi-automated.

All of the above doesn’t mean that open source is the worst choice from the information security perspective. You just need to understand all the risks: the implementation team needs to assess the development culture and the frequency of security updates in contender applications and to control dependencies and licenses (for example, by using a software bill of materials). Also, if your company is working in software developer field, it’s a good idea to scan all open source packages for vulnerabilities and malicious functionality.