sakai takes a bashing
Fri, Sep 14, 2007
This article talks about some of the failings of Sakai. I can’t comment on the application failings the author talks about as I’ve only worked in the guts of the system but I think I should perhaps say something on the complaint the author has about the implementation language of Sakai and how that affects its “open sourceness”.
Sakai is definitely a steep learning curve made even steeper if you’ve never worked with Spring. Spring itself is very intuitive but the layer that Sakai puts on top of it isn’t. To me anyway. The documentation is all over the place and mostly out of date and this was curious to me when I first came to Sakai. They were charging thousands of dollars for entry to the “club” but for some reason, none of that money seemed to have found its way to the development and documentation depts. There is a small core of “trunk committers” while the rest of the community seem to use Sakai as a source repository. To me, Sakai is more than a collaboration infrastructure expressed as a web application, it’s also an academic source repository for institutional specific tools that work with the Sakai “platform”. There are sometimes several versions of the same tool as different institutions prefer to stay with the ones they are familiar with and there are votes on when to promote tools to the main Sakai distribution and when to remove older ones. All making for a vibrant community.
An interesting quote from the article is:
“…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…”
Anyone can learn Java. Java is not a closed club, open only to a certain kind of person. What I think is more important, rather than the programming language used to implement a system, is the ability to understand enterprise level concepts and be able to express them in your language of choice. The quote, to me, implies that if Sakai was written in PHP it would be open source by dint of the fact that there are more PHP developers in academia than there are Java ones. Why is this? I would guess that it it takes a long time to become fluent in Java to the same level of fluency in PHP. We’ll it’s not a guess. It’s experience. It’s a fact and a fact that puts off academic IT depts from investing in Java.
“…a crack Java developer is both expensive and increasingly rare…”
You can knock up a quick and dirty, quick win application that solves a particular, politically sensitive problem pretty quickly in PHP. You just grab the nearest hack, stick them in a cupboard and say “do that now or else”. Again, experience. Java, on the other hand, traditionally comes with the development lifecycle of requirements gathering and testing. Something a lot of academic environments are unaware of. By the time you crank out a Java app in response to a political hullabaloo, the landscape has changed and the app is obsolete. So PHP rules in this type of environment. Dare I say that the number of Java developers in an institution reflects its political stability?
Java is geared to enterprise development. PHP is not geared to enterprise development. Sakai is an enterprise level application. Ergo, PHP would have been an inapt choice of implementation language. So rewrite it in PHP to make it more open source, the author might reply. Then you have the enterprise barrier to leap over and it’s much higher in PHP than it is in Java. Java has constructs that make it easy to work with enterprise data, PHP doesn’t. So although a PHP Sakai is “more open source” than a Java Sakai (to paraphrase the author), to apply the author’s reasoning to the new PHP Sakai, it’s equally “un-open source” due to the requirement to understand enterprise level programming.
There comes a point where you just have to have the skills. Not having those skills does not “narrow” the “openness” of an open source application. It just reflects one’s own narrow skillset. So the message to the author is, you can’t have your cake and eat it.