Open Source in Higher Education: Building a Life Raft for the Perfect Storm

Ian Dolphin is Executive Director of the Apereo Foundation.

We are approaching a decade and a half of experience in one strand of the higher education open agenda: the development and use of open-source software. Motivated by the three drivers of cost, performance, and control—as identified by Paul Courant, former librarian of the University of Michigan—open-source software has been widely adopted by higher education.¹ It is useful to periodically draw lessons from this collective experience to inform the shape and direction of future initiatives.

Software: Open Source and Community Source

Free software and open-source software are terms that emerged in the 1990s to describe currents of software development running counter to the proprietary business models that had prevailed for the previous decade. Applied to software in a narrow sense, the term open-source refers to a licensing model that allows access to, and modification of, source code with varying degrees of license-dependent restrictions on the subsequent use and distribution of that code.

Various governance models are represented across the open-source software landscape, ranging from an essentially pyramidal model, often described as a "benevolent dictatorship," to more collective and avowedly meritocratic models, represented by the Apache Software Foundation. Some projects in higher education refer to themselves as community source. It is important to recognize that community source refers to a governance model—or, perhaps more accurately, to a range of such models—rather than to a fundamentally different form of licensing. Community source, in essence, marries the organizational model of a higher education consortium to an open-source licensing regime, typically under the legal protection of a nonprofit entity. In some instances, such as the Apereo Foundation and the Kuali Foundation, this nonprofit entity is a membership organization.

Since open-source licensing can be an arcane area to understand in detail, some amplifications may be required at this point. Open-source software licensing relies on two principal types of agreement: inbound and outbound. Outbound licenses, and their differences, are reasonably widely understood, at least in broad-brush terms. BSD-style outbound licenses, such as the Apache License and the Educational Community License, allow more liberal use of the code they cover. BSD-licensed software can be incorporated into, or even made the basis of, proprietary software. GPL-style outbound licenses maintain free access to the software they cover forever—period. It is not my purpose here to add to the debate around these outbound license types but, rather, to emphasize the role of inbound code-contribution agreements, which are far less well known but no less critical. An inbound contributor agreement vouchsafes the code contribution as original and permits the receiving organization to make that code contribution available in perpetuity. Inbound contributor agreements are of two types: individual and organizational. When an individual also works for a company or institution, both agreements are required. In open-source software, this is the bedrock on which everything else is built.

An effective inbound licensing regime provides a significant advantage for collaborative, multi-institutional higher education IT projects. A collaborative project based on proprietary code typically engages in extended dialogue—and sometimes failure to agree—on issues surrounding shared intellectual property rights. The larger the number of project partners, the more complex that multi-point dialogue becomes. An inbound and outbound open-source licensing regime—managed by a neutral, supra-institutional nonprofit entity—can act to significantly reduce the friction associated with collaboration.

This begs a series of questions that relate closely to the organizing principles of community-source software. Should a new nonprofit entity be established for each new collaborative effort? If the main purpose of such a nonprofit entity is to provide a safe home for the shared intellectual property rights embodied in the software and related artifacts, together with a series of services to support the community of development and adoption around that software, how many such nonprofit entities do we need? Here it is necessary to balance choice with an effective pooling of resources. The short but slightly ambiguous answer to this second question might be: "Fewer than we have now, but more than one."

Governance, Cooperation, and Collaboration

The topic of sustainability and governance of the overarching nonprofit "home" for open-source software is worth returning to. But what of the practical experience of governing collaborative software projects in higher education over the last fifteen years? We have a diverse landscape to draw from, and we need to understand some of the nuances of that landscape—in particular, two significant vectors. The first might be described as the position of the open-source project in the software stack and the number and type of users the project faces. Is the project creating infrastructure that will be used mostly by software engineers to create solutions for end users, or does it face significant numbers of end users in itself? Are those end users relatively homogeneous, such as the users of a financial system, or more heterogeneous, such as faculty and students using a learning management system? More complex systems, such as a learning management system, contain both infrastructure and superstructure supporting user-facing interaction. Perhaps unsurprisingly, experience has demonstrated that infrastructure projects can be governed with a greater degree of simplicity than projects developing more complex solutions.

Governance is not quite that straightforward, however. The second vector to comprehend is maturity. Projects may require very different governance structures at different phases of their life cycle—from pre-initial release to maturity. The widely used uPortal framework had a start-up phase under a grant regime. That regime maintained the customary panoply of principal investigator and project team, but when the grant concluded, uPortal was transitioning to a community-driven governance model. In another example, the Central Authentication Service (CAS) had a point of origin outside an external funding program: an investment by Yale University to meet its own needs for a single sign-on solution. In a farsighted move, Yale moved CAS from an in-house structure to a community-governance structure. The important lesson here? There is no universally applicable governance model appropriate for every collaborative effort.

Further Up the Stack: Sakai

The evolution of more complex open-source software systems serving large numbers of diverse users offers equally valuable experience. Sakai, used by more than 250 institutions worldwide to support leaning and research collaboration, has evolved from a grant-funded project with a small number of contributors to a significantly larger operation that is no longer dependent on individual institutional contributions. As a mature and complex software framework, Sakai requires strong technical governance, which is provided by a project-management committee. But as an environment used by educators and learners globally, Sakai cannot set its direction through the customary higher education expedient of "putting a committee in charge."

Sakai has evolved an ecosystem that may appear complex but that gets things done. An active teaching and learning community, institutional investors, and a strong component of commercial partners help inform direction. In a recent EDUCAUSE Review article, Brad Wheeler made a useful distinction between cooperation and collaboration.² In large, mature, and complex systems, this is not, of course, a binary choice. In the world of Sakai, individual institutions may make specific investments in tools or fixes. Rutgers University has recently added critically important functionality to Sakai in this way. It is in the interests of such institutions to have others adopt their code and to grow this adoption into contributions from others. Without integration and adoption, the single institution may well be left carrying a maintenance burden alone. Similarly, groups of institutions may target particular areas for improvement and may collaborate to fund development. The Kaitei project is a collaboration of several institutions that are working to improve key pieces of Sakai infrastructure to make the environment more hospitable to the creation of mobile solutions. In this way, "cooperation" shades into "collaboration."

This ecosystem grew organically over time. It was not legislated into being, and it is still evolving, but it is proving remarkably adept at meeting the needs of many institutions that are prepared to both cooperate and collaborate.

The Life Raft: Foundation, Partnerships, and Globalism

Many higher education open-source projects and communities originated in the United States. That happened, in part, because of the vision of the Andrew W. Mellon Foundation Research in Information Technology Program and its founding director, Ira Fuchs. The program provided seedcorn funding for many positive developments that continue to serve higher education today.

However, the foundations that have been created to manage the intellectual property generated by the creation of open-source software—foundations that include the one I direct, the Apereo Foundation—face several challenges. We need to learn that diversity is not necessarily dilution but, rather, improves resilience and is the seed-bed of future innovation. Part of that diversity lies in developing global adoption and contribution. To accomplish this, we need to learn as much from community organization theory and—dare I say it—political theory as from the world of business. Finally, we also need to recognize that we are a node in a broader network of the adoption of open practices serving the higher education mission, rather than purveyors of universal truth. We have a great deal not only to contribute but also to learn.

1. Paul N. Courant and Rebecca J. Griffiths, "Software and Collaboration in Higher Education: A Study of Open Source Software," July 26, 2006.
2. Brad Wheeler, "Speeding Up on Curves," EDUCAUSE Review, vol. 49, no. 1 (January/February 2014).