Just three months ago, the University of Michigan and Indiana University made a joint decision to “pause investment” in the Sakai OAE project. The latest news is that the University of California Berkeley and Charles Sturt University (in Australia) have also decided to leave the Sakai OAE project. The only schools remaining as part of the Sakai OAE Steering Group are New York University, Cambridge University, and Georgia Tech.
Ken Romeo from Stanford has an excellent post summarizing the Berkeley and Sturt announcement and resulting community discussions, based on his first-person experience in the early version of OAE. It is worth reading his entire post, but I’ll quote a few key sections.
First, a bit of background: Sakai OAE has been a project for several years to develop a next generation learning management system. It started out as 3akai (pronounced [trwakai]) and then became just Sakai 3, but at some point it became clear that what was really needed was a system that was completely different than the current 2.x version of Sakai. So, Sakai re-envisioned 2.x to be called the Collaborative Learning Environment (CLE) and the next generation to be a completely separate product called Open Academic Environment (OAE). In addition, instead of taking the previous open community approach to development, it would be a “managed project”, run by the Sakai Foundation and several contributor schools [correction: in a comment below, Ian Dolphin, Executive Director of the Sakai Foundation, points out that it is the schools that run the managed project, while the Sakai Foundation provides infrastructure]. While I am grossly simplifying this whole process (there is more at http://www.sakaiproject.org/ and http://confluence.sakaiproject.org/) it boiled down to a few universities – New York University, Indiana University, University of Michigan, UC Berkeley, Georgia Tech, Cambridge University, and Charles Sturt University – which were part of the Steering Committee, guiding development, and the American Academy of Religion and rSmart joined them on the User Reference Group (URG), guiding the user experience efforts. These institutions had all contributed at least $200,000 or two full time employees to the project. I do not know the financial details, but it was clear that New York University was effectively the lead on this project, and they were running a pilot with real students.
In an announcement released to a public Sakai community forum on September 6th, Sakai Board Chair David Ackerman (from NYU) wrote:
In late August 2012, UC Berkeley decided to withdraw from the OAE managed project. This decision, on top of the departure of Indiana University and University of Michigan, has led the remaining partners and the project team to re-assess the project’s goals and timeline. Charles Sturt University recently also decided to withdraw as a stakeholder institution.
All partners remain persuaded that the concepts embodied in the design work to date are important and valuable innovations that are unmatched in other systems. And while the application architecture requires refactoring, pilots and user testing indicate that the user experience designs are both sound and unique.
Immediate actions taken in response to these departures include scaling back the development team and focusing efforts on the architecture to achieve greater scalability, performance, and deployment efficiency. With the changes in team composition, the project is capitalized through early 2013. By that time the goal is to re-implement the successful user experience design on a new architectural foundation. The project then will seek to expand community engagement and add additional partners to accelerate progress. [emphasis added]
Romeo goes on to summarize the resulting discussions based on Ackerman’s notice.
He [Ackerman] reiterated the stability of the project, but proposed that a discussion take place on the general Open Forum list. Several people immediately jumped in and it quickly became clear that there was no shortage of bad feelings about the managed project, OAE. There are comments about technical details that imply that they project was doomed from the start, and people who tried to speak up were asked to remain quiet. There is finger-pointing about the the management style of the project. And there is even a link to a page at Indiana University detailing how they are considering other learning management system vendors. There is some optimism, but for the most part, there are many calls to bring the focus back to CLE.
Jim Farmer has also posted a summary of the resultant discussions with the permission of the participants. This summary is useful in that it removes some of the emotion and frustration that can be expected from discussion forums, and it describes the key issues that emerged from the conversation.
By reading the forums, along with Ken Romeo’s and Jim Farmer’s summaries, some of the key issues facing Sakai become clear:
- Sakai OAE does not have a viable architecture to handle the requested UI/UX requirements – According to David Adams in the forum, “After four years, the system [in development] can’t support more than a few dozen users at a time, or search through more than a few thousand objects. Meanwhile, the potential customers need to operate at hundreds or thousands of times that scale.” The project failed to maintain a working system. [updated]
- There is conflict within Sakai community between the CLE and OAE mission – It is quite clear that many people in Sakai resented OAE being hailed as the next-generation replacement of CLE, especially without proven, working architecture and design.
- There is a need for corrective actions – Thus far, the OAE project has neglected to address difficult decisions (e.g. performance problems, delays in release dates) and instead pushed them into the future.
Does this mean that Sakai OAE is dead? I agree with the viewpoint of Charles Severance, one of those calling for Sakai community focus on existing platforms, as stated in an email:
This is not the “end of OAE”. Unless new sources of funding are found, it is a dramatic reduction of the centrally funded resources to work on OAE. It means that the funded OAE team will be wrapping up and OAE will evolve from funded resources to volunteer resources to move the project forward starting next year. OAE will continue to explore next-generation approaches and technologies – but at this point does not have the resources to deliver a “ground up rewritten replacement with the full scope of the Sakai 2.x CLE” as was the original intent of the OAE project.
Need for shared vision for all of Sakai
One of the points I raised in my post earlier this summer, regarding the departures of Michigan and Indiana, is still relevant:
I believe that one of the biggest impacts of the decision will be to raise further questions about the sustainability of the community source model as practiced by Sakai. One major challenge of the community source model is that the model can have too much top-down control, which removes one of the strengths of open source. By having implied or actual “control” over real contributors, it replaces the personal relationships and commitments that make the “Bazaar” function in the more organic forms of Open Source and relies too much on institutional politics and management structures. [snip]
The question moving forward, therefore, is whether Sakai OAE can take the opportunity of this announcement to coalesce behind a unified vision and leverage the community source model to execute on that vision in a timely manner.
I’d like to revise that last question to ask whether the entire Sakai community (CLE and OAE projects) can coalesce behind a common purpose and strategy. There is no shared vision within Sakai on the current and future roles of CLE and OAE, and there is no shared vision for how to execute in a timely manner. In my opinion it would be foolish to assume that the plight of OAE does not affect the prospects for CLE. The perception, if not the reality, is that CLE has no long-term roadmap (beyond v2.9), yet the market is not standing still.
This vision should directly address the ability to make more frequent and predictable upgrades of CLE for the existing users.
The message sent by David Ackerman calls for a wait-and-see attitude, ideally leading to “a new architectural foundation” by early next year. I think the Sakai community needs to address the question of a shared vision well before then.
Need to adapt to changing environment
Perhaps more significantly, but little discussed, is that the LMS and learning platform marketplace has changed, and it appears that Sakai community has not adapted to the environment changes. In Sakai’s heyday of the late 2000s, there were really two open source LMS solutions capable of institution-wide deployment (Moodle and Sakai) and two compelling narratives (freedom for institutions to control their technology platforms, and ability to avoid the constantly increasing prices of commercial LMS solutions). Both of these situations have changed.
There are now multiple open source learning platforms, and new options are coming out. Instructure’s Canvas is a different form of open source, ultimately controlled by the vendor, but it is open source nonetheless and changes the decision-making perspective of campus leaders. edX is releasing its platform as open source, as is Google’s Course Builder and Stanford’s Class2Go. Institutions that wish to go open source now have multiple choices. This might be an unfortunate situation for open source advocates, but it is reality. It is also worth noting the difference in open source models, as stated by Dr. Chuck via email:
None of these are open communities with open governance like Apache, Sakai, Jasig, or Linux. Releasing source code but retaining central control over the code base is easy. Building a sustainable community of volunteers and allowing the collective to guide the future direction of the product is far more difficult. So far, I don’t see any of these free samples of source code as taking any steps to hand control to a real, vibrant, sustainable, volunteer community.
Should Sakai emphasize this distinction in open source models as part of its ongoing mission? I think it would be a mistake not to do so, but it would also be a mistake not to understand the change in perceptions about open source in the market, including the importance of pace of innovation.
In contrast to the previous narrative of open source leading to lower costs, Sakai OAE is viewed as a costly proposition with no clear picture of an institution gaining return on the investment. As Jim Farmer shared in the comments to Romeo’s blog:
The motivation for UC Berkeley’s withdrawal may have been external. It was one of several open source development projects the University postponed—each withdrawal accompanied by a hopeful comment of future participation. The forthcoming Proposition 30 initiative would, if passed, increase business taxes to increase funding education. Now it is considered un likely to pass. This means a further reduction of $500 million the University and California State University in the amount the state would have provided. The University budget becomes a matter of survival rather than investment in the future.
Concluding thoughts
The departures of Michigan, Indiana, Berkeley and Sturt from Sakai OAE are life-threatening events for the project – not necessarily fatal, unless left untended. Without major efforts to develop a shared vision for all of Sakai, the prospects of CLE as well as OAE will likely suffer.
Update 09/20: Clarified comment on architecture based on comments from Ian Boston
I’ve steadily lost my optimism about OAE, and by extension Sakai as a whole, over the past year. I just don’t see how it survives, much less thrives, without a dramatic technical and social/process rethink. Even then it may well be too late.
Issues (I could write thousands of words below, but will try to be much more brief):
Technology. An engineer friend of mine whose opinions I value looked at the code interested in possibly contributing and he quickly gave up. His immediate reason was that it had no basic infrastructure for T&L and course management functionality. But more seriously, he made the point that the code looked like it was written by people more interested in cool technology than in shipping a working product. Recent hints shows what may well be more of the same high risk decision-making. Designing for massive scale now won’t matter if you never get the project done; productivity seems like it should be a much higher priority. OAE needs to provide a foundation that allows for the sort of rapid prototyping and feature addition that will serve the user-led design process.
Vision. The vision of OAE is actually really, really diffuse. The designers have been doing some really promising work lately that points to much more focus, but how many people really understand that?
Organization and labor. No real developer community; only paid developers. That’s not sustainable.
All of these issues are related. You can’t grow a developer community without the right technology choices, or a clear vision.
[Editor’s Note: The commenter has asked me to clarify that he is Ian Boston.]
Having been closely involved in this project in the early years I feel compelled to correct some misconceptions.
The conceptual architecture of the server that sat behind Sakai OAE was solid but it was crippled by two factors. A long term lack of support from the management of the project to take architectural and performance issues seriously. A server implementation team in which each developer believed they had architectural responsibility leading to a gradual erosion of clarity, vision and quality.
The evidence for these assertions can be found in the old google groups mailing lists as the server team wrestled to implement unimplementable UX/UI requirements on the chosen architecture. Features that forced the server team to attempt to implement a Social Content Management system using an Enterprise Content Management System (the key word to search for will be BigStore). Features that made the publishing model, successful in so many global social networks untenable. Features that forced the abandonment of hierarchical content structures in direct conflict with the “teachings” of Roy Fielding, “God Father of REST”.
The evidence for a lack of support from management for architectural concerns can be found by looking at the official efforts that were made by the project to address scalability and performance as long ago as October 2010, when, incidentally certain aspects of the performance were considerably better than it is now. The only reason the project did not die then, was due to the unofficial, unfunded and unsupported efforts of server developers determined to make something work.
For certain people close to the early project to suggest that they were prevented from publishing their thoughts to the community is a misrepresentation of truth and a slur on their own strong moral fibre. To my knowledge, no one has ever prevented these individuals from saying what they thought in public. His post to list also shows a distinct, lack of knowledge of the architecture or the immense attention to detail that was applied over the years that followed by everyone working on the server component, evidenced by numerous blog posts on the subject with detailed reporting of performance statistics, profiling, memory usage, concurrency down to micro second detail at extreem loads that represent only the tip of the iceberg.
OAE is in the state it is today because there was a culture by the management of the project that architecture, engineering and attention to detail where not relevant, driven by an assumption that the project was using a pre-built, tested web application framework such as Ruby-on-Rails or Node.js and the UX/UI features that were being approved by management could all be implemented as scalable and performant server features. That lack of management support was the reason I was forced to leave the project in June 2011.
As far as I know since a minimum funding level requirement was imposed on members of the Steering Group, University of Cambridge is no longer a formal member of that group, although I may be confusing that with the Executive Committee. Since both groups conduct their business in private its not possible for me to check.
Now OAE has entered survival mode, the team is merged, and the UI/UX/Server team is the only implementation team, there is hope. UX/UI Features that cant be implemented wont be presented to management for approval so there will be no battle to implement the unimplementable. I have no doubt that the complete rewrite in Node.js ontop of Cassandra will be a success, although it may not be possible for many to deploy. OAE will rise from the ashes. It remains to be seen if what rises will rise too late to be sustainable.
Bruce and Ian, thanks for additional insight into the architecture and code issues from a closer perspective than I have.
Ian, based on your comments I have updated the post to state “Sakai OAE does not have a viable architecture to handle the requested UI/UX requirements”. While this distinction adds valuable information in terms of a post-mortem and learning opportunity, I re-read this post but don’t think it changes my observations or conclusions. The change in language is meant to avoid stating why the architecture is not viable for the requirement request. Again, thanks.
I would encourage everyone to follow Ian’s advice and go back to read the earliest posts in the sakai-kernel Google group, such as the one from August 2008 in which Ian proposes a full rewrite of Sakai built on Sling/Felix or the one from November 2010 once it had become clear that the Jackrabbit-based system at that point was (in Ian’s words of the time) “a disaster”.
I think from the beginning the vision for the UI and the vision for the server-side never matched up. Both teams were pursuing their own dreams and goals without ever considering each other or the deep investment schools had made in Sakai 2.x.
As Ian states, the performance data to prove the OAE was going in the wrong direction was publicly available on the sakai-kernel and oae-dev lists for years. Early on in the project, the team chose to abandon any attempt at compatibility or upgradeability from Sakai 2. And critical basic LMS features have never gotten past a vague design stage. But none of these critical facts made it out into the general Sakai community. In fact, every six months, we’d see optimistic demos detailing how well hybrid mode would work and how soon Sakai 3/OAE would rescue us from the ugly mess of CLE. I think there’s still a portion of the community who believes OAE is just around the corner, will be a drop-in replacement for CLE, and will provide all the functionality users expect from an LMS.
Continuing optimistic statements of “just wait a few more months for this quick rewrite” from board members only make me more pessimistic about the future of either Sakai product.