How to contribute to open source
A guide on how to get started with open source contribution
In this article, I will briefly show you how I contributed to the following open source projects
- Spring Boot — https://github.com/spring-projects/spring-boot
- Spring Security — https://github.com/spring-projects/spring-security
- Elasticsearch — https://github.com/elastic/elasticsearch
I will also share why its important to contribute, lessons I have learned so far, how did I get started, what is my contribution strategy and motivations, as well as some examples of my contributions to date.
Why contribute to open source?
We use open-source software on every step of our development, and it is a moral thing to contribute back. StackOverflow surveys in the past few years indicate that the percentage of those contributing to open source is increasing
According to a 2016 Future of Open Source Survey Results by BlackDuck, around 67% of participation in open source has been to fix bugs and add new features, and 59% of developers participate in open source to gain a competitive edge.
Be the change that you wish to see in the world — Mahatma Gandhi
What can be considered an open-source contribution?
There are many different ways that you can contribute to open source. Here are a few of the ways
- Report bugs
- Fix a bug
- Add a new feature
- Suggest a new feature or enhancement
- Update documentation
- Offer translation or other services that complete the open-source project
- Review an open-source pull request
- Start a discussion, ask and answer questions
If you can think of more, please feel free to share it in the comments.
Why it took me so long to make my first open-source contribution?
A vast majority of developers love to contribute to open source, but we end up failing to do so for a variety of reasons. Here is why it took me a long time to make my first contribution
- Neither the university nor the professors have told us about open source
- The country you live in also plays a role in how likely you are to contribute
- Making open source contribution a new year resolution or birthday wish, never worked for me
- It’s essential to have a realistic open source contribution plan.
- When failing to contribute, I convinced myself that it’s because I am employed full-time, or work on a side project or some other reason. Never, had I owned the failure and plan better next time.
- At times, I have looked into existing pull requests and issues and have convinced myself that this is too complex, and I give up before I start.
- A majority of times, I have ignored the Github issues that required documentation change. A huge mistake. I started my contribution with a documentation change. That feeling when my pull request was merged, was like a domino effect.
- It’s helpful if your employer is supportive of open-source and promotes the contributing back.
- I have procrastinated for a variety of reasons.
- I am reading the book Atomic Habits by James Clear, and I am starting to realize how I failed so many times because I did not start small.
How did I find the drive and motivation to contribute?
I enjoy writing articles, and after I finished writing about habits and things I wish I knew earlier as a developer.
I thought to myself, an article on open source contribution would be amazing but, I had no track record of open source contribution.
Writing an article and sharing my knowledge was the motivation and drive for me to get started with open source contributions.
So far, my article on medium https://medium.com/@rhamedy has reached over ~120K views and ~25K reads.
Here are some of the advantages of contributing to open source
- Knowledge sharing
- Increase your circle of influence
- Build and promote your brand
- Collaborate and communicate through code reviews and discussions
- Give back to the community. ❤
- Connect with like-minded people, find your next employee/employer, co-founder, mentor or mentee
- Financial support
- Increase the odds of future employments
- Inspire and get inspired
Anything else you can think of, please feel free to share it with the rest of us in the comments.
My strategy to contributing to open source
I decided that I will contribute to a Spring Framework, a library that I have used before. I was reading the Contribution Guidelines when I noticed a few broken links so, and I created a pull request to fix them.
The pull request got merged, and it felt so good that I decided to keep going; however, there was a problem.
A majority of GitHub issues (i.e., bugs, first-timer, help-needed, feature) would get picked by other contributors before I even have a chance to express interest and so I had to come up with a plan and here is what I did.
- I subscribed (watched) to the Spring repository — Lots of notifications.
- Every morning, I would browse through email notifications, and if there is an issue that I feel like I can work on, I would comment to show interest.
This strategy worked so well for me that I had the right amount of open source work to do over the next few weeks.
My open-source contributions so far
I started my open-source contribution by fixing broken links in the documentation, and the next issue I worked on was an enhancement.
I worked on Clear Site Data to Spring Security’s LogoutHandler and the requirement was to read through the Clear Site Data specification, and this was an opportunity to both learn and contribute back.
My initial contributions started in the spring-security project, and then I made a few contributions to spring-boot as well.
In the above pull request, I helped deprecate a server property and add a new server property. During the code review, there were some great suggestions.
Once your changes make it into a release in spring projects, then you get a nice shoutout in their release page.
and in case of spring boot, you also get a nice Author mention in their documentation
Below screenshot shows a listing of all my open source pull requests so far, and I am hoping to add some more.
In addition to spring projects, I also made one contribution to elasticsearch, and unlike spring, it was a very bumpy ride.
Why was it a bumpy ride?
- I do not use or know elasticsearch as much as spring, so it’s important to understand how the library works.
- I have not worked with groovy before, and so the syntax was a little challenging.
- I did not know how the elasticsearch build pipeline worked, and that was a steep learning curve, as you can see from the back and forth comments.
So it’s crucial to pick issues where you have adequate knowledge, experience, and time. Or at least, you are willing to invest time in it.
If you see an issue in an open-source project, then offer a fix
While at work one day, I wanted to fix a few security vulnerabilities with maven dependencies and in particular, I came across the following highlighted in https://commons.apache.org/proper/commons-collections/security-reports.html
High: Remote Code Execution during object de-serializationand when I analyzed the dependencies, I found out that the affected dependency was coming from https://github.com/intuit/QuickBooks-V3-Java-SDK and so I created an issue and followed it with a pull request that got merged.
Tips and Suggestions
No article is complete without tips and suggestions, and here is my list
- A must-read guide on “how to contribute.”
- Learn Git basics
- Pick a language i.e., Java, JavaScript
- Identify repositories that welcome contributions — Use tools such as CodeTriage, Github Explore, Ovio Explore and this
- Read the repository policies i.e., contribution guidelines
- Learn the project you want to contribute to
- Filter issues based on labels such as help-needed, bug, first-timers, etc.
- Be mindful of other’s time, specially maintainers who help you.
- Ensure you have the necessary skills and time to invest
- Follow the discussions in issues and pull requests, see the code changes.
- Be patient, and keep an open mind to feedback.
If you think of any, please feel free to share them in the comments.
Further Readings
If you enjoyed reading this article, I have also written the following articles
