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

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

15

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 WheelerApr 15 '11 at 22:43

56

I suppose "What do I look like, an unemployed code monkey? I have a life!" is not an acceptable retort ;-)
–
Steven A. LoweApr 15 '11 at 22:51

11

In my experience, the "submit a patch" answer usually comes after the developer has already explained why adding the feature would not be practical.
–
user16764Apr 15 '11 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.
–
user1249Apr 16 '11 at 6:39

10

@orokusaki: Or D) They consider the feature less valuable than other features they could be working on, and they have limited resources.
–
David ThornleyApr 18 '11 at 14:50

29 Answers
29

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.

This sounds like it was written by someone with no experience maintaining an open source project.
–
Rein HenrichsApr 16 '11 at 0:08

41

@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 HarveyApr 16 '11 at 0:27

15

@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 HarveyApr 16 '11 at 1:47

8

@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 GrimmApr 16 '11 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 HenrichsApr 16 '11 at 7:40

Or better yet, to say, "I already did six months ago. When are you guys gonna get around to reviewing and committing it?"
–
Bob MurphyApr 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?
–
user8Apr 18 '11 at 8:08

14

-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.
–
JohnL4Jun 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 PlaiceDec 14 '12 at 1:48

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

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.
–
AaronaughtApr 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 PApr 17 '11 at 3: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 PApr 17 '11 at 3:34

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 PApr 17 '11 at 17:06

4

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 PApr 17 '11 at 17:11

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.

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 HenrichsApr 16 '11 at 0:10

3

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.
–
HedgeMageApr 16 '11 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.
–
ProdigySimApr 16 '11 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 HenrichsApr 16 '11 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 HenrichsApr 16 '11 at 17:39

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.

"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.
–
AaronaughtApr 16 '11 at 17:23

11

@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 CApr 17 '11 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 CApr 17 '11 at 15:11

8

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.
–
ProdigySimApr 17 '11 at 17:00

7

@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 ThornleyApr 18 '11 at 16:23

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

@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.
–
user1249Apr 16 '11 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 HenrichsApr 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, rubini.us/doc/en/contributing
–
Rein HenrichsApr 16 '11 at 18:55

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.
–
AaronaughtApr 16 '11 at 17:33

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.

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:

All users of the program are programmers or all bug reporters are programmers.

All programmers know the language the program is in.

All programmers know about every kind of problem a program of any kind might have.

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.

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.

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.

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 ThornleyApr 18 '11 at 16:06

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.

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?
–
AaronaughtApr 16 '11 at 17:25

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.

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 MiyasakaApr 16 '11 at 8:35

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

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.

@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 ThornleyApr 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.
–
AaronaughtApr 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 ThornleyApr 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.
–
AaronaughtApr 18 '11 at 20:31

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.

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.

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.

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

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.