Yesterday I had the privilege of heading down to the University of Virginia and catching up with Steve Stedman and crew who are strongly considering piloting a WordPress Multi-user installation for their ITC group. We talked a bit over a Mexican lunch about Content Management Systems in general (Patrick turned them on to Drupal, and I even got to talk Typo3 with the other Steve). It was extremely enjoyable and one of the topics that came up is UVa’s impending campus-wide move to Sakai, which I believe will be happening slowly over the next couple of years (the switch will be complete sometime in 2009). They have a pilot in the works called Collab, and in the afternoon show-and-tell session Patrick and I got to take a look at the inner-workings of Sakai for the first time.
It was pretty eye-opening in many regards. First and foremost, I have to be honest and say that I was pretty underwhelmed with Sakai. Steve and company did an excellent job skinning their install and, in fact, it immediately looks like a very inviting environment. But once inside, it seemed more like a labyrinth than a manageable tool for authoring and sharing resources quickly and easily online. I was surprised to find that Sakai, much like many of the proprietary course-management systems, fell prey to building their own applications such as the wiki, the blog, chat, forums, etc. None of them seem particularly stellar, and in fact many of them are admittedly sub-standard–specifically the blog. With all the thought, time, and money put into Sakai, you would think they would have realized that pulling the best of breed applications into this course management tool would be the way to go.
In fact, some of the UVa folks were excited about the feature that embeds websites using iframes into one’s own Sakai space (I believe they referred to it as links). While this may have some value, I think the integration of these sites is a bit tenuous at best. All that is really happening is that you are embedding another web page into Sakai -so you can’t really “run” Moodle or WordPress in Sakai, you can simply allow users to link them into the workspace. Making Sakai work as a kind of “centralized browser” of sorts. The problem with this is accessibility and the user interface. As we went through the demo of Sakai, the problems of navigating through the frames became readily apparent. Steve pointed out the issues here with the frames dis-orientating the user and how the system itself often has a series of “false homes” that can trap the user in a loop of sorts.
More than anything else, however, I was extremely disappointed with the limited RSS capabilities. You would think that an open CMS would have the RSS flowing like wine, and folks could have the option to hook in to one another’s content making for a community of rich syndication much like the feed-based architecture that Jon Udell discussed recently here. However, nothing doing from what I have seen. The one RSS feed I was able to see was for the wiki, and it seemed to have problems distinguishing between particular project pages. Making it effectively useless.
On top of this, the URI (or URL) for a particular user’s space is a long chain of undecipherable characters, making navigating to a site or sharing a link cumbersome–effectively hiding even open pages within a course. So radically different from the beauty of dynamic sub domains in WPMu, which in many ways may make all the difference for ease of navigation and the true feeling of each user having their own space on the web.
Now, truth be told, all these issues should be fixed, if not immediately, then at least eventually because the source code is open and folks can share extensions, work-arounds, etc. However, it may be open-source in theory and name, but given that it is primarily written in Java, I’m not sure how quickly Sakai will see any of these improvements. Perhaps for big, rich institutions like UVA putting Java developers on the scene can allow them to incorporate these improvements for the general community. Put even big, wealthy schools have definitive budgets, and a crack Java developer is both expensive and increasingly rare, making the open source ideology ring somewhat hollow. For at its root, open source, at least for me, has become so deeply associated with the ease of contributing to a code base.
Steve brought up several excellent points during the conversation, but I will focus on one in particular. Steve suggested that one of the possible dangers of a system like Sakai is that it is quickly becoming the flag-ship open source course-management system for many big research institutions, but with the community of contributors defined so narrowly to Java developers, at what point might open-source solutions suffer as an alternative for high-level administrators throughout education if Sakai doesn’t live up to its promise? Which in my mind is a definite possibility. A host of research universities threw millions of dollars at an idea of an open source application, but they did it in a traditional academic way which put the idea and the perceived needs before the actual community and real needs. Now, I firmly believe that the theoretical and abstract conceptualizations of academia is the manna of so many great things, but I am not so certain that this is the case for open-source course-management systems. In fact, I think projects like Drupal, WordPress, MediaWiki, etc., capture a vibrant community because the details are being imagined and re-worked as the applications evolve. The communal evolution doesn’t precede these systems existence, it defines it -a key difference from the organizing logic of a system like Sakai as I see it.
But, I am sure I’m overlooking, simplifying, or mis-representing several important elements of Sakai. I would love to hear about all the functionality that I have not seen yet, but I’m still a bit scared there is no there there.