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?)
Michael, on one point at least – OKI OSIDs (“open service interface definitions”) are not programming language specific, but to do something useful with them you need to cast them in a specific programming language. To that end, there is at least one project trying to cast the OSIDs in something other than Java; the Harmoni project is trying to cast them in PHP (cf. http://sourceforge.net/projects/harmoni). I’m not positive if it’s a distinct initiative, but I seem to think the folks at Middlebury who were developing Segue were also trying to do a PHP casting.
In terms of what makes something work with Sakai, my understanding is there’s two distinct issue here. A Sakai *application* by definition will be a Java-based portlet written to the JSR-168 specification which will allow it to be plugged into uPortal (or any JSR 168 compliant portal framework). Sakai applications will support OKI OSIDS, meaning that in addition to the application needing to support the JSR portlet spec, if you want your application to interact with other applications, or to utilize some of the core services of the system, it will need to implement some of the OSIDs. For instance, there OSIDs that define authentication and authroization services that you would likely need to implement, and others, such as the Repository OSID, that you would want to implement if you needed to access your deployments repository services.
As to how lightweight this is? Doesn’t really seem to fit my notion of lightweight, but you should probably ask a systems developers their perspective. Hope I haven’t steered you wrong with my explanations above; I’d be happy to be disabused of any of the notions I have of Sakai and OKI if they are incorrect.
Cheers, Scott Leslie
OK, so JSR-168 lets you build a window to another application from a Sakai page but you need OKI to do any real integration on the data level. I’d be interested in hearing people’s use cases to understand better which OSIDs are most likely to be utilized, when JSR-168 is practically sufficient, etc.
Also, how much flexibility is there in terms of the Sakai interface through uPortal? Which parts are Sakai-specific requirements. I remember seeing something about this in the Sakai FAQ but it was vague enough (at least for somebody at my level of familiarity) as to not be terribly enlightening.
Initiatives such as Sakai and OKI are good to the extent that they are trying to get away from vendor-specific solutions, but I think they’re a bit different from the “second-level tools that draw together granular collaboration services” that I was calling for in my post. I’m hoping for something more organic that links together services (such as furl) using standards (such as RSS) that are already out there and used by millions of people, rather than a new set of very complicated specifications.
One of the questions I’m trying to ask, Martin, (trying to be fair to the OKI team) is whether there exist simple standards that are “already out there” that can handle the job. Honestly, I’m not technically savvy enough to have an opinion myself.
It’s does seem to me, though, that there are at least three different things we could mean in terms of functional requirements, and how “organic” the system can be may depend on which functional requirements satisfy your particular goals (or mine, or Sakai’s). The first requirement would be syndication, e.g., I want to pull in a list of all the files I have stored in your tool. Sounds very RSS-like to me. Second, though, is to do real data integration, e.g., I want to see which discussion board posts in your system were made by registered users in mine. I’ve not seen anybody use RSS or anything like it for something like this, though I’m not qualified to judge whether it is feasible to do so. Third, there’s data portability, e.g., I want to get all the discussion posts for my users out of your legacy system and into my shiny new one. I have a strong suspicion that this third requirement demands a specification that is somewhat-less-than-lightweight, though again I defer to the programmers in the crowd.
Personally, whether we’re talking about a small-group tool like Groove or an enterprise tool like a course management system, I’d feel much more comfortable putting my data into a system that meets all three of these requirements. What I don’t understand yet is how much meeting each of these requirements will cost in terms of the steepness of the implementation learning curve (and therefore the degree to which it is possible to have the kind of organic second-level aggregation system that you are suggesting).
There are several interesting questions embedded in this thread, and I wish there were clearer answers.
Groove pops up on my radar a couple of times a year because it solves much of what I am looking for in group collab software. The combination of presence, file sharing, and archiving is essentially the core functionality that I keep on coming back to when a part of a distributed group project. Although lock-in is a very valid reason to dump Groove, my reason for not adopting Groove is price. Even its academic pricing seems not right to me. I recently downloaded a program called InterComm from a company called FiveAcross. The pieces to build simple group collaboration software are all out there. The original post’s focus on simple standards like RSS is smart. The InterComm product and a product called Gush from 2entwine.com seem to be heading down this road.
JSR-168 is the Portlet spec. It is relevant to the conversations we have had previously about adaptable online environments. And theoretically, the Portlet spec would allow a developer to tie many disparate pieces (portlets) together inside a portal (uPortal being just one of many different possible containers). Sakai is building on top of uPortal, but I am bit unclear at what takes precedence: building for JSR-168 or building using Sakai APIs + OKI OSIDs. My guess is that both will be possible but building Portlets will be the lighter-weight development because of the cross-vendor attention (and Portlet-building tools).