Written by Bronwyn Davies from PopUp Mainframe
In Part 1 of this series, I looked at some of the common concerns around open source on the mainframe, including security, support and risk. Those questions matter, especially when we are working with business-critical systems. But there is another question I think we should ask alongside them: what is the risk of NOT using open source?
Coming from a distributed systems background, I have seen how open source can expand a team’s options and change how people work together. Mainframe teams have opportunities to benefit from the same ideas, provided we choose and manage the tools appropriately.
More tools, and even more ‘freebies’
If you have a problem to solve, there is a good chance that someone has already built a tool or shared an approach that can help. Open source expands the range of capabilities available to teams and reduces dependence on a small set of products.
The value often extends beyond the first tool adopted, and you can get some pretty impactful freebies! Migrating to Git, for example, can provide code scanning, CI/CD pipelines, automation frameworks and dashboards, in some cases with minimal or no extra effort. Many of these capabilities can work out-of-the-box with mainframe applications. The benefit is not simply a new source-control tool; it is access to a wider way of building, reviewing and delivering software.
Innovation and learning from proven practices
Open source communities share ideas, features and improvements across organisational boundaries. Our experience has shown that access to that work can improve productivity and developer experience. It also gives teams an opportunity to learn from solutions already tested by organisations elsewhere rather than starting from scratch.
That does not mean every new tool belongs in a production environment. Project health, technical fit, security and support still matter, as I discussed in Part 1. But excluding open source by default can mean overlooking useful capabilities and the experience of the people who have already worked through similar problems.
Better collaboration, not just different tooling
One of the biggest transformations we have seen within the PopUp development team came through adopting Git-based workflows. The technology matters, but the larger benefit came from the way of working it enabled: shared ownership, visibility and knowledge sharing.
Open source communities reinforce many of those same behaviours. Through Open Mainframe Project initiatives, blogs, Slack channels, Discord communities, LinkedIn groups and industry events, mainframe professionals can ask questions, exchange lessons and contribute improvements. You do not have to solve every problem in isolation.
A more familiar experience for new developers
Developer experience matters, particularly as new engineers join mainframe teams. Industry-standard tools can reduce the number of unfamiliar systems someone must learn at once. VS Code is a good example: many developers know the editor before they first encounter a mainframe environment.
With tools such as Zowe Explorer, Code4z and IBM Z Open Editor, teams can use that familiar environment for mainframe development. Familiar tooling does not remove the need to learn the platform, but it can make onboarding easier and leave more time for learning the work that is genuinely new.
Greater flexibility alongside commercial software
This is not an argument for replacing every vendor product. Open source is not a silver bullet, and commercial tools remain an important part of many organisations’ technology strategies. The advantage of open standards and open ecosystems is that they can give teams more options and greater control as business requirements evolve.
The practical choice is to use the right tool for the job, understand the trade-offs and avoid limiting the options available to developers and operators before those options have been evaluated.
Note of caution: Not all open source projects are equal
While open source offers many benefits, which open source tool you choose matters. Project quality matters. Active, well-maintained communities generally make stronger candidates than projects with only a handful of contributors. Regular updates, code review, issue resolution, adoption and long-term sustainability all deserve attention.
Projects within initiatives such as the Open Mainframe Project, part of the Linux Foundation, can offer additional confidence through established governance and community support. The point is not to treat every open source project as interchangeable, but to evaluate the one you intend to rely on.
Where to explore next
For anyone exploring open source on Z, the Open Mainframe Project is a useful starting point. The zopen Community focuses on making z/OS more accessible through open source and has brought tools including Git, curl and vim to the platform. CBT Tape is a long-standing library of utilities used by mainframe professionals to solve practical problems. IBM z/OS Core Collection for Ansible offers modules and plugins for automation on z/OS.
These are examples rather than a prescriptive tool list. Start with a problem your team needs to solve, then look at the available projects, their communities and the support model appropriate for your environment.
Looking ahead
The mainframe continues to evolve, and open source is becoming an increasingly important part of that journey. This is not about replacing everything with open source. It is about adopting the right tools, learning from wider industry practices and creating better experiences for developers, operators and customers.
We have seen open source improve collaboration, accelerate innovation, reduce friction and expand what is possible on the platform. I believe that trend will continue. The question is no longer whether open source belongs on the mainframe. The question is how effectively we can take advantage of the opportunities it creates.
Learn more
If you’d like to explore this topic further, take a look at some of my previous articles:
