Josh Baron, Director of Academic Technology and eLearning at Marist College and now the new Sakai Foundation Board Chair, recently posted a great article in Campus Technology detailing Marist’s nuanced evaluation of Sakai and its community source provenance: Community Source Evaluation Strategies: Is Sakai Right for Your Institution? The article is a must-read for anyone at an institution considering the adoption of a learning environment—open/community source or proprietary—as all of Josh’s lessons pertain to both options.
I’m especially glad to see Josh include “Functionality Requirements” as only one of Marist’s five important evaluation criteria categories, putting it alongside Support Requirements, Community Health, Reliability/Scalability, and Innovation Drivers. All too often I’ve see institutions focus primarily on functional requirements in their technology choices, often at the expense of wise, strategic decisions that Marist’s other categories take into account. Every system will leave you with functional gaps…it’s the other stuff that will matter most in the end.
Reading through Josh’s piece, I was also struck by how the structures of commercial support for open/community source underlie each of Marist’s evaluation categories, and how well Sakai’s robust commercial ecosystem helps buttress Marist’s case for choosing Sakai. I’ll briefly cover each category below.
Josh points out that Sakai’s functional gaps outlined in Marist’s original evaluation were closed more quickly than expected. Many of the other points in the article explain why innovation and quality move faster in open/community source, filling in functional gaps in record time. The commercial support ecosystem in the Sakai community plays a key role in that process, adding their part to the staggering rate of innovation in the overall community. Commercial firms engage in productive partnerships with learning institutions—like the one between Marist and my employer rSmart that fostered Sakai’s support for the IBM technology stack, or that between Oracle and Unicon that brought us Sakora—and at the same time provide dedicated development resources that harness the collective needs of many clients to push Sakai’s functional breadth and depth.
Josh references the Sakai commercial support ecosystem head-on in this section. As he writes:
“As Marist concluded research into this area it became clear that running Sakai was like ‘consuming’ any other enterprise level system and that the myth that new development resources would be needed was just that, a myth.”
While the gist of this statement is dead-on, in my reading, it rings true only when one fills the word “consuming” with its full meaning: as an institution consuming commercial support for their open/community source system just like they would with a proprietary system. Maintaining open/community source technologies without commercial support puts different risks and responsibilities onto an institution that can call for extra resources. With commercial support, an institution is consuming Sakai just like “any other enterprise level system,” without dedicating additional technical resources, and usually at substantially less cost than proprietary systems, thanks at least to not having to pay license fees.
Josh is spot on again in describing the necessity to evaluate the viability of the community standing behind open/community source technologies. The community you join will bring you the greatest benefits of your open/community source strategy if it’s healthy. If it’s not, your might as well roll your own or pay the big dollars to a proprietary vendor. One element missing from Josh’s otherwise fulsome community health checklist is the existence of a vibrant commercial ecosystem. Sakai is fortunate to mark well in that category as well, which gives Marist—and all the other institutions who might need it—the commercial structures necessary to support their strategic choice.
Sakai owes the lion’s share of its enterprise performance quality to the many large learning institutions that run it in production and devote substantial resources to its development. For many institutions though, the community’s promise is not enough. They seek out additional guarantees for Sakai’s performance from commercial providers. In response, commercial providers bring additional focus to Sakai’s quality, reliability and scalability. It is through this focus, for example, that rSmart develops its dependable Sakai CLE distribution, upgrades and patches, and maintains our first-rate quality assurance and support programs, freeing users to focus on the more immediate work of their educational mission.
I laud Marist for taking these important, yet seemingly intangible criteria into account in its selection process. Out of the significant innovation drivers Josh lists, the decoupling of code development and support services in open/community source touches most on the role of the commercial sector. The decoupling Josh describes ensures that Sakai commercial providers focus on delivering outstanding support—because after all, the code is libre and gratis. If a provider doesn’t deliver good support, Sakai’s robust commercial ecosystem allows an institution to move to an alternative provider without the costly consequence of leaving their system behind.