(2) is what we have been mostly doing for the last couple of years, but our Java6+GWT+Ant+Subversion (only recently switched to git) stack was failing to attract new developers. There were several calls to rewrite the entire thing in (say) javascript.

However, they are exceedingly terrible at making consumer products. There's a lot of branding, marketing and design that goes into a successful consumer product. This is especially true for a product with network effects. Open source projects are bad at this for several reasons:

* People with these skills are simply not as likely to be involved in open source projects. * Developers will create features that they want. This is great, but what a particular developer wants is not necessarily what is best for the project. * Any one attempt at a consumer product will likely fail. The work you could have put into a protocol that would have made hundreds of consumer products easy to build has now been sunk into one, which may or may not succeed.

Also, specific implementations will become dated very quickly. Your stack sounds horrifying in this day and age. With server modules in a few different languages, and a minimal clientside library, there would have been hundreds of Wave variants at this point.

Just for curiosity's sake, let's say I wanted to write a REALLY bare-bones Wave client. Like, maybe just doing text-only waves, maybe not even real time. How hard would that be?

A client written for emacs in emacs lisp. I haven't looked at it in detail and it doesn't look like it's been touched in a while, but it may be a good place to start. I don't know if this was the same client, but during the initial Google I/O demo they had an example that I believe was using emacs. Timeline would fit with both when this was made and who made it.

And GWT is fine, I love GWT, but the current codebase has the current client and sever tied together you cant work on one without the other! They badly need to separate them out, establishing a protocol in the process.