5 Common Misunderstandings About Enterprise Open Source Software


The sophistication with which organizations approach business open-source — commercially supported enterprise software created using an open source development model — has grown as it has become more widespread. Yet we still see frequent misunderstandings in the following areas.

Let’s look at five issues that are important for IT leaders to understand and discuss within their organizations.

1st misunderstanding: you can offload security responsibilities on others

It is true that by purchasing a commercially supported product, you gain access to updates and upgrades throughout a defined product lifecycle. This access is essential when critical security breaches occur.

Delivery of relevant security-related patches and other information is informed by a Product Security Team that works with customers, contributors, and partners to protect against privacy and security risks. They are responsible for timely security patches and ensuring that customers can easily find, obtain, and understand security advisories and updates for supported products and services.

This allows you to offload the security of supported enterprise open source products to some extent. That said, the responsibility of IT departments is always to perform risk assessments and use updated software in an automated manner. Rob Hirschfeld, co-founder and CEO of RackN, likes to remind people that “you need to have a safe, routine way to patch all levels of your infrastructure.”

The responsibility of IT departments is always to perform risk assessments and use updated software in an automated manner.

There’s also the matter of software supply chains – the open source (and other) code they use in their internal applications or shipping products, including any dependencies driven by that code. In its “2020 Open Source Security and Risk Analysis Report”, Synopsis audited 1,235 applications and found that 99% included open source components. They also found that 82% of the codebases had components that were more than four years old.

Despite the attention software supply chains have begun to receive, Red Hat The Global Tech Outlook 2022 report found that only 10% of respondents listed third-party or supply chain risk management as a top funding priority for security, the lowest number of all. categories. (The survey took place 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 EG Nadhan says, “It takes villages – both public and private sectors – to comprehensively address open source security. Governments must take proactive steps to foster improved security of open source software, as seen in The White House meeting in December 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 stay one step ahead of their adversaries through a continuous injection of technological innovations 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 stuff from the internet rather than buying an in-app product. This is especially the case when 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 the necessary changes into the upstream project is a possible alternative in the latter case.) However, if software is not 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 uploaded projects turn into a fork of the upstream community project. And if you don’t want it, you’ll have to factor in the time spent working in the upstream projects to get the necessary features added.

There is also great complexity in categories such as enterprise open source container platforms in the cloud native space. Download Kubernetes? You are just getting started. What about monitoring, distributed tracing, CI/CD, serverless, security scanning, and all the other features you’ll need in a complete platform? Sure, you can probably integrate a whole host of projects yourself, but if your company 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 to suit your needs (or have someone do it for you) is a nice feature of open source software. But some DIY projects can also turn out to be more difficult, expensive, and fun than originally anticipated.

[ Read also: How to explain Kubernetes Operators in plain English ]

Misunderstanding 3: The main attraction of enterprise open source software is its low cost

Cost reduction is one of the open source priorities that has evolved the most over time among IT managers. Let’s be clear: enterprise open source often offers better value than proprietary alternatives. But there’s been a noticeable year-over-year trend in surveys like Red Hat’s The State of Enterprise Open Source that IT managers have downplayed reducing total cost of ownership as a priority benefit, in favor of attributes such as access to the latest innovations, better security and higher quality software.

It is always a question of value. (Budgets still matter.) But it’s increasingly about enterprise open source being better software and being where whole new categories of software, such as cloud native and artificial intelligence /machine learning (AI/ML), are created. Enterprise open source is no longer primarily 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’s hard to know where to start.

This is one of the benefits of enterprise open source. A vendor with engineers working in upstream communities can assess how mature products are, which projects are mostly duplicated, and which are complementary or serve different use cases.

Also, while there is a lot of surface fragmentation in the open source landscape, open source code often serves as a reference implementation for standards, helping to avoid the subtle incompatibilities that were commonplace in the pass. There has probably 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 unite primarily behind the community la more robust, as seen in the case of Kubernetes.

[ Get exercises and approaches that make disparate teams stronger. Read the digital transformation ebook: Transformation Takes Practice. ]


Comments are closed.