Written by Bruce Armstrong, member of the Zowe Advisory Committee (ZAC) and IBM Product Manager 

Consider this your open invitation to join the Zowe™ community!

There are many ways to contribute and influence Open Mainframe Project’s Zowe, the integrated and extensible open-source project for z/OS. In this article I’ll highlight a great way to start, and you don’t need to be an expert developer to do so!

First, in case you haven’t come across the group known as ZAC (pronounced “zack” — like a person’s name) allow me to introduce you. ZAC is not a “who” but rather a “what”. The acronym stands for the Zowe Advisory Council — and it has replaced the team previously known as the ZLC (Zowe Leadership Committee). This organizational change reflects the growing maturity of the Open Mainframe Project’s Zowe. Whereas the ZLC was a governing body in the early days of Zowe with control over some of the key decisions and direction of Zowe, the ZAC now has a strictly advisory role with a narrower (but still critical) role.

So, you may ask who is running Zowe’s day-to-day activities? What has replaced the wider leadership role previously served by ZAC? Zowe is now — and been for the last few years — a developer led, self-governing project, consistent with standard open-source governance practices. There are many Zowe teams (known as “Squads”) with different areas of specialty. The community follows of the Agile model of development in most everything we do — small, motivated, focused, and multidiscipline teams that love to move things forward.

With that in mind, the Zowe Technical Steering Committee (TSC) was created with a charter in-line with the Linux Foundation policies and practices, and which grants the TSC the authority that previously was part of the ZLC’s charter. The TSC is a decision-making body. The voters are the technical leaders in the community teams selected by their peers for their contributions (both in the form of skills and in leadership) to the project.

This blog post describes the reasons for the change from ZLC to ZAC, the roles of the ZAC and TSC and how they work together to move Zowe forward. The ZAC is a great starting point to anyone interested in helping create the direction and requirements for Zowe.

Why the change was made

To understand why the change was made it helps to remember how Zowe came to life in the first place, born of three parents with initial code contributions from Broadcom, IBM, and Rocket Software. The ZLC was the initial governing body in cooperation with the Open Mainframe Project to shepherd Zowe through its first few years. The ZLC was originally made up of two voting members from each of the three initial contributing companies. One person with a product management background and other with a technical/development background. The team worked on a consensus basis so votes usually needed to be unanimous to work out the organization, policies, and practices during the early days of Zowe. For the three initial contributors, this was their first jump into helping to manage a z/OS open source project, so it was a “learn by doing” experience.

The original ZLC helped Zowe ramp up quickly to get source code contributed, work with the Open Mainframe Project on legal issues, and gain agreement on processes such as building and testing. This sort of arrangement however was not the standard practice for ongoing governance of open-source projects whose central tenet is developer led, community self-governance where community is a community of developers, testers, builders and documentation contributors that do the day-to-day work of make the open source code real.

The current role of the ZAC

A primary purpose of the ZAC is to translate the needs of Zowe consumer stakeholders in terms that provide the TSC clear objectives for future releases. In common business terms, it is easiest to think of the ZAC as overseeing product management for Zowe whereas the TSC responsible for all development. However, an important distinction is that the TSC has ultimate decision-making authority over the direction of Zowe and the ZAC is strictly in an advisory role. The ZAC is meant to be a council of stakeholders (product managers, software vendors, enterprise customers of Zowe, universities, and other open-source projects, …) that debate and consolidate the needs and wishes of the stakeholders and communicate those needs and wishes to the TSC. As with any product management role, the ZAC also shapes and executes outward communication along with the TSC on Zowe and Zowe’s direction to the outside world.

Specific examples of Zowe leadership decisions or activities for which the ZAC serves an advisory role to the TSC include:

• Assisting in the establishment and review of the guiding principles to be considered for the Zowe project.

• Engaging with enterprise Zowe users to understand pain points and desires for the future

• Assisting the TSC in organizational issues with the various teams (what Zowe calls “squads” and providing input on new workgroup Zowe calls “incubators”. (The TSC decides when an incubator grows to maturity become a squad).

• Provide input on the future Zowe directions based on indicators of market needs — this is both on a quarter-to-quarter basis when the Zowe community does development planning and looking out two to three years into the future

• Advise on new version considerations planned for every two years — what older functions are deprecated and what new capabilities are considered part of Zowe core (“core” in this context are services under Long Term Support (LTS) by the community)

• Discuss any new conformance criteria considerations for Zowe integrations that allow 3rd party extensions to Zowe core capabilities

• Work with other Zowe squads in developing the outward messaging on Zowe and the Zowe futures roadmap

• Works to monitor the vendor neutral policy of the open community (one of the guiding principles of Zowe)

• Always working on new member recruitment to the ZAC, the squads, or new ideas for incubators projects to take Zowe in a new but related direction to our goals of z/OS modernization

ZAC governance and “membership”

The ZAC is intended to run on a consensus basis — there is no charter, no membership list, and no formal voting process. Though we run informally and by consensus we are not without rigor. We meet at the same time every week, publish an agenda prior to every meeting, track and publish meeting minutes, and track topics and tasks with GitHub issues that are fact-based so they can be more effectively understood, communicated, and prioritized.

As a group focused on “where to focus next” for the good of the z/OS platform, the ZAC is open to all parties interested in Zowe’s future. Although there is no formal list of ZAC members, we do have (by consensus) a ZAC Chair which is a rotating position changing each quarter. The ZAC Chair is responsible for managing and running meetings, publishing the agenda, and keeping minutes. Currently as of Q2 2023 the ZAC chair is me, Bruce Armstrong (armstrob@us.ibm.com). Other than the ZAC Chair, the members of the ZAC are those that show up and participate at our weekly meetings.

Your participation can be in live meetings or by raising issues for consideration. Come join the ZAC team and assist in shaping the future of Zowe!

The TSC-ZAC relationship

This blog post will not go deep on the TSC’s role except as it relates to the ZAC, but a short overview is helpful to understand how the ZAC and TSC collaborate. Many capabilities in Zowe require cross squad coordination and the TSC is there to make that happen. The TSC members are all leaders of their respective squads with all squads represented. As such the TSC is mostly made up of developers focused on architecture and engineering and great developers know they can’t code and listen to the market simultaneously. For this reason, the TSC looks to the ZAC for guidance on market needs, and a TSC representative is almost always present in every ZAC meeting. Likewise, the ZAC tries to have one of its members attend every TSC meeting. This way both bodies are always informed on the other bodies’ priorities and initiatives.

Your voice matters — make it heard!

Any open source community is only as good as the volunteers it has. Zowe needs developers but also vision setters and requirements from the consumers of the technology. The ZAC is a place to make your views know. Come join the meetings, raise issues and provide input to make Zowe the best it can me for you!

If you enjoyed this blog checkout more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #Zowe-dev, #Zowe-user or #Zowe-onboarding. If this is your first time using the OMP slack channel register here.

Finding out more

If you enjoyed this blog checkout more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #zowe-cli or #zowe-onboarding. If this is your first time using the Open Mainframe Slack Channel register here.