Read what I wrote again. Nowhere in there is any request for any kind of deadline; the only thing even approximating any kind of time constraint is the last - where I explicitly use "not even a hint" as a scale. Even something as vague as "three or four months, maybe", or "early next year" would be sufficient.
but too many sites make it too much of a PITA:
The closest thing to a "Fedora manual" that I have seen is a 900+ page book
True. But A) the user doesn't need to read the whole book to use the index to find references to X, and B) that doesn't apply to a half-dozen people working on SuperHandyUtility in their spare time.
If only that were still feasible; I would love such a solution, but the volume has grown too large in recent years.
Again, much of what you write is most appropriate for large projects, like an entire OS. My comments are directed toward those that are simply writing a single application. As for users reporting bugs, anything of the "my mouse stopped" without amplifying information goes to the bitbucket. Be nice and tell them that without more info (application, what they were doing, the usual suspects), nothing you can do. But don't make them register with Bugzilla and go through all the rigmarole to report (for example) that a dialog button is mostly covered by the label next to it.
We almost always do,
Again, true enough for a distro. But I recently had some questions about an active application; when I emailed the author, what I got back was "Oh, somebody else has taken that over; I don't have anything to do with it any more", with no mention of who had picked it up or how they could be reached. Website was as old as the negligible documentation (i.e. about 3 major revs behind, which is ANOTHER peeve...).
Why restrict this to Linux? The problem of different toolkits that do not integrate well with the OS is pretty universal.
I'm sorry to say that I was a Windows user from 2.0 until shortly after XP released, and while there were indeed some butt-ugly apps written with other toolkits, they still ran. I've had several cases where source code wouldn't compile because of hard-coded dependencies on a specific (obscure!) Gnome library (I use KDE). The author? "Oh, well, I don't use KDE, so I didn't bother testing it. Maybe someone else has ported it over...".
It doesn't take but one or two of the above experiences with an application for someone to say it isn't worth the bother, or that open source isn't any good.
One of the reasons I avoid all this open source stuff is that most of it is badly documented
IRC channels, wikis, blogs, mailing lists (and their archives), a set of web pages... none of these is a valid substitute for actual documentation that a user can actually find an answer in. Fine, if you feel the need to be high-tech, edgy, l33t, or whatever, make it a pdf or downloadable html pages. Do not force users to have to jump through any 'extra' hoops to try and get help with a problem they may be having. I'd also add:
10 to the 12th power microphones = 1 Megaphone