218

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

Improve this question
17
  • 16
    I wish I could upvote this more than once! (And that's coming from someone who has submitted patches to a handful of different projects and gotten them accepted. That attitude you describe is just plain annoying!)
    – Mason Wheeler
    Apr 15, 2011 at 22:43
  • 64
    I suppose "What do I look like, an unemployed code monkey? I have a life!" is not an acceptable retort ;-)
    – Steven A. Lowe
    Apr 15, 2011 at 22:51
  • 12
    In my experience, the "submit a patch" answer usually comes after the developer has already explained why adding the feature would not be practical.
    – user16764
    Apr 15, 2011 at 22:54
  • 7
    @Steven, depends on you just want to top the insult, or actually make them do what you need. I believe it is not an optimal strategy if you want the latter.
    – user1249
    Apr 16, 2011 at 6:39
  • 12
    @orokusaki: Or D) They consider the feature less valuable than other features they could be working on, and they have limited resources.
    – David Thornley
    Apr 18, 2011 at 14:50

29 Answers 29

Reset to default
117

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.

Improve this answer
33
  • 9
    This sounds like it was written by someone with no experience maintaining an open source project.
    – Rein Henrichs
    Apr 16, 2011 at 0:08
  • 46
    @Rein: Maintaining an open source project is no different from maintaining any other project. You have customers. If you ignore those customers, they will stop giving you valuable feedback, and they will go somewhere else for their solutions. Maybe that's fine with open source people, but I'd sure like to know if I was going to be totally responsible for making bug fixes to a piece of open source software, because that would make me think twice about using it.
    – Robert Harvey
    Apr 16, 2011 at 0:27
  • 18
    @Rein: Well so far I've heard you say twice that we don't know what we're talking about. Maybe you can enlighten us, eh?
    – Robert Harvey
    Apr 16, 2011 at 1:47
  • 9
    @Rein Henrichs: Your first two comments are ''ad hominem'' attacks. If there are differences between the two, say what they are, rather than saying other people don't know anything.
    – Andrew Grimm
    Apr 16, 2011 at 7:14
  • 13
    I suspect that the intent was "Maintaining an open source project is no different from maintaining any other project as regards listening to customer feedback and keeping their goodwill." If so, I'm fully willing to drop it but, as someone who has maintained several FOSS projects with anywhere from a handful to hundreds of contributors, I find the original blanket statement "incorrect".
    – Rein Henrichs
    Apr 16, 2011 at 7:40
79

The canonical retort is to submit a patch.

Improve this answer
4
  • 48
    Or better yet, to say, "I already did six months ago. When are you guys gonna get around to reviewing and committing it?"
    – Bob Murphy
    Apr 17, 2011 at 15:09
  • 14
    I normally don't like short answers, but this is seriously the only way to respond that's guaranteed to end in the result you're looking for. They clearly stated the best possible way to achieve your goal. Why muck about with any lesser solution?
    – user8
    Apr 18, 2011 at 8:08
  • 19
    -1 open source asshole answer. Not useful. (Sorry.) There is no canonical "retort". Best response (assuming the OP can't just submit a patch, which I think is a reasonable assumption in this case) is one of (1) "I don't have the capabilities or resources to generate a patch [and possibly include a link to this very question]", (2) eyeroll, no response, use of tool in its current state, or (3) search for a better tool.
    – JohnL4
    Jun 10, 2011 at 13:39
  • 2
    It doesn't necessarily have to be a patch. Providing detailed and refined feedback also holds worth. All this is saying is, don't expect me to invest my time to cover your specific need if you have nothing to offer in return.
    – Evan Plaice
    Dec 14, 2012 at 1:48
68

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

Improve this answer
12
  • 4
    @Aaronaught I've been around hundreds of open source projects and haven't noticed DIY as a default response. It's a response to certain flavors of request.
    – Havoc P
    Apr 17, 2011 at 3:29
  • 2
    All I'm saying is, I think more often than not, there is some reason a maintainer is at least a little sick of a topic (or person) before they say "taking patches," and it can be worth looking into why you got that reply. It's my experience, fwiw. If the question here is about cases where there's no reason to be sick of the topic or person, then sure, "taking patches" is probably not a great thing for the maintainer to say. People make mistakes. I still say, I doubt a retort (or a meta-discussion like this) is going to help, but engaging constructively might sometimes.
    – Havoc P
    Apr 17, 2011 at 17:06
  • 5
    Also, while it can be phrased more or less politely, if a maintainer has a work backlog in their mind, they probably have 1 thing they can get to themselves, for every 100 things they would take a patch for because they'd want the feature; and then there's yet another category of changes they would reject even if someone else did the work. So there does have to be some way to communicate "I would take that change, but don't have plans to do it myself." Some people here seem to feel that "Sure, coming right up" is the only acceptable answer. But "taking patches on that" is a real category.
    – Havoc P
    Apr 17, 2011 at 17:11
  • 2
    @Aaronaught those do sound like good phrasings. I think often no offense / rudeness is intended by "we would take a patch for that," but programmers are not as a rule the most emotionally sensitive types, may be rushing through email, and tone doesn't relay through text very well, so it's easy to come across as curt.
    – Havoc P
    Apr 18, 2011 at 14:14
  • 2
    Actually, "we would take a patch for that" is different in two subtle but important ways: (1) it does not place the responsibility directly on the user, and (2) it acknowledges that the request has been seriously considered despite not being implemented. Although the net result is essentially the same, it's a far more humane answer. (Still, it wouldn't hurt to explicitly add the implied ...but we don't have the resources to complete that ourselves right now.)
    – Aaronaught
    Apr 18, 2011 at 14:47
42

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.

Improve this answer
8
  • 15
    Of course, maybe they are jerks. This response alone is not a very accurate indicator, as it's also used by non-jerks when the asker is a jerk.
    – Rein Henrichs
    Apr 16, 2011 at 0:10
  • 4
    I'd also like to add that in the absence of money, you can often trade in-kind for some work: help triage a busy issue queue, hang out in the IRC channel and give support, test patches, or write documentation. Open source projects have limited resources and need to make the most of them. Adding a feature is viable if it's important to enough people, or important to people who do/give enough. If your case isn't the former, make it the latter.
    – HedgeMage
    Apr 16, 2011 at 2:38
  • 2
    Honestly the best way to convince a developer is to show him how much of his user base wants the feature. Bugtrackers with voting, forums threads, etc. are all very good for this, and are used in many open source projects.
    – ProdigySim
    Apr 16, 2011 at 6:10
  • 4
    Similarly, when people get a RTFM or DAFS as an answer, or a -1 on SE, it is because the questioner has not adequately convinced the answerer of the value proposition of answering their question for them. I'm sure many of you can relate to this feeling.
    – Rein Henrichs
    Apr 16, 2011 at 6:52
  • 1
    @Walter Yep, which is why I suggested convincing the person of "the value of your feature to their community as a whole".
    – Rein Henrichs
    Apr 16, 2011 at 17:39
31

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.

Improve this answer
22
  • 7
    "How would YOU respond if you thought that the suggestion wasn't worthwhile / well-thought-out / intelligible / etc" - exactly how every other professional responds. "Could you explain / give some examples of what you're asking for?" or "Could you give me some background on why you think you need this feature?" or "What if we did this other thing instead, would that work for you?" or how about just "Thanks for your suggestion, we will consider it for a future release." This is basic interpersonal skills, not rocket science.
    – Aaronaught
    Apr 16, 2011 at 17:23
  • 12
    @Aaronaught - Sorry, but you don't get it. The typical open source developer does not have the time to engage in polite but ultimately pointless discussions aimed at stroking the ego of his "customers"; i.e. pretending to care, when a half-intelligent person can figure out that it is all a facade. And to be frank, I find that kind of ego stroking politeness to be patronizing ... and MORE offensive than being told bluntly that there's no chance they are going to implement XYZ.
    – Stephen C
    Apr 17, 2011 at 3:32
  • 6
    @kurige - actually, if the people in question DID submit patches they would DEFINITELY would be considered. The problem is that the people in question are "all mouth"; i.e. no interest in putting in any effort.
    – Stephen C
    Apr 17, 2011 at 15:11
  • 10
    Because the typical open source developer already has a job, and they do their open source development for fun. Doing what other people want you to do is work. Doing what you want to do is fun.
    – ProdigySim
    Apr 17, 2011 at 17:00
  • 8
    @Aaronaught: Is it necessary to treat lots of jerks respectfully? Given a public service, there will be people who make unreasonable demands, often in an insulting form. Dealing with impolite fools can be a real pain. A requirement to be respectful to them would drive a lot of people out of the F/OS business, and that would be a loss to everybody.
    – David Thornley
    Apr 18, 2011 at 16:23
20

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

Improve this answer
18
  • Except that's not really what they're saying at all. They're saying "this thing that you want is not something the community wants, so we're not really interested in working on it. We might accept a patch if you wanted to work on it." Implicit is "we might also change our minds if the community does want it." Remember that "I want you to help me" goes against the fundamental nature of open source projects, where (to bring the full force of my Star Trek nerdery to bear) the good of the many always outweighs the good of the few.
    – Rein Henrichs
    Apr 16, 2011 at 17:43
  • Well, unless those few have a lot of money, historically speaking.
    – Rein Henrichs
    Apr 16, 2011 at 17:45
  • 2
    @Rein, no, what they are saying is that THEY do not want to do it. All this "the community wants" is just a straw man. The whole point is that one from the COMMUNITY is requesting it.
    – user1249
    Apr 16, 2011 at 18:22
  • 1
    "it is extremely impolite to suggest writing a patch if you do not know ahead that - if it came - you would consider it for your product." Agreed. Like I said, this is why I don't use this response. I can sympathize with it, though. "If you sincerely mean that "submit a patch" is meant to shut people up instead of delegating work, then you agree that this was asked by a community member and not a developer." I'm not really sure what you're saying here, sorry.
    – Rein Henrichs
    Apr 16, 2011 at 18:53
  • 1
    @Thorbjørn Ah yes. Well, in point of fact the open source maintainers I am familiar with certainly don't think that way. In fact, we go out of our way to provide developer guidelines and documentation to help people learn the project and the conventions for contributing to it precisely because we are aware of the skill gap. For instance, rubini.us/doc/en/contributing
    – Rein Henrichs
    Apr 16, 2011 at 18:55
16

The canonical retort is to fork the project.

Improve this answer
3
  • 8
    or submit a patch
    – Kamil Szot
    Apr 16, 2011 at 10:46
  • 2
    What good will forking bring you?
    – user1249
    Apr 16, 2011 at 10:55
  • 1
    @Thorbjorn: Everyone could use a good fork now and again. Even a pity fork.
    – user18014
    Apr 17, 2011 at 7:56
14

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"

Improve this answer
13

Submit a comprehensive test case.

Improve this answer
2
  • 1
    I Like this one, though, doing so would often times take longer than submitting the patch itself ! The constant here is the time to familiarize with the code base and is most likely the biggest portion of either creating the test or writing the patch directly !
    – Newtopian
    Apr 18, 2011 at 3:03
  • 1
    I like this answer for bugs. Even if you don't understand the framework enough to submit a fix, it saves a tremendous amount of time for someone who does. There is nothing less likely to make me fix an issue than a vague and irreproducible "bug" that might be simply a misconfigured system. There is nothing that makes me jump on an issue faster than a simple testcase so I can quickly try out different fixes.
    – BobMcGee
    Mar 8, 2016 at 14:02
11

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

Improve this answer
2
  • 5
    So only those who directly contribute have any right to complain about a bug or missing feature? Fine, I guess, but that also means that neither the contributors nor the users have any right to complain about lack of adoption.
    – Aaronaught
    Apr 16, 2011 at 17:33
  • @Aaronaught No, they have a right to complain, but there is a limit to the amount of unpaid time a developer can invest in a project and it's important for users to recognize this. In my own work, I reserve "I'd welcome a patch/pull request" for features that have lousy effort/community value propositions. Or for where the user is insisting they get the feature RIGHT NOW and not respecting someone else's time or other project commitments.
    – BobMcGee
    Mar 8, 2016 at 14:06
9

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.

Improve this answer
9

"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.
Improve this answer
8

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.

Improve this answer
8

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.

Improve this answer
2
  • Do you mean "I would rather get a response of" as opposed to "I would rather not get"?
    – Andrew Grimm
    Apr 16, 2011 at 7:09
  • Thank you for the first paragraph in particular. It's amazing how such a basic form of professional courtesy can be foreign to so many people. Whether you get paid or not, the appropriate response is to acknowledge the issue and explain its status (even if the status is "deferred").
    – Aaronaught
    Apr 16, 2011 at 17:28
8

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.

Improve this answer
6

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.

Improve this answer
3

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.

Improve this answer
2

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.

Improve this answer
1
  • 2
    Bug reports and feature requests are often not well defined. My experience is that competence and respect work well. Also, a well defined feature request will at best be considered. It may be considered low priority, or it may be something the project group explicitly doesn't want to do (there's good examples in the PuTTY FAQ, and a nice list of feature requests grouped by categories).
    – David Thornley
    Apr 18, 2011 at 16:06
1

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

Improve this answer
1

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.

Improve this answer
6
  • It isn't a contract unless both sides receive something. What the project typically wants is well-done bug reports and frequently well-done feature requests, and not all that come in live up to that end of the implicit contract.
    – David Thornley
    Apr 18, 2011 at 16:09
  • 1
    @Aaronaught: They're providing free testing only if they file bug reports that are detailed enough to work with. I've seen my share of bad bug reports. They may or may not be providing good advertising. Most people who use F/OSS don't give anything useful back, which is fine, but it sure isn't one side of a contract.
    – David Thornley
    Apr 18, 2011 at 18:04
  • 1
    @David: Would you please stop trying to restrict the conversation to only the most difficult/unproductive users? If we're going to generalize then that generalization has to be for the entire user and contributor base as a collective; releasing to the public gets you all of these people. In return for the good you get from many of them, you get some problems from many others. That's life.
    – Aaronaught
    Apr 18, 2011 at 18:36
  • 1
    @Aaronaught: If we're going to generalize, we need to make sure we're generalizing appropriately. I'm not trying to restrict the conversation to the worst users, just pointing out that they are there. Much of the conversation seems to assume that all users are contributors in a way, and that's just plain not true. If we're going to talk only about the users that are useful to the project, it only seems fair to talk about only the project team members who are generally polite.
    – David Thornley
    Apr 18, 2011 at 20:20
  • 2
    @David: Clearly there are some users and outside contributors who help, and also some who cause problems. Clearly there are some developers who are polite and professional to the extent that common sense and good time management skills allow, and there are also some developers who are rude and unprofessional out of habit. This was a question about how to deal with the latter group of developers. The existence of "problem users" is not in dispute, but it is a red herring which serves no purpose other than to derail the discussion by creating an adversarial situation - so let's leave it alone.
    – Aaronaught
    Apr 18, 2011 at 20:31
1

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.

Improve this answer
0

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.

Improve this answer
2
  • Alternatively, the developer has enough feature requests to keep him busy through the rest of the century, would like to include yours, but doesn't foresee getting to it any time soon.
    – David Thornley
    Apr 19, 2011 at 17:14
  • @David Thornley - That too.
    – Rook
    Apr 19, 2011 at 18:34
0

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.

Improve this answer
1
  • 2
    The right to contribute, yes, but last time I read the GPL it didn't mention anything about the responsibility for end users to make their own contributions. That's a little far-fetched, don't you think?
    – Aaronaught
    Apr 16, 2011 at 17:25
0

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.

Improve this answer
3
  • 1
    I don't think any developer should answer "submit a patch" regarding a request that doesn't fit the project's aim. That's more dishonest than rude. Either the software becomes bloated and the developer hates you for it, or he doesn't accept the patch and effectively wastes your time. The latter is more likely. The developer really should honestly say "We don't want to change this because ____" and be done with it.
    – Rei Miyasaka
    Apr 16, 2011 at 8:35
  • @Rei Miyasaka: Personally, I'd be furious if I received "submit a patch", did the work to make a good-quality patch, and was then told they didn't want the feature anyway.
    – David Thornley
    Apr 18, 2011 at 16:00
  • @David Yeah eh? I'd throw a chair or two.
    – Rei Miyasaka
    Apr 19, 2011 at 0:57
0

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

Improve this answer
2
  • I don't think anyone would choose to ask this question if they knew that the change would be a huge pain in the ass only used by one person. So instead of "submit a patch", why not politely and briefly explain why it is such a big deal and can't be done immediately.
    – Mr. Shickadance
    Apr 18, 2011 at 12:15
  • 2
    "Submit a patch" makes a really lousy brushoff, since it's possible that somebody will submit a patch. It should be reserved for low-priority nice-to-haves.
    – David Thornley
    Apr 18, 2011 at 16:13
-1

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

Improve this answer
-1

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.

Improve this answer
-1

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.

Improve this answer
-2

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.