Learn how open source projects are created with open source to then be available for more open source and commercial products.
Written by Javier Perez, Open Source Program Leader at IBM and frequent Zowe contributor
IBM is a Platinum Member of the Open Mainframe Project. This article originally ran on the IBM Developer website and was approved to run on the Open Mainframe Project blog as a member spotlight.
- Zowe Application Framework (also called Zowe Desktop or Web User Interface)
- Zowe API Mediation Layer (API ML)
- Zowe CLI
- Zowe Explorer (an extension of VS Code)
There is also a growing number of incubator projects such as Zowe Client SDKs, Zowe Mobile, and Zowe Embedded Browser for RMF/SMF and APIs (ZEBRA).
The Zowe project is a perfect example of how to grow an open source project by doing all the right things, including working (code changes, code reviews, integrations, and discussions) in the open using distributed governance and community participation. The community includes contributors, maintainers, and users.
It’s important to bear in mind that today all software leverages open source — all software, even for those companies that as a policy do not use open source software. The reality is that if they have software developers, they are using open source programming languages, as well as a variety of open source libraries.
Ignoring the topic of open source for a moment, everyone developing software today, even with low-level languages, relies on components called libraries or packages. There are millions of packages that developers reuse to address common needs in their code. Public registries like NPM, Maven Central, PyPI, Nuget, and others are growing every day with new open source packages. NPM for JavaScript and Node.js has more than 1.5 million packages, Maven for Java has more than 370,000, and PyPI for Python now has more than 290,000 packages.
Zowe is no exception, and as a growing open source project with thousands of lines of code, it also includes hundreds of open source libraries that are vetted for their use. The Zowe project includes great documentation and properly lists all third-party libraries used by component. Well-managed projects should always document all the third-party code they use. Zowe provides this information to stress its transparency to all users.
Let’s review some of the content of the different Zowe components, starting with the Zowe Application Framework, which is Zowe’s web user interface (UI) with apps to access z/OS functions. The code is based on the Express framework, the most popular framework for users of Node.js. It also uses Angular, the JavaScript framework, and Lodash, which is arguably the most-used JavaScript library and is used by over 131,000 other libraries. Most JavaScript/Node.js software includes many library dependencies (sometimes hundreds), so it is no surprise that a UI for Zowe uses literally hundreds of open source libraries.
It is important to note that the Zowe project has Continuous Integration (CI) and Continuous Delivery (CD) automation practices that include what is now known as DevSecOps. This refers to the use of security scans as part of CI pipelines to identify flaws and vulnerabilities in code and open source libraries.
Another key Zowe component is the API Mediation Layer, which provides a gateway to integrate with z/OS services and includes a catalog of REST APIs and discovery functionality. This component performs key functionality for Zowe and it is built using Apache Commons Collections and Spring Boot for Java development. A couple of very interesting open source projects used in the API Mediation Layer are Zuul, which provides gateway capabilities for dynamic routing and monitoring, and Eureka, a REST service for load balancing. These two projects are contributions to open source by Netflix. Companies like IBM and Red Hat constantly open source their code not only as a good neighbor gesture contributing to the overall open source community, but also as a way to bring more participation and contributions to their projects. Zowe has benefited greatly from a growing number of contributors.
The Zowe CLI, which provides a command-line interface to execute a variety of commands, and to facilitate automation, is also built with a number of open source components — such as JavaScript, TypeScript, tools like Chalk, and many others. Just take a look at the package-lock.json file or similar lock files in open source projects to get a sense of the large amount of open source package dependencies that are part of today’s software.
Most software today includes hundreds to thousands of libraries — more in languages like JavaScript, Node.js, Go, and Python, and to a lesser degree Java and .NET. Unlike Zowe, projects without good governance and DevSecOps practices can be pulling open source dependencies automatically via dependency management tools like Maven (Java), Bower (JavaScript), and Bundler (Ruby) without knowing the extent of their open source usage.
Like many other open source projects before Zowe, the idea to develop and create open source software using existing open source software is no longer novel — it is a trend. Successful open source projects don’t grow by hiding behind proprietary code; every new component, every new utility is contributed back to the community. Building on top of Node.js libraries or Zuul are examples of how you can create a successful project to solve a problem, to make integration easy, and in the case of Zowe, to take advantage of the large ecosystem of software that can now integrate with IBM Z on z/OS.
Zowe makes it easy for developers to integrate or build functionality on top of the open source components that Zowe offers. There is a large number of open source software as well as commercial offerings that are being built on top of Zowe components, a true testament to a successful open source project.
When enterprises and individual developers build on top of open source projects, they are invested in the success of the project. Open source communities grow ecosystems, and meaningful contributions foster communities.