There’s an excellent (albeit necessarily technical) conversation about implementing OKI (which are standards that, among other things, are central to the Sakai project) over at the dotLRN discussion board within the OpenACS web site. (OpenACS is an Open Source toolkit upon which the dotLRN LMS is based.) Here’s a key snippet of conversation: (more…)
Tag: OKI
-
Doubts about OKI and Sakai
I almost appended this as a comment to a previous post, but I decided it was important enough to elevate to the top level. I received this email from a person who wishes to remain anonymous but who has at least some first-hand knowledge of OKI:
I didn’t want to publicly disparage the OKI project but privately I have severe doubts at its role in edu software development. I can’t think of any comparable edu project to OKI in terms of hype and funding.
Sakai is using some of the OKI OSIDs but they also acknowledge that they need to go far and beyond OKI and have thus created their own set of Sakai APIs. Furthermore, as you alluded to in your post, this is not lightweight development at all. My biggest fear about all of these recent Mellon-funded edu tech projects is the immense barrier to entry because of the development difficulty. I fear that only the elite, the MITs, UMiches, Stanfords, will be able to contribute and play in this field.
This strikes me as a very serious concern. In our quest for technical standards of interoperability, are we losing sight of loose coupling? Are we trying to over-engineer something that perhaps would work best through organic growth?
-
Groove, Sakai, and OKI
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?)