If you've never contributed to an open source project before (or have only contributed very little), getting started can be intimidating, uncomfortable and outright scary. I'm pretty new to the contributor world myself, it was only a little over a month ago that I had my very first (positive) open source experience. I'd like to lay out how I started in what was (I think) the easiest way possible.
1. Don't Start
This may seem like a bizarre first step when the goal is to end up contributing to open source projects, but bear with me. The advice I received in college was to "just look for projects to contribute to", and I believe that advice was wrong (at least for me). I don't think that contributing to open source should be the goal, I think it should be the means by which you achieve other goals. Writing code only with the intention of contributing something is a good way to get discouraged or burn out quickly.
2. Business as Usual
Alright then, if I shouldn't go looking for an open source project to contribute to, how do I end up being a contributor? I think the first step is to stop seeing open source as being fundamentally different from everything else. It's not. Most developers use open source libraries every day in their work. The first step to being confident enough to effectively contribute to those libraries is to realize that they are just software, just like what you're writing.
3. Find Problems to Solve
This is the easy part. The entire point of writing code is to solve problems, it's what we do. Most likely, you're writing custom code because there isn't already a library that solves said problem, but there might be a library that comes close. When you realize that there is some hole in a library you're using (or want to use), you've found your in. Whether it be a flaw you found or a feature you need, this problem that needs solving is a gateway to the open source world.
4. Talk to the Maintainers
This is, in my opinion, the hard part. Reaching out to strangers to ask a question about their project may come naturally to some people but it most assuredly does not to me. That's why I'm providing a few sub-suggestions for this part.
4.1. Read the Docs
You may have already done this when you first started using the library, but it's time to look again, keeping your eyes open for the answers to a few questions. Look at the readme, contributors guide, any public documentation, and existing issues to see if you can find an answer to your question. It might be that the maintainers of this project chose not to implement the feature you want for a reason, or that the bug is actually intended behavior for some reason. Also keep your eyes open for any rules/guidelines for making contributions.
4.2. Ask a Question
This is important, don't tell the maintainers anything about their project. It's theirs, they know more about it than you do I promise. Whatever your goal is, frame it as a question. "Is there a way to do X?" "When I do Y, I get Z, but I expected to get Q, am I doing something wrong?". You should be coming to them with no expectations or prior assumptions, just a problem that needs solving. That problem is fundamentally yours until they agree that the problem is the project's.
5. Solve your Problem
Don't sit around waiting for a response from the maintainers of the project. Odds are if you're writing code for a living, you don't have time to do that. Write a workaround to the bug or a function that gives you the feature you want. Write it in your code, not in a copy of the open source library (you don't want to be in the business of maintaining forks). Keep this code as decoupled as possible from your project though, you may need it later.
6. Go with the Flow
Eventually the maintainers may get back to you, or they may not. If they do, hopefully they will answer your question. If they are amicable to the idea of adding the solution to their project, you can offer them the code you wrote in step 5 as a way to help. How you offer this code will depend on the project. Sometimes they'll want you to go through a fork/clone/branch/push/pull request process. Sometimes they might want a Git patch. Maybe they just want to see how you did it inline in the issue so they can implement it into their code base however they see fit.
7. Write a Comment
Post down below this post telling me your success stories. How did you go about contributing to a new project? Did you use any of my suggestions from above (even if you did it before reading this post)? Are there any other bits of advice you'd like to give to developers who have not (yet) contributed to an open source project?
Top comments (5)
There are so many incredible quotes in this piece. :)
This is indeed very insightful. I also see a lot of « Just look for projects » advice, and for me it never worked either. The projects I’ve contributed to were mostly libraires I used in which I found issues that needed fixing. I think this approach works really well, especially once you:
As for #6, and I speak more as maintainer here, I think proactively posting a snippet of the patch / workaround you used can be super helpful, both to the maintainers (they don’t have to ask you again!) and to other people who may lookup the issue because they’ve encountered the same problem.
Also, for feature requests, it can be a good idea to take some time and think about the exact API you want. It’s okay to start with « Is there are way to do X? », but what’s even better is to show how you would like the library/framework/tool to help you do X, and ideally include code snippets of that. Again, it helps maintainers better seize your problem and whether it’s in the scope of their project.
Anyway, thanks for this great post!
Great points, thank you! I agree with all of it, but I’m especially keen on posting your solution so other people with the same problem can find it.
I don’t think I emphasized enough how important i think it is to create issues. It serves not only as a means of communicating with maintainers but also as a form of documentation. A sort of living FAQ mixed with “known issues”.
Thanks again for your comment :).
Fab post! Looks like your journey is going pretty well these days.
A different perspective
I used to follow the good old device
Now it looks more achievable
Thanks for the post 😋👌🔥
Join our Pie project for Victara we always Welcome Devs