I think a paycheck is the only way for most projects.
Open source developers are scratching an itch. What itch would a UI or documentation person be scratching? The project would only be relevant if it's a user-facing app that they themselves use.
Well, you can also encourage contributors to document their work. With Django, for example, our policy is that a submitted patch will not be committed unless it includes both unit tests and documentation in addition to the code.
This means it can take longer for a patch to be accepted, but it also means that the documentation stays up-to-date.
Absolutely. I think this is the real answer. Developers need to learn to document and improve their UI skills. To me those are core skills of a developer. We can't expect professionals in those areas to come in and rescue open source.
Seriously, I don't know too many people whose idea of "scratching an itch" is writing documentation. There aren't a lot of documentation-hobbyists out there, as far as I know...
I've found the feeding infants a mixture of milk mixed with 25% pulverized IRS forms and 10% pulverized army field manuals, results in a 65% chance that by age 8, they will be obsessed with writing documentation.
By next year, we'll have an army of 1,000,000 tech writers ready to serve the emperor and rebuild the empire, errr, or at least document it's rebuilding.
Money. Not a ton, but it's a very time-consuming job.
I do like writing documentation, and I'm pretty good at it. Unfortunately it's a thankless task, and criticizing or feeding back to developers about shortcomings often engenders a frosty reply, so I rarely do it any more. Add in the fact that for simpler software, good UI design often makes documentation redundant, are you have to deal with the fact that the things most in need of good documentation fall into two classes:
a) domains of expertise where the documentation needs to be as much an introduction to the task for which the software is used as how to use it. Example: Adobe sells a great, great piece of audio editing software called Audition. It has been my favorite for over a decade. The manual is...well, generic. Before they bought the product, it was called CoolEdit, and it had one of the best manuals I've ever read: written by the main author of the project, it was as much an introduction to signal processing and audio engineering as a guide to using the program, since the utility of many fine features is not apparent to the novice user. Inexplicably when Adobe took over the project they ditched this - perhaps preferring to rely on third party publishers or their own publishing imprint (which is quite good). Some of the best documentation, like the above, gives the sense of having been written before the code, rather than afterwards when the programmer is burnt out.
b) legacy systems which may completely suck but which we are stuck with. Unfortunately, project managers tend not to look kindly on documentation that starts by acknowledging the software in question is poorly designed, confusing, or contains bugs which may never be fixed. They want documentation that tells yo how things are supposed to work, not documentation that goes into detail about what happens when it fails and how to deal with it (although this is the time when the end user is most in need of quality information).
There's one other problem, that of social exclusion. It's assumed by certain kinds of programmers and administrators that the code or tools must be accepted much as they are, and if one finds the system opaque or perplexing that that is part of the price one pays to develop expertise in it.
Many years ago, when I first installed Linux, I ended up at a shell prompt armed only with the knowledge of cd and ls. Typing 'help' yielded only a polite error. It took me quite a while to discover the 'man' (manual) command, and when I did I was less than impressed with much of the documentation. As mentioned above, many man pages devote no time whatsoever to explaining why you might want to use something. This is a kind of an artificial example, but one that encapsulates the seemingly arbitrary and unfriendly experience of computing for many people.
Reference materials usually do not perform very well as tutorial materials, and yet they are likely to be the first thing the typical user encounters. I made fun of Microsoft's Clippy character along with everyone else, but for the general user who just wanted to use the computer rather than understand it, it was actually a godsend.
