What's the canonical retort to “it's open source, submit a patch”?
programmers.stackexchange.com
programmers.stackexchange.com
Apparently, some people think "I have added your request to the end of our infinite backlog of requests" is a more productive response. "Submit a patch" not only conveys the same info, it also provides concrete advice on how you can jump the queue.
If somebody cluelessly expresses urgency and wants it fixed now, it's perfectly ok to say "if you need it soon you should consider paying someone for it". But I find "submit a patch" often used when people disagree with your suggestion but can't articulate why.
For the record, I will not say "submit a patch" for a bad idea, I will say "that's a bad idea". Not that people like hearing that, either.
But on the other side of the coin, I've never turned down anyone's request for a commit bit.
Many people think it's rude to ask someone who wants work done to do the work themselves.
I think it's rude to expect other people who've got you 90% of what you want to just drop what they're doing and give you the remaining 10%.
The answer is likely somewhere between, but (and I'm biased), I'd tend to think that those who brought a body of work forward should have a little more leeway in responding to the demands of those taking advantage of it.
"Here's a ladder. Take as many as you like."
"How rude."
A non-programmer can usually shed this condition with effort, or at the very least exchange laziness for money.
"If you don't have the time or inclination to do so... do you have any friends with talent who need money?"
Keep in mind that as a user of an open source project, you are already getting the whole thing for free. Asking for more is what's rude; being told, "sure, we'll add that when you write it" is a very polite invitation to invest in the software that you apparently rely on. Remember, everything that already works was once a patch.
If you don't know how to program, sure, submit a bug, but don't hold your breath. Pay someone to fix the bug or implement the feature you want: there are plenty of contracting companies that do this, and like anything in the world, you get what you pay for.
Finally, what is a retort going to get you, even if you come up with a good one? You got some software for free, and now you want people that don't care about you in any way (you aren't their friend, you aren't giving them money, etc.) to give you some more stuff. They say no. You respond with a witty retort. Where are you now? The same place you were a few hours ago.
Yes, by the people who matter: The ones with resources and the willingness to spend those resources on solutions to their problems.
Other people won't receive it so well. These people are neither your customers nor your teammates. The sooner you figure this out, the better. Decline their requests politely, suggest some alternatives if you can, and move on.
We've all heard the horror stories of bad clients. Constantly changing feature requests, never-ending requests for support. I'm reluctant to add to that pool. People who hire programmers should know what they want. Posting to a forum isn't knowing what you want.
Heck, I'm a programmer and just the prospect of saying I'll pay you to do x triggers stress hormones in my body.
I can readily see the concept of "I wrote this code, somebody else might find it useful, so I'll make it available, but I don't want to bother with doing anything else with it." If an author wants to write my feature, cool, but I just don't see any problem in 'submit a patch' answers. To me it's a the distilled essence of "I already spent all the time I want to on this thing, I gave you a gift, I don't owe you anything, if you value this feature you're welcome to do it but I don't value this feature and am not interested in working for free." - but it saves all the arguments that would come up if you actually gave that answer, as people with time on their hands would take every point and try to pick it apart and take up more time arguing. By explaining reasons, you're just handing out ammo to fire back at you. Saying no without leaving the no open to argument is the only way to limit demands on time.
For many of my projects, my answer would be worse in their eyes: Fork it and do what you like. I have no intention of adding bloat to this project.
That's far more rude, but totally truthful. I created that project for a purpose, and I was nice enough to BSD license it so others could do -anything- they want with it. Asking me to change it to your liking is going too far.
Of course, that assumes I don't want the feature. If I do like it, then I'll happily add it to my backlog and then ignore it until I feel like working on it.
Want that strange little T1 card to work in asterisk? Give them one and watch the magic. Its way cheaper than hiring someone to code it for you.
I'd like to imagine that the community surrounding the open source project is a perfect place to start looking for someone to hire to build it out from 90% of what you need to 100%.
So I can see why there is this attitude when those getting a free ride on the software also want it developed to their needs for free. Especially when the feature is very specific and isn't something any of the contributors to the project need.
As an aside: I hate it when people say they can't program out of hand without actually really giving it a go, we all started somewhere.
You've created something you think is worthwhile and given it to the world. Hopefully, one factor involved is that you would enjoy even a little appreciation.
If you say "these are my resources and this is my plan for further development, I would certain appreciate any resources that one might contribute to extend this", you might, just get a nicer response back than if say to the user " don't like it? There's nothing I'm going to do to change that".
I imagine people saying this are usually at the end of their tether fending off suggestions and feature requests. The best response in those situations is to say nothing, and to take a break. If the guy that finally did it for you just submitted an innocent suggestion, there's no sense in snapping at him.
Either that, or do it yourself (and submit a patch).
For the record, I have written a couple patches and released open source code before. I say this after years of trying to convince all my friends to switch to Linux, and finally coming to terms with the fact that even I still have to keep a Windows boot for certain occasions.
Would you consider paying up to what [insert (possibly proprietary) alternative] costs for someone to write the patch for you? Would you consider gathering more people so you can fund your patch?
For the latter, probably not. Assuming that for whatever reason I cannot write the patch myself, I do not have the time to start a new organization every time I encounter a new bug in some project. And I would guess that most ordinary consumers don't either.
This is not supposed to be a necessarily snarky response. Sometimes, an open source project exists, and it's not for everyone. The people behind the project should realize that every feature they choose not to include cause the software's value proposition to cease to exist for some users. It is up to them what to prioritize, and up to me whether using their software is worth the time of getting a patch committed.
Of course, my operating assumption here is that they want to hear about bugs/feature requests, and so it is worth something to them that I would bring it up in the 1st place. But I rarely ever make new feature requests. Usually this is in response to an evangelist telling me that I should switch to their platform, and my responding that it does not replace a current proprietary solution.