view printer-friendly version (opens in new window)
More Sakai details revealed and partner programme presented
The Sakai consortium of US universities and the OKI and JASIG standards bodies have revealed more detailed plans for the open source, standard compliant Managed Learning Environment (MLE) that they are building. Most notable is a partner programme by which organisations other than the founding members can join in, and get support- for a fee.
In a three hour teleconference session organised by UC Berkeley's Fred Beshears, the founders of the Synchronised Architecting of Knowledge Acquisition Infrastructure (SAKAInote) presented not just the case for their project but also the skinny on how they intend to achieve their ambitious targets. Moreover, initial fears of the bugbear of many an open source project in education -sustaining development and support beyond a project's funding- have been addressed.
To recap from the announcement, the Sakai project aims to develop a complete open source Managed Learning Environment (MLE), including course management, assessment functionality, workflow, collaboration tools and a portal by autumn 2004 for the pilot, and autumn 2005 for the full release.
The main motivation behind the project is to make e-learning software that meets larger institutions' diverse needs cost effectively. Many a project has tried that before by building the necessary parts in house, but diverse network environments, small budgets and, most of all, little or no coordination between institutions meant lots of good software that never reached its full potential, or never went beyond where-ever it was first developed.
Slapping an open source licence on these applications after the fact did not make a difference: other institutions are unlikely to adopt a piece of software, never mind continue development of it, if tweaking it to suit their needs is going to cost as much or more than starting from scratch.
Sakai seeks to address the problem by pooling resources, and focussing them on one framework that is flexible enough to accommodate many different tools and environments. Basically, it looks like Sakai is trying to do to MLEs what the Apache project did for Webservers.
But the big idea about Apache and similar large scale open source projects is that they have durable communities of practice around them. Developers can drop in and out whenever there is a need, and expect a good many support resources to help them get the job done. Apache even has a sponsored foundation that can pay volunteer developers who have proven themselves to accomplish specific tasks.
The partnership programme
Sakai doesn't have quite the deep pocketed sponsors Apach has, but what it does have is a $2.2 million grant from the Mellon foundation, and $4.4 million worth of resources from the core founders for two years. The trick, of course, is what happens above and beyond that, and they have wisely addressed that issue right now, at the start, with the Sakai Educational Partners Programme (SEPP).
The SEPP is meant to provide a way into Sakai for institutions other than the founders (i.e. the Universities of Indiana and Michigan, Stanford, MIT, OKI and the uPortal consortium) on both the technical and strategic level. Initially, partners will get support from Sakai core developers, a knowledge base, pre-release code,training events, an internal tool market and an opportunity to give input on development directions. The SEPP has it's own dedicated staff. After two years, the intention is that the SEPP partners gradually take over the reigns and direct development.
The catch? $10.000,- per year for SEPP membership. That may sound a little steep, but is not actually that much for a support programme of a major open source application. Like Red Hat Linux or Zope, you will be free to download the Sakai code and help yourself (even if you are a company looking to build products on Sakai), but you have to pay for anything more than that. As with other such ventures, the issues to watch is whether code is released reasonably quickly, and whether an informal group of volunteers will spring up around it.
Nuts and bolts
That leaves the ambitious deadlines, though. For that, the thing to bear in mind is the synchronisation aspect of the plan. The founders essentially bring a bunch of more and less stable, complementary technologies to the table that need further development. Rather than bring out new versions on their own, they reset the development around a common Sakai Tool Portability Profile.
Technically, that means that Michigan's CHEF environment becomes the SAKAI tool framework and has a load of services attached to it via OKI Service Interface Definition (OSID) adapters, uPortal becomes the Sakai portal that takes what comes out of the tool framework and delivers it to webbrowsers. Parts such as Indiana's Navigo assessment tool will be integrated either as a service, or else as a tool within the tool framework.
Done properly, this is a fast way of working, not least because the whole lot is based on a stack of technologies built around one language: java. But it also means that anything that is outside of that core will not be addressed immediately by the founders; for support for things like SCORM content or IMS Question and Test Interoperability (QTI) or Learner Information Profile (LIP), SEPP partners will have to jump in.
For this to work, and for the whole thing to become sustainable, the crucial aspect is the Tool Portability Profile. This is the architecture, set of standards (mostly OKI and the JSR 168 portal standard) and design patterns that will define how all the components will hang together.
The most notable feature of the Sakai architecture is that it integrates tools and content quite close to the user, and far down as service APIs. That's not quite so clean and loose as other, webservices based MLE architectures that are doing the rounds at the moment. Given the legacy technology that the founders put in, that's hardly suprising, and it could turn out to be as much of a virtue as a vice.
Most college IT managers would probably love to rip everything out, and start again with a lovely, elegant architecture, with just the right amount of layers of abstraction so there's no duplication of functionality. But in the real world, people have to work with a smorgasbord of systems that were never designed to work with each other, but have to anyway. In such an environment, a comparatively pragmatic architecture like Sakai's might actually do well.
The full, three hour teleconference is available as an archived stream from the ETS Berkeley page. The page also has a long presentation on the whole project, and an outline of the architecture.
The Sakai projectpages have just been opened, and has a really good FAQ.
note Sakai also puns on the name of French - Japanese fusion cuisine chef (as in Michigan's The CompreHensive collaborativE Framework (CHEF) contribution) Hiroyuki Sakai and the word has all sorts of vague connections to 'boundary' and 'situation' via alternative interpretations of the Kanji character used for 'Sakai' in Japanese.
I think I'd go for the arbitrary signifier, ta.
No responses have been posted