How do you phrase “it's open source, submit a patch” so that it's friendly?

Question

In the answers of What's the canonical retort to "it's open source, submit a patch"?, many people voiced the opinion that simply asking people to submit a patch is arrogant and rude.

But it seems to me that as a developer on any open source project, you will see many more feature requests on the mailing list than you could possibly implement. So when a user says, "I would like to see feature X", the truth of the matter is usually that the chances of it getting implemented are pretty slim unless they submit a patch themselves. Also, sometimes a little encouragement might be all that's needed to turn a user into a contributor.

On the other hand, you don't want to scare (potential) contributors away by coming off as rude.

So how would you say "please submit patches instead of asking for features" in a friendly manner?

Update: Thanks for all the suggestions! I see most of them require pretty lengthy explanations. But since I'd rather avoid either (a) explaining the same thing every other day (it just takes too much time), or (b) using snippets that I paste into email (it gets impersonal real quick), I wonder: Has anyone written this up in a document that I can link to?

(Project-specific things like how to write tests, compile the code, and submit the patch still need to be documented of course, but I think those technical issues should go into CONTRIBUTING.txt anyway.)

Answer 1

In short, you explain you don't have unlimited time to do their work for free. (You can skip the 'for free' bit), and that they can contribute any time they like, it's not "your" project, its everyone's project.

so you say "We're really sorry, that's a great idea but we're just too busy with all the other work going on, we'll add it to the list, but if you'd really like to get this in, and you'd like to help us out by contributing to the project then that'd be wonderful. We have some documentation to help guys get into making changes to the project, they're here, so if you have the skills and the time and want to help us, then please have a go and send us a patch with your changes. We might have to make some mods to it when we get it so it fits in with the project's standards, but you'll be doing us a great favour by at least giving us a leg-up for this work and we'll love you for helping us out".

Of course, once you start asking for patches, you can never, ever, leave them lying on your ticket system for too long, if you get a lot, you'll be integrating them more than doing the work you used to. You may not like that, but it's necessary if you want patches to keep coming.

Answer 2

You don't.

In so far as I've been experiencing it, candidate contributors are tinkerers, and won't submit a feature request by merely requesting it. They'll typically request it with some level of participation already:

• Wouldn't it be sweet if [...]? It might be possible doing A, B and C. (That's bait for: I don't have time but here's an spec'd out idea in case you do.)
• Here's a patch to do/here's a fix for [...].
• I'm thinking of writing a patch to do [...] and could use feedback/is anyone interested in helping out.
• Etc.

Coders who submit a feature request outright usually do so for a reason. Some of them include (and I know for a fact that the last two happen in WordPress, for instance):

• They're neck deep in other open source projects, i.e. have no time.
• They're free-riders and intend to keep things that way.
• It's way beyond their skill level/written in a language they know nothing about.
• They use the software from lack of a better option, and don't want to be dealing with a smelly pile of batsh*t^\b code.
• They can no longer be bothered because their prior patches got ignored/rejected, i.e. think they'd be wasting their time.

More typically, feature requests will be coming from end-users who couldn't contribute the patch even if they wanted to. Especially when submitted outside of the ticketing system.

---

I think your most important priority should be to not put off potential/existing contributors, rather that trying to actively recruit new ones. It's hugely important, and I say this from experience. I've a weird way of picking up a new code base, which involves cursory reading of the code to get some level of understanding of it, jumping into the ticketing system, and fixing easy looking bugs to learn the internals in depth (and filing new ones as I test). Over the years I've flooded a few projects with dozens of tickets and patches. Many times these tickets will get little to no timely attention (not even an acknowledgement, e.g. keep it up!) -- including when they come with documented diagnosing steps and unit tests attached.

Answer 3

Stay polite, and explain the situation clearly. What about something like:

Thank you for your feedback. We find your feature very interesting, but despite our efforts to implement most requested features in our product, we do not have enough time to implement them all. If you're a developer, you can join us by contributing to the project, since it's open source.

See, you can't just say "Why are you bothering me with your requests? I'm not here to work for you for free; if you want this feature, go and implement it yourself". The person may be a non-developer, may not know the language used to develop the product, etc.

So instead of being rude, you may suggest to participate to the project, and also explain why you may be unable to implement the feature yourself.

---

Another way to not being rude is to not have to say anything. If you have a website where the users of your application may suggest new features and report bugs, you may want to sort the items by their priority: for example if a feature is requested by 10 000 users, and another one is requested by only 10, there are chances that the first one will be implemented first.

On such website, you can always put a "implement it yourself" suggestion for the features which, after a few days or weeks, haven't received enough upvotes from other users.

Answer 4

Thank you for your request. We have added it to our project backlog and will be reviewing it shortly.

Please note that due to the volume of requests, we cannot guarantee that every one will be implemented. We rely on volunteers, so if you are a developer, please consider donating some of your time and submitting a patch. Otherwise, please know that we are all working hard to get through the backlog and will get to your request as soon as possible.

Really, was that so hard?

Answer 5

Well instead of just saying "submit a patch", you should elaborate a little more.

• Make clear, that you don't have the time for it right now or in the foreseeable future, so if others want it implemented soon, there is no way but providing a patch.
• Take the time to assess the feature. If you sincerely like it, there's no harm in saying that. Encourage people. Or if you think the feature is actually bad, then take the time of explaining that.
• Provide some starting help. Nobody knows the code base like you do. You don't have the time to do it, but you probably know exactly how you'd do it and where you'd start. Within 5-10 minutes you can share knowledge that others would need hours to figure out. Also this helps your big picture to prevail. Instead of having alien features bolted on to your project, you can guide contributors to a nice integeration.

Answer 6

Here's what I typically say...

"That's an interesting suggestion and it would be cool if FooBarLib could do that. Unfortunately, FooBarLib is just a spare time project for me so it is unlikely that I will get round to doing that in the near future. I welcome submissions to FooBarLib, so if you are able to implement this yourself, then feel free to submit a patch (make sure you read our "how to contribute to FooBarLib" guidelines first)."

Answer 7

In addition to the nice ways to say "Submit a patch", also provide developer oriented documentation so that others why really want the feature can get up to speed on your project easy. Many projects aren't developer friendly and require days at a minimum of reading thousands of lines of code and tons of small test cases poking at different parts of the system to get right.

If you provide help to the possible developers, they will be more than willing to provide help. This means good code documentation, good wiki pages explaining the flow (or a good UML/whiteboard diagram), and an easy way to get patches accepted.

Answer 8

I really love the way github encourages others to fork the project. Multiple versions of the same project can exist under different user accounts. If you don't like the direction I am taking the project than please fork it. You can easily submit pull requests but are not stuck waiting for me to accept it.

So my answer is often, just fork it.