The Open Mainframe Project is about the Open Source ecosystem on Mainframe and the projects that focus on enterprises. These are the interconnecting keys between the enterprise and open source. I had a conversation with John Mertic, who is the director at the Open Mainframe Project and works at the Linux Foundation and many other verticals about the work they do and how can one get started with contributing.

Q. Can you tell us about the Linux Foundation?

A. The Linux Foundation hosts over 400 Open Source projects across different horizontals and verticals every year. It attracts global participation and enthusiasm towards key open source projects such as cloud, web dev, the automotive industry, etc. The creators of these projects join the Linux Foundation to take it to that next level of growth because that's what enables the trust from a larger set of communities due to the neutrality of the foundation. The foundation helps ensure the quality and technicalities of these projects in a fair transparent manner and the licensing in those infrastructure pieces grab a lot of eyeballs so we ensure that they're all well tested to make sure that the code that you're using can be trusted.

Q. Why should students start contributing to Open Mainframe Projects?

A. The key reason to contribute is to learn the different technologies and apply your knowledge while interacting and networking with the community. You also get to give back to the community and build your resume simultaneously. This helps you put your resume out there and show your potential employer what you do and showcase the quality of your work. Our mentorship program gives you a unique opportunity to be working with leading companies in the industry and we often see that the next step after that mentorship is that you're hired because you've already shown that you're a contributor upstream and that you're getting acceptance within that community. We also see this time and again with people that are active contributors have higher visibility within the industry and that opens up many job opportunities for them

The most important thing for a student is to build up credibility and a portfolio especially when we're in a time like now, where you're not going to get the opportunity to be face to face with a lot of your potential employers. Therefore, I think as a student you're thinking about mentorship with one company, and folks that are looking to hire people that are talented in the space most definitely like to see a contribution where the code you're writing is being used. Improving your resume in freshman year or sophomore year when many students are unable to get internship opportunities can be difficult, but open source is a great way to get internship offers, some real-world experience, mentorship, and guidance.

Q. What are the key differences between working on an open-source project as a student and working in a corporate environment as an intern?

A. If I look back at my career, from an open-source community standpoint, it’s the output of your work that matters. In open-source, people can see exactly what you've done and its impacts. This helps in true portfolio building, whereas in an internship it’s more about having a guided method to work which also carries some pieces of it but mostly what people are looking for is what you have accomplished and what you've built, and the quality of your code. Being able to showcase that specifically your knowledge in the area is a great head start.

Some companies we see also keep a platform for students that contribute to Open Source. Open Source community is not just one organization it's multiple organizations with multiple potential users that are looking at using this code and building products. They don't know where the talent base is to start and if they can look upstream and see that there's a talent they can pull from, that's a huge step forward for them and enables them to get involved in the community pretty quickly.

Q. Can you elaborate more on Mainframe and its real-world applications?

A. Mainframes are computer systems that are designed around four key design principles: security, stability, performance, and scalability. We see that showcased in several key industries and in areas where you need all of these aspects of your computing system. So if we think of the financial industry, the transportation industry, or the healthcare industry, these are systems that often have been around in various ways for decades now and they're the cornerstone of those industries. These are systems that aren't going anywhere because they're uniquely designed to hit that use case spot where you need a high volume of transactional support.

Being able to scale that up and down very quickly, these are the only systems on the plan that is capable of doing it. A real-world example is having a credit card, where all the processing is done in the mainframe because of the sheer volume of it. If you have ever got on a train or have flown in an aeroplane, all those back-end systems are run by mainframes because there's a need for high transactional speed. It becomes an extremely critical infrastructure to have and the good thing is that the mainframes of today run a lot of different operating systems and you see a lot of usage of z/OS which is the long term operating system that has been used on the IBM Z platform which is also synonymous to the brand name of the mainframe platform.

It's been used on it for decades, but you're also seeing a growing use of Linux on the platform, and it looks like Linux on any other architecture whether it X86, arm, or risk five, it doesn't matter, they all look the same.

Q. Can you tell us a bit more about the Open Mainframe Project and why it came into existence, and what is its use case?

A. The Open Mainframe Project was founded six years ago on the case that open source is such a critical part of where the mainframe community is going and a lot of open sources came from the mainframe world. Computer operators of the time had this new IBM system and they needed to know how to use it and needed some help in being able to collaborate and so they came together and shared the code, experiences, and insights and that have built up over decades.

The larger mainframe community is also very passionate and interconnected and looking forward to the long-term sustainability of collaborating in open source and it started with work around the Linux usage on the s390x or mainframe platform and in time it's grown to open source projects. Many of the students may be familiar with it called Zowe, which is a set of APIs and tooling that helps access a z/OS-based mainframe system with the tooling that you'd commonly be using like APIs and CLI, and things of that nature. In some of our projects have explored areas such as the interconnection between Jenkins and z/OS and how that fits into this whole area. There's a huge need for connecting the pieces between the mainframe and the rest of the landscape. The open mainframe project sits in there and fills that piece and it hosts the projects that are key to making that connection and in a way it brings the mainframe into the mainstream way of viewing things.

If you talk to a lot of long-term customers, there's often a little divide within the organization between the mainframe and the rest of it. Companies are hoping to converge all of that together because their infrastructure is extremely broad it's not just a couple of servers up in, it's probably some hosted infrastructure, they're probably using some edge nodes out there and all sorts of IoT they're using and all sorts of pieces which they're driving their customer experiences from, the mainframe's a crucial part of that. Our goal is to make those interconnections that fit nicely within that ecosystem.

Q. What is the Z architecture and does z/VM with Linux make z/OS obsolete?

A. The Z architecture is the same way as the s390x architecture it's the nomenclature you'll see in the Linux world but basically, it's the architecture of these boxes of how they're put together and the degree of processing power and redundancy built into the box and the degree of additional hardware bits there that make these boxes the most performant resilient and scalable. You even see cases out there where people have taken entire data centres of distributed systems and consolidated them down to a single mainframe and there's still a lot of room left. So that's the overall arching at the architecture.

For the second question, I think that within the Z world you know that there are a lot of opportunities to run and different operating systems within it and a lot of the growth in the platform which is focused on Linux for many new workloads. At the same time, we're also seeing growth in the z/OS side of workflows because these companies are needing more and more infrastructure and resources and at the same token we're seeing projects that are coming and connecting z/OS based services back into the enterprise.

I think Linux adds some really interesting new use cases for the mainframe in many ways such as making it easier for certain applications to leverage the mainframe. At the same time, we're still seeing the same growth on the z/OS side and even though we hear about things getting obsolete now, companies don't change the entire code. You can do the code base that they're working on. So even though we feel okay, this tech is really old, there might be a lot of other companies who are still using it.

Q. What are the prerequisites to contributing and how can one get started with contributing?

A. All the projects are completely transparent and open projects that anybody can get involved with so not only is the source code available under OSI licenses but getting involved in the community is very easy and usually when I first recommend people to start, is to get on the mailing list, get into the Slack channel because there are tons of communications happening on both sides. You can start to get a feel of what the community is about and what the current topics are.

Many of these projects will also maintain good first issue and tagged issues so you can go there and check what those look like and maybe use those for some low-hanging fruit that you can get involved with or take advantage of. Each of them has a few different tech stacks to take advantage of and some of the projects that are more focused on the Linux side, are ones that are built more on leveraging Linux on the platform and there's a great free resource: the Z cloud for Linux, available that IBM hosts. It’s a great way to get started on the z/OS side. There are some local emulators that we do see people use from time to time and they tend to be not quite as performant.

Technology-wise I think each project a little different and making each of the projects guides you but I usually advise all of them to just start in the communications channel, head to the project meetings, and have some sort of degree of regularity which you can just sit on and learn about how things currently are. You can just take the course then you can then give back and add materials and add updates. We aim that all these projects are accessible and all of these are open and transparent.

Q. Can you tell us a bit more about the technical requirements in terms of the learning point of view and the learning curve required? How does one figure out what are the prerequisites and the tech stack used?

A. Across all of our Linux Foundation projects we drive, all these projects have a degree of autonomy of how they make those decisions and what ends up being required of it and the same is true here at the Open Mainframe Project. Look at the readme for the repo and look in the contributing file and those will detail that out for you.

Q. Can you tell us a bit more about what is the timeline and more importantly when you are selecting students, what is it that you look for in a particular student while you're selecting applications, and what makes one stand out?

A. I think the biggest thing we look for in students is probably a couple of things. First, is the enthusiasm, we can tell a student has put in a lot of effort into thinking about what they would want to do in this mentorship and that usually shines well because these mentorships are often very self-driven and this is often one of the things I see students struggle with the most when they're getting into a mentorship. Your project is clearly defined, there's a clean set of parameters and there's a clear timeline of what you're doing and there are clean outcomes.

A mentorship program mimics more of what real life is where you don't have all that defined, and you don't have your timelines defined and to a degree, you're put on the responsible end for helping pull some of those things together and when mentors are looking at students at the top of that list, they're looking for that aptitude built in there. As in are you self-driven and are you able to look at a problem and figure out what the right path is, are you a good communicator of status and updates. All of our projects look for I think technical aptitude is always a big piece of it. You want to be able to show proficiency, know programming stacks, and don’t necessarily have to be this specific one.

The biggest thing is seeing that the aptitude of the student to be able to take on this challenge because it is a huge challenge we sometimes see students that get into the mentorship and they realize how big of a challenge that is. I think the most successful students, are the ones that take on that challenge head-on and they thrive in such an environment so I think those are the things we look for most in the applications.

Q. Because everything is remote right now, communication is key. So what would you suggest as best communication practices when we're talking about contributing to open source projects?

A. I think the biggest thing is being proactive. Don't wait to be asked how things are going to be proactive or communicating when you're in it, don't wait until you're buried and two weeks behind on something to start to raise the flag of what this is looking like. If it’s going to take longer, let someone know. The more proactive you are, and the more you're sharing up the things you know, the better.

Secondly, a degree of consistency should be maintained so that a mentor can know what to expect. Being able to be consistent in how you're communicating so that somebody can walk away and understand the path. The other thing is just making sure that there is a lot of clarity in what you're trying to communicate and breaking it apart.

Q. What would you suggest is the correct way to ask questions when talking about collaborating on these projects?

A. I think one is to be very specific and concise so that you have a sense of when you're asking the question and what you're wanting to get back. There must be clarity coming out of asking that question, as in asking a broad question like how do I get started on z/OS, is a really broad question. But if you say I downloaded z/OS and I started using this piece and maybe I'm running into a challenge and I'm not sure how to accomplish it, that all of a sudden gives you a lot more specificity of exactly what you're trying to do, and that gives somebody a good clue of the answer you're trying to get back.

Secondly, is considering the medium and the audience that you're going after so probably going to the general channel and asking a broad question around z/OS is not going to get you any answers but if you have a question on the z/OS CLI and it's a specific one and you go specifically to their channel. you're going to get people who are thinking about this. So it's also thinking about very much targeting the right area where you're trying to get that feedback or maybe looking at this community and maybe the Slack isn't the best way, maybe it's opening an issue in this area and again it's very subjective. Be specific, being able to articulate well what you're trying to go after and having a sense of the answers you're looking to get back, and maybe even just articulating the answer that you're wanting to get back or giving a choice of answers can help direct that at the first go without needing a lot of additional questions.

Q. How do you deal with all the changes and advancements happening and how do you stay up to date with all the things that are currently going on?

A. I spend time researching and reading and learning. I try to get to conference sessions where I can read on some of the trends. I try to look at some of the webinars and things that are being put out there and try to capture a lot of those trends. I think one of the most important things to be thinking about in each of your careers is how am I setting up my technical understanding and my approach to new technologies from the early get-go. It wasn't necessarily the language itself, but it's the techniques and how you approach solving the problem and how you approach learning about the problem because the one thing also with many of these trends is that you see just a ton of excitement towards one thing and then everything has to be it.

Q. One good question regarding the contribution part is can we start contributing to the open mainframe project before the applications for this internship period begin?

A. I think it is recommended, and that's a great idea. It’s important to be fully prepared, like if the code's weirdly formatted, you go and clean it up or you write a unit test for something, or if you see something in the docs that you can help fix, those are things people love. Always start very simple, with that a lot of projects are good about tagging good first issues but every project maintainer has blind spots as well.

I think a project maintainer is going to be happier to get a bit of code of something that they can contribute as opposed to somebody bringing an issue and asking the project maintainer to go fix it. If you're willing to be a part of the solution you automatically get a lot more credibility because, at the end of the day, open-source is a democracy. So if you're willing to do the work, you rise in the eyes of that project.

Q. How do we know which projects would be participating in the program?

A. Projects kind of don't know sometimes what mentees are capable of and they kind of don't know this is their first time doing this just as you and as a mentee, this might be your first time taking part in one of these mentorships. A lot of times the mentors are also first-timers so we open all of our projects for mentorships. If the projects have a lot of the capabilities and have sort of needs and they see that the mentee applicants coming in can help get some of those needs.