Does your project say “no” enough?
We think of open source projects as friendly places where strangers from around the world come together to make something great. As part of that, we often expect projects to take the work we contribute with gratitude. In that context, saying “no” feels anti-social at best. But it turns out that saying “no” can be an important part of keeping a project sustainable. Learning how to say “no” well is especially important when dealing with an influx of new contributors, like during Hacktoberfest.
i think if we want a better open source culture we have to accept that for small single-dev projects “no, i don’t feel like doing this, patches welcome” is a valid response to a nontrivial issue, and “no, I don’t feel like doing this, and I also don’t want the maintenance burden so i won’t even accept patches” is as well
This isn’t limited to single-developer projects. Projects of any size do well when they say “no” strategically.
Why to say “no”
There are a variety of reasons why you might want to say “no”. The first is because the contribution or suggestion might be totally out of line for what you want the project to do. If I submit a pull request that adds the ability to check a list of stock prices and email the user when the portfolio drops by a certain threshold, that’s not necessarily a bad addition. But if your project creates an app that looks at weather forecasts to determine the optimal time to go for a walk, it’s an irrelevant addition. You should definitely tell me “no” in that case.
But maybe the contribution is relevant, but not something you want to take on. Once you merge something, you’re on the hook for maintaining it forever (or at least until you abandon the project). So while you might really like the code I wrote that posts “now’s a great time for a walk!” to social media, you don’t want to deal with the whims of billionaires. Keeping the API calls up-to-date is not interesting to you, so you tell me “no”. Or maybe I ported it to a hardware architecture that you don’t have access to. This is good for the user, but it means you won’t be able to test future updates.
What if the contribution is relevant and desirable, but not well done? Maybe I added support for another country’s weather service, but the code has no tests, no documentation, and is full of Bad Code Things. The idea is good, but the implementation is a maintenance nightmare. This is a good time to say “no.”
Another scenario is that you’re done working on the project. It’s no longer interesting to you, but you’ve left it available for people who still want to use it. If you accept more contributions, then it’s no longer abandoned and people will expect to see more activity.
How to say “no”
All of the examples above are valid reasons to say “no”, but you want to do it right. The best way to say “no” is to do it up front, before anyone does any work. This means being clear in your documentation what you will — and won’t! — accept. Let people know what’s out of scope. Have clear acceptance criteria that include style, test coverage, documentation, and anything else you care about.
If someone has already done the work, offer the best feedback you can. If it’s out of scope, say so. Invite them to make a “friendly” fork of your project that adds the features you don’t think are relevant.
If the contribution is good, but not something you want to maintain, see if the contributor is willing to stick around long-term. Of course, even if they say they’ll join the project, there’s no guarantee that they’ll be there tomorrow. But if you have more contributors, maybe one of them is willing to help maintain that code, too. Make it a team effort and you make it more sustainable.
If the contribution is poorly-implemented, work with the contributor to bring it up to your standards. Give them specific feedback that they can use to improve it to the point that you’re comfortable bringing it in. This takes time and energy, but it’s an investment in growing your community. You not only get the feature, but you might also gain a valuable contributor who will stick around for the long run (with better-quality contributions, too).
When you say “no” well, you keep your project focused and maintainable. While this may put people off in the short-term, it helps your project stay healthy long-term.