UC Davis, Sakai, and Open Source

Phil has been a busy boy, putting out two pieces about some Blackboard research that had gotten some negative responses and two more on a horrifically bad LMS outage for UC Davis and other universities using support vendor Scriba.

Our main schtick here at e-Literate is to get beyond the headlines. We try to explain what is actually happening and why it is important. Often, this involves puncturing hype like “robot tutors in the sky,” not by heaping them with scorn but by showing the gap between the hype and reality. But there are also times when we do the same for anti-hype. For example, there is a popular narrative that Blackboard is evil and bad and stupid, partly based on the massive brand damage the company did to itself a decade ago (and two CEOs ago). As a result, when they do…well…anything, it tends to be interpreted in the worst possible light. Personally, I’m glad that Blackboard is sharing the findings of their product research. I don’t know of many ed tech companies that are doing that. This is different than putting out a white paper about some study the company did showing how awesome their product is. Rather, it shows us how they are trying to understand their customers’ needs. Sharing that back with the world helps us, in turn, understand how Blackboard thinks. It is an important kind of transparency. As Phil’s second post on the topic highlights, we do have to understand that this kind of study is different than an academic study in order to draw the right conclusions from it. But that’s fine.

Likewise, the Scriba outage story plays into a “Sakai is dying” narrative. As it happens, I was at conference for the foundation that hosts Sakai last week and got something of a rundown on what was going on, including a preview of the release scheduled to come out this summer. (Oddly, nobody mentioned the outage, which must have been in its early stages at that point.) The Sakai sustainability story is complicated enough to merit a separate post, which I will get to later this week. In the meantime, I’d like to put the Scriba outage in context of how open source works in general and how the Sakai ecosystem works in particular. Because it is very easy for this story to reinforce preconceptions rather than looking at it carefully on its own merits.

Phil wrote,

There is an interesting angle here in that Sakai is open source yet data is not easily recoverable.

Right. Open source can help with problems like the Scriba outage. As far as I can tell, it did help UC Davis. But it’s not that simple. There is a lesson to be learned here for all LMS-using schools, but it’s not “open source doesn’t provide the flexibility that it is supposed to provide”; nor is it “Sakai is dying.”

The Theoretical vs. the Practical

One theoretical benefit of open source is that, if you don’t like your support provider, you can move to another one (or self-host) and keep your platform. If your provider were to suddenly disappear, as Scriba did, you would still be able to run it yourself or to transfer to another provider. This one of two main reasons that Instructure released most of Canvas as open source in 2011. The company was young and perceived as risky at the time. Releasing the code as open source was similar to putting it in escrow to assure clients that they would have something even if Instructure went belly-up.1 UC Davis was eventually able to stand up their own version of Sakai in part because Sakai is open source and the school therefore had access to a copy of the code.

But a number of other pieces also needed to be in place in order for this strategy to work well, or at all. First, Davis had to have a current local backup of their data. Running the LMS is all well and good, but what they really needed was their course data…you know, like student grades and stuff. One lesson here for any school, regardless of the brand or license of your LMS, is always have a current off-site backup of your data in a location not controlled by your vendor. Davis apparently had that. Second, you need the ability to run the system locally (or have some support vendor ready to run it for you). Davis used to host Sakai themselves and, being an R1 university of substantial size, obviously has a capable IT department. So they had the theoretical capability. The situation may have been complicated by the fact that their Sakai installation was apparently non-standard. We know that that the Davis installation runs on a different database than is typical. I would not be surprised to hear that they also have substantial customizations. One good thing about open source is that you can do anything you want with it. One bad thing about open source is that you can do anything you want with it.

Bottom line: Because (a) Sakai is open source, (b) Davis performed regular data backups on a site that was not controlled by the support vendor, and (c) Davis had the necessary technical capabilities in-house, they were able to scramble and get a local version kinda sorta running, on short notice, until Scriba re-emerged. On the flip side, there may have been Davis-specific complications that made this task harder

The Support Vendor Ecosystem

So that’s disaster recovery. What about moving to a different support vendor? Well, that depends. Are there any? And would you trust the ones you have? These questions, like many about open source, are project-specific and change over time.

Once upon a time, there were three major Sakai support vendors in the United States: rSmart, Unicon, and Longsight. Sakai was originally started by a handful of big schools that relied on their own staff for support, hosting, and development. The community of adopting schools was slow to expand to those that needed help to run or host the platform. As a result, three support vendors was both too many and too few. It was too many because there just wasn’t enough business to keep them all thriving. Unicon still does some Sakai work, particularly in the area of custom development, but they never did a lot of hosting work. rSmart decided to focus on Kuali—a move that ultimately proved disastrous to them—and therefore sold off their Sakai business to a company that then sold it to Scriba, the very one that caused the UC Davis disaster. The last hosting vendor standing in the US at the moment is Longsight. If there is only one, or even only two or three, the theoretical benefits of moving to another support vendor has limited practical value, particularly for schools that do not have the capability to self-host.

That said, you would need to know a lot more than this to draw firm conclusions on the future sustainability of Sakai. How many self-hosted schools are there? How many are hosted at Longsight? Or at other, smaller vendors? How much is going on internationally, with colleges and universities that are largely invisible to mainstream US-centric analysis? And how healthy is the development team? A note on that last point: An open source project can have a healthy community of developers that is disproportionate to the number of adoptees, since developer resources are not funded solely by licensing and support revenues. Therefore, adoption footprint is not as direct a measure of the health of the platform as it is for proprietary products.

More on that, and on the overall state of Sakai, soon.