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
THIS
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:
from when I was down there (USN) in 1976 -- folks were pretty much left to act like adults and be responsible for themselves. Now the whole country seems more farked up than the U.S., or even Britain!
Maybe they should start referring to him as Kim Jong Conroy?
So much for the concepts of "Freedom" and "Democracy" for Oz...
I've been running Linux for over 5 years, and have never had to do anything like that to get a USB drive to work.
Sure, there's some hardware that won't work under Linux because of drivers -- usually cheap-ass crap that people shouldn't be buying in the first place. Then again, my Linux system does recognise the vast majority of hardware, and doesn't need separate drivers for any of it. Hell, the first thing I do when I buy hardware for my system is throw away the Windows drivers disk(s) that came with it, along with whatever suck-ass "free" program they had to toss in to try and convince me to buy it. On top of that, I don't have to reboot eleventy-seven times while installing said drivers.
Say "twenty-three-skiddoo" to logout.
