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).
Not knowing anything about the deployment packages, it just seems to me that the Official Sakai Disto could include every known app, but that others would be able to prepare smaller distros that were focused around a set of vetted/integrated tools.
I suppose someone could come up with a K/12 distro, a Large University Distro, etc…
Or, are there limitations in the license that would preclude this?
I’m pretty sure that the license would not preclude the approach you’re suggesting, D’Arcy.
Cool. So, then… Start building “Michael’s Favorite Sakai Apps” disto… 🙂
Thanks for the comments, Michael. I’m especially interested in your: “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.” I’ve read everything on the SUNY site I can click to from the outside, what I find is a package featuring a wealth of experience generalized into a well-structured introduction, workflow, and with lots of advice along the way — a model and advice I’ve found very helpful for my job assisting faculty at an institution that is not that far along. I wonder if the problem is one of creating a community space or something much more detailed — as the SLN site suggests — a matter of developing principles out of practice, translating them into more general, accessible terms, and I wonder if the spontaneous, conversational model (and phantasm of community to which I generally subscribe) is the way to go. First, your system like mine has a public website and then a password-protected interior where, presumably, the good stuff is (like the SLN Handbook that I’d love to see): my colleagues, too, would build their “community” on the “inside”, which seems to me both to provide a somewhat protected space AND compromise overall enterprise: I’ve got lots of colleagues who were happy making funky web pages, which they “owned”, but who now find themselves yoked to Blackboard’s templates and feeling like they are a commodity the university may someday dispose of as it sees fit — sapping their morale. The Moodle users, as a group, seem happier in their sandbox (and I am envious). The best conversations I have are with teachers — people who like teaching, first, and then use one or another element of the technology to further what they already do. They get a charge out of teaching, and they’d like to share this charge with others. So, I’m wondering if, rather than starting from the platform, we might start off from this charge — the teachers teaching and students learning, and build from there: something I think Van Weigel, with the discussion of cognitive apprenticeship, deep learning, and vital communities of inquiry gets at rather powerfully. His frames of reference are not especially flattering to those of us interested in developing platforms: he sees them as tools (Lotus QuickNotes, EMC Documentum) better understood in terms of relevant metaphors (lecture hall, library, debating hall, etc.) because these metaphors — rather than those the web technologies presently offer (rdms, lists, http protols) — are more recognizably at the core of learning. So, rather than “platform” or “community” I’d begin with “seminar”. Or?
Thanks for the compliment on SLN, Bruce. (And by the way, look for a fairly major overhaul of our web site in the next couple of months.)
As you point out, we absolutely do need a teaching-centered conversation/community. This is actually something that I’m working on putting together out of SUNY, although it has gotten temporarily sidetracked due to time demands the major replatforming decision that we’re in the midst of making. This, however, is not mutually exclusive with having a community that devotes its energy to platform development. I tend to think of Open Source teaching tools as the sharing of best teaching practices in the form of source code.