— 2 min read
You are a developer (if not you may just had a faulty url landing). You have integrated in your daily workflow at least one library as a third party dependency. Ever wondered how these libraries are build? Wouldn’t it be amazing if you could give back some of your expertise in order to help these libraries and tools get even better and grow faster, collaborating with extremely motivated developers, and further more develop your own skills?
If so, your speculation is right! This is what contribution to the open source software is about. With a little digging, you’ve found the project you’d like to contribute. Now what?
At first there is the doubt. Am I good enough to write some code for a library possibly been used by other developers?
Then the fear. And what if I break something?
Procrastination keeps going on and you’re still scared of getting exposed to the community.
I know first hand, it’s difficult to break out of this while(true) loop.
As a first timer I had no idea what open source project were about.
What you are afraid to do is a clear indicator of the next thing you need to do. — Anthony Robbins
You can either start from tools you use everyday or resolve repository known issues or even add some features declared by the product roadmap. Another approach is to try out some other sources just like Kent C. Dodds has suggested in his article First Timers Only.
Before even writing the first lines of code checkout the CONTRIBUTION.md guideline. After all, you need to contribute some code properly according to the repo needs.
You need to be quite comfortable with Git CLI. A great tool in your asset will be some git workaround as suggested in “Git more done” (great reference, thanks to Alexander Shemetovsky and Matthew Smith). Don’t panic in case you mess your working branch, some practice is needed to get used to the whole process.
Always update and improve the documentation as well as the tests of the project.
Be ready to communicate and argue for your proposed implementation and also be open-minded to have code reviews.
Be patient through iterations and review cycles and keep in mind that most contributors, maintainers and reviewers have a hand in for repository in their spare time.
Throughout this whole process your skills will dramatically be enhanced. Your collaborators will be people with solid and honest disposal to help you and guide you. You will have your code reviewed by other people not only experts but also coders just like you.
Your code will possibly be rewritten even from the next commit and this not something you have to fear of, but what makes this whole cycle magic. After all of these iterations you give back something to the community, from which you have benefitted greatly.
The feeling of contributing just a small piece of code in a project that’s gonna be used by other developers is unique.
Roughly this is what I’ve learned and achieved with react-bootstrap. Let the repository raised-issues-tab be the initial trigger and never hesitate to open a pull request.