Community source vs open source

by Gabriel Hanganu on 25 August 2008 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.

Introduction

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 and Kuali, a consortium of institutions or commercial companies sign an agreement whereby they decide to contribute a certain amount of financial and/or human resources, and get, in exchange, exclusivity in influencing the development of the project during an initial closed stage. After this closed period, the code can be made available to everyone, and the development moves towards a more traditional open source model. Community source is described in another OSS Watch briefing note. This document compares the community source and open source development models, and discusses their suitability for consortia of Higher Education institutions.

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 model 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 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.

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 education?

One claimed feature of the community source model concerns its suitability for the Higher and Further Education market. From a cultural perspective, community source is often described as a perfect fit with the ethos and values of education and research, traditionally associated with intellectual innovation and the sharing of knowledge among scholars. As 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 discussions about requirements and design. 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 anymore).

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 the education sector is based on the assumption that collaboration in 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, the open source model could be a better choice for academic development activities.

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 ‘safer’ 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 necessarily reduce the control, unless the project management wants it to. For instance, Linus Torvalds is still the only person who can put code into the current development branch of 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, but the community cannot force him to take a direction he believes to be inappropriate.

In fact, it can be argued that there is (potentially) an increased risk in using a community source model. The initial contract between collaborators 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 for their individual needs. 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 or fork the projects as appropriate. This puts social pressure on the project to ‘do the right thing’ for the community as a whole rather than for a small number of influential partners.

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 the 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 it can be argued that by restricting code and development access to the consortium, members 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 people 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. In practice, the more resources they add, the more influence they get, as they move from user to contributor, to committer, to project management. Partner status and decision making power are measured in terms of actual work delivered, as opposed to financial investment.

Community source projects that treat early consortium members as ‘more equal’ than others may in reality be discouraging volunteer contributions. 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 education sector’s culture of sharing, or the ability to mitigate risks associated with divergent interests of contributors, appear difficult to sustain when analyzed alongside open source development.

Running community source projects across education focused consortia can be very appealing for the purposes of administration, 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 and Further Education.

Further reading

Links:

Related information from OSS Watch: