I think the most important thing we can do in the open source world (far more important than releasing new cool software) is to improve the quality of the documentation of existing software. Software without documentation is pretty much useless. Software with bad documentation is slightly better than useless, but still nearing uselessness. Software with some good documentation but which has incomplete documentation is better than useless, but only for some period of time: you can't keep telling yourself "I'll do it later" or outsource the job of documentation to some mythical "community": it's a chicken and egg scenario. Writing documentation is part of your job description as a programmer.

As the general quality of software improves due to widespread use of good software engineering techniques such as unit and integration testing, documentation quality is becoming the differentiator between project success and failure.

The most valuable descriptions of highly technical things:

• get to the point quickly without endless theory or architectural navel-gazing.
• start with an example.
• are written in an informal style.
• aren't optimized for brevity, nor are they optimized for testability; instead they are optimized for readability and imparting knowledge.
• can be read more than once; the first time you read one, you may gain different knowledge from it than the fifth time, but you still gain knowledge.
• aren't thrown over the wall as an afterthought, never to be consulted or changed again, they evolve over time as the software evolves.
• are complete
• are written using proper spelling and grammar

Here are some examples:

• The XML-RPC Specification
• AMK's Regex Howto
• Sphinx Documentation
• The Django Book
• Unix Power Tools

If you can create documentation of this quality or better, your project has no chance but to succeed on some level, even if your code is terrible.

Note also that I think that a choice between good docs and better software is a false choice. The act of continually writing documentation always makes software better, because if it's hard to explain, it's probably not very good. Complexity becomes clear very quickly when you need to explain it away; it's usually easier to change the software to be less complex than it is to document something complex. It's frighteningly easy to write undocumentable software.