Values of Community Source Development
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
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.
In the excellent book, The Success of Open Source, Steve Weber discusses
several aspects of the Linux community that have contributed to its success.
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
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,
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 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
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
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.
Frederick P. Brooks (1995). The Mythical Man Month: essays on software
engineering. USA, Addison-Wesley.
Margaret S. Elliott, Walt Scacchi (2003). Free Software: A Case Study
of Software Development in a Virtual Organizational Culture. Irvine,
CA, Institute for Software Research, University of California-Irvine.
Eric, Raymond (1999). The Cathedral and the Bazaar. Sebastapol, CA,
MacKenzie Smith, Richard Rodgers, Julie Walker, Robert Tansley (2004). DSpace:
a Year in the Life of an Open Source Digital Repository System. Cambridge,
MA, MIT Libraries.
Ron Yanosky, M. H., Michael Zastrocky (2003). Higher-Education E-Learning
Meets Open Source. Gartner Group.
Stephen Weber, (2004) The Success of Open Source. Cambridge, Mass.:
Harvard University Press.
Brad Wheeler, (2003). Aligning IT Strategy to Open Source, Partnering,
and Web Services. EDUCAUSE Center for Applied Research. Boulder, CO.
Brad Wheeler, (2004). "Open Source 2007: How Did This Happen?"
EDUCAUSE Review 39(4): 12-27.