As an open source maintainer, I am reviewing roughly 25 ideas per day - whether they are feature requests, design proposals, or pull requests. Inevitably, this leads to saying "No" quite a bit as well.

Usually, this is in a softer for like "No, not right now", "No, not in its current form", or "No, unless someone else approves", but the outcome is the same: the change is not accepted, and the emotional impact on the reviewer and contributor is similar.

Emotional Impacts

Its probably fairly obvious that hearing "No" sucks for a contributor. They wanted something to happen, and maybe invested a lot of work in doing so (please, please don't submit large changes without prior discussion...) and now its not happening. The emotional toll can be rough as well, ranging from confusion, frustration, and feeling unappreciated, unrespected, or "not good enough".

On the other end, saying "No" sucks as a maintainer. Most obviously, you are potentially causing the negative emotions mentioned above. This probably doesn't happen every time, but it doesn't really matter - there is typically no feedback loop on how someone felt about your response.

This could mean they decided to silently quit ever contributing again. Or they are slowly festering up discontent and will one day hit their limit. Or maybe they didn't really care and moved on. Usually there is no way to know which case we are in; if you do its usually a bad thing - someone complaining about the response and airing their grievances (publicly or privately).

Even worse, a contributor is likely only making sporadic contributions - maybe a few pull requests a week for an active contributor. A maintainer of an active project can easily have 100x this load of reviews, each one taking an emotional toll.

Overall, "No" sucks for everyone involved.

Project Impacts

The flip side of this, is that saying "No" is critical in maintaining a mature open source project. Once a project has reached some level of stability and adoption, its success is largely built on what it doesn't do (backwards incompatible changes, regressions, shipping too many features/complexity, having their supply chain compromised, etc) rather than the features it changes.

In this context, every pull request received is not a beautiful open source gift that will make the project better like it may seem on the surface. Quite the opposite - each change is a risk of destroying the project you worked so hard to build up.

Seemingly innocent changes, such as fixing typos or minor refactorings, are not safe either. Innocent looking changes could be masking intentional sabotage, and "minor refactorings" often have unexpected results. In the early stages of Istio, we had 3 consecutive outages caused by PRs that were meant to be refactoring!

Large changes, like new features, can also be dangerous. In isolation, most features additions look fine. In aggregate, things can look a lot different - approving even 50% of new features could quickly lead to the project crumbling under its own complexity.

With this mindset, most successful open source projects say "No" a lot - I would even say that "No" is the default answer. This has varying degrees, of course. SQLite, for example, simply doesn't accept contributions. Other projects may appear more liberal in accepting changes, but have a closely guarded core.

Mismatched Expectations - What Can Be Done

This tension between "Good for the project" and "Good for the people in the project" can cause considerable angst.

I wish I had a magic solution to this, but I don't. However, I do have some suggestions for contributors that can help reduce this friction.

Acknowledge the mismatch in motivations between you and the project. The motivations are not the same! One way I like to look at this is to understand the difference between a maintainer saying "yes" and "no".

Saying "Yes" is almost always permanent. Its extremely hard to remove a feature from software, and bugs may not be noticed until they had a permanent impact on users (i.e. caused an outage and permanently removed trust, even if its later patched). It is also often a unilateral change - as a maintainer, I can independently approve a change - but I do so one behalf of every other maintainer and user of the software. Every decision a maintainer makes is not about their own opinion, but rather trying to meet the best interests of all stakeholders. So the risk/reward math is much different for a maintainer.

Consider a trivial refactoring:

  • Benefit to the contributor: Feels a part of the community. Maybe contribute more in the future. May use OSS contributions to build resume. Benefits apply to this 1 person.
  • Benefit to the project: near zero.
  • Risk to the project: small but non-zero. However, this is amplified by the size of the project. A tiny risk amplified by 1 million users can easy outweigh any benefits to the contributor to accept their change.

Despite this, I almost always accept PRs like this. However, I view this as a trade-off for my own mental health at the expense of project health (which, in turn, leads to guilt -- you can't really win).

Understanding this can put some perspective in why projects may be hesitant to accept changes, even ones that are obviously beneficial.

So what can you do?

  • As a new contributor, work on things that the project is specifically asking new maintainers to work on. If they don't have these laid out, ask around.
  • Be willing to accept feedback, even if the feedback is "close this PR". Its perfectly normal to not have a PR merged - I have over 10% of my PRs closed without merging, and that is with many years of experience on the project.
  • Recognize the maintainers perspective -- its likely quite different than yours, and it sucks for them too.