Written by Rose Sakach, Global Product Manager at Broadcom and Open Mainframe Project Ambassador and member of the Zowe Leadership Committee
In August, the Zowe Community, in partnership with Open Mainframe Project, celebrated a major milestone — the 5th anniversary of the mainframe’s first-ever Open Source Project: Zowe. Community members recognized the milestone at the recent SHARE conference hosted in New Orleans with a 14-session Zowe track including a Community-lead Zowe day and a roadmap overview for discussing plans and exchanging ideas for enhancing and growing the technology.
Zowe contributors gathered at SHARE New Orleans
In 5 years, Zowe has grown and matured in many ways including:
- Projects (Core & Extension Components)
- Community membership & organizational structure
- Security policies, procedures, & practices
- Software releases & downloads
- Conformance programs, Vendor Extensions, Vendor Support Providers
- Industry recognition (awards & adoption) & Education
A pretty good resume for a concept many felt would struggle to survive in the industry. Which leads us to wonder how Zowe began. What in the world convinced very successful, highly competitive companies to collaborate and support such a mission? Many of us in the Community have heard various bits on how it all began, yet none of us seem to have the complete picture. In recognition of this major milestone, the Zowe Advisory Council (the Product Management arm of Zowe known as ZAC) felt it was the perfect time to reminisce, inquire, and unpack the untold story from the perspective of those who were there.
Over the past weeks, we spoke with several current and prior Zowe Community members from the initial contributing vendors. All of them were part of the original team responsible for the foundation on which the success of Zowe is built. As you read on, please bear in mind, there were many more people who worked tirelessly to set Zowe up for success. We wish we could, but we are not able to mention all of them. We look forward to sharing more from their accounts at future milestones. This story focuses on the recollection of the small sampling we were able to contact in a very short timeline. It is a documentary-type story that is better than we imagined with a mix of forward-thinking, determination, brilliance, generosity, heart-felt debate, common sense, relationships and trust. Do you know the Zowe story? Let’s find out. Here’s what we learned.
Before Zowe was Zowe: The “mainframe made easy” vision
We took our interviewees back to late 2017, early 2018 and asked them what they knew and how they participated in the project. Though many remember Zowe as code-name project Giza, Greg MacKinnon (Distinguished Engineer, Zowe APIML Founder/Creator, Broadcom) and a select few recall the name zLUX and many remember the initial spelling of Zowe without the “w”, which didn’t survive, it failed copyright. Interestingly enough, the name is NOT an acronym and quite honestly seemed to be a result of tireless brainstorming efforts to land on something that began with a Z and was “catchy”. The next thing you know as Matt Hogstrom (Distinguished Engineer, Broadcom, formerly IBM) says “I was reserving the zowe.org domain” and that ignited the project. Yay, we’ve got a website. But what REALLY got this open source project going? Who started it? Why? How did it survive?
Greg recalls, it started with Rocket Software. Enter Joe Devlin (former Rocket Software CTO, VP of Systems Software, Zowe z/OS Lead) and Sean Grady (Senior Software Architect, Zowe Web UI Lead, Rocket Software). Just 3-years into his tenure, Sean led an internal hackathon to introduce a Mainframe Virtual Desktop. “I was just out of college and I wanted a better mainframe interface, not just for me, but for everyone”. Supported by Joe, who staffed the effort with talented interns, zLUX was born and ultimately became Zowe’s Web Desktop. Delivering the technology was only part and perhaps the easiest chunk of the mission. The more challenging aspect was making it universally available. Both knew instinctively they would need IBM to help make that a reality.
Meanwhile, several new-to-mainframe Broadcom Engineers were tinkering around with IBM z/OSMF APIs and FTP in an attempt to improve their efficiency by aligning processes with methods they’d used on other platforms. Gene Johnston (Product Architect, Zowe CLI, Zowe Explorer, Zowe Client SDK, Broadcom) recalls how he leveraged his background in Windows/Linux to cobble together technology in order to add automation and flexibility to his mainframe testing techniques. “I was running FTP in PowerShell scripts to transfer files and submit jobs”.
Not far from Gene, on the other side of the building, unknowingly, Dan Kelosky (Product Architect, Zowe CLI Co-creator, Broadcom) and Jason Tucker (Product Architect, Zowe CLI Co-creator, Broadcom) along with their colleague (at the time) Chris Boehm zoomed in on another way to solve the same need using IBM’s z/OSMF APIs. The team’s desire to gain access to a wider range of off-host technologies for both testing and dynamic environment creation & teardown paired with Dan’s unyielding investigative nature to learn new technology is what ultimately led to the creation of Zowe CLI. Called “z/OSMF CLI” at the time, it immediately gained traction within the team and ultimately throughout the organization. Broadcom had uncovered a tool to modernize the mainframe experience. But Broadcom originally headed down the commercial route and introduced it as CA Brightside. Why did they contribute the CLI and eventually the API Mediation Layer to Zowe? What changed their mind?
Educate, Contribute, and Trust: Doing what’s right for the ecosystem
Rocket Software and Broadcom weren’t alone in their quest to deliver technology to change the interaction with and perception of the mainframe. Joe Winchester (Senior Technical Staff Member, Zowe TSC, IBM) put it this way “we were working on a project with similar goals as Zowe and released it in beta form.” Joe confirmed, IBM was also headed down the commercial road.
So, what tipped the scales? Wait for it… Believe it or not, a customer. It was an outspoken leader attending a Rocket Customer Advisory Council — someone who stood face-to-face with ISV leaders. That customer’s statement went something like this “Rocket, IBM, and CA are all trying to solve the same problem for the platform — you [all] need to DO SOMETHING about it — join forces with each other and figure it out”. If you ask anyone in the Zowe Community how this all got started, most will share some version of that quote. Indeed it was that statement that triggered the next, and probably the most critical move. Rocket’s response? Take zLUX to IBM and make the pitch to join forces.
Confidential project Giza was formed soon thereafter. While at IBM Matt Hogstrom recalls “we had a discussion with Rocket about their desktop technology and we [IBM] had ours, but we felt it wouldn’t be enough to start an Open Source project, so we reached out to CA”. Discussions began, meetings ensued and with the assistance and guidance of John Mertic, Linux Foundation Director of Program Management, the logistics associated with creating an Open Source project were tackled. Tim Brooks (Product Manager, former Zowe Leader / Organizer, IBM) was leading the effort on the administration side of Zowe. He recalls the early legal agreement challenges. “Each of the vendors had concerns over the IP particularly if a vendor backed out”. What ultimately mitigated this concern? A passion for doing the right thing backed by a licensing model that ensured the Community operated in good-faith. They truly recognized the collaborative result, not any individual result would be most valuable and impactful for the mainframe. To Tim’s surprise, it took weeks, not months to finalize the agreement.
It didn’t hurt that many involved early on in the project had prior experience in Open projects and were determined to learn from their past to make Zowe a success. Most agreed settling in on the technology stack was the challenge that stood out. Joe Winchester recalls “it wasn’t all peaches and roses’’ and it was very hard at first — but we landed in the right place. Greg MacKinnon put it this way, “staying open-minded, being diplomatic and focused on educating each other” proved to be the right strategy for making a selection where there was overlap. And, by the way, just about everyone mentioned, key to Zowe’s grounding was the trust and respect each of the ISV Product Managers, as well as the individual ISV leaders had for each other prior to its formation. Yes, the folks onstage at SHARE 2018. They were very supportive and influential in bringing it all together. The time was right for mainframe open source.
A mainframe open source project is born
With the technology settled, the teams somewhat formed, and the Open Mainframe Project as a home, Zowe was logistically good-to-go. But the Community knew they had a challenge ahead of them. Despite statistics showing the majority of mainframe customers were already embracing open source in other areas of their organization, everyone knew adoption on the mainframe would come with its unique challenges. Zowe was an opening act, a debut if you will, and everyone knew it had to succeed. Michael Bauer (Engineering Manager, former Zowe CLI, Zowe Explorer, Zowe Client SDK Squad Lead, Broadcom) put it this way “If we weren’t successful it may be life threatening for any future attempts”. The Community was in no way shape or form, in denial. They recognized a series of obstacles but this did not detract from their readiness to take them on.
When first introduced to the project, Mark Ackert (Product Architect, Zowe Systems Lead, Broadcom) described the skepticism and excitement over the possibilities in his initial reaction, “ I was dumbstruck at not only the thought of cooperation from competing vendors, the novelty of open sourcing any mainframe solution, but also the shifts in culture and potential this would bring to mainframe .” Mark was quick to point to immediate challenges — “How would we make software accessible to an Open Community that does not sit behind a vendor’s 100 foot wall?” Interestingly enough, what had to happen, happened. Mark mentioned how unusual it is for an open source sponsor to do much beyond hosting artifacts. The OMP changed its operating model to accommodate Zowe’s need to distribute the binaries.
Elliot Jalley (Product Manager, Zowe APIML, Broadcom) had other concerns, “my first thought was around security, how is this going to work? And, how are various vendors going to settle in on a code, build, delivery process? “ He goes on to say, “The first planning meeting gave the project a real sense of community.” And then, it all seemed to come together, and we all felt the momentum — especially once the Community began to witness signs of adoption. What sealed the deal around true cross-vendor collaboration for Michael Bauer was witnessing another vendor showcase software he was originally responsible for delivering. “Seeing our software being demonstrated by another vendor as though it was their own was AWESOME!” This is at the heart of what makes Zowe successful. Access to the industry’s experts, leveraging all technological backgrounds, collaborating with the collective experience and expertise around the world.
Adoption and Growth: The importance of Zowe Explorer
Key to early adoption was the ability to experiment with minimal set-up required. Every seasoned Mainframer knows this is easier said than done. Despite some thinking the z/OS components would be first, it was initially Zowe’s CLI (~1500 weekly downloads) and the Visual Studio Code extension known as “Zowe Explorer” (~98k installs) that fired up Zowe’s adoption trend. Not at all part of the original core components of Zowe, Zowe Explorer was sort of an afterthought. Dan Kelosky explains “after publishing other mainframe extensions to assist with coding outside of Zowe in the VS Code Marketplace, I knew I’d need something that gave me access to jobs and files — at a basic level I needed a place to put the code that I wanted to highlight.” So Dan and Jason began tackling this need with a new extension fundamentally back-ended with CLI commands.
What happened next? Remember the earlier Rocket hackathon story? Once again, new-to-mainframers came to the rescue. Broadcom interns picked it up as part of a project, improved the performance by re-coding to the CLI node SDK, added capabilities and introduced it to the marketplace. The Zowe Community recognized its value soon thereafter, onboarded the code and expanded it for enterprise consumption. Voila! With a core component for managing jobs and files through a Visual Studio Code extension and minimal back-end requirements, Zowe now had traction with every mainframe educator that wanted to train a VS Code developer on z/OS. Zowe could play a vital role in mainframe modernization for every mainframe vendor. Entry point for adoption, Zowe Explorer.
Zowe’s future is bright
When asked whether or not they think Zowe is a success, there were mixed responses. In contrast, there is absolute unanimity in the benefits of working on an open source project. For one thing, it attracts high-performing, conscientious mindsets. Fernando Rijo Cedeno (Software Engineer, Zowe CLI, Zowe Explorer, Zowe Client SDK, Broadcom) put it this way “you find yourself amongst people who are very motivated and are self-starters’. Not to mention, given that all of your code contributions are tracked via commits, it increases your value, it’s like “having a transparent resume”. Elliot Jalley added “Working on an open source project gave me more confidence both technically and strategically”, indicating it fast-tracked his exposure to the wider IT landscape. While Mark Ackert rattled off a number of professional benefits including, comradery, a greater sense of teamwork, world-wide team collaboration, status, influence and a sense of ownership with visible outcomes from personal contributions.
Another benefit, sometimes perceived as a detriment is the added security afforded by open source. When asked about the consumer concerns and the perception of being less secure, Greg MacKinnon summed it up and Dan Kelosky agreed, “Open Source is perceived as being less secure but in reality it is more secure, simply because there are more eyes on it… many don’t look at it this way but when you code in the open, you are vulnerable to criticism, and that’s ultimately what helps you improve the most.” That’s certainly the case with Zowe. Highly motivated, extremely talented individuals contributing their expertise and criticism for the benefit of the platform.
Interestingly enough, our team is not collectively convinced the industry has recognized the true value of the project. Sean Grady put it this way “just about every month I meet a new customer who hasn’t heard about Zowe” and that’s disappointing. Joe Winchester admits “I predicted more people would install the z/OS components and would be building apps, I never imagined the success of Zowe Explorer and Zowe CLI”. Joe Devlin explains he’s “more disappointed than overjoyed” with the state of Zowe. Admittedly recognizing good signs of success (a la Zowe Explorer) but expecting more prominent mainframe software leveraging it. As a seasoned veteran in the space, Joe is confident Zowe will be there in 5 more years. Jason Tucker concurs and is not convinced the industry has caught on to the usefulness of Zowe CLI’s ability to connect platforms.
Despite these cautionary concerns, many view Zowe as a success. Citing the Arcati Yearbook statistics of mainframe sites who have adopted or are planning to adopt Zowe, as “amazing progress” for z/OS software. But also in terms of empowering the Community itself. More than Committers, they have embraced and furthered that spirit of exploring and expanding where it makes sense for the platform. The evidence is peppered throughout Zowe’s brief history with the emergence of new projects: Client SDKs, Explorers (VS Code & IntelliJ), Zowe Mobile, ZEBRA, the Workflow Wizard, Zowe Chat, ZEN, and most recently Event Management. Zowe remains on a path to “join forces and figure out” how best to bring the mainframe forward for the benefit of all.
Mark Ackert summed it up nicely. “Zowe makes too much sense. What we are doing is fundamentally core to the platform and if they don’t [know it] already, our customers will recognize how critical it is for the platform. We are in alignment. Doing the right thing for the right reasons.”
So there you have it. The origin of the first-ever Open Source Project for mainframe, changing the way the mainframe is managed forever — well grounded and going strong.
For all who played a role in Zowe’s existence and have moved on,
For all who continue to work on improving Zowe,
For all destined to join the Zowe Community,
Thank you for what you have done, are doing, and will do for Zowe, you are all a part of history.
On behalf of all Mainframers, we are forever grateful for your effort, your passion and your contributions. Happy Anniversary Zowe. Given the Community that supports you, we are certain you’ll be around for many more.
Learn more about and download Zowe at zowe.org .
This blog originally ran on the Zowe Medium blog. Read more Zowe blogs here.
Ask a question or join the conversation on an Open Mainframe Project Slack Channel #zowe-api, #zowe-explorer-intellij, #zowe-explorer, #zowe-cli, #zowe-dev, #zowe-user, or #zowe-onboarding.
First time using the Open Mainframe Slack Channel? Register here.
