I’m pretty comfortable with collaborating in open-source projects however, this wasn’t always the case. A couple of years ago, I was intimidated at the idea of contributing to someone else’s project publicly.
I used to think that I was the only one who felt like this but after asking people about this, I’m starting to suspect that many people feel the same way (Not a large enough sample size to verify that this is true across the board).
The downside of people feeling too intimidated to contribute to projects is that we miss out on many contributions that could advance open-source projects forward.
On the flip side, there are bad actors in the open-source community who don’t feel intimidated. These people waste maintainers’ time and slow down projects.
Hopefully, this guide will make maintainers’ lives easier by encouraging higher quality contributions.
Maintainers get their roles by:
- Being one of the people who initially created/founded the project they are currently taking care of
- Being granted the role through the recognition of their contributions
- Being hired to be a maintainer
In all these cases, maintainers don’t owe you anything!
They work on projects in their free time or get paid to maintain projects by their employer. You aren’t the one paying.
Even donating doesn’t entitle you to make demands about the direction of the project (unless otherwise stated).
To make their lives easier, maintainers may add contributions guidelines and issue templates to their projects. This also helps contributors provide more detailed and useful information to maintainers about issues. These templates may also trigger automations too.
As you can see, there are plenty of tasks that maintainers do in projects. Some of them are doing these tasks in their free time.
It’s important to respect their time. Their free time could be reduced at any so please try to make their lives easier so that they can make the most out of it.
If you still don’t understand why you should respect maintainers’ rules and guidelines, then consider the following analogy.
Each project under a maintainer/user’s name is part of their kingdom. Since it’s their kingdom, they decide whether your contributions can be included into their projects so you must follow their rules to be able to contribute to the project.
If you don’t follow their rules, you’ll find that it will take longer for your changes to be reviewed than other contributors who are following the maintainer’s rules and guidelines. Your contributions could possibly be rejected or never reviewed!
If you don’t agree with the way maintainers run a project then there is a solution! Fork the project!
By forking the project, you have a copy of the changes made to the project up until the moment you forked it. You are free to apply your own changes on the existing work done and pull down changes from the upstream project over time.
You are free to manage your fork in whatever way you wish to do so!
We’re human, we’re not perfect. We make mistakes sometimes.
Fortunately, we do understand this. Measures are in place in projects to reduce the impact of mistakes. Maintainers do appreciate the help.
If you have read through the contribution guidelines of a project and can confirm that you’ve followed all the instructions accordingly in your contributions, go ahead and submit your changes.
Any mistakes you’ve made will be addressed in feedback. The positive intent of our contribution is clear.
I believe that there is no need to be afraid of contributing to open-source projects. Especially if you have good intentions.
Bad actors don’t aren’t afraid so you should not be afraid either.