Johndan points out that Brent Simmons lessons on writing feature requests and bug reports are useful, "fairly generalizable" rhetorical strategies.
One additional observation I'd like to make concerns feature requests, support requests, and bug reports for open source software. In my experience with offering support on drupal.org, so often people get the writer/reader part of the rhetorical triangle wrong when posting to open source project communities. They frequently assume the consumer position in a client/customer dynamic in their posts, often demanding assistance and venting their lack of customer satisfaction frustration at the community.
Undoubtedly, it's a misunderstanding about how open source communities work--that and the fact that such people are drawing on their consumer experience, the most relevant rhetorical situation they have. Open source projects function as communities of collaborators. Everyone who participates is a volunteer working to satisfy their particular interests or needs, and sometimes this involves helping others. But there is never a guarantee that help will be forthcoming. It's one of the tradeoffs of getting software for free.
So for anyone seeking support from an open source community, keep in mind that you are typically dealing with a non-profit style organization of volunteers who are giving away free product and services, not a company who owes you a guarantee. Sometimes the service is available; sometimes not. If that's not the level of service which you need, consider hiring an open source consultant from the project.
opensource rhetorical situation
Right on, Charlie:
In my futile (so far) attempts to persuade my employer to let Drupal in, I often hear terms like "vendor", "centralized support", and "quality control." I guess from the institutional point of view, it makes sense (no one wants extra headaches), but this is the same discourse people are used to when talking about, say, Blackboard, which provides (or tries to provide) all those things.
pz
when to users donate?
I'd blogged about this article over at FSF, but it looks relevant here, too. It's the issue explored from the developer's perspective. How can devs balance their desire for income with their desire to keep users' trust in their product?
For my part, I never found the "It's free, so shut up!" argument very effective. It seems like a pretty lame excuse--and ultimately self-deating for FOSS. It's always tempting for a FOSS developer to get into the "beggars can't be choosers" mindset, but users of FOSS software aren't bums. Just because a program is zero-cost doesn't mean we should overlook its faults or "be nice" when things go horribly wrong.
In short, if FOSS can't hang with the big dogs, it needs to get off the porch.
about freeware and attitudes
The article's about freeware and thus, IMHO, doesn't directly apply well to open source. Open source community projects are exactly that--open source communities. The project prospers when the community works well together and can accelerate in development when more contributors join the project or existing contributors are able to do more. Freeware isn't about commons-based peer production.
Still, you are right. The "it's free, so shut up" argument is not very effective and does more harm then good. It is not productive. But, as pointed out above, neither is the customer/client relationship which newbies sometimes expect in their first experience with open source. Venting "when things go horribly wrong" doesn't accomplish anything positive, either. It will often get you less help than a more friendly approach would.
Freeware
Charlie, I think the expression is "RTFA!" :-P
Anyway, I did RTFA, and I agree--freeware is distinct from FOSS in many ways. For one thing, if freeware was FOSS, then one developer wouldn't be solely responsible for addressing that "firehose" of bug and feature requests. By the Great Twinkie, man. :-)
That said, I can see much of what he suggests applying to my students. When they have a tech difficulty and try to report it, it's almost always hopelessly vague and mean. "I can't get this stupid website to let up upload my paper what can I do!!!" or some such nonsense. I waste considerable oxygen in class telling them that they'll have to provide more context for me to help them, but they never do. I'm convinced that the only people who know to provide context are those who have actually seen this problem from the other side. Then it becomes a "Ooooohhh, that's why" epiphany.
are we talking about the same article? & feature requests
The link I followed is about making a case for micropayment donations. I see some indirect connections, but not sure what you are looking for since working with FOSS communities is a little different than this proprietary freeware developer example. Still, one interesting connection might be reverse bounties.
Or maybe it's because we have a different conception of how FOSS communities work. For instance, when you state that "one developer wouldn't be solely responsible for addressing that 'firehose' of bug and feature requests" you seem to be implying that a FOSS community has an obligation to respond to all bug and feature requests. Feature requests, IMHO, are more about sharing ideas for development, and they don't have to be addressed. The perspective is one that newbies have a problem with as a result of the term "feature request." Most newbies treat it more as "Here's what I want."
The problem with that approach is that it does not recognize the collaborative potential of feature requests as an invention and feedback tool. The "Here's what I want" approach is not about improving the software as much as it is about satisfying a specific person's needs; it's a client/customer based perspective again. The better approach is to view feature requests as a collaborative method. I post feature requests, and have been encouraged to post feature requests by developers, as a way for them to review ideas when they do get around to revising a module to see what supports their goals for working on the module and improving the software. With this in mind, I sometimes post feature requests for things that I could care less about for me to use.