219

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

gnat
  • 21,442
  • 29
  • 112
  • 288
Vincent Scheib
  • 381
  • 2
  • 4
  • 6
  • 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 '11 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 '11 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 '11 at 22:54
  • 1
    While I've heard this phrase in response to feature requests before, it's never come from anyone I would consider a "developer" for the project. Usually this phrase is used by the part-time patch contributors who sit on IRC or forums. If you find this phrase being used on an official bugtracker, I'd be astounded. – ProdigySim Apr 16 '11 at 06:07
  • 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. –  Apr 16 '11 at 06:39
  • @user16764 -- I'm not sure any dev would suggest submitting a patch for an impractical feature unless he were indecisive. – Rei Miyasaka Apr 16 '11 at 08:30
  • 7
    "I am not a programmer, I have a life"? (P.S. Actually, I am a programmer, and have no life - but also little tolerance for arrogant programmers.) – Evan Apr 16 '11 at 10:57
  • 3
    @Rei: absolutely. If the feature is just an awful idea, the correct suggestion is "fork the project with all the bad features you want"; why would the patch be accepted if the feature's not worth adding? – Wooble Apr 16 '11 at 14:34
  • 7
    When a programmer says, "Submit a patch" it always means one of three things: A) They're too lazy to code it themselves even when they may like the idea, B) They don't understand what you mean and are too lazy to try (or are apathetic about learning), or C) The feature doesn't benefit them directly and don't care to help others unless it also benefits them. – orokusaki Apr 16 '11 at 22:17
  • 1
    @user16764 not so. Usually it's the first and only answer you get. Or if you get another one it's "donate a few thousand dollars and we'll maybe look into it". – jwenting Apr 17 '11 at 14:45
  • 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 '11 at 14:50
  • It seems patches aren't welcome to this question! – Andrew Grimm Apr 19 '11 at 05:22
  • @David - that falls into category C. – orokusaki Apr 22 '11 at 01:12
  • 3
    @orokusaki: No, C as you put it concentrates on value to them. D allows for the development team wanting to help others, but not considering the requested change important enough overall. Frankly, the concept of assuming that people who are doing things to benefit the community are lazy, apathetic, or selfish on the basis of one comment disturbs me. – David Thornley Apr 22 '11 at 02:13
  • Time is the currency of OSS. Don't expect much unless you have something of value to offer. Detailed and well thought out suggestions have worth whereas complaints and empty demands are counterproductive (ie worse than worthless). – Evan Plaice Dec 14 '12 at 01:44
  • @StevenA.Lowe If you reply that you're not an unemployed code money, be prepared to hear "neither am I. Closing the issue." back. You've just told the developer that even though they've *built a product for you to use for free, out of the kindness of their heart*, you think their time is worthless but yours has value. Why would anyone do free work for someone with that attitude? – BobMcGee Mar 08 '16 at 14:18
  • @BobMcGee: bear in mind the OP asked for a witty response, not a serious response. – Steven A. Lowe Mar 10 '16 at 21:03

29 Answers29

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.

Greg Hewgill
  • 10,181
  • 1
  • 46
  • 45
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 9
    This sounds like it was written by someone with no experience maintaining an open source project. – Rein Henrichs Apr 16 '11 at 00: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 '11 at 00:27
  • @Robert I don't know, even then from a question I asked most of the answers boiled down to "I don't give a crap about my end users" http://programmers.stackexchange.com/questions/58805/should-you-put-personal-beliefs-in-your-program Anyway, really good answer, +1 – TheLQ Apr 16 '11 at 01:09
  • 3
    @Robert - Actually, there is a BIG difference. If they are paying customers, they are making a tangible contribution to the project by paying license fees / maintenance fees. Besides, the question is not about fixing bugs, it is about implementing new features. – Stephen C Apr 16 '11 at 01:11
  • 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 '11 at 01:47
  • 2
    @Robert - You said "Maybe that's fine with open source people." Yes. It is fine. They're digging their own grave. So what? The point is, it's a different set of circumstances. Users shouldn't "expect" anything for free (which is what I think we're talking about since you can have commercial open). – Mark Canlas Apr 16 '11 at 01:54
  • 6
    @Mark: Oh, I totally agree with you. Especially when I see questions on StackOverflow with the title, "Is [insert favorite open-source project] dead?" because the author hasn't pushed a change in the last two weeks. But still, I think that if you are touting your open-source project as the greatest thing since sliced bread, you ought to at least have some vested interest in keeping the bread fresh. Nobody says you have to accept every feature request or bug fix that gets tossed your way, but "it's open-source, write it yourself" does seem a bit callous. – Robert Harvey Apr 16 '11 at 01:56
  • 2
    @Rein this sounds like a totally accurate description of submitting patches to a couple apache projects, where the mechanics of getting the patch into the code base were several times longer than writing the fix I wanted to make. – Kevin Peterson Apr 16 '11 at 03:50
  • @Robert In regards to the importance of maintaining customer goodwill, there isn't much difference between FOSS and proprietary products, I agree. In many other regards, however, they are very dissimilar. – Rein Henrichs Apr 16 '11 at 06:49
  • @Kevin you're right, it does sound like a rant by someone who's frustrated with a particular project's behavior or process. – Rein Henrichs Apr 16 '11 at 06:55
  • 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 '11 at 07:14
  • 3
    @Andrew The most obvious difference is that open source projects make their source code available and allow outside contributions. It turns out that this actually has a significant effect on the way the project is maintained. For instance, coordinating the efforts of hundreds of people spread across different continents with different levels of ability and commitment is quite different from coordinating across an internal team that you have considerably more control over. Likewise, the way features are prioritized in an OSS project is very different from a proprietary project. – Rein Henrichs Apr 16 '11 at 07:21
  • @Andrew besides, when someone makes a positive claim without providing basis, they bear the evidentiary burden. If someone says "you're wrong", that is a) not an ad hominem attack and b) does not require basis. It's a challenge statement. – Rein Henrichs Apr 16 '11 at 07:32
  • @Rein: "You're wrong" = (mildly) personal. "That's incorrect" = less personal. Also, what kind of evidentiary support do you expect to show that someone has personal experience? – Andrew Grimm Apr 16 '11 at 07:35
  • The claim I'm talking about is "maintaining an open source project is no different from maintaining any other project." – Rein Henrichs Apr 16 '11 at 07:37
  • 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 '11 at 07:40
  • 3
    My one quibble is that a lot of users do pay for open source software, even free open source software. From donations to bounties, there are a lot of ways users put money into FOSS. Jeff even blogs about it every year and encourages people to donate to projects of their choice. With smaller or more responsive projects you can sometimes get dramatic results from a relatively small payment. Of course, other times not. –  Apr 16 '11 at 09:15
  • 3
    "just stop talking to her" - that's essentially what the person wants from you. That or to actually submit a patch. – Kamil Szot Apr 16 '11 at 10:49
  • 6
    @Rein, the differences you mention are (a) implicit in the definition of open source and thus blindingly obvious, and (b) totally irrelevant to the discussion at hand. You've presented nothing that contradicts the basic idea of having to learn the *conventions* for any software project, be it FOSS or commercial or enterprise, which is what this answer was about. It seems that you've taken one or two statements entirely out of context and responded with the typical anti-social abrasiveness that the OP and many of us in the peanut gallery have come to expect from your ilk. – Aaronaught Apr 16 '11 at 17:13
  • I have to say this has been the most useless comment thread I have ever participated in on SE. – Rein Henrichs Apr 16 '11 at 17:44
  • 3
    Robert makes the claim that "Maintaining an open source project is no different from maintaining any other project." I challenge it. I am then told to say what the differences are, presumably because they are not obvious. I do so. I am then told that the differences are "blindingly obvious". Ok. *I agree*. That's why I didn't mention them until asked. Why don't you tell *Robert*? I also have my "people" and my "ilk" indirectly insulted while being accused of ad hominem. Good game, SE. Good game. – Rein Henrichs Apr 16 '11 at 17:56
  • 2
    @Rein: To me, Robert's comment pretty clearly communicated that FOSS projects are basically the same as commercial/proprietary software projects in the sense that you have to deal with end-user feedback. Since his second (*emphasized*) sentence directly states "*You have customers.*", and the following talks about their feedback. To take it the way that you have, you have to pretend that the entirety of his comment was his first sentence. – Adam Robinson Apr 16 '11 at 18:07
  • @Adam see my follow up where I say basically the same thing. – Rein Henrichs Apr 16 '11 at 18:09
  • 1
    @Rein: Then why are you still defending your previous comments instead of deleting or revising them? – Adam Robinson Apr 16 '11 at 18:41
  • 2
    @Adam because people continue to attack them, apparently without reading the rest of the thread (and in any event they can't be edited past a certain time period after creation). – Rein Henrichs Apr 16 '11 at 18:45
  • 1
    @Rein: They're attacking your previous comments because the sentiment that they express is unwarranted, given your newfound understanding of the original intent of the post you were responding to; you're attacking statements that weren't made. They cannot be edited, but they can be deleted. – Adam Robinson Apr 16 '11 at 18:53
  • As I said before, "I'm fully willing to drop it". It seems that others, including you, are not. – Rein Henrichs Apr 16 '11 at 18:59
  • 1
    @Andrew Grimm: Technically not: An ad hominem attacks the person to weaken the credibility of the argument. (You don't know what you're talking about so you should be ignored). Here, he's using the weakness of the argument to draw conclusions about the person. (Your argument doesn't match my experience, therefore you don't have my experience). It's very easy to use the two in close conjunction, of course, to reinforce each other. – wnoise Apr 17 '11 at 19:46
  • 1
    @All Comments aren't the right place for an extensive discussion. If you want to continue, please take it to chat. Thanks. – Adam Lear Apr 19 '11 at 01:42
  • Even when you have all the tools at hand, are familiar with checking out and modifying code, and generating patches, that is not always enough. I've had several experiences in the past where I was able to track down a particular edge-case bug in some code that affected me. But in a large project, I might not always know about *other* areas of the code that *might* be similarly affected. The primary developers have broader knowledge of the project, and can more easily identify other edge-cases and side effects that a patcher might not be aware of. – Dougal Campbell Apr 25 '11 at 19:10
  • 1
    @Doug, in my experience this is exactly true, but you still have to convince the "core" developers that it's worth their time. "Enlightened" core developers care about their community's needs and can be convinced on such grounds, but (sadly) not all core OSS developers are "enlightened". In the real world, lots of bugs (or feature requests) that affect exactly one person languish in bug tracker limbo forever. Best possible world? No. Realistic? Yes. – Rein Henrichs Apr 29 '11 at 02:18
  • 1
    @Rein, I should have been more clear. The problem with the "submit a patch" response is that even an experienced programmer might be able to identify a bug, but still not be familiar enough with the project in question (due to the size of the codebase, or a language he isn't expert in, etc) to provide a decent patch. For example, I recently came across a bug in the SSH2 PECL extension for PHP. I'm able to write a test case to demonstrate the problem in PHP, but my C skills are too rusty to track down the root problem and patch it (even if I had the time). – Dougal Campbell Apr 29 '11 at 14:01
  • @Dougal (sorry) yep. Full ack. – Rein Henrichs Apr 29 '11 at 14:29
79

The canonical retort is to submit a patch.

wnoise
  • 271
  • 2
  • 7
  • 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 '11 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? –  Apr 18 '11 at 08: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 '11 at 13:39
  • 1
    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 '12 at 01: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.)

Havoc P
  • 918
  • 6
  • 11
  • +1 for checking mailing list archives, etc. If it's a common request, I've definitely seen new users get frustrated when they get the "submit a patch" response because they don't know it's been asked many times before. – Dean Harding Apr 16 '11 at 03:05
  • 1
    There are some good points in here but I think you've created a false dilemma. There are plenty of closed-source developers that will respond *politely* to a bug report or change request explaining that (a) it's in the queue but other features have priority, or (b) it's been rejected due to blah blah blah. That's far less rude than "do it yourself". It sounds like you're referring to the same user *badgering* developers for his/her pet feature, and in that context I could understand some escalation to rudeness, but I think the original question was about DIY being the "default" response. – Aaronaught Apr 16 '11 at 17:17
  • 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 '11 at 03:29
  • 1
    One situation I didn't think of earlier, is the "pie in the sky" "big impractical ideas" mailing list thread. Especially if such a thread consists mostly of people who are not software developers, it can get a grumpy reaction. Some of these threads are just overenthusiastic, but is not uncommon to get plain old crazy people showing up on open source project forums. That's why maintainers end up a little short as they try to triage who's potentially a contributor, who just needs a little help, and who's a black hole of poisonous time wastage :-) – Havoc P Apr 17 '11 at 03:34
  • @Havoc - I think we're all aware that when you try to corner someone, they'll respond with rudeness or even hostility, but no matter how silly a feature request sounds, if there's been no prior discussion or escalation then it's not appropriate to respond that way, and that is what I believe this question is about. You're talking specifically about the situation where a user won't leave you alone, and that's a bit of a special case. – Aaronaught Apr 17 '11 at 16:56
  • 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 '11 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 '11 at 17:11
  • 1
    @Aaronaught, I think a lot of people have trouble separating the behavior of core developers who actually represent the project from self-appointed whiner police who defend the project on user forums and sites like slashdot or reddit. The former very rarely give a rude response without a _lot_ of provocation. – Karl Bielefeldt Apr 18 '11 at 02:25
  • @Havoc: Why not just say "other issues have priority and we don't know when this can be done"? That's clearly what you mean here, and yet "submit a patch" actually doesn't communicate it effectively; it *might* mean "we agree but can't get to it right now" or it might mean "we don't give a sh*t". Any programmer who's willing to submit a patch will do it proactively anyway, it's not necessary to point out that option. – Aaronaught Apr 18 '11 at 02:35
  • @Karl: That's a definite possibility and perhaps that is why some people seem to be taking this question personally. Nevertheless, it is a valid question, asking how to respond to people who respond with "do it yourself" or "use the source, Luke" as a matter of course. Whether those people are core developers or fanboys certainly matters in a broad sense, but isn't pertinent in this specific context. – Aaronaught Apr 18 '11 at 02:38
  • 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 '11 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 '11 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.

Rein Henrichs
  • 13,112
  • 42
  • 66
  • 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 '11 at 00: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 '11 at 02: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 '11 at 06:10
  • @ProdigySim definitely. – Rein Henrichs Apr 16 '11 at 06:46
  • 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 '11 at 06:52
  • If it's just about working on my idea for me, then I have to agree. But if "my idea" becomes "our idea", and if it's not just "for me" but for a lot of current and future users, then having someone who already knows the code work on it might be better than having a new kid on the block submit a patch. – Walter Mitty Apr 16 '11 at 12: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 '11 at 17:39
  • -1 for this answer but +10 for the comments. Time is the currency of Open Source because it's a finite resource. If you're going to make a suggestion, invest some time in refining it. If you want higher priority, draw more users in to request a fix. Be willing to accept a 'no' if your idea doesn't fit into the bigger picture. You're not the only user. – Evan Plaice Dec 14 '12 at 01:53
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.

Stephen C
  • 25,180
  • 6
  • 64
  • 87
  • 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 '11 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 '11 at 03:32
  • @Stephen - No, *you* don't get it. Your post is basically an off-topic rant. If your users are idiots who pepper you with random suggestions, and your response is, "Submit a patch" (Which is, of course, the topic of this entire page.) then you are not only being rude and immature, but your also being deceitful, since you've already made it apparent that you have no interest in the suggested features/bug fixes. – kurige Apr 17 '11 at 07:52
  • 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 '11 at 15:11
  • 2
    Stephen - why is it you believe that the "typical open source developer" somehow has any less time than any other developer, or that his/her time is any more important? If you consider professional courtesy to be ego-stroking then you are simply not any kind of professional and have no business dealing with members of the public in any capacity. – Aaronaught Apr 17 '11 at 16:52
  • 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 '11 at 17:00
  • 1
    @Prodigy: Dealing with change requests is *part* of "development". It is as if I volunteered to drive a school bus, but loudly proclaimed that I shouldn't have to deal with stop signs or speed limits or passengers because I already have a job and all I want to do is drive the darn bus. It doesn't quite work that way. If you're going to provide something, *anything* to the public, then that comes with certain responsibilities; if you can't handle those responsibilities then you should do it as a hobby, not a service. Close up the support channels and label it a personal project. – Aaronaught Apr 17 '11 at 22:54
  • 4
    @Aaronaught: I was simply answering your question of why typical open source developers have less time. Your analogy is horribly flawed and I hope you don't plan on being taken seriously. – ProdigySim Apr 18 '11 at 03:56
  • @Prodigy: It would seem that many developers have trouble taking *any* criticism seriously, but so far you haven't identified what's flawed about the analogy. Developers should either accept the ancillary responsibilities that come with owning a public project, or find another outlet. – Aaronaught Apr 18 '11 at 13:34
  • 5
    @Aaronaught: The roles are different. If I'm being paid to work on a project, I'm doing it for external rewards, and I'm happy to deal with details that only affect one person, say. If I'm working on an F/OS project, I'm doing it for internal rewards, and dealing with annoyances that I'd consider part of the job if paid becomes annoyances that I'm not being paid for, and time not spent on working on my vision. – David Thornley Apr 18 '11 at 15:01
  • 2
    @Stephen C: An alternative would be to try to "sell" your idea, by including a short summary of how this would be beneficial to lots of people. – David Thornley Apr 18 '11 at 15:03
  • @David: That's all very well and good but the responsibilities do not change based on why you're doing it or what you are or aren't happy to deal with. If you are performing what is essentially a public service then you have a responsibility to treat members of the public respectfully - even if the only reason you're doing it is for your own personal satisfaction. I'll reiterate, if you don't want to deal with users, if you're just doing it for fun, then... just... *do it for fun*. Make the project private or create a private fork that doesn't accept change requests. – Aaronaught Apr 18 '11 at 15:32
  • 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 '11 at 16:23
  • 1
    @Aaronaught: Stops signs and speed limits are legal requirements, taking customer feedback is not. In your example, the bus driver volunteers to do something FOR someone. In most open source, developers are devleoping for themselves, and simply making the code public. Driving a bus full of people puts the lives and properties of people at risk, developing open source software does not. Say I want to make a small tool for myself and build on it. I open source the code and release it for free in hopes that other people/devs will find it and help. Why should I not be allowed to do this? – ProdigySim Apr 18 '11 at 17:08
  • @David: The issue of certain users being jerks about it is one that *you* and a few other folks brought up in defense of certain poor answers to this question. It doesn't seem to me that the person who asked the question is that kind of jerk, and nowhere in the question is it stated or implied that the rude remarks are due to equally rude or insulting badgering from users. A few a-hole users is not a valid justification for responding unprofessionally to everyone else. – Aaronaught Apr 18 '11 at 17:34
  • 1
    @Prodigy: If you are "developing for yourself" then why would you make the code public, much less list your contact information as a project maintainer? The only reason to do such a thing is to invite others to either use or collaborate on the project, and in either case, you are implicitly declaring your intent to support it. If you have no plans to support it, then don't use a public repository. A lot of you seem to want to have it both ways; you want the recognition for the project (you claim not to care but your actions suggest otherwise) but none of the responsibilities that implies. – Aaronaught Apr 18 '11 at 17:38
  • 1
    @Aaronaught: I don't agree that publicizing source code or binaries is an agreement to support. I'm pretty sure the licenses for most open source project outright declare that the opposite is true. I also stated in my example that I am releasing a tool that I like to use, in hopes that other people will help improve the tool that I use. It's very self-serving, but it's not illegal or immoral. – ProdigySim Apr 18 '11 at 17:42
  • 1
    @Prodigy: Self-serving indeed. Then why not contribute anonymously instead of putting your name on the project? You can't possibly believe that the fine print in some inscrutable license agreement is a valid excuse. If you don't intend to support the project then perhaps you should put that in the project description so hapless users don't mistake it for the many other free and/or open source projects that actually *are* maintained and have developers that *do* listen. Or better yet, post the code on an anonymous blog somewhere so somebody else who's willing to support it can take ownership. – Aaronaught Apr 18 '11 at 17:51
  • 1
    @Aaronaught: So if I post the code anonymously, *then* I have the right to not produce features people ask for? Why is this distinction important? – ProdigySim Apr 19 '11 at 22:49
  • 3
    @Aaronaught The simple truth is, you're not entitled to an OSS developer's time; no more than you are free to walk this earth without providing something of value. If you can't accept that fact, do all of us Open Source project authors a favor by not using OSS. – Evan Plaice Dec 14 '12 at 02:02
  • @EvanPlaice: You almost seem to be suggesting that an "OSS developer's time" is somehow sacred. Nobody is *entitled* to *anybody* else's time unless a signed contract exists. So what? That doesn't give you any more justification to be a jerk than a doctor or lawyer - both of which are generally more forthcoming than programmers, especially "OSS developers". Just because you *can* tell somebody to do it themselves doesn't make it socially acceptable; it's OK to say "sorry, I don't have time", but "code it yourself" is just beyond the pale, especially when they've put effort into the request. – Aaronaught Dec 14 '12 at 04:25
  • @Aaronaught: "why would you make the code public" -- *in hope of patches*, of course. The OSS developer gives away the code because maybe some people will help him develop it further, period. Sorry to comment five years later, but that point needed to be made. – RemcoGerlich Oct 29 '16 at 20:43
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".

  • 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 '11 at 17:43
  • Well, unless those few have a lot of money, historically speaking. – Rein Henrichs Apr 16 '11 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. –  Apr 16 '11 at 18:22
  • No, it isn't a straw man at all. It's the main way things are prioritized in open source projects. What *one person* wants does not have enough weight if the rest of the community is not interested. If open source maintainers did everything every member of the community wants without regard for the needs of the community as a whole, the project would quickly become a useless mess of unwanted features. You're the one concocting the straw man by suggesting that maintainers are doing what "they" want rather than representing their community. I am one. I know that is not true. – Rein Henrichs Apr 16 '11 at 18:25
  • To put it another way, who whole point is that ONE from the community is requesting it. – Rein Henrichs Apr 16 '11 at 18:30
  • @Rein, your argument does not hold. The reason: "We will accept a patch". –  Apr 16 '11 at 18:30
  • @rein, to be exact - the "it is open source, submit a patch" does not imply that the patch will be accepted. It _does_ however imply that such a patch would be at least _considered_ accepted. –  Apr 16 '11 at 18:34
  • Do know what the outcome is almost every time "submit a patch" is used? No patch. That's why it holds. In fact, in my experience this is said precisely when the expectation is that it will not result in a patch, as what the maintainer thinks is a more polite brush-off than "we're not interested in doing that". For the record, *I don't say it myself*, because I think it is disingenuous, restricts dialogue and is unnecessarily hostile to new users and new ideas. – Rein Henrichs Apr 16 '11 at 18:34
  • I prefer to say "How do you think this feature will improve the project?", although I have to admit that it can be difficult to respond to every request with such equanimity. – Rein Henrichs Apr 16 '11 at 18:36
  • Also, to be pedantic, note that the response given was "please *submit* a patch". ;) – Rein Henrichs Apr 16 '11 at 18:37
  • " It does however imply that such a patch would be at least considered accepted." This is a little bit confusing. Do you mean "considered *for acceptance*"? As in not necessarily accepted? In that case, I agree, but it removes your objection to my argument. – Rein Henrichs Apr 16 '11 at 18:39
  • @Rein, I believe you misunderstood my answer. The "oh, yes..." thing was the expected response to the retort, not the thinking when "submit a patch" was said. –  Apr 16 '11 at 18:41
  • @Rein, 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. Your argument of "useless mess of unwanted features" would then not hold, because they would then be added then. 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. –  Apr 16 '11 at 18:46
  • I must have then, because it certainly sounded like the "oh yes" thing was the thinking of the maintainer, which would itself be a straw man. – Rein Henrichs Apr 16 '11 at 18:48
  • @Rein, the thinking of the maintainer when being explicitly asked to help because the community member cannot do said development on his own. –  Apr 16 '11 at 18:50
  • 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 '11 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, http://rubini.us/doc/en/contributing/ – Rein Henrichs Apr 16 '11 at 18:55
  • Also, from a project I maintained, http://projects.puppetlabs.com/projects/puppet/wiki/Development_Development_Lifecycle – Rein Henrichs Apr 16 '11 at 18:56
16

The canonical retort is to fork the project.

user16764
  • 3,583
  • 1
  • 25
  • 22
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"

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
13

Submit a comprehensive test case.

alecco
  • 101
  • 1
  • 6
  • 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 '11 at 03: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 08 '16 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.

yfeldblum
  • 1,532
  • 10
  • 9
  • 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 '11 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 08 '16 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.

Michael Brown
  • 21,684
  • 3
  • 46
  • 83
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.
John
  • 1,037
  • 7
  • 14
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.

Dean Harding
  • 19,871
  • 3
  • 51
  • 70
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.

Bacon Bits
  • 486
  • 3
  • 4
  • Do you mean "I would rather get a response of" as opposed to "I would rather not get"? – Andrew Grimm Apr 16 '11 at 07: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 '11 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.

Mateen Ulhaq
  • 968
  • 3
  • 11
  • 21
Bertrand Delacretaz
  • 101
  • 2
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.

TheLQ
  • 13,478
  • 7
  • 55
  • 87
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.

Jon Hopkins
  • 22,734
  • 11
  • 90
  • 137
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.

vartec
  • 20,760
  • 1
  • 52
  • 98
  • 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 '11 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.

Vincent Scheib
  • 381
  • 2
  • 4
  • 6
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.

Paul Nathan
  • 8,560
  • 1
  • 33
  • 41
  • 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 '11 at 16:09
  • @David: Both sides do receive something. Clearly the developers have made it open source because they want others to contribute. They are getting those contributions for free. Others who merely use the product are *still* contributing something: They are providing free testing and in many cases free advertising. So I'd say that, yes, there is definitely an implied contract here. Maybe not a legally-binding one, but we're not talking about the law here. – Aaronaught Apr 18 '11 at 17:58
  • 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 '11 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 '11 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 '11 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 '11 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.

jokoon
  • 2,262
  • 3
  • 19
  • 27
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.

Rook
  • 19,861
  • 9
  • 53
  • 96
  • 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 '11 at 17:14
  • @David Thornley - That too. – Rook Apr 19 '11 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.

Apalala
  • 2,283
  • 13
  • 19
  • 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 '11 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.

Alexander Gessler
  • 742
  • 4
  • 11
  • 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 '11 at 08: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 '11 at 16:00
  • @David Yeah eh? I'd throw a chair or two. – Rei Miyasaka Apr 19 '11 at 00: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.

Kevin Peterson
  • 429
  • 2
  • 5
  • 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 '11 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 '11 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

Community
  • 1
Lincity
  • 101
  • 2
-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.

CyberFonic
  • 161
  • 3
-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.

Renji Panicker
  • 1
-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.

Rei Miyasaka
  • 4,541
  • 1
  • 32
  • 36