A Micro Chat on Exploring Careers Through Open Source
In conversation with Harsh Bardhan Mishra
In this article, we talk to Harsh Bardhan Mishra about his Open Source journey. We discuss various aspects, from entering into Open Source to cracking jobs through open source and how to crack GSoC and other open source programs.
Harsh Bardhan Mishra is an Open Source Engineer at Local Stack, GSoC admin for moja global, was part of GSoC ’21, GSoD ’21, MLH fellowship, and previously interned with HackerRank and Red Hat, open source played a significant role in helping achieve all this.
What is Open Source?
Open Source is source code that is available publicly where people can contribute and modify existing features. It had a decentralized software development model and promoted collaboration.
Various programs have been launched to encourage open-source contributions among people and help them get started, like GSoC, Outreachy, Microsoft Reinforcement Learning, LFX, and GitHub Externship.
Talking to Harsh Bardhan Mishra
Let’s dive deep, peering into the thoughts of Harsh.
Q. ) How did you get started with Open Source, and what motivated you towards contributing to Open Source?
I was introduced to the term “Open-Source” through one of my College Seniors, who was incidentally the first person from my College to have been selected in Google Summer of Code. His inspirational work made a lot of students follow suit and get started with Open-Source, but many lost interest along the way. I was one of the students in my batch to know about GitHub and created an account in 2019; I quickly lost interest midway and primarily used it to push personal projects.
My first contribution to Open-Source came through Hacktoberfest-2019. I created my first Pull Request in one of the projects being managed by my seniors, which was merged, thanks to the meaningful guidance that I was looking for to get started with Open Source. I participated in my first fully-fledged Open-Source program in December 2019 as part of the JIIT Month of Code. My mentor started mentoring me on one of his projects, through which I received very positive feedback and became one of the top performers in the whole program.
Next up, in 2020, I kept contributing to multiple other open-source programs in the capacity of a participant and now a mentor. The best experience in Open Source came through the MLH Fellowship, where I received a lot of guidance and helped with the best practices of Open Source development. I was the Grand Finale Winner in the MLH Fellowship twice. It exposed me to the nuances of Open-Source development like nothing else and prompted me to explore communities around me and participate in them.
I continued my open-source participation with Google Summer of Code at MetaCall & Google Season of Docs at Moja global in 2021. One of the reasons that motivated me to participate in open-source development has been the low barrier of entry for new contributors, the majority of which includes students. It not only prompts them to learn new things they are otherwise aloof from until they get into the industry but also capitalizes on high-quality mentorship from maintainers, which can significantly boost their tech journey.
Q.) What have you learned till now by contributing to Open Source?
A ton of things: During my Google Summer of Code period, I worked on a Polyglot kernel which allows you to implement inter-language function calls. Imagine writing a function in Python and calling it straight from JavaScript or vice versa. As part of one of my open-source internships at Quansight, an open-source software consultancy based in the United States, I was working on re-engineering continuous integration pipelines for SciPy, an statistical and mathematical library with over a million downloads every day.
As I stated before, open source provides a low barrier of entry for students and junior developers who would like to capitalize on good mentorship. Open-source programs like Google Summer of Code, Season of Docs, and Outreachy internships, have made contributions to open-source accessible & sustainable for many. Apart from hard technical skills, Open-source teaches soft skills that play a crucial role in building a career in tech.
Open source also helps us build necessary insights into working on something impactful, being empathetic to users and your fellow contributors, improving communication gaps with people we work with and your community, and much more! I cherish learning these things the most, and I believe open-source plays a crucial role in inculcating these qualities from the start.
Q.) How contributing to Open Source have helped you in your career?
I owe my career to open source itself. I currently work at LocalStack, a fully functional cloud stack that allows you to run cloud apps locally. Before this, I worked at Quansight on a project called QHub, an open-source tool to deploy your data science stack on Kubernetes or High-Performance Computing providers. Both of my experiences were made possible via my open-source work and contributions itself.
Today’s job market is going tough, with a lot of emphasis being put on skills & proof of work rather than certificates and theoretical knowledge. In this situation, people go for different things — Some go to hackathons to build demonstrable projects, some practice coding problems on various platforms to develop their rankings, and much more. Open source gives a platform to people to solve challenging problems that have not been figured out yet! Working on these problems can help you build a great portfolio that will surely catch someone’s eye.
However, for many people, building a career in open-source itself can take time and effort. In India, a lot of students depend on internships, where they have to work with actual companies out there to showcase good experience. If you are still looking for a dedicated role, try contributing to open-source and building a demonstrable profile. Many people I know went forward and made a career on it via sponsorships & much more that intend to support their work and contributions long-term.
Q.) What advice would you like to give to someone who’s just getting started with open source and struggling in selecting the organization and contribution
This is where most bungles — To be honest, there is not one path someone can follow to get started with open source. Everyone had a different journey — I have known people who started because their seniors or peers contributed, some because they wanted to learn something, and others because they wanted to participate in an open-source program. While the motivations for everyone were different, one thing that was pretty common among all was that they were software developers. Most (if not all) had worked on some good personal projects, had an intricate understanding of how systems & software work, and knew how to accomplish something in particular.
One of the most common mis-patterns I notice is how people try to get started with open source just after writing their first lines of code. They try to find the best project, look for contributions, and jump into it. This does not do justice to either them or the maintainers, who will spend considerable time & energy mentoring them. If you are a beginner, consider working on your projects. Before my first open-source contribution, I had worked around some Python scripts for web scrapping & penetration testing, built a few applications, and simple webpages. Give it a shot since it would be a rewarding experience for you, and you can jump onto finding projects and organizations that suit your interests.
Once you have some basic skills, leverage the technologies you already know or have an interest in to find relevant projects that you would like to contribute to. It would ensure that you are already familiar with the technologies associated and can contribute seamlessly with some guidance from an experienced mentor. Next, find some good documentation — READMEs, Quickstarts, and Tutorials to get a better glimpse of what the project stands for. Once you understand, try understanding the breadth and depth of the project.
Through breadth, try understanding the Project Structure and what some files or directories are supposed to do, and explore as much as possible. After covering the breadth, go for the depth by understanding the project from the core. Both will take a lot of time but will ensure that you have a rock-solid foundation for starting the contribution. Once you have an understanding, get your hands dirty. Create a parallel development setup and start breaking stuff around the codebase to figure out bugs, regressions, or anything you can fix! That will serve as a way to help you get your first Pull Request done!
Q.) Any advice you would like to give to students?
The best advice in current times would be to keep working on your skills and develop a strong portfolio that showcases your best work. Being a good developer requires core technical skills and good enough soft skills, encompassing various fields like communicating with stakeholders across multiple levels, having an aptitude for learning new trends, and finally, a capability to deal with ambiguity and build solutions for challenging problems.
Apart from this, the students should always preserve the drive to explore for students. With so many technologies out there, it is always difficult to contain the excitement of trying out new technologies and opportunities that are coming out there. The biggest goof-up folks make to self-reject themselves before they even start at things. Give yourself some time, understand what you know (and what you don’t), and give your best to everything you encounter. However, there is also an intermittent need to have a singular focus on what you wish to achieve.
No matter what you do — Competitive coding, Open Source, Development, or anything else (especially when you see fresh controversies happening every other week), try to be a better problem solver. The more challenging problems you solve, the better your chances in a chaotic outfield of folks from various backgrounds, experiences, and skill sets.
Bonus Questions!
Thanks for reading up till here; here’s a set of questions that will definitely help you out with your open-source journey
Q.) As a mentor, what qualities do you look for while selecting candidates for open-source programs?
I primarily look at three things: What new skills can a candidate learn in a program, what kind of passion or perseverance does the contributor bring to the project, and what is their long-term goal with the project? I don’t believe in seasonal contributions for the sake of it. Hence, if a contributor doesn’t have plans to continue with the project after the end of the program, it doesn’t give us enough incentive to mentor and help the candidate grow while contributing. As mentors and organization administrators, our goal is to make communities sustainable. That can only be possible when we bring more and more of our selected candidates to take similar roles in the community and build capabilities among new contributors.
Apart from this, the passion you bring to the project automatically converts into quality code, tests, and documentation and can be singularly measured as the necessary impact you get. I don’t have any specific complaints against anyone, but many of the candidates I have interacted with miss this critical capability to bring new insights and ideas to a project and tend to parrot the details we have already divulged.
Lastly, it is also essential to see where you stand — If you know everything that a project requires, it doesn’t give us enough impression that this mentorship program would be helpful for you. All open-source programs are modeled around mentorships, and as mentors, we are responsible for imparting the knowledge and skills that can help you succeed. If you know everything, we can assume you are overqualified, and we can look forward to someone who can make the project successful and the mentorship worthwhile.
Q.) Any resume and cover letter-related tips?
It is always preferred to keep everything simple (and stupid!). Make sure to complete your resumes and cover letters with various technologies and skills that only partially work together. Avoid mentioning anything that you need proof of work for. Try to prioritize your projects, over-prioritize our experience (if you have some), and beef it up with actionable insights and metrics you must have recorded. While it’s always tricky to provide resume suggestions without looking at one, it captures the gist.
The purpose of a resume is to show selective details about your portfolio that correctly capture your skills. You don’t need to mention everything, lest your birth date and the courses you took in your college! A cover letter is a pitch that shows the best of you in words and actions and gives the reader a greater insight into your work and you! Hence always mention fine details that go hand-in-hand with tangible proof of work, which should serve just right for you!
FAQs
Q.) How to prepare for GSoC ( or other open source programs) and select the organizations.
I have already shared how you can go about selecting projects to that you would like to contribute. Picking up organizations to contribute to always has a personal touch, and there is not one logical answer or flow that I can provide that can help you pick one. A good question from me to the readers would be: What excites you the most? Some people like to work on Web Engineering, some on low-level systems programming, some are more into developer toolings, while others want to work on cloud & infrastructure. Every program you are looking to participate in has a neat project list that details different projects you can contribute to based on the domain they are being worked upon.
Apart from the general domain & the projects at hand, exploring the kind of support you get in a community is worthwhile. Every organization is tied to a community that supports and sustains it. Once you join a community, you can explore and see if this is the one with whom you want to work for a few crucial months of your early career. If you think that you have found a fit, that’s great. Start engaging with the maintainers, make contributions, and work on writing a detailed proposal/application that showcases your interest — Otherwise, it’s easy to move on and find an organization that you want to stick with.
After you have an initial acquaintance with the organization, things are straightforward. Make an excellent first impression, use your communication skills well, and make meaningful contributions (not just typo fixes!). It will give you a great head-start for any open-source program, not just GSoC, and enough bandwidth to brainstorm on the project you wish to work with or even propose your own. GSoC, or any other open-source program, has a significant barrier to entry because of the competition and not because the projects are alienated against new contributors. A little bit of time and consistency can do wonders!
Q.) How to read and understand large projects?
I have discussed this before, and maybe I can do it in detail now — Try performing a Breadth First Search (BFS) and a Depth First Search (DFS) for the Project. Once you find an organization/community and a project, the first thing that would intimidate you would be the codebase. Most well-established open-source codebases run over a few thousand lines of code, where most lose motivation to continue. Most students have never written beyond a few hundred lines of code in production. Trying to understand such a large codebase with thousands of dependencies and multiple contributors doesn’t make sense.
The first step in tackling such a codebase is doing a Breadth First Search (BFS). Understand the project structure and what some files or directories are supposed to do, and explore as much as possible. You can always hit up Google if you are getting stuck somewhere, which can get you very much acquainted with technical jargon or terminologies that contributors seem to use all the time! Next, do a DFS (Depth First Search), and understand the Project from the core. This is where you explore what a specific file, function, or class is supposed to do, where they are being used, and what is the overall application flow.
During this process, understand the Test Suite as well. Most contributors are blocked off their first contributor by a test suite that automatically tests their code and, in most cases, fails it because of unhandled edge cases. Make sure to make sure the Test Suite runs smoothly with your contributions. Look forward to understanding how the Test Suite works under the hood so that you don’t push buggy code or the maintainers reject your contributions for failing the checks. If the Project needs test/automated pipelines, that is an excellent way to contribute to the Project since no maintainer would refuse to have good test cases.
At last, I would like to conclude that in the past few years, many software organizations have started preferring people with open-source backgrounds; having an open-source background will help you stand out from people and gain real-world experiences, so try out new stuff.
A big thanks to Harsh Bardhan Mishra for contributing to this article. I hope it’ll help out many people.
Also, if you wanna reach out to him, you can mail him at erbeusgriffincasper@gmail.com or drop a DM on LinkedIn(https://www.linkedin.com/in/harshcasper) or Twitter(https://twitter.com/harsh_casper).
