The danger of ever suggesting some feature on a product, especially open source, is that you'll get the response, "why don't you do it?".

That's valid, and it's cool that you can make the change yourself. But we know practically that products do often improve as programmers listen to the voice of users — even if those users are other programmers. And, the efficient way to make those changes can include someone who's already working on the project taking up the idea and implementing it.

There are some common terms used to refer to software development problems. e.g. Bikeshedding. Is there a common term used that essentially replies, "Yes, I know that I can change just about anything in the world — even closed source. I could get hired, and go write that code. But in this case I'm just making an observation that may in fact be useful for another coder already well suited to easily make that change — or just generally discussing possibilities."

[p.s. (a few days in) - I should have pointed out that "submit a patch" is often said with wry humor, and I'm seeking an appropriate witty response.]

It's a difficult point: since the user doesn't directly or indirectly pay for a product, she cannot ask for a feature to be implemented. It's not as if you were a stakeholder or a direct customer who ordered the product, and not even an end user of a commercial product.

This being said, "submit a patch" is not a valid answer. It's not polite. It's not correct. Even for an open source product. "Submit a patch" is the short version of:


  "we don't care if you like our product or not. Go and modify it if you want, but don't bother us with your customer requests."


What about submitting a patch?

Well, it's not so easy. To do it:


You must know the language(s) used in the open source project.
You must be able to load the source code from the version control to be able to modify it.
You must have all the correct versions of any build dependencies installed (including both runtime libraries and build tools).
You must be able to compile this source code, which is not so obvious in some cases. Especially, when a huge project takes a few hours to compile and displays 482 errors and thousands of warnings, you may be courageous to go and search for the source of those errors.
You should understand very well how the project is done, what are the coding style to use, if any, how to run unit tests, etc. If the project doesn't have a decent documentation (which is often the case for open source projects), it may be really hard.
You must adapt yourself to the project and to the habits of the developers who are participating actively to the project. For example, if you use .NET Framework 4 daily, but the project uses .NET Framework 2.0, you can't use LINQ, nor Code Contracts, nor other thousands of new features of the latest versions of the framework.
Your patch must be accepted (unless you do the change only for yourself, without the intent to share it with the community).


If your intention is to actively participate to the project, then you can do all those things and invest your time for it. If, on the other hand, there is just an annoying minor bug or a simple feature which is missing, spending days, weeks or months studying the project, then doing the work itself in a few minutes is just unreasonable, unless you like it.

So is there a canonical retort to "it's open source, submit a patch"? I don't think so. Either you explain to the person that she's impolite, or you just stop talking to her.
