As a maintainer of several open source projects for now 3 years, I regularly meet people, mostly about an open source contribution. This allows me to experience all kinds of interactions.
Most of them are collaborative and great, and keep me thrilled to work in open source. But some of them are spoiled by common beliefs or preconceived ideas about open source. So I'd like to bust one today.

Today I would like to tell you that, I’m really sorry, but your Pull Request is not a gift. And by ‘gift’ I mean something given by someone to another person out of kindness.

Before going any further, I want to highlight that this post is my opinion, not an absolute truth. Open source is broad, open source projects come in all shapes and sizes. What is true for some projects might be false for others.

Back to the story, it all starts here:

The background of this story is that a contributor sent many pull requests to a project I maintain - as a member of a large team - and the contributor was disappointed to see that his contributions were not being reviewed fast enough for him. Unfortunately, when these contributions were submitted, the maintainer team was overworked to push a release out, so we slowed down the reviewing work in order to get this release out and be able to resume normal work later, freed from the release stress.

The contributor was really frustrated. This was because, from his point of view, what happened was that he used his own time, his personal time, to find and solve many issues of our project, and submitted the solutions to us. He saw his Pull Requests like many presents sent to us, him gifting us bug fixes or improvements 'for free' so we would not have to do it ourselves. He expected us to welcome these gifts warmly, like solutions and answers we did not have to find, and process them quick and fast. Because... this is what you do with gifts, right? Thank the giver greatly, take the gift and enjoy it fast.

Unfortunately Pull Requests are not gifts.

This is an unfortunate misunderstanding. When a contributor submits a Pull Request that does fix a bug, they might think they are doing us a favor. I understand why some people think of it like this: this person used his/her time to build something and send it to us. This really looks like a favor.

But sending a Pull Request to an open source project is not a favor - at least not for all projects. Nor a gift, or a noble gesture.

When someone submits a contribution to an open source project, the very first person who benefits from this action is... themselves (most of the time). That is because, most of the time, this person is first a user of this project, so for example by fixing a known bug, they actually make the software better for them first - and then share their solution with every other user.

As maintainers of an open source project, we have our own roadmap to push. We have projects, goals, milestones and actively work on them. If someone finds an issue on the project and sends a Pull Request, we’ll be happy to review it so that the whole user community of the project can benefit from it, but we’ll see it as one more item we have to process, not as a gift.

For the projects I maintain, we do not ask people to submit Pull Requests ‘to be kind’. We do not request people to dedicate some of their time to the project ‘out of kindness’, using their time and skills for us. We do not want people to spend time contributing on our projects ‘to help people’ or ‘to be a nice developer’. What we need is people that use the project and, if they see they can improve it, do submit their improvements as Pull Requests. Kindness and friendship is good. But that's not what contributing to open source is about. It's about collaboration.

People sometimes think that a maintainer team should be happy to receive contributions, should be happy for all of this time strangers dedicated to build and send Pull Requests and we should welcome these tokens of appreciation as gifts. We do not see this picture this way. Actually more Pull Requests is... more work for us?

Yes, more work for us. Understanding, validating and merging your Pull Request actually takes a lot of work.

When receiving a contribution to the project, we have to review it. We apply the very same review process that we follow between maintainers, we verify the same items, we look for the same defects. So we spend time on the issue.
When dealing with tricky changes, we might trust people whose skills and knowledge we know well. But people we don't know? We have to be even more careful.

Open source contributions can be submitted by people from literally anywhere, and this is great. They can come from experienced developers or junior developers. They can come from people who carefully analyzed every aspect of the problem they were trying to solve, or they can come from someone who saw a bug, saw a quick fix and submitted it without realizing that his quick fix actually introduced another bug.
Since I have no idea what group the contributor comes from - because we get contributions from complete strangers - I must prepare for the worst so I actually double-check everything in the Pull Request. Sometimes, in order to verify the Pull Request correctly solves an issue, I will go as far as trying to solve the issue myself to verify how I would solve it and compare it to the submitted solution, which means the work has been done twice: once by the contributor and once by me. But this is what I need to be able to approve the Pull Request and state that it is valid and can be merged. After all, maintainers are gatekeepers and guardians of the quality of an open source project.

Moreover, reviewing and exploring this Pull Request can require even more work. I might request the help of an UX designer to validate some UX choices. I could also request a QA analyst to verify that not only the Pull Request correctly fixes an issue but it also does not introduce other bugs. In the end, for a Pull Request that was submitted after one hour of work by a contributor, maybe five or six hours of work will be required to validate it is correct. So... someone’s Pull Request, worth 1 hour of their time, might require 6 hours (and you can convert this in dollars spent) on our side to validate it. That makes it an expensive gift to receive.

Overall, receiving, validating and merging a Pull Request requires maintainers some work. It can even happen that the quantity of work needed to validate is higher than the quantity of work needed to build the Pull Request in the first place.

So you might be wondering... ‘if reviewing and exploring external contributions is so expensive, wouldn't it be more cost-effective to simply ignore external contributions and only work between experienced and approved developers?’

There was a recent example of a project that followed this strategy: Litestream. Initially, Litestream was closed to external contributions because it was too expensive for the maintainer team to handle them. As I said before: reviewing Pull Requests costs time and money. If there is not enough time or money, a project can simply choose to not accept external contributions.
Fast forward, Litestream now accepts bug fixes contributions, but no features. Bug fixes are slightly easier to handle as they are clearly scoped and most of the time the number of changes is small.

For the projects I maintain, rejecting external contributions would probably kill the community so it’s never going to happen. It’s expensive, it’s long, we have a huge backlog of Pull Requests waiting for review but we’ll deal with them, no matter how long it takes because this is key to keeping an open source project healthy. This costly process of validation is what makes it possible for anyone to contribute to the project, making it truly open. So we’ll happily pay the price and welcome and review incoming contributions.

Whoops! I just painted a very grim picture of one of the aspects of an open source project. Please let me brighten it a bit before the end.

If you regularly contribute to an open source project, you will become more experienced about it, and the maintainers team will start to know you. This will make the reviewing process smoother and fairly more enjoyable on both sides as trust will start to grow between you and the project’s team.

Then the next step becomes possible: when trust is firmly anchored, you could even apply to become a maintainer of the project. Yes, you. If your application is approved, you would be able to help the project team handle the reviewing Pull Request workload and will definitely make the project healthier, for both sides once again.
If you’re curious about how this happens, have a look at the maintainer application process of the Wordpress project as an example. Each project can have a different process, but most of the time the main requirement is trust, because welcoming a new maintainer in a team is like giving them a duplicate of the house keys.

So now you know :) are you willing to make open source better?