view printer-friendly version (opens in new window)
US universities consortium starts OKI and Portlet implementation project
Updated. After the release of the first batch of Open Knowledge Iniative (OKI) Open Service Interface Definitions (OSIDs), and the release of the new JSR 168 Portlet specification, the Universities of Indiana, Michigan, MIT and Stanford and the uPortal consortium set up a project that will implement and integrate the lot: SAKAI. The idea behind SAKAI is to build a framework where MLE compontents can be plugged and played in a wide variety of institutional networks.
With something of the voice of experience, the project outline notes that previous attempts at getting open source educational software beyond the project stage and into different institutions were hampered by very different infrastructures and user interface requirements. Another obstacle is comprised of "inter-institutional timing differences of when a particular software need has mobilization, funding, and attention have impeded pooling requirements and development resources in synergistic ways'". Aka the 'not-invented-here' syndrome that led to numerous competing and incomplete open source enterprise software projects.
The proposed solution is a combination of tight control and tight deadlines, imposed on a manageable core of institutions that between them may have enough clout to give the project enough momentum to sustain itself. That, and the commitment to build on standards.
Given the involvement of MIT, and the commitment to OKI, one would expect that the SAKAI software would function as reference implementations of the OSIDs. Scott Thorne, one of the leads on the OKI team, doesn't quite see it that way: in his view, SAKAI is meant to come up with production level application almost within a year, and is therefore much more specific and robust than a typical reference implementation. Given the implementation experience that SAKAI will entail, there may be some refinements of existing OSIDs, however.
Also, a glance at the SAKAI roadmap reveals that a lot of the work on the project involves a refactoring of about ten existing enterprise software packages to fit and/or constitute the framework. Pre-eminent among these is the University of Michigan's CHEF framework- an environment for research, learning and teaching collaboration. In general (UK) terms, it is a VLE with a Portal, and some MLE functionality, and was designed to be extensible with new tools- hence its suitability as a foundation for SAKAI.
Another big piece that will go into the pot is uPortal, the popular HE portal software. The package provides a means of disseminating and aggregating specific bits of information; typically news, weather as well as course information, institutional anouncements and so on. This is accomplished by having a portal draw together the snippets of information from a variety of portlets that are kept in the portlet containers of different organisations into one, personalised portal page.
Which leads to the other major specification that will go into SAKAI: JSR 168. This is an API definition for portlets from the Java community, and specifies the kinds of commands a compliant porlet understands. It works alongside the slightly older, non-Java specific Web Services for Remote Portlets (WSRP) protocol. The point of JSR 169 is that it makes it easier to deploy portlets that have been developed elsewhere.
Other interoperability bits that will go into SAKAI include a means to let tools interact, the 'Tool Interaction Framework'. That means not just one-to-one always on connections from, say, a student record system to a library system, but also a common means for tools to invoke one another. Finally, a single means of customising user interfaces is to be developed. These last two interoperability components will be SAKAI specific.
Though not that much information exists about the precise architecture of SAKAI, the commitment to JSR 168 and OKI suggests a slightly unusual framework: rather than focus on data formats and behind-the-scenes web services in the manner of, for example, the IMS Abstract Framework, it pitches interoperability both above and below the conventional levels. 'Above' by using the portal technology, which is really a means to shuttle processed results and some interaction direct to the user, and 'below' by using the OSIDs, which connect an application to the rest of the world almost at code level. That is, stuff is integrated at the practically the highest and lowest possible levels, with very little inbetween.
As the SAKAI partners seem only to well aware, though, technology is only a part of the story; the socio-political aspect is at least as important. With a $2 million a year budget, and a deadline of complete VLE and assessment functionality in a year, there seems little doubt that there is momentum to get things done. Perhaps the bigger question is whether it will work after that.
Experience learns that the biggest single factor in the success of a piece of open software is a large and motivated adopter community. Once that is in place, the end of a project does not also become the inevitable end of the package's development. The question, then, is whether the small and fixed core SAKAI group will be a turn-off for other people. There already is a notion of secondary contributors, but that may not be sufficiently attractive or influential for everyone.
The positive spin on the present structure would be that, in a year's time, there will be some actual code to play with, which, if it really is as well componentised as it promises to be, could be easy for other people to adopt, configure and extend. The 'build it and they will come' principle, in other words.
SAKAI was outlined during the Educause 2003 conference, and discussed during the IMS Quarterly Meeting in San Jose.