I actually like writing documentation, even if I'm not great at it yet, but I struggle to be able to do this well for other people's software. I feel that project documentation, to be done well, has to be part of the project itself.<p>Half the time I start writing documentation for a feature I've built myself, I go back and rework the design based on what I learned from trying to document it. It's rather enlightening to write "Here's how to do this thing that you'll do 100 times a day...", and then discover to your horror that it takes 14 steps. Oops.<p>And when you try to document the <i>why</i> and <i>how</i> of most open-source projects, it very often comes down to "historical accident" and "it's like some other ancient system you've probably never used either". There's a lot of features where I'd just write "This next dialog box is useless, so just hit return", or "This thing you have to type is completely nuts, so just memorize this nonsense".<p>I believe that's why third-party documentation (O'Reilly books, The Missing Manual series, etc) is so successful. It's a lot easier to write (tactfully) "This is dumb, so here's how you get past it", than to go back and fix the feature. And nobody wants to write documentation about their own software that says "Yeah, I know this thing you have to do here is dumb, but hey, it's only a 1.0 so please don't hurt me."