Values of Community Source Development

• By Lois Brooks
• 09/01/04

To help us understand open source in the context of higher education, Lois Brooks lays a groundwork based on the work of some of the best thinkers in the software development world. By Lois Brooks, Stanford University

There are a lot of projects underway in higher education institutions right now that are pushing software into open source. Open source isn’t new, of course, and in the 30 years that it has been a viable model for software development, some common practices and values have emerged. The structure and beliefs of the open source community are increasingly present in higher education. In recent years a trend toward community-based projects has emerged, where institutions pool their talent and resources to develop products for use by the education community.

The definition of open source is access to the raw, original code of an application. The intellectual underpinning is that the code itself is at liberty—the source itself is available to anyone who wishes it. Others can modify, extend, poke around to learn, or whatever they wish. The notion is not that open source is free of cost, though often there are no licensing fees. Open source is not free of cost. It costs someone to make it, maintain it, write documentation, and so on. It also costs to learn to use, install, and modify it. This is an important distinction to make as we reflect on the many inter-institutional open source projects that are emerging in higher education. We need to think about open source not as a product or as a way of distributing code, but rather, as a philosophy about how we develop tools in the higher education community.

The projects emerging today are strategic, and they are intended to engage other people in the process from their inception. The model for these projects, called community source, is a hybrid of the two most common methods for developing software as described in Eric Raymond’s foundational essay, “The Cathedral and the Bazaar.” (Raymond, 1999)

The Cathedral and the Bazaar

The cathedral defines software developed in a typical business situation, such as when we deploy ERP systems on our campuses. It is carefully architected and engineered by experts working in an isolated project team. The cathedral doors open when the construction is complete. The cathedral process works when the problem you are trying to solve is well-understood and the way people will use the software d'esn’t change very often. The project team constrains access to the software through focus groups and beta testing, and while feedback is accepted, it rarely changes the direction of the project. The responsibility for success rests with the project team.

The cathedral model has distinct advantages. Top-down decision making helps assure that the efforts of the IT staff are directed to the priorities for the institution. It also allows us to invoke the planning needed to meet the rigid deadlines under which we work—start of school, graduation, and so on.

There are disadvantages as well. The project teams are often not in touch with the user community. Also, teams are constrained to the talent available locally. Perhaps the biggest problem is one of economics: Institutions cannot afford to build everything they need with small, closed, internally funded teams.

In contrast, Raymond offers the model of the bazaar to describe the open source world. Many people come together to create something that is larger than anyone could accomplish on their own.

The work of Linus Torvalds and the Linux community is the exemplar of a successful open source project, though there are many other successful projects as well. When Torvalds was a graduate student, he posted a note on the Internet asking if anyone had thoughts about a new version of the mimix operating system. The response was immediate and strong, and 10 years later we have a fully open source operating system that is in use on one-third of the Web servers in the world, a system that is widely held to be better than its commercially developed counterparts (Weber, 2004). It is a remarkable accomplishment. A community of volunteers works without pay, at their own pace and skill level, on whatever they want to do. In the case of Linux, hundreds of developers are active at any one time.

Successful Models

In the excellent book, The Success of Open Source, Steve Weber discusses several aspects of the Linux community that have contributed to its success. They include:

The community is made up of people who are interested in the software and the technology enough that they want to work on it on their own time. Some people are deeply involved and are heavy contributors, others less so.

The large community is leveraged in useful ways. When a problem or bug is found, or an idea is generated, the likelihood that someone can solve the problem or absorb the task is much greater than on a small team. A secondary benefit is that the open communication allows participants to know when a problem has been solved. They can look to the community for solutions before reinventing the wheel.

Open source communities are known for the lively and frank interchanges of ideas on discussion forums. Exposing all ideas to the community for conversation, allows good ideas to be generated and vetted by the community.

Successful open source projects are well-led and well-organized. Linux, Apache, and Unix have systemized ways that final decisions are made on critical things like whether code becomes part of a final production release. The organization and governance structures provide a balance to the community involvement.

Simply stated, the more people who are available to a project, the better the ideas, the greater the ability to absorb a task, the faster the work gets done, the more quickly bugs are fixed. With a greater talent pool from which to draw, it is less likely that one person will cause a bottleneck as work queues on his or her desk.

There are two fundamental problems with adopting this model wholesale for all of our projects. First, we are not all volunteers, so real money, and hence, the keen interest of our institutions, is involved. Second, it is not likely that our institutions are willing to bet the next release of a mission-critical system on the goodwill of people we only know by their screen names. We need to acknowledge that our institutions have finite budgets, no tolerance for downtime, and that we have hard deadlines. If we are deploying a new version of the CMS, it had better be done before the budget runs out; it had better be ready to go when school starts. We need control. This means that we need structured, managed projects.

Raymond presents two contrasting models, one very controlled with predictable outcomes, the other harnessing the minds of many to create a rapidly evolving product. There are aspects of both methodologies that are being extended and modified to fit the higher education environment.

The notion of harnessing the best of our brains is appealing. We know what we want, we know how to design, build, and deploy software. The sheer volume of expertise and talent in the higher education community is a huge asset for gathering ideas and creating tools.

Like the people who self-select into open source projects, institutions that opt into a particular community are motivated to work on the projects. They might be interested in the technology or perhaps in the functional aspects of a project—something draws them to it. They have an interest in getting something done. The challenge, then, is to align ourselves with each other when the ideas and timing mesh.

In successful projects, the people who participate have developed ways to work collectively and to communicate effectively. We have a long history in higher education of inter-institutional research projects. It is a short step, then, to leverage our collective talent by working together on the development of tools. This allows the best ideas to emerge and helps to avoid reinvention of the wheel.

The collaborative projects emerging in higher education are beginning to combine elements of the cathedral and the bazaar to allow us to capitalize on the elements of each in ways that fit our needs and environment. This new hybrid model is community source.

The New Community

Who makes up the new communities that we are forming? First, we find colleagues at other institutions who have similar goals, similar responsibilities, and similar timing around what they are trying to get done. We form community source projects around a common desire to get something done. The work on Sakai with Stanford University, Indiana University, MIT and, Michigan is a perfect example of this. In higher education we are uniquely suited to collaborate because we are not in competition with each other. There is no loss of income or blurring of our distinct identities when we work together on software projects. We only gain from the collaboration.

A second key component of community source projects includes the commercial partners who can provide the product support that adopters will need. The Gartner Group highlights commercial support of open source eLearning products as critical to their long-term viability (Yanosky, 2003). In the case of uPortal and the Open Source Portfolio Initiative, commercial groups are partnering with universities on the development of the products, and on Sakai, they are entering the community as support providers. Engagement of the commercial support providers helps the projects because they have expertise that university developers typically do not have, most notably, experience with many different campus environments. Also, having vendors engaged helps assure wider adoption of the open source software. People who rely on the support provided by software companies when a product is purchased are able to utilize open source products because reliable support structures are in place.

Third, our communities include funding agencies, who provide seed funding to the projects and are increasingly engaged in shaping goals, forming alliances between project groups, and using their contacts to help the community structures develop.
Finally, the new communities include all of higher education and potentially, K-12. The emerging projects are formed with a desire to engage the community in much broader ways. In part this is tightly coupled with our values as academics. We share knowledge rather than keep it to ourselves. There are also economic motivators, which include both lowering the overall cost of development to our institutions, and fostering enough movement in many projects so that we can adopt new tools as well as develop our own. However, a vibrant community requires active participation. MacKenzie Smith, et al., write, “Achieving true community requires the transformation of users who are initially consumers into stakeholders.” (Smith, 2004)

Considerations for Stakeholders

What d'es it mean to be a stakeholder? It means that as a community we have a vested interest in the success of a project, which comes from adopting, using, and relying on the tools. This begins by expanding the factors in our decision process to include adoption as an option to the traditional buy/build. Brad Wheeler counsels that there is a complex equation of elements in such a decision. Criteria include fit with the institution, user needs, costs for acquisition, maintenance and support of a system, and the current priorities of the institution (Wheeler, 2003). A school cannot afford to build everything or to participate as a contributor in every project, so each major decision requires that we review the options available to us. The cathedral model is well-known for its benefits and shortcomings, and we may continue to build applications in-house at times or make decisions to purchase commercial products when it is expedient. Adoption is also a choice. There is much less fear among IT leaders now about open source than there used to be. When a well-established open source choice is available to us, say Linux or Apache, there is really no question about adoption. None of us would take on the task of writing Web server software now when we can quickly and easily adopt something.

Wheeler also counsels that we consider to what extent we wish to control our destiny. The community source efforts demonstrate the commitment to this control by the institutions that are contributing resources. The emerging question for IT leaders is that of adoption of the products developed by community source groups. The open code is now a key factor, since institutions may extend, change, or modify in small or large ways. The criteria for decision making can now include the question of whether an institution wishes to customize the features or the look and feel of a product for local needs, as well as the extent to which integration is needed or desired. Of course, sometimes the best choice is to just install a piece of software and not invest in local modifications. The community source products will need to stand on their own merit.

The question of support often arises when considering the use of open source software. The engagement of commercial support providers in the community source efforts offers a tangible benefit to the institution considering adoption. The decision about the software can be decoupled from the decision about a support provider. If there are several companies available to support a product, they can be selected through RFP, and if their service is not satisfactory, another can be selected.

Values and Community Source

One significant value of engaging in the community source process is that it teaches us to look more widely, to be more accepting of things “not invented here,” and to think more strategically about the build/buy/adopt argument.
It almost g'es without saying that being part of a community source project is enriching for everyone involved. Pedagogical and technology ideas are exchanged, evaluated, argued, and the best emerge. We learn best practices from each other for how we work and how we think about our work. Carl Jacobson of the uPortal project comments that being a part of a community project is multidimensional; much of the value is in engaging on issues beyond the software itself. Many of us face the same set of policy issues on our campuses, e.g., regarding copyright protection and access polices for digital materials.

The community source structure gives us opportunity to converse with colleagues at other institutions about policy and practices that the digital age requires.

Even as we become more individually engaged in community source efforts, we are obliged to consider the interest of our home institutions. At what point d'es the institution reap the benefit from our involvement? This will be realized when the institution is able to use the products of many community source projects together. What if the same content could be referenced or moved easily among a portfolio, a course management tool, and a scholarly archive? Imagine that your campus portal allowed each person to access data from all the tools they use in their learning, teaching, and research in a cohesive way.

The ultimate goal of community source efforts is to develop tools that meet the changing needs of dynamic teaching and research institutions. By working together, we can accomplish more than we could do on our own.