Note: This is only my own personal opinion. It does not reflect the opinion of any of the organizations I work for or work with.

I am often asked why the University of Michigan and other schools that founded Sakai and built it for over ten years have left Sakai and moved to Canvas as their primary / enterprise-wide LMS. This is my answer to that question.

It is a very interesting question because while the founding schools no longer are involved in Sakai in leadership roles, Sakai has a healthy open source community and is maintaining its market share quite nicely against Canvas, Blackboard, Moodle and Desire2Learn / BrightSpace. A few schools switch each year but not like the founding schools that all went to Canvas almost in the same year and at the same time. As I see it, there is something different at work between those founding schools and other schools.

I think that it comes down to the notion that in the early and mid-2000s, we *thought* that there was an alternate form of Open Source that we called “Community Source” where the primary participants, authority, funding, and leadership would come from institutions rather than individuals. The leadership would be the CIOs or educational technology directors at universities and they would commit far more resources than a single individual would bring. The form of the contribution would be dedicated staff with travel and other funding support for those staff. This would lead to a more stable resource pool and a more predictable product roadmap and schedule. The logic was that by pooling the contributions, the sum would be greater than its parts and there would be a solid return on investment for each of the contributors.

It seemed like a great idea and a number of projects were founded on this “Community Source” model including Sakai, OpenCast, Open Academic Environment and others. World-class schools like Michigan, Stanford, Berkeley and Cambridge brought significant talent and money and lent their brands to these projects to help them get off the ground. And the model worked for a few years when the focus was getting to a open source “Minimum Viable Product”. The tasks were well defined and large chunks of new code was laid down and progress was very tangible. Filling out the MVP was the shared priority and there were few decisions where different schools wanted to go different ways.

Of course each of these projects imagined that their long term direction was a broader open source community supporting the product so the need for the founding schools to continue to contribute money and resources into the project would be lessened. So at the same time as the project leadership asserted top-down control to build the MVP, there were efforts to bring in the second and third rounds of adopters and contributors to increase the depth and diversity of the community. Initially the value proposition for these later adopters was that these big wealthy schools were doing the hard work and investing lots of resources so new schools could contribute at the margins and dedicate far less resources than the founding schools. In a sense they would “draft” behind the founding schools to conserve their resources.

This community expansion led to a conflict in the priorities between the founding schools and more recent adopters. The recent adopters had needs and the founding schools had needs. The founding schools saw the new entrants as providing resources that should “pay back” the founding schools initial investment. The founding schools felt they should be able to reduce their investments and still maintain control over the project’s priorities. The new schools had little understanding of the costs that the founding schools had already invested and felt that it was not their place to bring resources similar to those already invested by the founding schools.

And even though the projects produced “Minimum Viable Products” after 2-3 years – having a MVP is only the beginning of the need for resources. The founding schools who invested so much in terms of money, people, and institutional commitment in getting to MVP rightly wanted to take a breather. But just at that time, either a major rewrite, or maturing the product feature set, or major performance work was needed to support the ever expanding community of adopters. In any software project the maintenance and improvement of the product always far outstrips the cost of initial development. And that maintenance / improvement is not nearly as “exciting” as building the product in the first place.

So projects find themselves in a sort of stalemate where everyone is waiting for someone else to do something. The founding schools generally begin to feel the pressure to keep investing to improve/finish the product that has become so closely associated with their university brand. The feeling slowly dawns on the founding schools that they can “check out any time they like but they can never leave” – and if they make significant investments to maintain their leadership in the project it will not gain any more fame or glory and barely be appreciated by the schools that are following along on the coat tails of the founding schools.

At the same time, the individuals at these founding schools (like myself) increasingly find the project more interesting because at some point there is real serious software engineering being done. Code is rewritten to be internally cleaner, performance improves, design is improving, small rough details are smoothed out and the adopters and users of the product are becoming increasingly happy. So everyone is enjoying their role in the project except the administrators of the founding schools who are providing significant financial resources. They increasingly feel like their leadership has no payback and they are taken for granted no matter how much money they contribute to the commons. Furthermore they often find themselves in a situation where the community priorities as perceived by the developers in the community (some of whom are paid by the institution) are different than the priorities of the institution footing the bill.

By this time projects are 6-8 years old and many institutions have had some turnover in their leadership / administration. The new administration sees the annual spend on the open source project that their institution founded as a “gift” or “welfare” that has little benefit to them but puts a significant dent in their often shrinking budget. So slowly but surely the founding institutions begin to quietly reduce their commitment to the needs of the many and focus on their own needs. Perhaps they fork the code base and just start customizing it locally to make themselves happy and don’t worry too much about aligning their directions with the shared community code base. Perhaps they stop upgrading to the latest version – one way or another they begin to fade out.

Another aspect of this “fading out” phase is that they stop putting a priority on fixing community-identified bugs in code areas that were originally built by the institution. They fix bugs in “their” code that they find on “their” campus but generally begin to ignore bugs (and proposed fixes or improvements) from the rest of the community. A backlog of unfixed bugs starts to grow and the easiest thing for the institution to do is just fade further away from the project.

The non-founding schools and other community members perhaps would love to fix the bugs in the core code, but out of respect, they wait for the founding schools to do the work. After all the founding school wrote the code and therefore should be expert in the code and why not leave the bug fixing, testing and releases to the school “best suited” for the task.

The administration of the founding schools begin to look for an opportunity to “escape” from the projects without losing too much face. The very project that by this time they have been investing for nearly a decade with millions of dollars from the general fund of the school and with the only future prospect is for the school to look worse over time and lose whatever brand benefit accrued back in the “old days” when the project was young and fresh.

So for schools like Stanford, Michigan and Berkeley, the market buzz about Canvas in 2012 gave them the opportunity to make a “clean break” with the project they founded. In short order, without too much analysis, and without much rationale nearly all the founding schools went to Canvas and did so quickly. They had revolutionized the LMS space by their investment in Sakai, and their investments and brand power had helped build standards like LTI and Common Cartridge, and the Canvas LMS in many ways was the realization of all that investment.

In my mind there is no doubt that moving to Canvas was a perfect exit strategy for the founding Sakai schools. In many ways, Canvas looked a lot like the “Sakai 3 Rewrite” proposed in 2008 that never bore fruit. I have a lot of respect for way that the founding schools found a clever way out while keeping their reputation and legacy largely intact. A reasonable strategy, well timed and executed with Canvas as the primary beneficiary.

But Then What of Sakai?

One might assume that when the forward momentum of a project has slowed to almost a crawl and then the founders leave the project, that it would be time to close up shop, give up and adopt the founding schools new strategy as customers of a company instead of owners of an LMS.

For Sakai, this did not happen. In a sense, the Sakai has been successful because it has re-dedicated itself to real, 100% open source. We focused on greater inclusivity, more balanced leadership, trusting each other as a replacement for top-down authority. Community members made their own choices regarding priorities and when and if they would contributed to shared pools of resources. We accepted the fact that volunteers were truly volunteers and respected each contribution for what it was.

Having a truly open community as core values led to three successful outcomes:

First the non-founder schools around the world had grown to know the technical inner workings of the code as well as the founding schools. They were ready with a queue of bug fixes and performance improvements that they were aching to put into the code base, but the founding schools were blocking them because the founding schools were so “checked out” and did not even want to test other people’s improvements. Once each founding school announced their departure, activity in their areas of the code base greatly increased and it took a very short amount of time until the community was capable of improving, testing and releasing all areas of the code base. And in the post-founder area, there was no “owner” of the code areas so anyone was allowed to participate with large and small improvements and bug fixes.

Second, there were many top-quality schools that had joined Sakai after the founders. Their administration and CIOs felt like they could “do it better” than the founding schools (especially those last few years when the founding schools were quietly reducing their commitment). These schools wanted to take their turn at the helm of Sakai.

Third, the Sakai commercial affiliates such as LongSight and others had become a small but robust economy on their own. The software developers in the Sakai Commercial Affiliates quickly moved into the leading technical roles vacated as the staff of the founding universities were pulled from the project.

A new crop of leading Sakai institutions often decided that instead of hiring and then contributing lots of developers, they would simply write requirements and pay contract developers (often at Sakai Commercial Affiliates) to implement the changes or improvements in Sakai desired by the Sakai schools.

Also the attitude within the community began to change. Instead of maintaining separate forks of the products at the major schools and each company, folks put more energy into improving the community edition of the product. The common shared code became the “gold standard” for the Sakai community and all the investments started moving in the same direction in a very coordinated manner. The amount of benefit to Sakai for each dollar invested has gone up dramatically since the founding schools left. The level at which the remaining Sakai schools were willing to invest was more than the available developers could handle and some fully funded projects waited up to six months before developer resources were available. It was nice to have a “backlog” of projects waiting for developer availability.

The Sakai 10, and 11 releases were really the first “post-founder” releases. And while at times we could have used more resources, the Sakai 11 release was the most technically challenging and important release in Sakai history. With a goal of eliminating the use of iframes to improve accessibility, creating a market-leading responsive UI, and an all-new grade book UI, Sakai 11 was quite a bit of work and took over two years to complete (2014-July-08 – 2016-July-23).

Also moving the source code to github for the Sakai-11 release made it far easier for a larger community of smaller contributors to work together more effectively so there were are now for more “hands” to move Sakai forward.

Summary

Nothing is assured but it is quite clear that the departure of the founding schools was a necessary challenge that the Sakai community needed to face sooner or later. There is no question that it was one of several scary “periods” in Sakai community history.

I continue to celebrate the contributions of the founding schools to Sakai, and fully understand the founding schools administration’s need to make a clean break and take a rest from changing the world. Their significant investments in Sakai has led to interoperability standards like IMS LTI and IMS Common Cartridge that have forever changed how we use LMS systems. Their investment made it possible to contemplate the idea of Next Generation Digital Learning Ecosystem (NGDLE).

By relinquishing their leadership in the open source LMS space, our founding schools could free up resources and invest in and lead other interesting educational efforts. The founding schools departure from Sakai leadership also roughly coincided with the rise of the notion of MOOCs in 2011-2012. Stanford, Michigan, MIT and Berkeley are widely seen as some of the strongest contributors in that new space where the focus is building free content rather than building free technology.

No leading university can, will, or should commit to anything forever. These brilliant founding universities should not be expected to invest in a successful project forever to “protect their legacy”. There are only a very few universities in the world that can by force of will invent something that has never been done at scale before like the NSFNet, X-Windows, the Andrew File System, the World-Wide-Web, Mosaic Web Browser, OpenCourseware, Sakai, MOOCs, etc and have those efforts “reach escape velocity” in a way that have a permanent and positive long-term impact on the world. We need to celebrate those rare gifts for what they are and not be sad when those schools take a step back so they can gather themselves and move on to invent the “next big thing”.