Contributing to Open Source can be super intimidating. Back in 2016 I already knew about the idea of contributing Open Source software. But never actually got started until November 2017. This is when I did my first contribution. Even though I started then, it was after getting accepted into Google Summer Of Code 2018’s edition, that I learned a lot about contributing to Open Source.
My first Open Source contributions
For some time I wanted to contribute to Open Source but never actually took the steps to do it until I saw an initiative called 24 Pull Requests, which is about giving back to open source during the month of December.
During this virtual event, in 2017, I did my first Open Source contribution by adding a job board website to a repository with resources for people looking for a job, made of markdown files. My contribution is in the pull request #22 that I submitted for fvcproductions/hire-me project.
Then at the beginning of 2018, I started contributing to some projects as I was trying to apply to Google Summer Of Code (GSoC), making these two contributions:
I submitted pull request #1986 to opendatakit/collect project, where I picked up work from another contributor’s contribution and completed the issue. This involved changing a line of text on an Android application.
I created issue #167 reporting an improvement to systers.io website and then submitted pull request #168, changing the text for Slack community on the “Contact Us” page.
So I started with small steps. Then in April 2018, I got into Google Summer of Code with Systers Community where I was able to learn much more about Open Source.
Blocks to contribute to Open Source
So while I was participating on Google Summer of Code and trying to find ways to involve the community on the Mentorship System project I was working on, I remembered about what was keeping me from contributing to Open Source initially.
Then I created a short survey for newcomers of Systers Community so that I could understand what was some blockers from other members on contributing to Open Source.
After reading the answers given and blockers from my personal experience I gathered these blockers:
How and where to start contributing;
Not seeing many beginner issues;
Not being confident with my skills;
Some projects seem too intimidating;
Lack of time to contribute to open source;
What if I can’t finish something I committed myself to.
Overcoming Blocks on contributing
So after looking into the common blockers gathered, I started thinking about them, and if I could find a way to overcome them. So here is my perspective on these blockers.
How and where to start contributing
You can start with some initiatives just like I did with 24 Pull Requests. Some other examples are Google Summer of Code, Outreachy, and Hacktoberfest.
You can find Open Source communities that can have a consistent organization and context among its projects, and a community of contributors who can help you get started. A good way to find these is through seeing accepted organizations at Google Summer Of Code. These organizations may have well set up projects ready for you to contribute to. I found communities such as Open Data Kit, Open Food Facts and Systers here.
Regarding finding projects, you can look into the projects you use frequently (e.g.: open source library, social impact project, any piece of software you use, etc…). You can look at issues labeled as “first-timers-only”, “good first issue” and “help wanted”, since these are usually used to indicate that the issues are beginner friendly. You can also check Up For Grabs, which has a list of projects targetted for new contributors, and also CodeTriage.
There is an awesome guide on “How to Contribute to Open Source” by opensource.guide, that you can also take a look at.
Not seeing many beginner issues
As I said before, look out for issues labeled as “first timers only” and “good first issue” since these are specially targetted for new contributors. For example, whenever I can, I label issues like this for newcomers, at systers/mentorship-backend and systers/mentorship-android projects. Although these labels can be helpful don’t limit yourself to them, because some issues may not have these labels but are still doable for you.
You can always propose new issues, and if they’re valid then contribute to them. This is exactly what I did with my contribution to Systers.io website. I created an issue and then fixed it.
If you really don’t find issues that you feel you can solve for the project you’re looking into, try to look at other projects for you to begin with.
Not being confident with your skills
Confidence comes with time… And you don’t have to know everything. Being a software developer, I wanted to start contributing with actual code, but my first contribution consisted of editing markdown files. Even though this wasn’t a feature added to a project in the form of code, my contribution could help people looking into resources for a job hunt. I was super happy with this first step towards getting started with contributing to Open Source.
My next contribution involved changing text being used on an Android application. Even though this seemed like a small change, it was totally a valid contribution. So having said this, I think you can start small while building up your confidence while you start contributing. Even small changes are valid contributions to advance a project.
By the end of the GSoC program with Systers community, I understood that thought my journey I was feeling a bit more confident as I contributed to the community.
Some projects seem too intimidating
I totally understand this, there are projects in Open Source, that I don’t feel prepared to look into, as much as I might have the curiosity to. I can think of open source programming languages or tools I use that have a large codebase.
Know that projects have documentation that can help you, so look out for that. Make sure you looked into the project’s documentation, that can be on the Wiki (e.g.: GitHub Wiki), on a documentation folder together with the code, discussions on forums or on the issues comments’ section. Documentation can be scattered in multiple places. Also, it takes time to understand a project you never worked on, you may have to spend some time looking into the code and setting it up to understand the project (if you’re contributing with code).
Besides looking into the available Documentation, you can always reach out to the community and maintainers from the project, if you really feel stuck, so that they can provide resources to better understand the project.
Lack of time to contribute
Everyone has their own lives going on, with their own commitments. You have to think about how much you want to be involved with Open Source, and the “why”. Is this worth your time contributing to a specific project? Is it to give back to a project you care about? How much time can you actually give for this? What are your motivations? After you understand these you’ll have to think about how to incorporate this into your schedule and how to prioritize this.
Why not start with baby steps, both on the time, and the task you’ll work on. You can try to allocate a period of time, per week, to work on Open Source projects per week (e.g.: 1 to 2 hours on Sundays, 1 hour every day, …). You can also start working on low effort issues like I did for my first contribution. This can help you get acquainted with a usual open source workflow (e.g.: fork -> clone -> work -> submit pull request) and help you get into a habit.
For me, it really helps to contribute to something I care about and want to see grow. Also, I enjoy a lot maintaining a project and making it accessible to newcomers to Open Source (e.g.: by creating issues with “first timers only” label in mind). I also enjoy giving back to the community that I worked with during GSoC.
What if you can’t finish something you committed yourself to
What if you commit to work on an issue and then you aren’t able to finish it, either because you lost interest for the issue, or aren’t able to finish it in the time you set yourself to do it, or its not appropriate for your current skill level… no matter the reason, this can happen.
If you’re getting initially stuck in the issue you’re trying to solve, it helps to ask questions to the community and read the documentation available to you.
If you really feel you have to give up on it, don’t just abandon it. Give notice to projects owners, maintainers and the community, that you won’t be working on it anymore, thus giving the opportunity to someone else to solve it. You can let them know by leaving comments on the issue you committed to. This is totally OK! Also if you already have some work on it that can help the next contributor, share that. By doing this, you’ll make the maintainer’s life easier, because they will know that another issue is available to be assigned to another contributor.
Hope you enjoyed this article and find getting started with open source a lot less intimidating!
To find more information about open source, I find opensource.guide website to be a very good resource to all things related to open source.
You can find me on GitHub, Twitter, LinkedIn, and my personal website.
Top comments (9)
My first contributions were bug fixes of bugs I ran into myself. I'm afraid it still often happen people fix those in a fork or some other way instead of trying to get it in the main branch which is a shame.
One thing that helps with that, and contributing with open source in general, is having patience. Which is hard, but often maintainers do it voluntary, and often that maintain multiple projects.
Yes! Patience is key! From both ends, both maintainers and contributors. We all have our lives... so as a maintainer it might take some time to get back to comments on issues or submitted Pull Requests (PR). And as a contributor, it may take time to fix the PR according to a maintainer's review or to actually do a contribution. And with this... communication. When I have to take some time off, I let the community know that I'll be off for some days.
That's nice, to let them know. I've had really good experiences with clojure with fixes/merges within hours. But also pretty bad ones with two rust repos. Not sure if it's language related or just unlucky. For the rust ones it's 'normal' not to hear from the maintainers for weeks.
This. This was also how I made my first contribution on Github, sometimes the barrier to getting the pull request merged to the repo is not getting a response from the maintainer. I know we really want to get our commits in as fast as possible but sometimes we just have to be patient and wait for the maintainer to reply.
Great post Isabel!
I thought of another blocker: some communities or the maintainers themselves are not very welcoming or they are not working actively in that direction. I think the community around a project should be a pull factor for newbies, no matter how big or small the contributions are.
It takes effort for the maintainers to create a fertile ground around a project :)
Thank you so much, rhymes! 🤗
I agree with your point! The community around a project matters so much. I didn't put that in the post actually because I have never experienced unwelcoming maintainers (although I've heard about these situations before). I've been fortunate about the contributions I made to Open Source, which were to projects where people were welcoming. And for example the community I'm at, Systers Open Source, the community is well managed, welcoming and they take the code of conduct seriously. As a maintainer I try to make the project and environment around it welcoming. In the end, we can all contribute to make Open Source world welcoming for anybody.
Your list of blockers is correct (only missing the community aspect that @rhymes mentions). I've observed this in quite a few different projects over the years, too, both as somebody already working on the project (OpenSolaris amongst others) and as somebody wanting to get involved.
My most recent not-my-project submission was a new feature in Nikola ( github.com/getnikola/nikola/issues...) which enabled both captions and ordering of pictures in a gallery. A feature which I wanted, so I scratched that itch. It took me a few iterations to get it all ready for integration. By the time I made that PR I had many years of software engineering experience in both C and Python, and a lot of confidence in my skills (both writing code and interacting with people).
The first change request I submitted was for Solaris 8 (I worked for Sun at the time), to fix a small bug in the
mptdriver (SAS hba). I was so nervous. Perhaps since this was a commercial software operation and all the contributors had been deemed by mgmt to be good enough (hey, they hired us, right?) I didn't feel quite as nervous as when I offered a changeset to thedarktable.orgproject to make that build on Solaris.Wow, what an amazing and encouraging article! Thank you so much for taking the time to write it!
Thank you so much Tony! So glad you enjoyed it!