Sakai and the Four Cs of Open Source
        
        
        
        
The 2003 Campus Computing Survey reveals that about one-third of all college 
  courses make some use of a CMS, up from 15 percent in 2000. Equally significant 
  in tracking the rise of CMS: fully four-fifths (82 percent) of the colleges 
  and universities participating in the 2003 Campus Computing Survey report that 
  their institution has established a “single product standard” for 
  the campus CMS—typically Blackboard or WebCT.
 CMS emerged in response to an institutional need: how do we “make it 
  easy” for faculty to use the Web in instruction? While CMS may not be 
  the mythical “killer app” of the Internet, CMS products—from 
  Blackboard, eCollege, WebCT and other providers—have certainly become 
  an integral component of campus IT offerings.
 In the language of business school profs, CMS looks like a mature market with 
  immature products. From the market side, more than 80 percent of the potential 
  buyers—in this case colleges and universities—have made a commitment 
  to a single product standard. But the products are young, the product category 
  less than a decade old. Consequently, it is not surprising, given the relative 
  youth of the product category and the corporate providers, that campus conversations, 
  chat rooms, and articles in The Chronicle of Higher Education document concerns 
  about upgrades software bugs, and, of course, the rising cost of the CMS license.
 Enter The Sakai Project. On 22 January 2004, four universities—Indiana, 
  Michigan, MIT, and Stanford—announced the Sakai Project (www.sakaiproject.org). 
  Sakai’s goal: to develop and distribute a “complete course management 
  system that incorporates the best features of the participants’ existing 
  systems and experiences.” The project received seed funding by way of 
  a $2.4 million grant from the Mellon Foundation. Additionally, the four founding 
  institutions “will contribute services worth at least an additional $4 
  million over the next two years.”
 Eighteen days later, on February 9th, Sakai announced a $300K grant from the 
  Hewlett Foundation to create the Sakai Educational Partner’s Program (SEEP). 
  The SEEP “will provide the staff and services to ensure a long-term community 
  for sustaining and evolving Sakai-based software.” Eighteen research universities 
  plus one community college district signed on as founding SEEP partners. Each 
  founding partner has made a three year/$30K commitment to Sakai.
 My old math says that the two Sakai announcements represent $7.27 million 
  in academic venture capital for the development of an Open Source CMS that is 
  intended to be “better” than current or future commercial products. 
  My market math says that these 23 institutions—four founders and 19 founding 
  partners—intend to change the structure of the campus CMS market.
 What drives Sakai? Four factors appear to fuel the Open Source CMS activity—indeed 
  the Open Source movement—in higher education.
 The first factor is code. Implicit in the Sakai announcement is a statement 
  from the founders that “we can do it better”—provide better 
  code, better product, and better services than currently provided by commercial 
  firms.
 Second is the control factor. The 23 Sakai founder and partner institutions, 
  along with many other colleges and universities, want control over CMS, as well 
  as the accompanying and supplemental applications. In this context, control 
  can be interpreted in two ways: first, product control over the development 
  and direction of CMS products and resources, including the increasing important 
  CMS “supplements” such as assessment modules and ePortfolio functionality; 
  and second, local control that permits the institutions to customize the core 
  product.
 Cash is the significant third factor in the campus conversation about Open 
  Source. Not surprisingly, the rising cost of CMS licenses is a major concern 
  for many institutions. While an Open Source CMS may not be truly free, the annual 
  $10K campus commitment from the SEEK partners is probably significantly less 
  than their current CMS license fee. In this context, an Open Source CMS reflects 
  a response to the mantra of college presidents in times of financial duress: 
  do more with less, and do it better.
 Finally there is community. Higher education really d'es view itself as a 
  community. Colleges and universities share information and collaborate on projects 
  in ways are unimaginable in the corporate sector. Sakai is another example of 
  collaboration as community, collaboration that has been integral to the development 
  and success of the Internet, Internet2, and other technology-based initiatives.
 Will Sakai succeed? And what’s the appropriate measure of success: 50 
  or 500 institutions adopting Sakai as their official campus CMS?
 As I indicated in my January Digital Tweed column (“The Penguins Are 
  Coming”), I remain an agnostic about Open Source: I don’t know if 
  it can make the leap from specific, discrete “back-room” applications 
  (think Apache server software) to complex, applications intended for those of 
  us who do not have computer science degrees.
 Moreover, I strongly agree with Annie Stunden, CIO at the University of Wisconsin, 
  who accurately articulates a large part of the agnostic’s dilemma. Writing 
  in the November 2003 EDUCAUSE Review, Stunden expresses concern that the campus 
  community has yet to develop an effective model to support shared Open Source 
  solutions: “We need to develop creative, collaborative solutions to the 
  dilemma of maintenance and support in our shared software development initiatives.” 
  The “code it and they will come” strategy is not an effective dissemination 
  model.
 Although I’ve identified four C factors as drivers for the Sakai and 
  Open Source movement, I wonder if there may be a fifth: confidence. Perhaps 
  a key measure of success for if and when Open Source moves from the back room 
  to the desktop is confidence in Open Source—among both IT leaders and 
  IT users.
 Good code—as well as user confidence—take time to develop. Consequently, 
  patience, feedback, and user support are key factors that will determine if, 
  when, and how Open Source migrates from back room services to complex user applications.