This document has progressed through the OSS Qatch QA process and is now published on the official OSS Watch site. The text below may have been edited since publication.
The community source development model
Traditionally software is produced and distributed following either closed source or open source developments models. Community source is a development model that attempts to find a middle way between the two paths by borrowing elements from both. This document discusses the main features of the community source model, and suggests that, while useful for coordinating contributions across institutional consortia, the tendency of favoring code over community significantly undermines the sustainability potential of this model. At the same time, addressing the tensions associated with the community source model can be seen as a useful reflective step towards a deeper understanding of open source and a more mature implementation of open source development in educational institutions.
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 with reference to Eric Raymond's classic terminology, 'the pub between the cathedral and the bazaar'. This model combines closed and open governance practices, and blends elements of closed source development, in the classic sense of an organization employing staff and resources to work on a project, and 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 tendered 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 early critical 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.
Community source is equally claimed to provide 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.
Culturally specific educational funding
The community source model was initiated, and has proved to be successful, 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, 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 co-ordinate educational investments. The community source model may be more successful in the US precisely because of the highly fragmented nature of the US academic funding that requires a proper mechanism for coordinating investment.
Implementations of similar projects in Europe and Africa are currently under way. Examples include development work on SAKAI at University of Cambridge 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.
It is interesting to note that some of the largest projects that started as community source gradually moved towards open source 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 appears to have taken on board some of the lessons learnt while developing Sakai, and although it started as a community source initiative, it had clearly expressed the intention of moving to an open source model on its path to sustainability.
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. 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 realized 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 occurrence of typical open source processes - such as the emergence of a 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 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 or Sun, use 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. For instance, Sun's community source membership requires individuals to enter a Sun Community Source Licensing agreement, which, it is argued, offers them a number of benefits over either a purely open or purely proprietary source approach. 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.
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 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 in parallel with the experience of building a community. Seen from this perspective, community source is an effective catalyst for reflecting upon the deeper nature of open source, and therefore a useful step towards a more informed implementation of open source solutions across educational institutions.