Contributing to Open Source Projects
Contributing to open source projects can have many different benefits and motivations for different individuals or companies. In this blog post, I’m going to write about my motivation and process for contributing to open source projects.
My Journey
I have been aware of that contributing to open source projects is one of the best alternatives to improve professional skills for a long time. But I had also postponed it for a long time, even for the times that I couldn’t find enough opportunities to learn and grow at my employer. It’s one of my big regrets…
About one year ago I became more aware of that contributing to open source projects is the key thing to build a globally valid career for me. I’ve been learning the Go programming language since 2014, I read a book, many tutorials, and blogs, but I haven’t been practicing so much, so I decided to select a project to improve my Go skills. I had selected the Prometheus as a metric system for one of the projects that I lead. Prometheus is open source and written with Go, so I decided to contribute to the Prometheus project.
I hadn’t used Prometheus yet at that time, so I started to read documents, watch videos about the project to learn about its internal structure. It lasted for a few weeks. It wasn’t a big problem to understand the functionalities of the project. I installed it, tried it, etc. Then I tried to find an easy issue to work on, via filtering the Prometheus GitHub issues with labels “help wanted”, “low hanging fruit”, “good first issue” etc. But when I tried to understand how to implement the issue, it wasn’t so easy, because I felt that it needs some pre-knowledge about the design, implementation of the project. I tried to figure out for a few weeks on by myself but then I gave up.
After a couple of months, we completed and released the project that Prometheus is used. I had learned more about Prometheus. I tried one more time to contribute to the Prometheus project, I selected an issue and started to work on.
And I opened a PR, it got some reviews, I fixed them and later the PR was merged! It was a big moment that motivated me to go forward. Later I opened two more PRs, one of them was closed because it was not a no longer necessary thing(I didn’t ask before starting the implementation), then another one hasn’t been taken any attention from the person who opened the issue, it’s still open.
After searching some issues on the Prometheus project to work on, felt that the project was popular but there weren’t so many issues, and issues had been taken by some old contributors, maintainers. So I thought that it’s not easy to take a place in this project and decided to find another project to contribute even I like the concepts which are tsdb, instrumentation, metrics, etc.
For 2019, one of my goals is becoming an active open source contributor to a project. And I selected Kubernetes project, because;
- It’s a huge project,
- There are many special interest groups(sigs) for different areas of interest,
- Lot’s of issues to work on, and of course lots of easy issues for a new starter,
- Lot’s of people from different companies to work together,
- It’s a cloud-native project and touches many other concepts, technology, etc.
At that time I had no usage of any Kubernetes related things and it was a challenger to select the project. And so, I started to read Kubernetes’s documents from its documentations. It’s a large project, there are many different areas in the projects to work on. So, focusing on the whole project is not meaningful, especially for a starter. Choosing one of the areas wasn’t so difficult for me, I like storage-related concepts, so I decided to contribute Kubernetes storage-sig.
Almost every issue that I’ve taken to work on started with chaos, lots of known unknown, unknown unknown. I should learn about this, and this, and this, etc. Sometimes It was a be a big psychological barrier to go forward. And almost every issue is completed with big enlightenment about many concepts which I think it was worth the pain that I have to start.
Many people work on Kubernetes projects, full-time, part-time company-sponsored people, individual contributors, etc. I generally have been working with responsive, supportive people. I can say that I generally have been receiving good guidance, fast responses, reviews, etc. from the contributors of sig-storage, such as @msau42, @wojtek-t, @davidz627, etc. I’ve been using GitHub, Slack and sometimes email list to communicate.
And I’m still on it I have been contributing to storage-sig related issues at most of my free time.
Benefits
I have two main selfish reasons to contribute open source projects, I mentioned some of my other posts; I don’t want to limit myself in the borders of my employer in terms of practicing and learning. And I want to build my career as a more globally valid, not specific to a company.
Open source projects can provide opportunities to you;
- to work on different areas, not bounded with the daily job.
- to work with and get feedback from many different people who work for many different companies, have many different specialties, approach, experience, etc.
As an open source contributor, you get more recognition in your community and make your brand(it’s your professional career) more strong.
It’s one of the best ways to represent your previous works to the public.
You can improve your communication skills because of remote working.
And of course there is a mutual relation in here, to receive the things above effectively, you give your time and professional abilities to the open source projects and their community.
Challenges
I think the first one is a sacrifice from your free time. It’s not always easy to try to understand a technical problem and try to write code, after your full-time job.
If you’re not a regular user of the project, understanding the concepts can be difficult and tiring. Especially it can be difficult to work on some large features, because you may not imagine the real-world scenarios so much. It has become more clear for me after we started to use AWS EKS at Udemy recently.
Sometimes accessing the knowledge can be difficult, especially for some technical details, sometimes you may have got to read lot’s of code to figure out how a thing is working. Also for Kubernetes, trying something on your local environment may not be easy. There are different tools to run a local cluster, but there may be lots of different configurations. At sometimes it may not easy to understand the reason for the problems which you are facing.
You may not receive enough attention for your some PRs. Worst, your reviewers may be lost after some reviews. You can be disappointed if you have done lot’s of work according to review comments that you had taken.
Summary
Contributing to open source projects has great learning and growing opportunities, I believe many software engineers are not aware that enough. It’s been technically very easy to start contributing to a project with the powerful social coding platforms, like GitHub, GitLab, etc.
I have been working as a software engineer for about 14 years, I can’t imagine what a great professional experience that I can have if I would contribute to open source projects at least some of those years.