I have been working for many years now as an open source software developer. I enjoy doing that, but there are some issues that happen when new contributors want to send me a pull request to one of the projects I maintain.
The main issue is that new contributors tend to send me pull requests directly before even opening a discussion on the change they would like to add, how to add it and why they think it needs to be added.
This creates many problems, as I generally refuse accepting their pull requests and explain why I did that. But since most of us are “sensitive” human beings these days, those new contributors usually become sad and never contribute to the project again.
In this post, I’ll try to explain why it is a better idea to open a discussion before sending your pull request to any open source project you would like to contribute to (even if they don’t state this), and why this is extremely important from the OSS’s maintainers point of view.
Open Source Isn’t “Just Take My Modification, Bro”
When you are contributing to any open source project that you didn’t create yourself, then you have to understand that there are scopes, constraints and goals in the minds of these creators just as you do. They may not like the direction you are trying to take the software to, or they may have other better ways in their minds of doing the same thing.
In any way, you can’t just simply send your modifications and expect the maintainers to merge them however they are. You need first to learn more about the software, what type of changes they are ready to accept and what type of changes they might refuse. You need to check whether your pull request fulfills what they looking for or not.
This is generally documented in most open source projects under the “Contributing” section of their README or official documentation platform. But even if it wasn’t, this doesn’t mean that they do not have the same reservations.
Why You Should Open a Discussion Before Contributing
- Are you sure the maintainers would like to add this feature or change that you are sending? Maybe they have other plans in their minds about what they want to change, maybe someone else on the project is working on the same feature or a related feature, so your change could break things for them without you noticing. Or maybe, they simply don’t want to add that feature. And if they refuse your pull request, you will be disappointed how your continous work for hours was rejected.
- Are you sure your way of doing it is what they want? Say you are contributing to a program built in functional programming style, and you send a pull request turning it into an OOP program. Do you think they would be happy to approve such change? Perhaps not. Perhaps you should stick to the programming, writing and building style used in the project instead of introducing your own. Because otherwise, you are forcing the original developers into your own learning curve, which is not a polite way of entering a project.
- The methods in which you do a programmatic change to a software are extremely important. Maybe the coding approach you used would cause the program to become slower or take more memory, maybe it would cause another built-in feature in the software to break. Maybe developers of that OSS only want to do the task in a specific way, so why bother with all of this headache and wasted working hours instead of just asking them first?
What Would Happen if you Don’t?
In most of the cases your pull request would simply be refused.
Sadly some first-time contributors become defensive when their first pull request is rejected for the reasons mentioned above. Which is why I am writing this article; to let people know the correct way of proposing a change into an open source software so that they don’t fall to that feeling, and so that they get a grasp of the other side’s point of view.
New contributors are always welcome to any open source software. You have no idea how much any average OSS maintainer would be happy to see other people interested in his/her own software and start contributing to it.
However, that happy feeling quickly becomes a pain in the chest when the pull request sadly needs to be refused, or otherwise chaos would happen in the code.
The Bottom Line
I hope this was a quick enlightening post for those of you who are thinking to contribute to an OSS for the first time.
The effort of just opening a discussion about the change before doing it takes an absolute nothing of your time, but it would save both you and the maintainers of the OSS too much time and effort, beside enhancing your relationship on the long run to work together on the project.
If you have any similar experiences or comments on this, we would love to hear them in the comments below.