/!\ 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.

Community source vs open source

In traditional open source development the software code is made available for inspection and modification from the beginning of a project. The contribution of independent or institutional partners may be voluntary or may involve legally binding agreements, but essentially everyone has equal access to the code from day one. In contrast to open source development, in so-called 'community source' projects, such as Sakai or Kuali, a consortium of institutions or commercial companies sign an agreement, by which they decide to contribute a certain amount of financial or human resources, and get in exchange exclusivity in influencing the development of the project during this initial closed stage. After this closed period the code is made available to everyone, and the development moves towards a more traditional open source model. Community source is described in more detail in a related OSS Watch resource. In this document I compare the community source and open source development models, and discuss their suitability for projects involving Higher Education consortia.

Confused terminology

The distinction between open source and community source is not easy to make, mainly because the two terms are often used inappropriately. On closer inspection, many of the claimed advantages of the so-called community source actually refer to general features of open source development. Particularities such as the increased capacity for integration with other systems, the lower cost of consultancy and support, and the improved staff development and knowledge sharing skills, are ultimately consequences of opening up the audiences' access to the software code and development. Both models provide alternative revenue generating solutions that challenge traditional commercial practices based on selling licences for the use of software. Thus the often mentioned 'unbundling of software and support', which results in separating the market for consultancy services from the proprietary ownership of the code, is a general consequence of continually modifying the code and contributing the improvements back to the community.

It is possible to find models similar to community source within the open source environment. For example, some projects opt to launch in a so called 'stealth mode', that is, they operate as a truly open source development from inception, but restrict marketing information about the project during the early stages. This has the effect of permitting access to anyone who cares enough to discover the project, whilst at the same time allowing the initiating members to maintain a focus on early strategic objectives, rather than community development.

A cultural model for Higher Education?

One claimed feature of the community source model concerns its alleged suitability for the Higher Education market. From a cultural perspective, community source is often described as a perfect fit to the ethos and values of Higher Education, traditionally associated with intellectual innovation and sharing of knowledge among scholars. Like in traditional scholarly communities, community source development allegedly builds on a shared core system, without imposing any restrictions on the production of local extensions.

However, if community source projects begin with an initial closed period, there are restrictions placed on the development of local add-ons affecting those outside the initial community. During the closed period only the contractually bound partners can see and modify the code, or contribute to requirements and design discussion. This restricted sharing feature is extremely important, especially if one is familiar with the idea that sustainable open source is essentially about community development. In order to develop a community one needs to help people congregate around a 'shared core', and by restricting early contributions community source appears to force non-contractual members into 'forking' the code (at which point no common core is available for sharing any more).

Community source communities can be compared with scholarly communities only in the sense that the initial partners share a core system among themselves, unavailable to the rest of the world. The claim that community source is the most suitable development model for Higher Education is based on the assumption that collaboration in Higher Education comprises sharing information among specialist circles of academics. But can academic collaboration be perceived in isolation from the rest of the world, especially as wider engagement beyond scholarly confines becomes increasingly important today? Unlike community source, open source development is open to everyone from day one. Seen in this context, if one were to identify a suitable development model for Higher Education, the open source model would be a better choice.

Mitigating institutional risk

Another claimed advantage of community source arises from its very nature, as community source projects are essentially meant to coordinate institutions rather than individuals. The early stage contractual consortium appears to be a less risky financial solution for the partners involved, as the restricted sharing of the code seems more appropriate than opening it to everyone. In many situations community source is preferred over open source for fear that the latter may result in unpredictable veering of the project towards the interests of unknown contributors.

However, this anxiety reveals a common misconception about open source. Open source projects do not actually carry an increased risk of being 'hijacked' by unknown contributors. In open source projects 'read' access to the code is provided, along with a right to modify it for personal use, but this does not result in a guarantee that these changes will be included in the project source. A community-minded project will encourage contributors to supply modifications, but the project is under no obligation to take them on board. A move to open source does not necessary reduce the control, unless the project management want it to. For instance, Linus Torvalds is still the only person who can put code into the Linux kernel. It is true to argue that he has to listen to the community, otherwise they will create a separate project, as is their right to do. This ability to fork is also present in community source projects once their code is released.

In fact it can be argued that there is (potentially) an increased risk in using a community source model. The initial contract may be useful for clarifying the partners' obligations, but the strategic priorities of a partner may change over time, or there may be internal dispute over the best way to achieve the project objectives. Nevertheless the project partners will continue to be contractually obliged to pump money into what may turn out to be a less than optimal solution. The initial contract keeps people tied even in the case of a failing project. In open source projects there is no such obligation, only community pressure. Open source models do not lock people into projects. If the project is successful the outcome is the same as in a contract-based one, but if it fails, it fails fast, as partners can quickly pull out.

Early contractual consortium

Since institutional partners that have contributed resources have more decision making power, it can be argued that the participants in a community source project are not equal. Community source advocates maintain that this is only true for the initial stage of the project, during which time such inequality cannot be avoided. Since community source can only start off with large institutional pooling of resources and injection of external funds, it is normal, they say, that the consortium partners are given pre-eminence and an opportunity to influence the initial trajectory of the project.

However this early stage is often far more important than the subsequent ones, and by restricting code and development access to the consortium members it can be argued that the potential for wider buy-in is limited and the natural development of the community is hampered. In open source the partners would be the initial project management committee, and these persons may even be contractually obligated to one another. The difference is that in open source access to the code and development is open from day one, and more partners can work their way into the project by adding new resources at a level appropriate to their need. The more resources they add, the more influence they get, as they move from user to contributor, to committer, to project manager. Partner status and decision making power are measured in terms of actual work delivered, as opposed to financial investment.

In community source, projects that treat early consortium members as 'more equal' than others may in reality be discouraging partner contribution. Additionally, the initial contractual agreement may foster bad feelings between the members who have contributed financially and those who have come on board late in order to participate, as it were, 'for free'. Even when the partners are considered equal, the consortium members may feel frustrated, as having made significant contributions to a project in the early stages, they continue to be perceived as having more control by the newer members of the community. The Eclipse Foundation, for instance, is still struggling with this issue, although there is an increasing number of members on Eclipse Foundation projects who were not part of the original consortium.

Conclusion

Community source and open source share similar motivations, but their approach to development is quite different. While open source projects believe it is better to release early and release often, community source projects attempt to create largely complete products before opening up access to the development process.

Some of the claimed advantages of community source, such as increased capacity for integration with other systems, or lower cost of consultancy and support, are in fact general features of open source development. Other features, such as appropriateness to the Higher Education culture of sharing, or the ability to mitigate risks associated with divergent interests of contributors, appear difficult to sustain when analyzed in the context of open source development.

Running community source projects across Higher Education consortia can be very appealing administratively, but the lack of openness during the initial stages of development can seriously undermine their sustainability potential. The lessons learned from community source projects are extremely useful, and they should be used to reflect on the deeper nature of open source development and its potential impact upon UK Higher Education.

Further Reading

External resources

The SAKAI Foundation

The Kuali Foundation

The Eclipse Foundation

Open Source 2010: Reflections on 2007

Invest locally

The Future of Open Source in Higher Education

Mitigating the Risks of Big Systems

Software and Collaboration in Higher Education

OSS Watch resources

Community source development model

Sakai: a case study in sustainability

How to build an Open Source community

OSSWatchWiki: CommunitySourceAndOpenSourceDevelopmentModelsCompared (last edited 2013-04-15 13:56:16 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.