You are correct that we have been incubating since 2010 - the community around it has changed quite a lot since then though...
There is no roadmap, as we do not (yet) have a large enough consistent amount of developer power to benefit from one. Most of the patches we receive are fixes/improvements that benefit the submitter (e.g. full text search, monogodb backend, etc.)
I agree, prior discussions on the mailing list have been unable to resolve this though. There are two directions in which to progress:
1) Convert the project to be primarily about the federation protocol (which was the original direction of FedOne), with the existing client being a 'demonstration' implementation of the protocol. This sets our market to be other developers.
2) Be client specific, extend the existing client, add mobile support etc. Setting our market to be users directly. 'The next communications platform'.
(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.
It seems pretty clear to me that option 1 is by far the better one. Open source projects are great at creating protocols.
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.
Rewriting the client sounds like an awful task, but it might be necessary. I think I liked wave, but really have no interest in trying to get that online. If it was a stack I knew ( Rails ) or a stack I knew would be nice to use ( Flask, Node ) I might be interested in getting a copy online and maybe contributing.
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.
I have been wanting to do this for ages...but without a established client/sever protocol its a nightmare.
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.
There is no roadmap, as we do not (yet) have a large enough consistent amount of developer power to benefit from one. Most of the patches we receive are fixes/improvements that benefit the submitter (e.g. full text search, monogodb backend, etc.)