The sophistication with which organizations approach enterprise open source — commercially-supported enterprise software created using an open source development model — has increased as it’s become more pervasive. Yet, we still see frequent misunderstandings in the following areas.
Let’s examine four issues that are important for IT leaders to understand — and be able to discuss, inside their organizations.
Misunderstanding 1: You can offload security responsibilities to others
It’s true that by buying a commercially-supported product, you’re gaining access to updates and upgrades through a defined product life cycle. This access is essential when critical security vulnerabilities arise.
The delivery of relevant security-related patches and other information is informed by a product security team that collaborates with customers, contributors, and partners to protect against privacy and security risks. They’re responsible for timely security fixes and ensuring that customers can easily find, obtain, and understand security advisories and updates for supported products and services.
Thus, you can offload the security of supported enterprise open source products to a certain degree. That said, IT departments’ responsibility is still to perform risk assessments and make use of the updated software in an automated way. Rob Hirschfeld, co-founder and CEO of RackN, likes to remind people that, “You need to have a safe, routine way to apply patches at every level of your infrastructure.”
There’s also the matter of software supply chains – the open source (and other) code that they use in their internal applications or shipping products, including all the dependencies pulled in by that code. In its “2020 Open Source Security and Risk Analysis Report,” Synopsys audited 1,235 applications and found that 99 percent included open source components. They also found that 82 percent of codebases had components more than four years out of date.
Despite the attention that software supply chains have started to receive, Red Hat’s 2022 Global Tech Outlook report found that only 10 percent of respondents indicated that third-party or supply chain risk management was a top funding priority for security, the lowest number of any category. (The survey was in the field after the Executive Order on Improving the Nation’s Cybersecurity but before the log4j security vulnerability. Hopefully, the latter has increased awareness and urgency around software supply chains.)
Red Hat chief architect E.G. Nadhan says, “It takes villages — from both the public and private sectors – to comprehensively address open source security. Governments must take proactive steps to foster improved security of open source software, as witnessed during The White House meeting in Dec 2021, with some of the largest public and private users and maintainers of open-source software. Security, like the game of chess, requires nations to be ahead of adversaries through continuous injection of technology innovation from the private sector.”
[ Get the checklist: Top security and compliance considerations for IT modernization. ]
Misunderstanding 2: Cost is the most important decision factor in the do-it-yourself approach
It might seem natural to download community-supported bits from the Internet rather than purchase an integrated product. This is especially the case when the community projects are relatively simple and self-contained or if you have reasons to develop independent expertise or do extensive customization. (Although working with a vendor to get needed changes into the upstream project is a possible alternative in the latter case.) However, if the software isn’t a differentiating capability for your business, hiring the right highly-skilled engineers is neither easy nor cheap. There’s also the ongoing support burden if your downloaded projects turn into a fork of the upstream community project. And if you don’t want them to, you’ll need to factor in the time to work in the upstream projects to get needed features added.
There’s also a lot of complexity in categories like enterprise open source container platforms in the cloud-native space. Download Kubernetes? You’re just getting started. How about monitoring, distributed tracing, CI/CD, serverless, security scanning, and all the other features you’ll want in a complete platform? Sure, you can probably integrate a multitude of projects yourself, but if your business isn’t building Kubernetes-based container platforms, do you really want to? This is where enterprise Kubernetes platforms come in.
The fact that you can download the software and modify it as needed (or have someone do it for you) is an attractive feature of open source software. But some DIY projects can also end up being more difficult, expensive, and distracting than initially envisioned.
[ Read also: How to explain Kubernetes Operators in plain English ]
Misunderstanding 3: The main attraction of enterprise open source software is its lower cost
Lower cost is one of the open source priorities that has shifted most over time among IT leaders. Let’s be clear: Enterprise open source often does deliver better value than proprietary alternatives. But there’s been a notable year-over-year trend in surveys like Red Hat’s The State of Enterprise Open Source that IT leaders have deemphasized lower total cost of ownership as the top-of-mind benefit, in favor of attributes like access to the latest innovations, better security, and better quality software.
It’s still about value. (Budgets always matter.) But it’s increasingly about enterprise open source being better software and being the place where whole new categories of software, such as cloud-native and artificial intelligence/machine learning (AI/ML), are being created. Enterprise open source is no longer about primarily being a “good enough” substitute for proprietary UNIX or application servers.
[ Read also: 5 open source tools IT leaders should know about now ]
Misunderstanding 4: Open source software is a source of fragmentation
It’s easy to look at the open source software landscape and conclude that there is so much overlap and duplication of projects that it is hard to know where to begin.
That’s one of the benefits that enterprise open source provides. A vendor with engineers working in upstream communities can assess how mature products are, which projects are primarily duplicative, and which are complementary or serve different use cases.
Furthermore, while there is a lot of surface fragmentation in the open source landscape, open source code often serves as a reference implementation for standards, which helps avoid the subtle incompatibilities that were commonplace in the past. There’s likely been an increased emphasis in recent years to standardize some of the base layers — as seen with the Open Container Initiative (OCI) standards — and a greater tendency to mostly unite behind the most robust community, as seen in the case of Kubernetes.
[ Get exercises and approaches that make disparate teams stronger. Read the digital transformation ebook: Transformation Takes Practice. ]
