Here’s the second installment in the great video series from the University of North Carolina’s Sakai Pilot Blog about the strengths of Sakai 2:
Tag: Sakai
-
Update to the Sakai 3 Timeline
Sakai Foundation Interim Executive Director Lois Brooks just posted a brief update to the Sakai 3 development plans. The detail that stood out to me is this:
The new project brings together the existing body of work, and the existing teams, into a single, coordinated effort, and aims for a completed version that is feature-equivalent to Sakai 2 in mid-2011. [Emphasis added.]
This represents a change from the earlier road map that didn’t anticipate having a full Sakai 2 replacement until 2012.
A couple of caveats are in order. First, nobody really knows what it means for Sakai 3 to be “feature-equivalent” to Sakai 2. Whenever you move to a new system design, some features that made sense in the old world just don’t make sense in the new one. That’s particularly true in this case, Since Sakai 3 is very different from Sakai 2 in both functional design philosophy and underlying architecture. For schools currently on other platforms, this doesn’t matter much. The “feature-equivalent” tag simply conveys the Sakai 3 project team’s confidence that they are releasing a competitive product. For current Sakai schools, the issue is more complicated. They will have to look whether anything that matters to them will get lost in translation.
Second, people on the project team tell me that, at this point, 2011 should be considered to be something closer to an aspirational goal than a due date derived from a detailed project plan. In June, there will be development planning sessions both immediately before and immediately after the Sakai conference. A lot of work gets done at these sessions. Over the month or so following, more gels as attendees go home and rally their troops and as tentative decisions are finalized through communications with stakeholders who may not have been able to attend the conference. We’ll know a lot more by mid-July.
For now, the main take-away here is that the Sakai 3 development team is expressing an increasing sense of confidence in the project’s resourcing.
Update: After rereading some emails, I’d like to slightly downgrade my adjective from “confidence” to “optimism.” One early test will be to see whether schools step forward with additional resources once the project plan is fleshed out. Again, much of this will happen in roughly the Sakai conference time frame. There is a lot of interest in participation being expressed within the Sakai community, but we don’t know yet whether that interest will translate into resource commitments in sufficiently large numbers to ensure delivery on this more aggressive schedule.
Stay tuned.
-
Some Strengths of Sakai 2
Image: University of North Carolina I write a fair bit about Sakai 3 because I am excited about the possibilities for change that it represents. That said, there are a couple of points worth emphasizing. First, Sakai 3 doesn’t exist yet and won’t be adoptable as a full LMS for a while. (See Sakai 3: What It Is and When To Move To It for details.) Second, Sakai 2 is a very good current-generation LMS that is meeting the needs of many schools today.
University of North Carolina, which has been piloting Sakai 2, has been putting out some excellent evaluation materials on it. (See UNC’s Sakai Evaluation Results, for example.) Their Sakai pilot blog also contains some gems. For example, they have identified five “big ideas” that they believe represent some of Sakai’s strengths—particularly in comparison to Blackboard, their current LMS. Here is a video describing the first of those ideas:
In addition to the school-wide evaluation, the UNC medical school has been looking at Sakai to meet their more specialized needs. (See Academic Study of Blackboard vs. Sakai at UNC School of Medicine.) They have some niche requirements which are critical for them, foremost of which is a good calendaring system. Here’s a video of medical school faculty talking about how Sakai works for them:
-
A Closer Look at Mobile App Development for Higher Education
I have been blogging a fair bit lately about the competing mLearning efforts between Blackboard and the Moodle community. Much of the conversation so far has focused on the front end apps and whether web-based or native apps are better. (The latest is that there is a native iPhone app for Moodle in addition to the mobile browser app.) But let’s be clear: Many of the smartphone apps you have for your iPhone, Android, Blackberry, or whatever were built by lone developers working part time. I don’t want to trivialize that work, but it’s hard to see how one platform is going to achieve a durable competitive advantage against the others based on its mobile client.
I’m going to draw on some recent conversations about mobile apps in the Sakai community to reflect a little on what it takes to build an mLearning platform. In the process, I’ll also think out loud about what kind of a business this area will or will not sustain in the long run.
-
It's Official: The Sakai Foundation is Hiring a New Executive Director
The job description is here. If you are thinking about applying and have questions, feel free to ping me.
-
Understanding the Sakai Product Council
If you have never been involved with an open source project, one of the great sources of mystification (and anxiety) for you might be how a group of people spread out all over the world with a wide range of motivations can come together to work on a complex project and produce something coherent and useful. Of course, we know that such things do happen. (For a beautiful illustration of it happening under conditions of extreme lack of visible coordination, watch Jon Udell’s classic analysis of the evolution of a Wikipedia page, Heavy Metal Umlaut.) We know that it can work. But, from the outside, it’s hard to understand how.
The truth is that there is a wide range of governance structures that work for different open source projects, and none of them are particularly mysterious once you come to understand them better. Some projects, like Moodle and Linux, have structures that bear some superficial resemblance to normal management structures in that they have strong central managers who make a lot of final decisions. I say “superficial” resemblance because, in many cases, these managers are acting as part traffic cop and part adjudicator, rationalizing contributions and suggestions for direction from all corners of the community more than they are giving top-down commands.
Other open source projects, like Sakai, take a more distributed approach to management. When they can, they tend to modularize the development so that small groups can work largely independently from each other and can reduce the coordination required to those areas in which their pieces have to work together, either from a technical perspective through integration or from a functional perspective through, for example, common user interface conventions. For those functions where cross-module decision-making has to happen, the community develops mechanisms that look a lot like a representative democracy. In some cases, community members will vote directly on an issue that needs to be resolved. In other cases, they will select representatives to work together in a small group to work through the issues. Just how much (and what kind) of coordination is required depends on a number of factors. Software that has a significant user interface generally requires more coordination than software that does not. Programs where the modules share a lot of technical integration interfaces or services also tend to require more coordination than those that do not. Projects that are in the beginning of their life cycle tend to require more coordination those that are mature.
Over the years, the Sakai community has tried a number of different coordination structures. One of the most recent innovations (and experiments, really) is the Product Council (PC), of which I am a member. What follows here is my own personal meditation on how the PC came about, what function it is attempting to serve and how successful we’ve been at it so far.
-
Sakai 3: The Benefits of 'Everything is Content'
One of the more radical departures that Sakai 3 makes from traditional LMS design is that everything in the system is treated as content. A traditional LMS is an aggregation of tools—discussion boards, grade books, test engines, wikis, assignment drop boxes, etc.—each of which has its own data model in a relational database. It’s really a hodgepodge of separately designed tools that are knitted together through a user interface layer and a few common services. In contrast, Sakai 3 is being built on top of the Apache Jackrabbit reference implementation of the Java Content Repository (JCR) standard. Everything is treated as content, including grades, test questions and answers, discussion threads, syllabi, personal profiles, chat messages, and so on.
This approach has some benefits in terms of shoring up common weaknesses in LMS designs. But, more profoundly, it also leads to some pretty fundamental changes in the way that learning environments can work, thanks in large part to the strong and growing adoption and maturation of useful content integration standards.