There are four types of documents I find necessary for any project: (1) Requirements Documentation, (2) Design Documentation, (3) User Guide, (4) Program Documentation. I think UML is a great way to organize the first two, the third needs lots of pictures, and (since I mainly use Perl) a combination of comments and POD (plain old documentation) is best for the fourth.
You should "design" the problem domain. This means carefully documenting the problem you intend to solve in a requirements document. Even for (especially for?) open source projects it's critical to communicate the purpose of the system. The audience for the requirements documentation includes other programmers and problem solvers.
You should "design" the solution domain. This means carefully documenting your solution to the requirements. Even for (especially for?) open source projects it is critical to communicate the architecture and design solutions of the system. The audience for the design documentation includes other programmers and problem solvers.
I completely agree that the user manual is critical. But, how many of you have bought a "Netscape for Dummies" book? (Not most, I imagine). How many have spent much time looking at a user guide for any web browser? Sometimes complex functions can be so well hidden behind intuitive interfaces that the need for a user guide is minimized. I believe the importance of the user guide depends on the problem and the system implementation. Sometimes it's more important than others.
I love literate programming. Using the plain old documentation (POD) features of Perl, I can put the code and program documentation in the same place: run the code, publish the documentation. I believe program documentation is especially important to the open source community. Our goal should be to share our knowledge before we prove our cleverness. Just like any language, learning to program involves reading and writing. I consider learning from other people's code more important than writing my own. I enjoy reading well documented code. Sometimes I avoid reading clever, puzzling, undocumented code.