Martin Terre Blanche has an interesting post (found via edu_rss) on why he won’t be using Groove and what he thinks will (and won’t) become a viable alternative. His strongest argument boils down to lock-in and data exchange problems. He believes this to be a fundamental problem that is common to the current crop of both desktop and web-based collaboration tools. Here’s a sample of his analysis:
I doubt if there are other desktop products that do a better job than Groove and I don’t think web-based group collaboration systems such as yahoo groups are really the answer either. I think two things are now on the horizon that will make the sort of simple straight-forward collaboration so many people need possible:
- The development and wide acceptance of simple RSS-like standards for scenarios not currently properly catered for by RSS, such as identity, group membership, and events. This will hopefully make many more kinds of collaboration possible, patterned along the same lines as the open, distributed collaboration currently happening via blogs and RSS.
- The development of second-level tools that draw together granular collaboration services into coherent higher-order tools. There has recently been a flowering of wonderful new online collaboration tools (such as spurl, furl, flickr, bloglines and many others), and many of them (including Google itself) come with programmer interfaces that make it possible for developers to access some of their functionality and incorporate it into their own creations. Mostly the tools people have built so far have concentrated on creative ways of using the functionality provided by each separate service, but I think it is likely that soon tools that draw on several systems simultaneously will start to emerge.
These two points sound roughly like what OKI and Sakai, respectively, are trying to do for world of course management systems. But are they going to be successful? How lightweight is OKI? (Certainly not as lightweight as RSS, is it?) Why is it necessary for OKI to be programming-language-specific (i.e., it requires Java)? How easy is it, really, to write a service that plugs into Sakai via OKI? Or is it really the uPortal standard rather than OKI where a lot of this plug-in-type work can happen?
Honestly, I’m very confused. If anybody out there can clarify the situation, please post to the comments here. (Sam Ottenhoff, are you reading this?)