Since we run Linux, we deal with a lot of Open Source code. Doesn't seem to matter where it comes from, there is a common thread: the documentation sucks. The UI often sucks as well, though that's a bit less of a given than the documentation.
We attribute this to the fact that Open Source projects tend to attract more programmers than anything else, and programmers are very often not good at thinking in the way newbies think. So they write documentation and UI that are only useful to someone who already knows how to use the program. They don't do it intentionally; in fact they quite often try very hard to write good docs, but it usually doesn't work out.
This has been the case for OpenACS too; although we have a decent install doc, there is very little else. And we see complaints all the time from new users about the lack of docs and the impenetrable UI.
My point? This is what happens when programmers design for programmers. It hasn't been fatal for OpenACS because our users are mostly programmers too, just as the users of qmail and the other tools Mike complains about being poorly documented are other sys admins who are ultimately able to figure it out. But it *would* be fatal for dotLRN, which is an *application* rather than a toolkit.
IMHO that's why user representation, participating and funding are so important. We need to make sure that the proper importance is placed on the things users need, not just on the things programmers need.
