One of the emerging themes from the Sakai Amsterdam conference was a strong desire in the community to develop a coherent vision for Sakai’s developing educational value proposition. Now, because of Sakai’s heritage as a project grown out of an alliance of strong, independent institutions rather than led by a single, charismatic leader (like a Martin Dougiamas or a Linus Torvalds), the process of fostering such a shared vision is a bit complicated. The most likely scenario is that capabilities first developed to meet local concerns of one or more of the members gets recognized by the community at large as addressing a common and reasonably deep need; it could then get picked up as part of Sakai’s identity.
I’d like to suggest four capabilities existing in at least prototypical form within Sakai today that could lead us to a vision for Sakai as providing unique and valuable benefits to the teachers and students that use it. That word “unique” is important. While it is always tempting for the Sakai community to try to emulate the admirable success of the Moodle community, the fact is that Sakai is not now and never will be Moodle, just as it is not now and never will be Blackboard. The educational potential for Sakai has to come from its own DNA as a technology platform and, even more importantly, as a community. With that in mind, the four ideas I am suggesting today are all about taking advantage of the…um…Sakai-ness of Sakai.
Fundamental Building Blocks
One of the most profound differences between Moodle and Sakai is that Moodle is a system created by teachers for teachers while Sakai is a system created by universities for universities. As one participant put it, “The fundamental building block of the Sakai community is the institution, not the individual.” While I continue to have my concerns about this approach, I am coming to see that it offers some unique opportunities. The first two ideas I’d like to discuss take advantage of those opportunities.
Access to Education
To me, the first reason for the existence of virtual learning environments is to increase the students’ access to educational materials and experiences. In turn, universities can only provide that access to students if the technology being used doesn’t require more resources than they have to maintain and support. Moodle has accomplished this goal with a KISS development philosophy, making it ideally suited for guerrilla installations with minimal support requirements. While the Sakai community can and should continue to work on reducing the resource requirements to run Sakai, the fact is that the different goals and different architecture mean that Sakai will never be as easy run as Moodle. So how can Sakai make its contribution to the goal of increased access?
One clue comes from a recent post by Wytze Koopal, in which he notes that “about 50% of Sakai use is through intermediaries.” Wytze goes on to emphasize the availability of commercial hosting partners, which I agree is important, but equally important is the growing trend of college consortia to pool resources for shared hosting. (The Foothills community college alliance led by Vivie Sinou is probably the best known of these, but there is a growing number of others.) Sakai can foster this strength by continuing to improve the scalability and multi-tenant capabilities of the platform. More importantly, though, Sakai can foster this strength by drawing on the institutional nature of the community, building a network of alliances and a communal knowledge base of best practices that lowers barriers for smaller colleges to pool resources, either with or without the support of a commercial provider.
Taking this a step further, we can think about providing students with access to courses across institutional barriers. Last week in Amsterdam, I heard presentations by two different university consortia –one in the UK and one in the Netherlands– that have implemented Shibboleth to support distributed learning environments. Among others things, this opens up the possibility for a student in one university to easily take an online course in another without jumping through a lot of technological hoops. From what I understand, it would not be difficult to enable the creation of such technological passageways between universities simple to accomplish using a stock distribution of Sakai. I’m guessing this could be added to the core within 18 months. But as Rolf Granow pointed out in his presentation on supporting the Bologna process (slides), the technology is the easy part. Building the inter-institutional agreements is slow, hard work. And yet, as a community of educational institutions, Sakai is uniquely positioned to help foster these relationships. This would require the participants to step beyond the notion of Sakai as a technological alliance and begin to think of it as more of an educational alliance, but I think that’s exactly what an increasingly large percentage of the community is asking for.
I could go yet another step with this idea and talk about fostering access to open educational resources, but I think I’ll save that for another post.
The Long Tail of Learning Applications
This next idea could be subsumed under the previous topic of access to education, but there’s enough new stuff here that I think it merits separation out as its own entity. As my regular readers know, I have long been an advocate for the idea that we should stop spending so much effort on building the 6,973rd implementation of generic groupware applications and start putting more energy into specialized learning applications that are designed to teach specific topics. (For a summary of that argument, see this article that I co-wrote with former SUNY colleague Patrick Masson.) Sakai supports a reasonably rich plug-in architecture that enables the development of new tools. This is good, but the current state of affairs has a number of limitations, one of which is that each addition of a tool by an institution requires a relatively non-trivial decision to maintain and support that tool. Just as Sakai could foster inter-institutional resource-sharing at the level of hosting an LMS, it could also host resource sharing at the level of individual tools. As Chuck Severence pointed out in a relatively recent blog post, there are now at least three methods for integrating tools into Sakai using web services. In addition to lowering the barrier of specialized Java skills, and indeed removing the requirement that your tool be written in Java at all, these methods open up the possibility of remotely hosted tools. Add WSRP and SAML support into the mix, and developers truly have a wide array of options for developing remotely hosted tools.
I would like to see these techniques refined to make Sakai the absolute best VLE for developing remotely hosted tools. I would like to see new support models that enable system administrators to say “yes” more often when faculty members ask for specialized tools. I would like to see new economic models that make it feasible for resource-rich universities developing specialized teaching applications to share them with even the poorest of their peers in the Sakai community, rather than keeping the use of those tools confined to the few professors within the developing institution that had the money to do the work (as happens much of the time today). I would like to see the Sakai Board seek funding for developing this newer, richer kind of open educational resource. The particular strengths of the Sakai community uniquely position it to accomplish these goals.
A Flexible Framework
Besides the institutional nature of the community, the other element of Sakai’s DNA that has always particularly stood out to me is the idea that it would be built from the ground up as a flexible framework. Universities could adopt Sakai as an out-of-the-box solution, but they could also use it as an erector set to build their own virtual learning environments, uniquely suited to their own needs. To my mind, the community has not yet come close to capitalizing on this truly beautiful notion. The last idea I suggested was one way to extract more educational value from the framework. In this next section I’ll propose two more.
Tearing Down the Wall
In my experience working with teachers who innovate with educational technology, there are two types of innovators: innies and outies. Innies learn to love their LMS, learning every nook and cranny, delighting in discovering new teaching tricks by exploiting some little-known feature (or even a bug) in the system. Outies venture forth into the wilds of the internet, cobbling together their ever-changing virtual learning environment out of tools like Flickr, del.icio.us, YouTube, PBWiki, WetPaint, or whatever else happens to be new and hot. Innies constantly refine what they already do well; outies sometimes fail and sometimes succeed, but usually do one or the other spectacularly. Outies adopt early; innies adopt thoroughly.
You would think that there would be a natural alliance between these two groups, with outies leading as the pioneers and innies following as the settlers. But that rarely happens in practice. Why? Because the two groups have very different levels of time commitment for dealing with the rough edges of technologies. For example, my wife experimented with using Frappr to build a sense of community among her remedial ESL students at the Borough of Manhattan Community College. The idea of building connections among students belonging to diverse factions of urban immigrants using a map was absolutely brilliant. But after doing some exploration, she and I came to the mutual conclusion that most ESL teachers in situations like hers probably wouldn’t adopt it. Why? Because it was too much to learn and too much to manage. First, the teacher and students had to create their own logins and group space. Now, this might have been a manageable task for a young, tech-savvy faculty member and a class full of stereotypical “digital natives.” But the reality of her school was that the majority of faculty members had been teaching there for 15-30 years, largely without any technology to speak of, and some of the students had extremely limited technology skills on top of limited direction-following skills. Just getting Frappr set up was an ordeal. Plus, you had to get everyone out to a different site and learn a completely different set of controls. Now, if Frappr groups could have been provisioned directly from the LMS (which, in turn, was provisioned by central administration), and if windows into subsets of Frappr functionality could have been placed directly into the already familiar virtual learning environment that faculty had been trained to use, there might have been more potential adoption.
Sakai could facilitate this kind of cross-pollination, using the same basic technologies described in the “long tail” idea above. The community could identify outies who are willing act as evangelists for their favorite new tools (and outies usually are), brainstorm with them about how to file down the rough edges via integration with Sakai, and then reach out to the various platform hosts (Google, Yahoo!…whoever) to develop that integration. With that done, all you’d need to do is put the innies and the outies in a room together (preferably with food) and let nature take its course. Peanutbutter, meet chocolate.
Liberating Content
One of the least excusable sins of current-generation LMSs is the fact that the course instance owns the content. When a course gets archived, all the contributions of the teachers and students get squirreled away on some tape drive somewhere, never to be seen again. As I have written about in a number of different ways on a number of different occasions, content should be freed from the shackles of the course instance, for reasons having to do with both educational effectiveness and plain old values and ethics. As a student or a teacher, I should be able to move my content –my speech acts and my documents– out of the course and take it with me easily. I should be able to store it someplace centrally if I want, but I should also be able to move it out of institutionally provided storage and take it with me wherever I go. Likewise, if I am productive within my own personal blog or wiki or whatever comes tomorrow, I should be able to keep generating (and storing) ideas there and share it selectively with the course environment with ease. LMS developers are starting to recognize some of these needs; witness the fact that all the major vendors sell some kind of repository add-on or other, for example. But these are just bandaids. The virtual learning environment should be architected from the ground up with personal ownership and control of one’s own content as a core value.
Sakai has a unique opportunity to do this now that ContentHostingService (the API that the majority of tools use to store and retrieve content) is being re-implemented on top of JSR 170 (the Java content repository standard). By leveraging this standard and the new software category of content repositories that is blossoming as a result of it, Sakai could liberate content from the course instance by default, making it persistently accessible to individuals via familiar file folder structures. If you layer on top of that something like an atom store, then you make content truly portable in all the right ways. Sakai should seek out use cases within the community (my own earlier-referenced blog posts provide a few potential starting points) and make Sakai the virtual learning environment that best supports freedom of content.
* * * * *
These are all just examples, of course. I can think of at least four more possibilities off the top of my head, and I’m sure there are many more that haven’t even occurred to me. The point is that in order for Sakai to grow into what it could be, it has to avoid the twin traps of either trying to be something that it’s not by emulating another system or getting sucked into a Peter Pan syndrome by avoiding any commitment to forming an overarching communal vision of what Sakai wants to be when it grows up. I think the community is ready to make the hard choices, and I look forward to seeing it happen.
