What's the canonical retort to "it's open source, submit a patch"? [closed]

Question

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.]

Answer 1

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.

Answer 2

The canonical retort is to submit a patch.

Answer 3

This is the standard answer when developers don't think they will get around to doing something in any reasonable timeframe, but it's been repeatedly brought up.

It's most unfair when it's been repeatedly brought up, but the person who's most recently mentioned it doesn't know that, and just gets "we are taking patches for that" right away. In this case the maintainer is fed up with the discussion but the user thinks it's a new topic. Anyhow, most likely if you get "taking patches" right away, you shouldn't take it personally but might want to read over the archives and bug tracker for more details on the issue.

If you are repeatedly bringing up a request yourself, "taking patches" is potentially intended to be a relatively polite brush-off, vs. some less polite alternatives...

And then of course there are rude maintainers who will say "taking patches" with no explanation ever to anyone, but I'd say that's a minority.

If you've ever maintained an open source project with a lot of users, you'll know that there are 100x more requests than the maintainers could ever get to, and many of those requests are important to the requester but would be outrageously difficult, or would disrupt a lot of other users, or have some other flaw that's only visible with a global understanding of the project and codebase. Or sometimes there are just judgment calls, and it takes too much time to argue every one over and over.

Most non-open-source companies will not give you access to the developers at all, and you'll just get the silent treatment or a polite but bogus story from customer support. So, in open source at least you have some options (pay someone to code the feature, etc.) and while developers might be rude, at least they give straight answers. I'd rather have "no" than the usual "it's on our roadmap... [2 years later] ... it's still on our roadmap" kind of thing I've gotten from a number of vendors...

So I don't think there's a retort. Maybe the open source maintainer is just really busy, maybe they're a jerk, but either way, they likely have a tough job and getting into a who-has-the-last-word debate isn't going anywhere. The best you can do is contribute in some way and try to be constructive.

Maybe it isn't code, but possibly there's a lot of analysis and documenting user scenarios you could do. When I was maintaining the GNOME window manager, lots of times it would have been helpful for people to go analyze a problem globally considering all users, and really write down the issues and pros and cons and what should happen from a global perspective.

(Instead, the usual thing was to start flaming as if they were the only user that mattered and there were no tradeoffs. And while that's great, and was a datapoint, and often I managed to stay polite or even solve their problem eventually... flaming does not make anything happen more quickly. It just confuses emotions into the issue and wastes everyone's time.)

Answer 4

The reason you get this response is not that the maintainers are jerks, it's that you haven't adequately convinced them of the value proposition of them working on your feature for you.

The best response is to start a dialogue about the value of your feature to their community as a whole, to see if you can convince them to change their minds. Maybe they're right and they know more about their own community's needs than you do -- but, then again, maybe not.

If the feature is only valuable to you and of little to no value to the community, I find that money is an excellent motivator, while complaining about their attitude is not.

Answer 5

What's the canonical retort to “it's open source, submit a patch”?

There is no reasonable retort that is likely to make any difference. Attempting to persuade volunteers to do something that they have no intention of doing is a waste of your time ... or worse.

Your options are:

• Do what the response suggests; i.e. implement the feature and submit it as a patch. It is called "giving something back".

• Find someone who would be willing to implement the feature for you for real money. It could be the project itself (e.g. in return for sponsorship), someone associated with the project, or some random "coder for hire".

• Find an alternative product.

---

If you received this response when you made a "helpful" suggestion, consider how you might have responded if you were in his shoes. For instance, how would YOU respond if you thought that the suggestion wasn't worthwhile / well-thought-out / intelligible / etc, but didn't have the time or patience to engage in a protracted debate?

---

I've been involved in a long running open source OS project, and one of the most annoying things is people who sit in the "peanut gallery" and pepper you with a stream of suggestions about doing things "better" that:

• are incomplete, unintelligible or downright nonsensical,
• are untried ideas with an objectively low chance of success,
• would require a huge amount of effort to implement, and / or
• are counter to the stated goals of the project.

Often the best response is to pointedly challenge the person to get involved in the project ... and hope that they take the hint ... to "put up or shut up". Unfortunately, the most annoying ones don't even take a hint.

Of course, the other response to such people is to not respond at all, or completely ignore them.

Answer 6

The response would be reasonable if you and the programmer in question were equals, and knew just about the same about the code base and the language and all the other things relevant to this particular thing you are pointing out.

You aren't equals (or you probably would just have done it) so I would suggest a proper retort to be:

"There is no way I can possible do it as fast and good as you can, which is why I asked you to help me in the first place. Please!"

I believe that it goes against fundamental human nature to say then "oh, yes, this thing I have spent a long time on and is really good at, is so simple that anybody can come in from the street and do as good a job as I can".

Answer 7

The canonical retort is to fork the project.

Answer 8

The canonical answer to "submit a patch" is:

"I don't have the skills, experience or time required so can you please tell me where to ship the cases of beer to the guy who can do it for me"

Answer 9

Submit a comprehensive test case.

Answer 10

"If you do it, I will include it" is much better than "no."

If you are unable to do the work for one reason or another, explain the circumstance to the project maintainer in private.

If you are unwilling to contribute in some way to an open-source project that you would like to use, then you should be looking for commercial support or another commercial product instead.

Answer 11

A good open source project will have a bug/feature request system where users can submit bugs/features and others can vote on them so the maintainers can identify what's important to the community as a whole. The quickest way to get your feature in place however is to submit a patch for it. Period...no ways around that.

Answer 12

"Thanks for the response."

Because:

• At zero price, demand (requests for features) exceeds supply (available coders to implement said features).
• Ragging on anything that's provided free lacks class IMHO.
• This is the whole point of FOSS: people bringing vegetables and meat of their own to add nutrition to the stone soup. If I can't contribute something, then I should be thankful that I can eat at all, and not complain that I'm not eating better.

Answer 13

You don't have to say anything. The very fact that the developers have responded is indication enough that they already know the problem exists and that is causes pain for (at least some) users.

At the end of the day, nothing you say is going to convince the developer to work for you if they don't want to.

Answer 14

Personally, I would rather get a response of "This is a known issue, but unfortunately it is not an issue being addressed any time soon. Developers are working on other issues. There is no ETA at the moment."

The "submit a patch" response is very rude, as it assumes a number of things:

1. All users of the program are programmers or all bug reporters are programmers.
2. All programmers know the language the program is in.
3. All programmers know about every kind of problem a program of any kind might have.
4. All programmers have free time to work on an open source project.

Even if we assume the "submit a patch" response maker knows all the above, that simply makes the statement sound like "X hours of my time is worth more than the orders of magnitude more of hours of your time you'd to get up to speed and fix the issue".

Generally, when I get a rude response from a developer when I ask about a problem I have or submit a bug, I stop using that program. I no longer use uTorrent (not open source, but the point remains) for example, because the responses I got on their "support" forum were so rude. I submitted a problem I had in the Bug Reports forum. The thread was immediately locked with a link to another thread about a similar, but different issue in a thread (which was also locked, of course). In the meantime, I opened a thread in the General Discussion forum asking if anyone had found a workaround to the problem. In the time it took to save that thread and go back and see that my first thread had been locked, my thread in General was locked and my forum account banned for disruptive behavior. I uninstalled uTorrent and haven't been back since.

Answer 15

Just replying "submit a patch" is rude IMO, but still...if you use open source software for anything serious, you must be prepared to take care of it should the need arise.

The following is based on a post by Jeremias Maerki (of Apache FOP fame):

If something doesn't work for you, you have several options:

• This is open source: you can fix it yourself.
• If you cannot fix it yourself, you can wait until someone has free time and thinks it is fun to implement.
• If that doesn't happen, you can find or hire someone to do it for you.

I think it's a very valid full version of the "submit a patch" answer.

Answer 16

Every time I see this I immediately start looking for an alternative product. To me this is a dangerous sign that the maintainers either don't care about their users (bad if your project is used everywhere) or have lost interest in the project. Both of these usually mean that the project will die soon or will be plagued by stagnation as developers refuse to move the project forward

(Note that I'm not saying that the very first bug report you see with this kind of response you run. You have to look at a general trend. If most bug reports end with this kind of response, then follow this advice. If its just a few, then those are most likely feature requests that don't fit a the projects goals or are extremely use specific)

As @MainMa said starting to contribute to a brand new project is very difficult. Most developers don't understand this as they've been working on the project for months/years and it makes sense to them. This can sometimes be an honest mistake.

Answer 17

I occasionally joke that free software can be free as in beer, free as in speech or free as in you get what you pay for.

While I say it jokingly (I work for a company who use a lot of OSS) but I think there is a truth there - if you want commercial level support then you need to either use commercial software with a suitable support deal, or find an open source software solution that allows you that level of support (usually through someone being paid to provide it but potentially through your organisation employing or assigning development resource to work on it).

"Submit a patch" is infuriating but it highlights something about OSS and perhaps it should be a reminder that OSS isn't right for everyone in every situation, at least not without making sure you've got a solid support framework for it (either in-house, paid for or through the community).

We often think about software which is free as in beer but not as in speech (that is non-open freeware). Perhaps this is a case where we should think about the software as free as in speech but not as in beer.

Answer 18

Switch to well maintained alternative.

From my experience with well maintained open-source projects is, that if you create well defined bug report or feature request, then it has very high chance of being implemented.

Answer 19

"I can work on only one thing at a time, but I can complain about many things at once. I think both functions are useful." - akkartik on ycombinator.

Answer 20

I consider that when one is working on a project, providing releases and support, an unspoken, implied, contract of support between dev and user comes into being. The dev has taken on the implied responsibility of supporting the codebase for his users, including adding features at request.

"Submit a patch" is basically giving the finger to the users, in my opinion. This is contextual - sometimes it's just too much effort to implement, sometimes it would wreck the existing project or incur feeping creaturitis, or any of a host of other reasons. But, ultimately, it is saying, "screw you, not doing it". Which, in my mind, is, in some level, a breach of that unspoken contract.

Answer 21

There are several ways it should be done.

• Feature proposal and vote. but this takes time.

• Get hired by a company who need it to make the patch. Obviously this is the best solution, but get ready to collaborate with the guy who makes the open source software you want to upgrade.

• Finding out why the feature is not implemented in the first place is important too. Often the feature is out of the line of the software project: the team doesn't want this feature, don't feel necessary or they just think it's not the good way to do something. In this case you should just fork the project and make it yourself.

• Use proprietary software that does what you want.

• Remember that OOP software often eases the process of integrating a feature.

• Whining on a mailing list, on irc or in a forum will just piss out programmers, and will give ammo to OSS proponents.

Answer 22

There is nothing you can say that will make him do it. After all, why should he? Because of one user's wishes? It's not good enough a reason.

But, if you can collect a reasonable number of users and give rational reasons ("I want it" is not a rational reason.) why that feature could be useful, in general and to you and number of others he just might change his mind.

Although, there is also a special case that must be considered. That a dev. is tired of developing the app, slowly wishing of abandoning it (has other things to do), and so he is slowly abadoning feature requests. Apart frm trying to convince him to release the code, in this case there is practically nothing you can do, even with respect to the above.

Answer 23

Open source projects in particular are friendly to bounties or funding of the development of a particular feature, even if the new feature doesn't make it to to the official releases.

Plus, yes, one of the ideas behind publishing open source is for anyone and everyone to have the right and the responsibility to make their own contributions.

With closed source, your best resource is to gather an statistically important group from the user base that wants solutions like the ones you want.

Answer 24

In my experience this response is usually given if the user request doesn't fit the project's aim. It happens when people think that you're going to implement everything that they propose to you, and a bit more - for free, open source and a great and happy future.

'Submit a patch' is a relatively rude response (and it should be avoided, of course. Especially in this concise and sharp form. There are many ways to express roughly the same message - for example 'invite' the users to help because you don't have the time to implement it on your own). But as is, it's a clear 'stop wasting my time'-indicator. As such, there's not much you could do about it, nor is there are 'canonical' response.

The best response I can think of is to actually present a patch. Assuming your patch works, you have at least proven that the idea is not totally unrealistic. Usually, this means that the people in charge of the project will re-consider the proposal.

Answer 25

"submit a patch" is a legitimate brush off for ideas that don't fit into the goals of the project. It's probably better in the long run to just tell you the idea sucks or you're trying to use the project for something far outside it's intended scope, but "hey, if you think what you're asking is so trivial, why don't you try to fit it into our existing code base" is sometime appropriate.

If it's minor and really of use to the intended users of the project, then just submit the bug report, clearly describe the issue, give steps to reproduce, indicate that you're using the current nightly build, and leave it at that.

What may seem like a minor simple change that would help tons of users may actually be a huge pain in the ass that no one would use besides you. That's the best case for "submit a patch".

It's also possible that you have run into a case like the notorious glibc maintainer who seems to have a one-track mind that his system is the universe, his interpretation of specs is the word of god, and that's all there is to it, regardless of how many people would prefer otherwise.

Answer 26

I actually signed up just to answer this question.

Is there is need for a retort? this response is usually used when the developer knows about the issue but doesn't think it as important.

I will give you a live example. ubuntu dropped the systray support(but can be worked around by white listing a app) and added new app indicators. some apps like jupiter relied on systray support so the developer told about the workaournd instead of adding app-indicator support so i asked the developer to add the app-indicator suppory the reply was "Send us patches." on asking the reason they chose not to implement this . there was this

I have no interest in spending my time building support for a libra1ry that I will never use just because someone with a lot of money demands it by blacklisting my applications ability to function properly on his Linux distribution simply because he can.

If it was a real technical problem, I would probably take action but this is purely a political maneuver, so no I don't think so.

No, I'll just whitelist it

Fair enough. the developer has reason not to implement a feature but is willing to accept patches. this is not really rude and offensive so there was no need of a retort.

bottom line : the canonical retort would be to submit the patch but if you can't there is no need for a retort

Answer 27

Start a bounty for the feature you want.

Or go out and buy the product that claims to do exactly what you want and abuse their support personnel when you discover that the marketing doesn't match your expectations.

Answer 28

I would suggest creating a project for implementing the feature on sites like RentACoder/ELance/etc, and posting about it on the original open source project's forum. Any of the programmers on the open source projects, including the author, now has a financial incentive to consider your request.

Answer 29

The best I can think of is "you suck".

Sorry this obviously isn't very helpful, but I think this is just one of the unfortunate situations where the user is completely screwed. A brutally honest appeal to the developer's conscience is a last ditch effort.

You could try offering (cough) "donations" to have your problem addressed, but I fear that such a practice if made common would lead to some really bad loss of integrity in the industry, as bug fixes should never be made profitable, either for "Free" or commercial software.