THE LINUX FOUNDATION PROJECTS
Blog

Open Source and the Mainframe Part 1: Addressing the Common Misconceptions

By | September 29, 2026

Written by Bronwyn Davies from PopUp Mainframe

I recently had the pleasure of participating in a panel discussion at SHARE Pittsburgh 2026 titled “Open Source and the Mainframe: Ask Me Anything.” It sparked some interesting conversations and highlighted a topic that continues to generate strong opinions across our industry.

Coming from a distributed systems background, my perspective on open source is perhaps a little different from that of someone who has spent an entire career on the mainframe. I have consistently seen collaboration, innovation and continuous improvement deliver better outcomes for teams and organisations. As Head of Development at PopUp Mainframe, those principles are central to how we build software and support our customers. Open source aligns naturally with all three.

Yet open source still generates hesitation in some mainframe environments. For some, it represents opportunity; for others, it raises concerns around security, support and risk. In the first part of this blog series, I want to address the objections I hear most often and explain why they deserve a closer look. In Part 2, I’ll discuss the value of open ecosystems, and how this specifically applies for Z.

“Open source isn’t secure”

This is often the first objection raised when discussing business-critical workloads. Security is important, and every organisation running production systems should be rigorous about the software it introduces. But proprietary software is not inherently free from risk. Whether software is open source, commercial or developed internally, the same diligence is needed around security, compliance, testing and operations.

Our experience has shown that a sound approach includes understanding the versions and dependencies in use, documenting review and approval before deployment, and tracking provenance. Software Bills of Materials (SBOMs) help teams see what is in an application stack and respond when vulnerabilities are disclosed. Automated scanning can check code and dependencies throughout the software lifecycle.

Teams can also choose enterprise-supported distributions when they need additional verification and support. IBM Open Enterprise Foundation for z/OS and Rocket Software Open Source Solutions for Z are examples discussed in this context. The principle of least privilege still applies, and every organisation needs a response plan for critical vulnerabilities, including zero-day events.

Open source also gives organisations a route to contribute fixes and security improvements to the projects they use. None of this makes open source a silver bullet. It means that its security should be managed as deliberately as the security of any other software.

“The mainframe doesn’t do open source”

The mainframe is not separate from the open technology ecosystem. It is “just” another platform that can benefit from modern engineering practices, automation and open source innovation. Treating it differently limits opportunity.

Nor is open source on the mainframe merely an aspiration. Linux on Z and LinuxONE, Git, OpenSSH, bash, Python, Node.js, Docker, Kubernetes and Ansible are among the technologies already widely used across the ecosystem. For z/OS, Zowe Explorer, Code4z and IBM Z Open Editor help make VS Code a useful development environment for Z.

The aim is not to reproduce every distributed-system workflow unchanged. It is to make relevant tools and modern engineering practices available to mainframe teams where they help solve practical problems. Mainframe teams, like their distributed counterparts, want tools that reduce repetitive work, improve developer experience and make delivery easier.

“Open source has no support”

For teams operating mission-critical services, support is a reasonable concern. But open source and commercial software are not an either-or choice. Many organisations combine open source tools with vendor products, purchase enterprise-supported versions, build internal expertise, participate in project communities and contribute enhancements where appropriate.

We should also remember that we do not have to solve everything ourselves. Other organisations have already faced many of the same adoption challenges, and open communities make that experience easier to share. The key question is not whether support can exist; it is whether the organisation has an operating model appropriate for the software on which it depends.

“How do I explain open source to my Chief Risk Officer?”

Start with the same questions you would ask of any software investment: How will it be secured and supported? What visibility do we have into the software supply chain? What are the compliance obligations, patch-management processes, project governance arrangements and plans for mitigating risk?

Mainframe-specific checks may include support for the s390x architecture; EBCDIC and ASCII compatibility; resource use and MSU considerations; integration with CPACF encryption; compatibility with RACF, ACF2 or Top Secret; software composition analysis; licence compliance; and the health and activity of the project community.

All of these common misconceptions should prompt  important engineering and governance discussions, however they are not reasons to rule out open source outright. Every technology choice involves trade-offs. Once we have examined the concerns around adopting open source, it is worth asking the other half of the question: what might we miss by not using it?

In Part 2, I will look at the practical value of an open ecosystem for mainframe teams, from development tools and automation to collaboration, knowledge sharing and flexibility.

 

Keep up to date with Open Mainframe Project:

Share