Ben Brophy, a UI designer at MIT, muses about whether Sakai is a platform or a product. His initial answer is that it should be both. But he worries about the implications of having it as platform:
The conference ended with a Q&A session with the Sakai board members. I asked how decisions about what’s included as the ‘core tools’ will be made. The response I got from one board member was “I’d like to see Sakai include six discussion boards. The user can try them all and decide which they like best.” No other board member disagreed.
That’s been bugging me ever since. Even assuming that each school’s IT department will pick a default set of tools (a possibility mentioned by the board member), does it make sense to have Sakai include every tool built? Can there be no standards for inclusion? If I’m developing a new attendance-taking tool that I want to be able to post grades, what do I do if there are 6 gradebooks?
This isa problem, for sure. But it’s not one that I’d be looking to the Sakai community to solve for me.To me, the potential that Sakai offers is overwhelmingly as a platform. As a product, it has not been very impressive so far. And the truth is that there are a number of servicable LMS products out there right now, including a couple of the best ones that are FOSS (“Free/Open Source Software”). I have no reason to believe that that the Sakai team will build a better mouse trap in this regard, especially given the fact that their organization is still very much top-down driven and CIO-driven (rather than teacher-driven like, say, the Moodle community).
No, what excites me about Sakai is that it potentially gets us a lot closer to that Learning Management Operating System that I blogged about recently. Consider the following:
- Sakai is going to integrate increasingly well with uPortal, which is itself a very nice integration framework, supporting RSS and iframes for easy stuff and WSRP and JSR-168 for more complex things.
- In addition to the Sakai APIs and the cross-pollination with the now IMS-supported OKI project, there is increasing cross-talk about interoperability between Sakai and Moodle.
While it would be very nice if Sakai eventually provides a good out-of-the-box experience (I’ve not yet had a chance to try 2.0, so I’ll reserve judgment on the current state of affairs), what’s much more exciting is that faculty members could run apps from Sakai, Moodle, uPortal, and some other WSRP-compliant system side-by-side. It should create an ecology of teaching tools for me to choose from.
Will we need to provide some guidance for both instructors and institutions to help them choose the right grade book, discussion board, or whatever? Sure, absolutely. But a technocracy of developers like the current Sakai community is exactly the last place I would look for that guidance. We’ll need a commons, a community space where teachers can share insights about best tools for a given discipline or audience or instructional goal. As long as the Sakai framework makes it easy to swap tools in and out without programming, then I think it will be easy and natural to build such a parallel supporting community. And, of course, institutions will provide their own support, choosing canonical toolsets to support and promote.
But the critical thing that I believe the Sakai Brahmins need to understand if they are going to be successful is that, despite what Ben may think, they are building something very much like Apache–with a twist. Their goal should be (like Moodle) to lower the skill requirements for tool building to a point where technically-inclined teachers can participate. The Holy Grail in this regard, for me, is still Jotspot. Failing that, Sakai should at least make it possible for heterogenous toolsets to be integrated with relative ease (i.e., not requiring programming in many cases).