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?
My immediate response to your question (Are we trying to over-engineer something that perhaps would work best through organic growth?) is a definite yes. But maybe I’ve become too indoctrinated by “small pieces” ideology and by my experience of how plain old html, blogs and webfeeds actually work, while more complex, more centralised systems (such as the Groupwise “collaboration services” used by my university) don’t. So maybe I shouldn’t dismiss a top-down, expert-driven approach too quickly. Let’s wait and see. Jason Kotke by the way has a lovely post on the “web as platform” at http://www.kottke.org/04/08/web-platform
On a related note – your anonymous correspondent says s/he fears “that only the elite, the MITs, UMiches, Stanfords, will be able to contribute and play in this field”. I think it’s a valid fear, but goes beyond this. Over-engineered projects of the sort s/he warns against often feel to me like an attempt by some Manderin class to hold on to control over e-learning (and internet-based collaboration generally) – to freeze out the small-time tinkerers who are actually what the internet is about.
I don’t think we need to attribute evil intent in order to explain the problems with OKI and its ilk. To begin with, the developers are trying to solve the hard and very real problem of vendor lock-in. As Stephen Downes (among others) has noted, Blackboard’s tendency to produce vendor lock-in is actually touted as a virtue among investors. The way to break that is with interoperability and portability standards. That’s vital in the long-run, but it’s also a hard problem. And it may be that a grand engineering project at this early stage in the game is not the best way to go about it.
Which brings me to my next point. OKI comes from MIT, which has a reputation for hideously over-engineering their internal IT projects. I know of at least one group there that decided to go to an outside tech project because they had no confidence that the equivalent internally-developed tool would ever be finished. The engineers were too busy building their castle in the sky. I’m not qualified to judge whether OKI has fallen prey to the same tendency but I have heard enough to worry me from people who are qualified to judge.
The alternative way to go would be something like the strategy that you (Martin) have been advocating and like the Kotke post you reference describes. This would not solve the lock-in problem, but it would allow for more rapid experimentation and evolution. Also, portability headaches aren’t quite as bad when the thing you’re locked into is only one part of an environment that you built for yourself out of pieces that you like. The bigger challenge would be interoperability. You need a way to aggregate data about what each student is doing in all the various tools. And you’re going to want to do it in a way such that you don’t have to rewrite your software (on top of having to figure out how to transfer your data) every time you swap out one service for another. I’m not saying that this can’t be done; I’m saying I don’t know what’s involved with doing it.
You say: “You’re going to want to do it in a way such that you don’t have to rewrite your software (on top of having to figure out how to transfer your data) every time you swap out one service for another.” – Yes, absolutely. So if for example flickr folds or changes in such a way that it no longer works as a means of sharing photographs for a group of students/practitioners working together, it should be relatively easy to switch to something else. And each group or individual using the “service integration system” should be able to easily choose from a menu of possibilities which ones they want to plug into. Like you I don’t really know what would be required to make this happen, and suspect that it might be very difficult. However, I also have a strong intuition that there is a first relatively simple step that could bring this much closer to reality, namely some form of persistent identity for people using a service integration system. The way I imagine it is that you’d sign on once to the integration system, then use other services as an when you need to without having to worry about sign-up (the system creates identities on the various services for you) or sign-on. Secondly, the system would allow people to form groups and your group membership information would be carried into the various services that you use. Hard to do, but not that hard. You also say “you need a way to aggregate data about what each student is doing in all the various tools”. Again agreed, but to a large extent this has already been made easy by the fact that RSS is starting to pop up everywhere. Increasingly, whatever people do online leaves an RSS trace, and it is not that hard to slice and dice these to produce, for example, an integrated feed of what a group of students are up to. Where no webfeeds are produced, often stuff at least does end up on a google-indexed web page, which makes shibboleth collaboration possible.