I think, initially, the focus should be on the simple client/server modular brute forcers.
I see the benefits of a distributed model, but I think we should focus on something more directly useful first. As neinbrucke pointed out, there are a lot of people who would prefer (actually, require) that the hashes they are testing not leave their immediate control. A distributed model would be useless for them. Most security professionals who are testing a company's passwords for security can't let those hashes go roaming around the internet.
Once the server and clients are written, it would not be difficult to write a more advanced server that implemented a distributed system. The clients can directly communicate to this server which handles all the distribution.
Also, as long as the API involves enough fields to handle authentication, this can be used for a internet-wide cracking system. Again, either directly connect the clients to the server or, more likely, write a small server daemon that proxies requests for the central server.
I think the client-server model gives us the most flexibility, without the need to rewrite/recode things. The clients will remain useful, and the servers can be easily modified as they aren't doing any actual heavy lifting. The servers could also be written in something easier to handle strings with - PHP, Python, etc would be perfectly suitable languages for servers.
I'll work on getting a developer environment set up with a wiki & ticket/roadmap tracking.