A Review of Sakai: Free As In Freedom

A couple of weeks ago I bought Chuck’s Sakai: Free As In Freedom (Alpha). When it arrived in the mail, I thought, “great, another $20 shelled out on a book that was exciting to buy but that I won’t actually read with all the other distractions in my life.” How wrong I was. Chuck’s book is actually a page-turner – at least for those of us who’ve tried to tag along for the Sakai ride. There have already been two positive reviews of the book by Alan Berg and Jim Farmer. Like them, I took no small pleasure in reading it not least because Chuck reveals a lot of things that I was only vaguely aware of (having never sat on the Sakai board) or that I might have been familiar with but that I’ve forgotten over the course of the years.

Not all of Chuck’s recollections can be summed up in this review but one especially worth highlighting (and which you can get the gist of by reading the closing chapters) is that Chuck and the board differed on issues of governance. Anyone whose dipped more than their pinky toe into open source initiatives knows, following Eric Raymond, that there are cathedral style (e.g. hierarchichal) software organizations and bazaar style (e.g. organic self-organizing) ones, and that open source (with many notable exceptions including the up and coming Instructure) generally gravitates toward the bazaar. But while many of us came to Sakai (and open source) because we longed for more inclusive, less top-down software communities, this doesn’t mean we’re partial to moving away from the cathedral and into the bazaar in equal degree. These same differences existed on the board and Chuck sums up the division as follows:

My opinion was that the purpose of the Foundation was to have a light touch and focus on nurturing the individual and organizational members of the community. The Foundation was to be the cheerleader, the communicator, throw good parties several times per year….and generally give folks a rallying point to find each other… the Foundation was never to take the responsibility for the direction of the product, nor should the Foundation hire core developers, nor should the developers report to the Foundation staff to receive their assignments.

The opposing view held by the majority of the board members was that the Foundation and Foundation staff were a form of command and control with the top of the authority hierarchy as the Sakai Foundation Board of Directors. The…stakeholders were concerned that letting individuals….make their own priority decisions….would be too risky for the adopting schools…..Central control and guidance was needed to insure that the product would move forward according to a well-defined and well-understood roadmap and do so on an agreed-to schedule.

Given my own school's tepid reception to the Sakai product (I still remember one Weber student who summed up his experience in version 2.4x with the withering description “everything is scattered from hell to breakfast”), we were receptive, on pragmatic grounds, to a little more command and control planning. And yet, at the same time, Chuck’s vision appealed to my own deeply seated political and pedagogical beliefs. Especially as Chuck justifies them near the end of his diary:

The reason that I prefer a bazaar-style organizational structure for Sakai was that software for teaching and learning is something that everyone understands and has feelings about. There is not one set of designated experts who can define and design teaching and learning software and hand that design to some developers and have them “code it up” as if programming was an advanced form of typing….good ideas can literally come from any part of the world and an idea can come as easily from a student as from a professional instructional designer. So I felt that it would be wrong to let design and priority decisions rest in the hands of a select few.

Given the competing virtues that are inherent in authoritarian and more anarchic governance structures, it was true, as Chuck also observed, that there wasn’t a “universally correct” organizational strategy that Sakai could have followed. But for better or worse, Chuck’s vision differed from most of the board’s and in his view it played an important role in his decision to relinquish the executive directorship to Michael Korcuska at the Amsterdam conference in the summer of 2007.

Chuck’s sympathies with a more loosely organized development model can also be found in other places in his narrative. For example, while he eventually learns to appreciate Carol Dippel and her QA efforts, he’s initially skeptical. And while he credits Mike Elledge’s use of Microsoft Project to systematize Sakai’s development efforts he readily admits his own aversion to using it. The portrait is rounded out when Chuck recounts buying a couple of suits for bettering his Sakai advocacy: apparently his credit card company flagged the purchase as suspicious. By whatever stereotypes of consumer behavior credit card companies use to build portraits of their users they seemed to have pegged him more as a Birkenstock than Wingtip kind of guy.

I’ve only talked with Chuck once very briefly while riding up an elevator at the Movenpick hotel at the Amsterdam conference. But I don’t get the sense, even after noting the above predilections, that he’s out to “stick it to the man.” For example, in contrast to some of the rest of us, his misgivings of Blackboard were not that deep-seated. He describes the patent suit as a defensive action that any corporation out to protect share-holder value would have been interested in pursuing (p. 176) And in spite of the suit he continued to seek productive partnerships between Sakai and the Blackboard corporation. Like Brad and Joseph he knew how to appeal to freaks like me who sometimes have difficulty acknowledging that our 401-k’s make us complicit too in the heartlessness of capitalism. But he did it in a way without alienating potential partnerships with commercial interests outside academe.

As the Soviet’s used to say (and as historians often still profess), “the future may be certain but the past is always contested territory.” Which is another way of saying that if Chuck has offered up an intriguing story, I hope it doesn’t end up being the authoritative history of Sakai. The sub-title, after all, is a “retrospective diary” rather than a history, which would suggest that many other stories are worth telling. For example, Chuck glosses over the divisions that arose between those of us who saw Sakai primarily as an LMS and as a commodity whose core design could largely be derived from prior art and those who proclaimed the LMS as dead and Sakai as a larger platform and community for innovating new online teaching technologies. The CLE versus LMS story is, I expect, only one of many other stories worth telling. Perhaps, as Jim Farmer has suggested, we need to publish a compilation? In the meantime Chuck’s book is a great (Alpha) history.