I am starting this thread with the intention of discussing the future development of FedOne. Namely, how we (the community and Google) can continue this effort, what will have to change to garner more participation, and the code we need Google to open source to provide the greatest benefit. This thread will hopefully not become another place to question the decision to kill the commercial version or talk about how much of a bummer this is in general. Plenty of other places for that. This is written in the spirit that Google, which Dan Peterson said in another post on this forum, will continue to open source more of its code and Google will still use the Wave technology internally as part of other projects (meaning the technology itself won't perish in the halls of Google).
The number one thing I believe we need to do to garner more participation in FedOne is to combine/link what is really the two worlds of the open source Wave effort - The Wave Data Api and Federation. Much of the potential and utility of Wave is in the live interaction of gadgets and robots as well as the ability to embed this technology within standard web pages. This is sorely missing from FedOne. If Google will commit to open sourcing or developing the code to enable FedOne to support gadgets, robots, and the embed api I believe a large segment of the existing community will remain and more will come. Number two is we need a slick lightweight client attached to FedOne, namely a write enabled version of Splash (if you haven't seen splash here's a screenshot: http://twitpic.com/27zx6c). Splash, as an FYI, is also built off of the Wave Data Api mentioned above. No it won’t be as powerful as the simple web client, but it will be much easier to extend or use as a template (I saw someone used it to develop a mobile version) and not to hurt anyone’s feelings, but it looks a heck of a lot better than the simple web client. Think about how community participation increased when the simple web client was released and how it really came out when it broke. This effort needs a client and I believe Splash fits the bill. The simple web client is still important, but I believe it will be a smaller segment of the community that takes on the task of extending that to a commercial quality. I believe there also has to be a change or rather an addition to the model of contribution. We need a sandbox where the community can place and go to find user contributed updates that don’t first have to go through Google’s review process. So much can be accomplished just by putting out an initial version. When I contributed and cloned my mongoDB persistence patch (as opposed to the patch set created by the review) Steve Baker took it and extended it to store the deltas as readable JSON as opposed to the base 64 encoded version that I had and Vaclav Sykora created a version that supported RDBMS using JDBC. I’m not saying Google has to provide this environment, just that this is needed as a one stop shop to see contributions and examples that haven’t yet or may not get pushed through the Google review. So specifically to Google. Why should you invest resources when you’re killing the stand-alone version? First, if indeed Google intends to continue to use the Wave technology in other projects it can leverage the innovations made by the community through this effort. Also, in the ever increasing social and real-time world, it makes sense to support perhaps the technology best suited for social in real-time. You believed in Wave enough a year ago to make it the highlight of I/O 2009. The same potential exists, it just has to find its niche within your market (I can envision many relevant enterprise applications right now). Let’s say for example, Google develops a social networking site to compete with Facebook (crazy idea, I know :) ). One of Facebook’s biggest draws are the games. Now let’s imagine Google comes out with a social networking site that provides an API that allows developers to easily create multi-player games where friends can play with/against each other in real-time over standard Internet protocols. The Gadget API can enable this and through continuing this effort Google will have a cadre of developers familiar with the technology. Google then can take it one step further and say you don’t even have to work within our system; you can have your own game servers that can federate with Google’s Social Site. Point is, who knows where FedOne will go? We do know what the technology is capable of and that is worth continuing support. In summary we need the Wave Data Api linked to FedOne, a slick client (Splash), a sandbox, and most importantly a commitment from Google that the community can rely on. Google, if you do make this commitment, please make it real and give us the developers that have really supported this effort and truly know the code. Anthony Baxter, Soren Lassen, Alex North, and recently Lennard de Rijk are some of the names that immediately come to mind that have developed a rapport with the community and have invaluable knowledge of not just the Wave protocol, but also the community and where it wants to go. I know I focused on developers, but I don’t want to leave out those that provide invaluable support to the community like Joe Gregorio and Dan Peterson. These are just my thoughts. I welcome and invite others to contribute their ideas on a way forward. -Anthony -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
