The community source development model

by Gabriel Hanganu on 22 August 2008 , last updated

Introduction

Community source is a term coined by Brad Wheeler for a type of open source project that is governed by a consortium of educational institutions. In a community source project, a number of consortium partners commit financial and human resources to a project, which is then managed using typical consortial governance.

Fundamentally, community source is an approach to consortium-based software project management, with an open source license applied to the resulting products.

Originally applied in the Kuali and Sakai projects emerging from universities in the United States, the model is no longer used by either of these projects; Kuali moved to a single-company open source project in 2014, and Sakai joined the Apereo Foundation in 2012, which operates an Apache-style foundation model. Only Duraspace, the organisation that develops DSpace and Fedora, still uses a model similar to Community Source.

As two of the most high-profile Community Source projects no longer use the approach, it has been suggested that Community Source is a failed model.

This document discusses the main features of community source development.

Hybrid development and procurement

In community source projects, a number of educational partners agree to contribute financially, or with staff time, to the development of the software. While access to the code is initially restricted to the members of the consortium, and staff time is contributed as paid work, the subsequent opening of the code allows free public access and individual contributions by globally distributed volunteers. For this reason, community source is claimed to be a hybrid model, or, to adapt Eric Raymond’s classic terminology, ‘the pub between the cathedral and the bazaar’. This model combines closed and open governance practices, blending elements of closed source development, in the classic sense of an organisation employing staff and resources to work on a project, with the openness and non-compulsory nature of traditional open source projects.

Initially, the investments of developers’ time, design and project governance are provided by colleges, universities and commercial firms rather than by independent developers. These contributions are made as the first phase of a project, then additional work is contributed on an ongoing, voluntary basis by individuals and institutions with a continuing interest in the project. In this way, it is argued, the project secures the substantial support necessary during its critical early stages. In exchange for providing the agreed staff time and resources, the consortium partners are offered exclusive access to the code, and thus an early opportunity to influence the development of the software towards their specific requirements.

Proponents of community source claim that it provides a hybrid path in terms of software procurement. The model is often perceived as a bridge between the revenue-driven corporate world and the less commercially-oriented Higher Education institutions. IT directors in the education sector usually need to decide whether an institutional software solution will be bought or built internally. Community source allegedly strikes the right balance between buying or building software to be deployed and maintained institutionally. One contributes to the development of the code, and one can adapt and use it for one’s needs, without actually owning the software. Therefore the community source model is claimed to provide a so-called ‘borrow’ path, which gives the best of both buying and building software.

Critics however point to the model as combining open source development with outdated management practices; for example, Michael Feldstein writes that:

“In practice, Community Source is essentially project management approach focused on maximizing the control and influence of the IT managers whose budgets are paying for the projects. But those people are often not the right people to make decisions about software development, and the waterfall processes that they often demand in order to exert that influence and control (particularly in a consortial setting) are antithetical to current best practices in software engineering”

Culturally specific educational funding

The community source model was initiated in Higher Education institutions in the US. Its applicability to other cultural contexts is yet to be demonstrated, given the global variation of economic and educational environments. This aspect is acknowledged by the US-based advocates of community source themselves. Brad Wheeler of Indiana University, for instance, points out that the US Higher Education funding market, comprised of many disparate financial sources, often looks ‘chaotic’ to the Europeans, who have developed an ability to centrally coordinate educational investments. The community source model may have been more popular in the US precisely because of the highly fragmented nature of the US academic funding, which requires a proper mechanism for coordinating investment.

Implementations of similar projects in Europe and Africa also took place. Examples include development work on Sakai at both Cambridge and Oxford in the UK, and Kuali at Strathmore University in Kenya. Acknowledging the cross-cultural variation of educational markets is an essential element in planning the economic and cultural sustainability of such projects. Their successful deployment outside the US largely depends on the adjustment of educational funding mechanisms associated with the community source model to the economic and cultural particularities of the respective educational consortia.

Cross-institutional administration

Projects that start as community source tend to adopt other forms of governance in their later stages.

For instance, the Eclipse project shifted from closed to community source, then gradually became an open source project. Sakai started life as a community source consortium, then moved towards open source development. The Kuali project started out using community source, then became a single-company open source project.

In all these examples, community source looks more like a transitional phase in large cross-institutional collaboration processes, rather than a software development model on its own. This observation suggests that the community source model might need to be assessed against other criteria than those normally employed when evaluating open source development.

Because community source projects tend to focus more on collaboration between institutions than between individuals, the relevant criteria for evaluation need to assess their effectiveness in coordinating economic and administrative policies, rather than building communities around the development of shared code.

A closer look at the transition from initial to later stages of community source projects like Sakai provides a useful insight into their development model. The early funding application to the Mellon Foundation, which bound the four institutional partners (Michigan, Indiana, MIT and Stanford) together, indicates that the initial focus of this community source project was not, despite the model’s name, on community. The Memorandum of Intent signed by the four university presidents essentially specified economic, legal and administrative aspects related to the institutional collaboration. According to this document, a) each institution would provide five developers to the control of the Sakai Project Board; b) the project was granted use of specific software (and associated intellectual property) that had been developed internally at Michigan and Stanford; c) the project products would be distributed under a BSD-style licence that did not restrict rights to commercialization; d) the institutions would implement the Sakai software upon the completion of the project.

The focus, therefore, was less on building a community around the software code, and more on creating an administrative framework that allowed the software versions to be produced on time and according to an agreed list of priorities.

Reflecting on open development

Favouring code over community is common in the early stages of software development. However, this attitude reveals a rather limited understanding of the relationship between these two key elements of open source development and its role in the long-term sustainability of a project. A community source project, where access to the code is initially restricted to a small, named group, can arguably have reduced management overheads, although this reduction is minimal when compared to a well-run open source project, and the project also has to overcome the additional management overhead of organising the consortium and managing negotiations between partners.

Restricted access also limits the scope of contributions and participation in the project. This is particularly important when we consider that today’s users are tomorrow’s developers. Understanding the deeper relationship between developing the code and building the community is a complex process, which even some projects that declare themselves open source fail to entirely acknowledge.

In describing the early stages of the Sakai project, Brad Wheeler recounts the period when the appointed developers from the partner institutions struggled to find an efficient way of collaborating with each other. Key to this process was finding the right balance between the priorities of their home institutions and the priorities of the newly created community of developers. That period was crucial for the project, because it was at that stage that they began to perceive community building as integral to the process of developing the code. Developers worked on the software code as specialists commissioned by their institutions, but at the same time they discovered that they were also community members in their own right, who were able to bypass institutional requirements if necessary.

Consequently, the developers realised that the quality of the code depended to some extent on the quality of the community that was being formed. This step in acknowledging the role of community was crucial in moving towards an open source model, as shown by the subsequent emergence of typical open source processes - such as the meritocracy that gradually became effective in influencing decision making within the community. From this perspective, the most important feature of the community source model is that it can provide an excellent reflection tool for reassessing open source development - on the personal, social and cultural, as well as the economic, legal and administrative, levels.

Closed community source?

An alternative meaning of the term community source exists, in addition to the one discussed so far. Some companies, such as Microsoft, used the term community source to refer to the licensing of the source code to members of a closed community, who in order to be able to access it must enter an individual licence agreement with the code owner. The modified code can be shared within the community, but cannot be made available outside its walls. In most situations, the licensing document is the key factor influencing membership rights and development practices within these communities. The main problem with this understanding of community source is that the licences proposed are in all cases incompatible with the requirements of the Open Source Definition (as specified by the OSI), which amongst other things requires free access to the source code and free redistribution of software.

Nowadays, Microsoft manages distribution of source code through a suite of licences under by their Shared Source Initiative, two of which are open source licences.

Conclusion

We can view community source as a transitional model for a number of Universities in the US engaging in collaborative open source projects at a particular point in time within the constraints of a particular management model. Its hard to imagine a new project using the community source approach out of choice rather than necessity, or to imagine a project continuing to use it when other options become available.

The value of the community source model becomes apparent only by acknowledging that the criteria for evaluating its effectiveness are different from those used to assess traditional open source development. Community source, as explored in this document, essentially involves an initial period of closed contractual collaboration between institutions that pool together resources to develop code according to a set of predetermined requirements. In contrast to this, the focus in open source is on loosely connected individuals, who may or may not represent an institution, but who all share the effort of developing code that is open from day one, in parallel with the experience of building a community.

Seen from this perspective, community source was part of the process whereby a number of institutions moved towards a more informed implementation of open source solutions.

Further reading

Links:

Related information from OSS Watch: