It’s been six months since I stood down as Chairperson of Galasa, an open-source project under the Linux Foundation. Galasa took me around the world, from Las Vegas, Orlando to Milton Keynes, and gave me the opportunity to work alongside some incredibly talented engineers. Yet six months on, the lesson that stays with me isn’t about technology. It’s about people, ownership, and what it takes for an open-source project to outlive its founders. Looking back, I spent a lot of time thinking about architecture, roadmaps, testing frameworks, and adoption metrics, trying to demonstrate that the project was healthy through numbers alone.

The hardest part was building a community.

There were a number of difficulties in running a project like Galasa – I didn’t have regular code contributions coming from another vendor, the conversation around testing z/OS applications was as advanced as it needed to be to adopt the technology, and despite my best efforts, I found it hard to bring new people into the project that wanted to take leadership roles to compliment or succeed my own. The adoption metrics were promising, I had the team pull download data, interaction data on Slack, the likes on LinkedIn. However, with any open-source project, you need the momentum of a community to continue going, you need the debate around whether to remove the Eclipse plug-in, or whether we are ready for a version 1.

I believe that open-source communities don’t succeed by a group of people agreeing on an architectural change, they are defined by people who are engaged enough to disagree. 

The role was fantastic at putting me in the forefront of the customer problem. For example, when I was pulled into a conversation from a distributed developer attempting to write Galasa tests for their mobile banking app, and he had a complex Galasa set-up on his system, digging around through complex 3270 screen tests and CICS interactions. Another example, where I was called over to a table at a conference to analyze a hybrid-cloud CI/CD pipeline and how Galasa was going to be the central test framework for their z/OS Connect tests. I enjoyed encouraging new presenters at their first conference, watching external companies talk about Galasa and how they’re using it to make their day-to-day work easier. I believe that we don’t do enough testing on Mainframe applications, and as a culture, we’re incentivized towards test-driven development and shift-left testing, which is difficult when your test scripts are written in dog-eared, coffee-stained test scripts in the drawer of a colleague that you bring out only when testing something into pre-production. Additionally, I found the creation of strategy fascinating – how do you rally people around a common goal, set out what you want to achieve, and create the processes to do that. It’s the small things, like bringing development updates to YouTube to encourage wider viewing, documenting all meeting notes for future reference in GitHub, stepping back to watch others’ present when you could have easily done it yourself. 

The reality of running an open-source project is tough. I spent hours looking for contributors, through the Open Mainframe Project’s Summer Mentee program, LinkedIn, talking to potential contributors online, understanding how other open-source projects succeeded, presenting at customer sites to get them interested. It needs a diverse group of companies to thrive. Looking at successful projects such as Kubernetes, it became clear that technology alone wasn’t enough. Kubernetes wasn’t successful because Google built it. It succeeded because companies such as Microsoft, Red Hat, and IBM brought different perspectives, competing priorities, and healthy tension to the project. The competing companies forked the code for their own use, spent time sending engineers to conferences, evangelising the project online. I spent time balancing the roadmap and engineering effort that the team wanted to dig into, with blogging, articles, videos, and ensuring that we weren’t just building great tech, but talking about it too.

If nobody knew we existed, then they wouldn’t consider joining us.

Ultimately, metrics can tell you that people are watching. The number of views on a blog or video, the reactions to a LinkedIn post, the number of people in a room at a conference. Metrics helped when we wanted to pull features because we knew who was using it, or how many people were downloading code or viewing the website documentation. What metrics can’t tell you, is whether people are willing to invest their time, evenings, weekends, or careers to help build something. That, is something I massively underestimated.

If I could go back, there are a few things I’d do differently.

Firstly, I’d invest earlier in creating smaller contribution opportunities. Joining an established codebase can be intimidating, and it wasn’t always easy for new contributors to find a meaningful starting point.

Secondly, I’d spend more time developing future leaders. Open-source projects need succession planning just as much as commercial organizations do. Ownership must be distributed if a project is going to survive beyond its founding team.

Finally, I’d continue pushing beyond the traditional mainframe audience. Going to DevOpsPro and the Linux Foundation conferences started that, but I didn’t do enough. Some of the most interesting conversations I had, came from developers who weren’t part of the established community but were trying to solve similar testing and automation challenges. 

Looking back, I don’t regret a moment of my time with Galasa. I love working with talented engineers, travelling the world, and helping continue to shape conversations about the future of testing on the mainframe. If there’s one lesson I’ve taken away, it’s that open source is ultimately a people problem, not a technology problem. Code can be written by a handful of developers, but communities require shared ownership, healthy debate, and a constant influx of new voices. Building Galasa taught me about software, but it taught me even more about leadership, community, and what it takes to create something that can outlive its founders.

When I first started leading Galasa over two years ago, there was only one question that I kept asking myself – how do I make this project sustainable for the long-term?

Open source is a unique way to develop software, predominantly because it is through the passion of developers, documentation writers, designers, architects, and leaders that volunteer their time to spend creating something they believe in. This can create something extraordinary and industry-changing like Kubernetes, Zowe, Linux, and the vast array of projects that are used across the IT industry to keep the world running. However, the downside is that unless you have a continuous stream of volunteers, these open source projects can suffer and find it difficult to continue. 

There is often a passion and driving force behind those that maintain open source projects that keep the community alive, and that can be seen through webinars, blogs, conference presentations, awards, YouTube videos, and more. However, if this isn’t curated and thought through, especially when the project is small, it can be hard to gain the publicity and the extra support that you might need. For example, if someone new picked up the project to use it for the first time and they had nobody to contact for help when they got stuck, it’s unlikely they’ll continue using it.

When I took on Galasa with the rest of the brilliant maintainers and committers, it was clear we needed some guiding principles with the activities we were going after as a group. What would help the project survive for the long term? What can the maintainers do to continue attracting new users and developers? What is the strategy?

Firstly, strategy is a concept that has been poured over and written about over centuries. However, for this, I’ve used the definition that strategy is a plan of action designed to achieve a long-term or overall aim. So, the first thing for us to do was define the mission and vision – what was Galasa here to achieve?

The mission was defined as the following: to allow customers to deliver software with confidence by simplifying and encouraging automated integration testing to help Mainframe modernisation within Hybrid Cloud environments and increase the reliability of repeatable software releases. Yes, it was long and wordy, but it best fit what the project was about, to make deploying software on the Mainframe easier and more reliable.

Then, once we’d defined the overall aim of the project, it was time to consider what were the long-term goals that we were trying to achieve. The guiding principles by which when we are choosing to do something to benefit the project, did it fit into the following aims?

1. Grow the number of users and companies utilising Galasa.
2. Grow the number of individual contributors on GitHub.
3. Deliver version 1, user requirements, and features for Galasa.

These may seem far reaching and not very SMART (specific, measurable, achievable, realistic, and timebound), well, that was the point. If we created goals that were too difficult to obtain, everyone may lose interest and find it demotivating. On the other hand, if the goals were too specific, and everyone was volunteering time, then they may find the pressure of holding to those goals too much and they would not continue.

In reality, it has been difficult to continue all three of these goals at the same time – sometimes it’s more important to prioritise the build pipeline and creation of a better documentation experience, than it is to blog and make videos about the project. However, they have provided a good steering guide for the maintainers to consider what they are focusing on.

The most important thing about creating a good strategy is the ability to remain consistent and reliable in delivering in small steps towards the overall aim. The journey for Galasa remains bumpy as we enter our third year in the open, however it’s the love and passion for creating something that will be used to make software engineers and enterprise level applications more resilient for the long term keeps us motivated.

How have you created strategy for open source projects? Do you agree with what I’ve laid out, or have you done things differently? I’d love to hear your experiences.

On the 11th February, the Technical Steering Committee got together to talk about the progress on the project, the roadmap, what’s next, and to share experiences of the contributors and committers of the project. It’s been a couple of months since we all got together and looked at the technical deliveries of the project and the roadmap for the next few months.

Mike Cobbett, the project’s lead technical architect, lead the discussion below on the latest releases of 0.38, 0.39, and the upcoming planning for the 0.40 release later in February. Recent releases have introduced encrypted secrets management, a consolidated mono-repo for easier contributions, and role-based access control (RBAC) to improve security and governance. Looking ahead, the team is focusing on enhancing parallel test execution, improving security with HTTPS support inside clusters, and expanding Web UI capabilities for better visibility into test cases and results. Additionally, upcoming work will enable integration with password-protected Maven repositories and upgrade etcd for improved authentication and performance. As the contributors continue to enhance the project, the key aims are to ensure Galasa remains scalable, secure, and adaptable to your enterprise testing needs.

The team release regularly, with all the issues being tracked in GitHub with a long backlog of items that the team want to achieve.

The Galasa contributors and committers have an ambitious roadmap focused on enhancing scalability, security, and usability. In the near term, efforts are centred on secure access control, including role-based authentication enhancements and expiring access tokens to improve governance. Test execution is also being streamlined with support for password-protected Maven repositories and better HTTPS certificate handling. As the project progresses, expect major advancements in the Web UI, including expanded test visualization, log analysis, and real-time status tracking. Further down the line, the team is exploring infrastructure optimizations for better scalability, continued security enhancements, and ongoing refinements to make contributing to Galasa more accessible for the open-source community.

The contributors and TSC are looking ahead into 2025 with excitement about the increase of use of Galasa and the continued technical development in Galasa. You can also find content about all the technical updates have happened over the last quarter on the Galasa website. If you’d like to contribute, come and join us for our daily scrum meetings, fortnightly iteration planning meetings, monthly TSC meetings (calendar link), and the Github repo.

When I took on the role of the Galasa TSC Chair in 2023, I was very fortunate. I had a group of talented engineers, architects, and testing specialists that have spent years creating a project with great code and a strategy that made sense in the wider market. When we took this to the Open Mainframe Project, it meant that the stars aligned – it didn’t take a huge amount of persuading to bring it into a formal governance model and start bringing the team along with us.

Even though we had a great team, it was still a huge change for the team. The Galasa team were talking through internal channels, having calls that weren’t accessible to the wider public, we didn’t really create blogs or videos to publicise the project, and we always had the question: when is the project going to be in the Linux Foundation?

As part of this transition, we had three key questions and issues that we had to work through, and I thought in this blog, I could give some advice for new projects, based on what we have gone through as part of the Galasa project.

Here are three questions that in hindsight, would have been helpful to structure our transition into the open:

1. What cultural considerations do you need to think about for contributors?
2. How do the process and procedures of the project change due to the adoption by the Open Mainframe Project?
3. What are the tools and practical software development changes that need to change?

Let’s take the first idea – how do you consider people when transitioning into a governance model? There are two different personas here as well, one being the individual contributor that is writing and committing code to the project, and the second being companies or vendors that are interested in steering the technical direction of the project.

The individual contributor’s needs are very different to those of a company, understandably the person leading the change in the open source project needs to ensure they have good relationships with the contributors, so they feel safe enough to come to the project lead and raise concerns, ideas, or give feedback on where the project can be improved. This can be resolved with the leader thinking about over communication to the team, giving them clear milestone dates and expectations and ensuring that the team are continuing to deliver code whilst the transition is going on. Pivoting to companies that are involved, these require a different level of communication – this is because the company may need to be involved in press releases, setting up the technical steering committee meetings, or ensuring that the right people in the company are involved in decisions when discussing how to form the basis of the community.

Leading from helping the individuals, process and procedure must change when going into an open source project governance model, for example: changing when meetings happen; the location of meetings on platforms like Zoom; meetings are held in public; and the idea that a project has voting members from many different companies.

Galasa was transitioning from a single company contributing model to multi-company overnight. This meant that as a leader, you may have to think about setting up a newsletter-style update to the different contributors and stakeholders, ensuring that agendas are published in advance for those not immediately attending the daily meetings, and ensuring that any process around voting for members is made transparent, easy to access for everyone, and fair. This can include publishing voting topics ahead of time or doing these via email rather than on a call. It’s okay to be overwhelmed with the amount of process change to turn into an open source community, but it takes some thought into how to communicate these changes, and at what pace do the team feel comfortable to adopt them.

Lastly, the tools and practical software development changes that are considered when moving into adoption. The first, would be practical things like using GitHub in the public – does this mean using GitHub projects, or another way to track issues? How does the project intend to use infrastructure provided by the foundation, such as Cloud accounts, Kubernetes environments, or in the Open Mainframe Project’s case, a Mainframe. Moving those build and development environments can be challenging and different when moving from internal infrastructure. This can be significant for the contributors involved, because it could be a completely different mindset shift from what the team have been dealing with before – a big challenge for Galasa has been the move to LFX Insights for security vulnerability scanning, open source scanning, and general tools that are provided by the Linux Foundation that were different within the internal company previously.

In conclusion, the key to forming an open source project is ensuring that the group and community that are motivated to putting the open source project in the open are aligned and communicating. Whether that’s on calls, Slack, email, or in person. The changes that are required are 80% cultural and 20% tools and process, which can mean that the type of leader at the top of the project can be critical to a project’s success.

If starting and forming your own open source project – consider how you want the contributors to feel coming into your new project, how they can get access to information, and how they can best work together as a team in the newly formed public environment.

Learn more about Galasa:

• Check out the Community page –  https://galasa.dev/
• Join the conversation on Slack – #galasa-dev, #galasa-help

The Technology – Gherkin, Eclipse, and the CLI

The first quarter in 2024 has been full of new enhancements, with the latest version 0.32.0 being released in March. One of the major pieces of work that was agreed at the project steering committee, was the removal of the Eclipse Plug-In. This has been a feature of Open Mainframe Project’s Galasa for a while now, and the decision to become IDE-agnostic, CLI-focussed, and more streamlined as a project, has meant that with the 0.32.0 release, the plug-in has been deprecated. Users can still use Galasa in an Eclipse environment using the in-built terminal, but this also opens up avenues for alternative IDEs such as VS Code, IntelliJ, and many others of your choice. This has been followed by Gherkin support, improved security and authentication within the Galasa tests, and 3270 image rendering by the CLI.

Restarting and cancelling a test has been introduced to provide parity with the existing Eclipse plug-in. It allows you to manage tests that have encountered problems during execution in the Ecosystem, so if a test gets stuck due to a timeout or other unexpected issue, you can reset it by restarting the test in the queue. If the reset doesn’t resolve the problem and you want to give up on the test entirely, you can cancel it. It’s important to note that cancelling a test won’t erase any data about the test that’s already been collected and stored in the RAS (Reporting and Analysis System). Finally, these commands send the reset or cancel request to the server immediately, without waiting for confirmation. The success of the command simply means the server received the request, not that the reset or cancellation is complete.

Lastly, a number of users have been asking about Gherkin support. The Galasa framework is now fully Gherkin capable, with updated documentation to show how to run a local Gherkin test, supporting Gherkin keywords on the z/OS 3270 manager, and much more. This allows the user to choose how to craft their tests and fit with their existing languages. In addition, the introduction of 3270 image rendering means that users can list tests that are run, pick one, download it, and then show the rendered image for auditing and capturing purposes that are vital to those users that need to keep track of their tests. Galasa would welcome more contributions to help us move the Gherkin support forward. 

The Team – Iteration Planning, TSC, and Scrums

This quarter has been a lot of fun, we have been continuing to run with our fortnightly iteration planning meetings (like Mike presenting the one below) with the regular team looking through items to include on the plan for the next two weeks. You can join us on a Monday at 2pm GMT (here). This has also included three scrums a week to talk about what someone has achieved, what the blockers are, and what their plan is for the next day.

The Technical Steering Committee (TSC) monthly calls (on the second Tuesday of the month at 3pm GMT here) have also been running once a month, in January, Mike presented the technical roadmap for 2024 and as a group, we evaluated the different features and changes we were looking to make, including a version 1, increasing the functionality of the CLI and potential items for later this year like test scheduling.

Additionally, in January the TSC spent some time looking at our goals for the year and how we could measure them. The TSC spent some time looking at how we might measure usage of Galasa and bring more contributors into the fold to foster some new ideas, fresh ways of looking at the code, and ways to develop Galasa that we haven’t thought of yet. The next step for the TSC is looking at a charter and for us to review the roadmap for 2Q and beyond.

Lastly, Will Yates represented the team at SHARE Orlando in early March, which led to some great sessions around getting started with Galasa, how to go from zero to test case in 60 minutes. The feedback was brilliant and it gets the project off to a great start in 2024 to grow the message and audience.

The Docs – Simbank, CLI, and more

The docs are significantly restructured to focus content around using the CLI to perform tasks in Galasa now that Eclipse is no longer supported. New content and supporting diagrams have been publish about authentication, along with information on how to install an Ecosystem using Helm. Lastly, a Frequently Asked Questions (FAQ) page is now available and is updated regularly with answers to queries raised in the OMP Galasa Slack workspace or with the team.

You can also find content about the technical updates have happened over the last quarter in the Galasa website (https://galasa.dev/), including information on running Gherkin tests using the CLI and other new CLI commands that have been implemented, so you can get started quickly on newly available features.