Written by Louisa Seers, Product Manager at IBM, Chair of the Galasa Technical Steering Committee (TSC) and Open Mainframe Project Ambassador
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:
- What cultural considerations do you need to think about for contributors?
- How do the process and procedures of the project change due to the adoption by the Open Mainframe Project?
- 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
