Build applications, not infrastructure
First, some definitions. An application is what the user does: send email, chat with friends, share files, drive to work. Infrastructure is what the application uses to get its job done: HTTP, SMTP, SSL, Windows, Linux, the Internet, roads. This post talks primarily about the context of software, because that's what I do, but I think that this applies in all areas of life.
Infrastructure almost never precedes the applications that use it. P2P in its present popular form did not exist until Napster and Gnutella were created to share files. Blogs preceded RSS. The web didn't exist until Tim Berners-Lee needed a better way to share scientific information with his colleagues. Even the Internet itself didn't exist until the military needed a nuke-proof way to share information. (It would have been created anyway, but that's another post.) Power companies were originally light companies.
The same piece of software can be both an application and infrastructure. Apache is an excellent example of this. Apache is really Linux's "killer app." It runs on Windows and BSD, but the main point is that it doesn't require Windows, and many machines are built for the sole purpose of running Apache. Apache is an application when I am setting up a web server, but it's infrastructure for you when you're looking at my blog.
Guerrilla.net is an example of a failed infrastructure project. It never got off the ground because there weren't any applications that required it, thus giving people an incentive to work on the project and deploy it. Censorship-proofness isn't an application. Distributing copies of DeCSS is an application, but that's still possible and quite easy by simply sharing links to mirrors in private forums. Other examples include just about every alternative OS ever made, such as the GNU HURD and TUNES. Linux succeeded because of Apache and the GNU applications.
Technoptimists like myself tend to get caught up building infrastructure, and it almost always turns out to be a waste of time. The most successful projects are ones with an existing application and whose additional infrastructure requirements are very simple. For example, Jabber's initial application was chat. Chat programs already existed, but people were becoming frustrated with the attempts by the various chat vendors (AOL, Yahoo, MSN) to corner the chat market by limiting interoperability. Jabber's protocol (its infrastructure) started out very simple and has stayed relatively simple. Now that Jabber is deployed, other applications are being deployed on top of it. Of course, with the chat vendors making noise about interoperability, it's time for a new killer app for Jabber, because Jabber will die very quickly if it's no longer needed for chat.