Written by Adithe Das, Open Mainframe Project Summer Mentorship 2026, mentee researcher, guided by mentor Francesco Giordano
Being selected for the LFX Mentorship program with the Open Mainframe Project gave me the opportunity to experience software development in a completely different way. Before this mentorship, most of my coding experience came from classes and projects where I was usually building something on my own or with a small team. Contributing to an established open-source project was a completely new experience. My mentorship focused on the Zowe Client Java SDK, where I worked under my mentor, Francesco Giordano.
Looking back, what made this experience valuable wasn’t only the code that I contributed. It was the process of learning how to work with an existing project, receiving feedback from experienced developers, making mistakes, improving my work, and eventually seeing my contributions become part of the project.
Finding My Way Around a Real Open-Source Project
When I first started, there was a lot that was unfamiliar to me. I had to learn more about Zowe, z/OSMF, and how the Java SDK communicated with REST APIs. At the same time, I had to understand a codebase that had already been developed and maintained by many other contributors.
One thing I quickly realized was that working on open source is very different from starting your own project. I couldn’t simply write something in the way that made the most sense to me. I had to look at how similar features were already implemented and understand why the project followed certain patterns.
I spent time reading existing classes, looking at tests, understanding the package structure, and becoming familiar with the project’s coding standards. At first, even figuring out where a new class should go could take some time. As the mentorship continued, those things slowly became more natural.
From My First Pull Request to Feeling More Confident
My first major task was implementing the Delete Workflow API. I created the WorkflowDelete class and added the necessary validation, documentation, and tests. Technically, the goal was to allow a workflow instance to be deleted through the z/OSMF REST API.
But for me, the bigger part of this issue was learning the contribution process itself. I had to understand how my implementation should fit into the existing SDK, make sure my tests covered the expected behavior, and then respond to feedback during review. Completing that first contribution gave me a much better understanding of the project and made me more confident going into my next task.
Becoming More Comfortable with the SDK
My next contribution was the Archive Workflow API. This time, I noticed a difference in how I approached the work. I already understood more about the structure of the SDK and had examples from my previous contribution that I could learn from. I created the WorkflowArchive implementation, added tests, and went through the review process again.
What I started to understand at this stage was the importance of consistency. When contributing to a large project, your code should feel like it belongs there. Someone reading the code shouldn’t have to figure out which parts were written by a new contributor and which parts were already there.
That changed the way I thought about writing code. I started paying more attention to readability, naming, documentation, testing, and how my implementation compared with the rest of the SDK.
Pushing Myself with My Final Contribution
My final contribution, the Get System Variables API, was the most challenging part of my mentorship. Unlike my earlier contributions, this task involved several pieces working together. I worked with input factories, response models, request handling, URL construction, and different options for retrieving system variables. There were also multiple rounds of review and refactoring.
At times, I would think an implementation was finished, only to receive feedback showing me another way it could be cleaner or better aligned with the rest of the SDK. Instead of seeing that as simply having to redo my work, I started seeing code review as another part of development. I learned to ask myself not only, “Does this code work?” but also, “Is this the best way to implement it for this project?” That was probably one of the biggest changes in how I approached programming during the mentorship.
The Part You Don’t Always See in the Final Code
One thing this experience taught me is that a finished pull request doesn’t show everything that happened behind it.
There was a lot of reading documentation, looking through existing code, testing different approaches, receiving comments, changing implementations, and testing again. Some of the most useful lessons actually came from the changes I had to make after submitting my code.
Through review feedback, I learned more about concepts such as the Factory Pattern, reducing duplicated logic, organizing packages, constructing URLs more cleanly, and following the preferred patterns already established by the project.
These may seem like small details compared with implementing an entire feature, but they are the things that helped me understand the difference between simply writing working code and writing code that can be maintained as part of a larger project.
More Than Three APIs
By the end of my mentorship, I had successfully contributed three new APIs to the Zowe Client Java SDK, along with supporting classes, documentation, and unit tests. Seeing my contributions reviewed, approved, and merged into the official project was definitely one of my proudest moments from the mentorship.
But when I look back at the experience, I don’t think the biggest accomplishment was simply completing three issues. The bigger accomplishment was seeing my own growth between the first contribution and the last one. At the beginning, I spent a lot of time trying to understand how everything worked. By the time I reached my final contribution, I was much more comfortable navigating the codebase, understanding review comments, making changes, and thinking about how my code would be maintained by other developers.
What I’m Taking with Me
This mentorship gave me practical experience with Java, REST APIs, unit testing, GitHub, documentation, and open-source development, but it also taught me things that are harder to learn from a classroom project.
I learned how to work with code that I didn’t write, how to follow an established development style, how to accept and apply constructive feedback, and how important communication and collaboration are in software development. Most importantly, the experience made me more confident about contributing to larger projects.
I want to sincerely thank my mentor, Francesco Giordano, for helping me throughout this journey. His guidance, patience, and feedback played a huge role in my growth during the mentorship.
I am also grateful to the Zowe community, Open Mainframe Project, and LFX Mentorship program for giving me the opportunity to learn, contribute, and be part of an open-source community. Although the mentorship has come to an end, the experience and lessons I gained from it will stay with me as I continue growing as a developer. I’m proud of what I contributed, but I’m even more excited about where I can go from here.
Stay tuned for more mentee blogs as our Summer Mentorship Program continues!
- Learn more about this year’s summer mentees and mentors
- Watch past mentee presentations on our Mentorship Playlist on YouTube
- Follow our blog for the latest updates from the program
- Connect with us on LinkedIn
- Sign up for our quarterly newsletter