Model of a Mature Open Source Project

A Model of a Mature Open Source Project

URL = http://dissertation.martinaspeli.net/deliverables/drafts/dissertation-current-draft.doc

A case study of the Plone community, and one of the few in-depth examinations and case studies of free software production models.

Thesis at the London School of Economics; MSc Analysis Design and Management of Information Systems; Dissertation 2004/05; # 459134

Author?

Excerpt

Elements of a mature open source project

In trying to answer this question, it is useful to reiterate the most important elements of a mature open source community, as described in the literature and as interpreted through the analysis of Plone in the preceding section. These elements will then be recombined to propose a theoretical model of such a community.

Project organisation and governance

The most common understanding of the organisation of an open source project is that of a strong core of developers and a larger periphery of users, bug fixers and bug reporters (Crowston and Howison, 2004). A two-tier task structure emerges (Lee and Cole, 2003), with some tasks delegated to the periphery, although the boundary between core and periphery is seldom precisely defined. Further, the composition of the core itself can be just as socially complex as that of the rest of the community, and can be subject to changes in leadership and participation, as well as the dynamics of evolving personal relationships.

Decision-making happens among the core, most active developers, and an accepted, meritocratic governance structure tends to emerge, rather than be imposed, based on trust and social capital. This in turn is based on complex social ties, which can be understood through metaphors of kinship and camaraderie (Zeitlyn, 2003). The governance is democratic in the sense that where trust is eroded and the perception of community self-governance is lost, developers will “vote with their feet” (Franck and Jungwirth, 2002) and leave or “fork” the project.

Additionally, mature projects frequently spawn more formal institutions to protect intellectual property, and represent and promote the project (West and O’Mahoney, 2005), such as the Plone Foundation. Other institutions that may be formed include business facilitation organisations like the Zope Europe Associations, or institutions representing key groups of stake-holders. However, in practice, ultimate control will tend to remain with the community and the core developers.

Culture and dynamics

The structure of the project is embedded in its culture and value system, emerging from the language, history, humour, norms and artefacts shared by the project’s members (Markus et. al., 2000). Discourse shapes the beliefs of the participants, who in turn enact these beliefs upon the software, and upon the community itself (Lee and Cole, 2003). Knowledge is embedded in the software artefact, and disseminated to project members through informal learning systems as well as documentation. Culture and social webs also fuel participants’ motivation to contribute (Tuomi, 2005).

Community cohesion is rooted in shared cultural beliefs. Fragmentation of stake-holder groups and differences in priorities and vision can be beneficial if a project’s culture makes it receptive to dialectical processes of critique and experimental variation (Lee and Cole, 2003). Project members must be able to throw out an implementation when a better one is proposed, even if significant effort went into the first attempt. Conversely, where egos are easily bruised and a willingness to resolve dispute for the good of the project is not implicit in the project’s culture, “flame wars” will erupt, and more pragmatic developers may shun the project.

A dimension of culture which warrants particular examination is that of ideology. A number of open source projects are driven to a greater extent by strong ideological beliefs in the “fairness” of the open source model, and are suspicious of non-free software. Other projects are more pragmatic in accepting outside interests, but the fundamental ideology of the open source movement is by definition an important part of any open source project (Franck and Jungwirth, 2002).

Community of practice

Bringing structure and dynamics together, the concept of communities of practice holds promise in developing a deeper understanding of the functioning of an open source project (Lee and Cole, 2003). By examining modes of belonging, the community’s definition of competence, the facilities for learning-in-action and legitimate peripheral participation, as well as the community’s boundary and mechanisms for defining identity, a researcher can better understand how the community itself is composed (Wenger, 2000). In particular, it is important to identify if and how the community is designed as an informal learning system, allowing new participants to gain legitimacy and identity by acquiring expertise, as this is the primary means by which the community grows and evolves. Thus, the reciprocal relationship between identity, legitimacy and expertise is particularly relevant to open source projects (Kimble et. al., 2001).

In analysing a community of practice, one should also take into account the possibility that it, and hence the identities of individual practitioners, may span across formal organisations, such as firms or institutions connected to the project (Brown and Duguid, 1991). Sometimes, a dichotomy of identity inside and outside the project may be beneficial in bringing in new perspectives at the boundary of the community of practice. At other times, conflicts of interests may occur.

User and business relationships

The lines between consumer and producer are usually blurred in the open source innovation process, as developers are almost always also users of the software (von Hippel and von Krogh, 2003). However, for a project to be successful, it must also attract outside interest – “real” users, who are not programmers. In the words of Paul Everitt:

It is soooo (sic) hard to get a vortex created. Meaning, enough mass, buzz, governance, and momentum to separate yourself from the 400 open source CMS projects and actually have a shot at closing mainstream sales.

When “real” users begin to show an interest, it creates a potential for business interests, too. Businesses may follow a variety of strategies, but for the purposes of understanding the community, they can be separated into two categories: Those which passively or parasitically leverage the software as consumers, integrators or service providers, and those which become an active part of the community itself, integrating their own communities of practice with that of the open source project (Dahlander and Magnusson, 2005).

Life-cycle

Finally, open source projects and products follow life cycles just like their commercial counter-parts. A consideration of whether a project is in the starting phases, trying to gain momentum, in a growing or mature stage, or in decline, will afford the researcher some ability to predict the size, cohesion and vibrancy of a community. Naturally, many projects never reach a mature stage, because the social processes and cultural factors described in the preceding sections are never initiated."