Sustainability and Governance in Developing Open Source Projects

From P2P Foundation
Jump to navigation Jump to search


* Sustainability and Governance in Developing Open Source Projects as Processes of In-Becoming. Daniel Curto-Millet. Technology Innovation Management Review, January 2013.

URL = http://timreview.ca/article/649


Description

"Daniel Curto-Millet, a doctoral student at the London School of Economics and Political Science in the United Kingdom encourages us to ontologically redefine sustainability. His study of openEHR and the Opereffa framework have shown him how sustainability is not a state that is stable (even in its desire for stability), but instead sustainability is a process where the multitude of actors, artefacts, archetypes, and so on, and are all in constant flux. He thus feels we need to conceptualize sustainability in a manner that allows us to make sense of it processually – in other words, as in "becoming" (Deleuze and Guattari, 1987). In order to be able to do this, he draws our attention to everyday negotiations, working outs, and engagements that openEHR and its larger ecosystem perform with and within to achieve a more detailed understanding of sustaining (and not sustainability)."


Excerpts

Daniel Curto-Millet:

Why Open Source Governance Should Be a Verb

Typically, it is understood that a project is open source if its license conforms with criteria set by the Open Source Initiative (OSI). At its foundation, open source is a static, legal definition describing what can be done with the source code (Perens, 1999; Raymond, 2001). Whether this matters at all to the general public, or whether it has any immediate effect beyond the development team, is a problem known as the "Berkeley Conundrum" (Fitzgerald, 2003). It matters when considering the reaches that code as law can have, the specific mechanisms of social control it can induce, and the implications to democratic values (Lessig, 2006). Lessig's view is more political, less static. His concern turns from legal code to one of consumption, production, and social responsibility. These issues are even more relevant given the new domains, into which open source has entered and which are far away from its academic and hacker origins (Fitzgerald, 2006; Lindman and Rajala, 2012). When discussing open source and archetypes (abstract representations of meaningful clinical concepts in EHRs), a board member says:

"When I hear open source I tend to think software rather than knowledge so it’s quite different. So the philosophy is, the issue is how do you know when an archetype is good. How do you know, the phrase is, how do you quality assure a model? That your fellow colleagues, the developers, that national governments know that this archetype is safe, doesn’t contain manifestly bad practice, whatever. And most people take the view that of a kind of waterfall approach, so you get the great and the good and the wise say what the requirements are, some clever people [...] develop the archetypes, and then we pass this off to a standards body, [...] have some experts, blood pressure experts who say oh yes, yes, yes, that’s right, they tick the boxes, they will have some formal criteria against which they’ll be marking the archetypes and they will pull in experts, maybe cardiologists. Now I just don’t think that’s going to happen. I don’t think it is possible to know when an archetype is good enough." [emphasis added]

This quotation evidences the new nature of open source software, away from the code, in the knowledge realm; it shows some of the values and goals associated with using an open source approach (quality through edition, diffusion, and acceptance of the archetypes; open source rivalling with standards bodies as an institutionalizing power; and continual and acceptable change. "When is an archetype good enough?" Who can answer that other than someone following an open source process?

Open source, and the artefacts it engenders, are definitions in the making, processes, arguments, and particular engineering models. The knowledge engendered is not a thing, a static good eventually catalogued, it is potentially embedded in a continual process of being made, of evolving. Given that an open source commons is an ongoing construction that can never be considered "finished", it can be difficult to place a commons in time and ask the question: "When is an open source commons?" To answer the question, and to understand why it is so difficult to answer, we must study the nature of these commons.


Open Source Commons Through Open Source Collective Actions

Ostrom's work was framed by the economics of resource scarcity. Notably, one of the spin-offs of her framework helped inspire a framework on social-ecological systems (SES) (McGinnis, 2011). How can Ostrom's work be useful in a field where what is abundant or scarce is not one of the usual resources that we think of (Anderson, 2009)?

What is an open source commons? According to the static, legal definitions of open source, the code is the foremost of commons. It is the central artefact to which people are contributing. However, focusing only on the source code is limiting, because it does not take into account the entirety of what Ostrom calls the "action situation", where actors interact and evaluate outcomes (Ostrom, 2011). In open source, this is not one physical space, but many interrelated ones (e.g., presence in the code, in the mailing lists, in the documentation, in the IRC channels, in the annual conferences, even in the press). It is useful to see that open source is not just online coding, but that it occurs in a wide variety of different media. The rules and engagements are likely to be different in each media, and the ownership of those different spaces depends on various rules and norms of engagement. Ciborra would probably say that these technologies carry different "necessities of hospitality" (Ciborra, 2004).

The notion of an open source commons is also a fleeting one, with the increasing range of domains into which open source is entering (Fitzgerald, 2006). The complexity of what a common is, and therefore, the ownership of those commons is much more complex than it used to be. As an example, openEHR could be said to have several layers of commons. The project's goal is to become a standard in health by defining and creating archetypes that in turn define meaningful clinical concepts. These archetypes are based on a reference model that has become an established standard. The reference model was principally inspired by the efforts of openEHR and other previous projects in which the core members participated. Archetypes are potential clinical requirements for any system that adopts openEHR; they describe clinical concepts such as blood pressure. To define archetypes, the openEHR foundation proposes two editors, one from a company with goals closely aligned to the foundation, and another from Linköping University. The editors themselves are based on parsers that understand the Archetype Definition Language (ADL). When archetypes are drafted, they are placed in the Clinical Knowledge Manager (CKM), which is a repository of archetypes where they can be discussed, analyzed, reviewed, approved for publication, translated, etc. On top of that come templates, which are supposed to instantiate the deliberately generalized and generalizable archetypes to particular contexts of use.

Now, all of these are resources in the making. All these layers can have their own licensing, and, maybe more importantly, have their own interrelated action situation. How could this complexity be managed without undue reduction and simplification? How should these "crops" be studied? What should an archetype look like? Who decides what it should accomplish? Once again, because of the continual, in-becoming nature of knowledge-commons, we fall back to the true commons in openEHR, and in many other open source projects: processes of creation. The processes involved and the knowledge created are so entangled that it is difficult to distinguish the assemblage of actors from the processes they are driving that not only try to reshape the world, but come to a collective understanding of their own collective actions. Since there is no "when" bounding the creation of knowledge-commons to a specific, well-defined time, the next logical step is to study how these knowledge-commons are created, and what are the processes that sustain them.


The Sustainable Processes: Creating Abundant Commons

Sustainability in open source refers to the project's ability to support itself over time (Chengalur-Smith et al., 2010). It has already been studied, especially through the lens of the community, free-riding, and project size (Lerner et al., 2000; 2006).

Recent efforts have looked at processes instead of static commons. Studies have shown that power relations are important in the process of contributing to the source code (Iivari, 2009; 2010). Also, values, culture, and organizational shifts have been identified as key issues in the adoption of open source into corporate processes (Lindman and Rajala, 2012; Shaikh and Cornford, 2009). Finally, technology has been seen to play a role in the way it enables collaboration in a distributed scale (Laurent and Cleland-Huang, 2009; Noll, 2010; Scacchi, 2009).

It is difficult to place a taxonomy to the current study of open source precisely because of the evolving understanding of its complexity. Open source is a negotiated concept, and the processes of creating open source software can be competitive and conflictive, and it can disrupt technologies beyond expert walls. It is becoming an abstract political machine, shifting itself to accommodate new ideas, pushing for changes (Deleuze and Guattari, 1987). Open source becomes a way to diffuse innovation and to act upon it. When asked about the use of open source in developing software in multiple-expert-domain, an interviewee said:

"Well, you could argue that you don’t need open source to build that relationship, but the thing about it is that, if you want to build an ecosystem of clinicians and developers all collaborating around the same software, let’s say around the NHS [National Health Service], then it needs to be generally open source, or at least the clinical models need to be open source."

Open source becomes an enabler and an enactor of ecosystems. Through its links to its rooted academic history, to the hacker folklore which is slowly dissipating, to the corporate worlds it is entering, to the legal definitions that impose obligations and grant rewards, and so many other links, it creates a viable alternative to the development of worldly projections. Some would say that it has created itself as an obligatory passage point, an indispensable question that has to be asked when thinking about developing a new software project (Callon et al., 2009). "Should we go open source?" is implanted in practice, just as the software engineering norm "don't reinvent the wheel" has been impressed into every computer scientist. Another interviewee said:

"And the rigour bit, for me, in the scientific world, most of physics couldn’t exist without open source software, because that’s the way people, you know, software is extraordinarily complex, unless you’ve actually got it in your hand and you work with it, you don’t really know. And there’s so much software around in the world that nobody really knows that... And it gets sold for millions and millions of pounds and then it turns out to be not what people wanted. We really need the practitioners in the field to be much more grounded."

This quotation emphasizes another aspect of open source development processes: it is sustainable through the scientific, rigorous, transparent values that it enacts by the publishing of the artefacts. This definition encapsulates the requirements engineers' philosopher stone: how to build the correct system above building it correctly (van Lamsweerde, 2009; Letier and van Lamsweerde, 2004). In other words, how can the proper processes be employed that will ensure that a useful system is built? This brings the discussion full-circle back to the governing of open source.


Governing Open Source: Sustainability is a Process

If the processes are so important in defining continuous knowledge-commons that spring out of open source, how should their management be studied? Can they be managed at all? Clearly, knowledge-commons require continuous efforts, but how can their processes be sustainable? Going back to Ostrom's work, the cited interviews lead us to wonder how sustainable processes can be governed in open source. Actors, it is argued, are one of the principal elements.

In institutional theory, a major component of sustainability is the shared meaning given to norms (Ostrom, 2011). A shared meaning, even inside open source contexts implies some form of stability. As Schweik and English (2012) put it: "Institutions – social norms and formalized rules along with established mechanisms of rule creation, maintenance, monitoring and enforcement – are the means through which direction control and coordination can occur." This assertion presupposes an establishment of stabilizing forces throughout open source projects. It is worth wondering to what extent these are accepted, if not debated openly. In open source, even basic and fundamental assumptions are put into question, forming part of the learning process (Dueñas et al., 2007; Shaikh and Cornford, 2004). Also, given the usually informal nature of open source software development, how can the invisible, tacit rules be taken into account (Iivari, 2010)? Are stability and sustainability too strongly associated? Are order and routine erroneously taken as the norm (Tsoukas and Chia, 2002)?

Ostrom's work helps when analyzing institutional norms and dysfunctions in the governance of commons. Through the identification of dysfunctional institutions, we can ponder on the tensions between sustainability and stability in open source. Usually, taken together, dysfunctional institutions give the impression of instability, and open source can be seen as such a disruptive force (Carlo et al., 2010). Could instability contribute to maintaining sustainability? If projects become too stable, they could end up losing momentum. Shaikh and Cornford (2004), found that the learning processes in open source vary depending on the community, technology, code, and even basic, concepts that are questioned but induce collaboration and conflict. Thus, stability is, just as sustainability, a relative concept. This is on par with Ostrom's research, where actors evaluate previous outcomes of an action situation, opening the door to much more chaotic and irregular evolutions. When defining actors, Ostrom limits the set to "single individuals or as a group functioning as a corporate actor" (Ostrom, 2011). This is somewhat limiting, but given that the intended audience were economists, as information systems scientists, we can enlarge the population of actors to other entities, agential or not.

In Ostrom's work, actors play an important role in the governance of projects. The actors form an integral part in shaping the processes of creation. What actors contribute to the sustainability of open source processes, and in what degree? This is a difficult question to answer, and will likely depend on the project. But the list is much more varied than it would otherwise seem. Entities understood as economic resources are much more than static objects devoid of action. Some even attribute sentiments to them (Ciborra, 2006). Commons (knowledge or otherwise) are not only resources, they are living entities to which are assigned and which themselves assign centres of gravity and inscribed behaviours. Their properties, their beings are infused with materiality. They are well and alive, and they have an enormous influence, despite being "things". Take another quote from an openEHR board member in a recent project board meeting:

"The analogy that comes to mind is the interaction between publishers and librarians. In the context of librarianships, you have national repositories [...] you have some kind of governance framework around the numbering and cataloguing [...] and you have an ecosystem of publishers. You need a new kind of governance which recognises the curation, the librarianship, the skills, is an analogy related to books, there's going to be a correlate of that in the context of archetypes, templates, and there's also going to be a world of publishers."

The recent debates in the publishing world have provided an analogy to explore and understand how the project itself could or should evolve. It is a new exploration to different types of worlds that appear unexpectedly open. Who could have thought at the beginning of the project that it could learn from the publishing industry?

The knowledge-commons mentioned in this quote (i.e., the archetypes and templates) are thought to be static resources, which, in a matter of seconds, are disembodied, reshaped, and reformed into academic papers, peer-reviewed journals, processes of governance, and curation of books that are seen to merit their emulation. The properties of these knowledge-commons are so flexible in their definition and their processes, that they escape the static view attributed to actor-objects to such an extent that they evade the boundaries between objects and subjects. This is relativism. The knowledge-commons, what they are and what they could be, tear and pull at the project members, influence their view on their governance, and even demand curation.

In this sense, governance is not merely accepted and established institutions, rules, and norms, but also projections of possible worlds, competing values that define the project's essence, historicity, past arguments, motivations, and many other fleeting concepts (Scacchi, 2002). And hence, the difficulty to understand open source projects only through the evaluation of outcomes, when the worlds that are projected are so difficult to grasp. What IP license should be applied to what artefacts? What effect will the licenses have on the uptake by future community members? These evaluations depend, not only on outcomes, but also on the chaotic projections of possible worlds; they may lead to a positioning of the project in some way or another, yet will remain malleable and subject to change. What might be interesting to study are the efforts to cement those evaluations, to create those fleeting institutions, or as Callon would put it, to objectify them (Callon et al., 2009).

Thus, the evaluation and exploration is not without consequences. Opening the project to the outside and questioning its internal processes is crucial in the sustainable governing of open source. The actors, intentionally or not, initiate a tentative alignment with possible worlds, embracing uncertainty so as to better cope with it. Does openEHR have the necessary mechanisms to "curate" archetypes? What would a curated archetype look like? What are the processes that need be implemented for allowing the archetypes to fit unknown requirements? Is the project relevant in this new world? A seemingly invisible negotiation takes place to align the project to possibly relevant new actors.


Conclusion

This article tried to problematize the nature of sustainability in open source software. Given the open properties of the knowledge-commons present in open source, their management is much more amenable to changes. Continuous efforts are made to sustain the project and adapt it to the demands of the changing environments, sometimes questioning basic concepts, their purpose and meaning. Sustainability, therefore, is much more than a simple binary state, but the continuous efforts of assemblages of varied actors (technologies, democracy, quality through diffusion and adoption), unexpected alliances (publishing world), collective efforts, and values. These actors are crucial to the sustainable governing of open source. Their efforts and enactions, supported by their values, forces open source projects to explore worlds it had not imagined, in turn questioning its own place and purpose, and the adequateness of its processes.

Sustainability in open source, therefore, is not a one-time buy-in option. It is a continuous process of engagement, of negotiation of even basic concepts. Sustainability depends on the evolution of commons created by project communities. New communities can, sometimes unexpectedly, become integrated into the project, redefining the contexts of use, processes, and purpose. The project, then, is introduced into arenas that were not anticipated. In this article, I have attempted to make apparent that the development of open source projects needs a considerable amount of rethinking in terms of governance, which can only be achieved through the understanding of specific open source concepts: principally, the in-becoming nature of commons and underlying processes of development, particular values, fluctuating contexts of use and boundary-less sourcing of requirements." (http://timreview.ca/article/649)


Source

  • Special Issue: Open Source Sustainability. Ed. by Chris McPhee and Maha Shaikh. Technology Innovation Management Review, January 2013.

URL = http://timreview.ca/article/643

Maha Shaikh:

"This issue contains seven articles relating to the theme of open source sustainability. The authors come from diverse backgrounds and geographical locations, including Canada, Finland, France, Spain, the United Kingdom, and the United States."

Retrieved from "https://wiki.p2pfoundation.net/index.php?title=Sustainability_and_Governance_in_Developing_Open_Source_Projects&oldid=68972"