The community source development model
by Gabriel Hanganu on
Traditionally, software is produced and distributed following either closed source or open source development models. Community source is a development model that attempts to find a middle way between the two paths by borrowing elements from both. Community source and open source are compared in more detail in the Community source vs open source OSS Watch briefing note. This document discusses the main features of community source development, and suggests that, while useful for coordinating contributions across institutional consortia, the tendency of favouring code over community could have an impact on the sustainability potential of this model. At the same time, addressing the inherent tensions of community source can be a very useful step towards a deeper understanding of open source and of a more mature implementation of open development across 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, 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.
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 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 be more successful 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 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.
Some of the largest projects that start as community source gradually move 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 has 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 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. However, restricted access will also limit 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.
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 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.
- The Sakai Project [http://sakaiproject.org/]
- The Kuali Foundation [http://www.kuali.org/]
- The Eclipse Foundation [http://www.eclipse.org/]
- Open Source 2010: Reflections on 2007 [http://www.educause.edu/apps/er/erm07/erm0712.asp]
- The Cathedral and the Bazaar [http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/]
- Glass Cathedrals and Community versus Code [http://osofbiz.blogspot.com/2008/01/glass-cathedrals-and-community-versus.html]
- Mitigating the Risks of Big Systems [[http://www.nacubo.org/Business_Officer_Magazine/Magazine_Archives/July-August2007/Mitigating_the_Risks_of_Big_Systems.html](http://www.nacubo.org/Business_Officer_Magazine/Magazine_Archives/July-August2007/Mitigating_the_Risks_of_Big_Systems.html)]
- Software and Collaboration in Higher Education (pdf link)[http://www.ithaka.org/strategic/OOSS_Report_FINAL.pdf]
- Kuali implementation at Strathmore University, Kenya [http://www.strathmore.edu/news/kuali-implementation.php]
- Sakai development at CARET, University of Cambridge, UK [http://www.caret.cam.ac.uk/jiscvre/index.html]
- WMWare Community Source Program [http://www.vmware.com/partners/programs/alliances/co-dev/community-source.html]
Related information from OSS Watch: