LAYERED COLLABORATIONjames.howison.name/pubs/HowisonLayeredCollaboration.pdf · AND OPEN SOURCE...

LAYERED COLLABORATION:

A SOCIO-TECHNICAL THEORY OF ORGANIZATION IN FREE AND OPEN SOURCE SOFTWARE DEVELOPMENT

James Howison1 Carnegie Mellon University

[email protected]

Abstract

This paper develops a theory of layered collaboration in the development of community-based Free and Open Source Software (FLOSS). The theory is developed through a research arc of discovery (participant observation), replication (two archival case studies) and formalization (a model of developer choices). The theory explains two key findings: the overwhelming majority of work is accomplished with only a single programmer working on a task and when tasks appear too large for an individual they are more likely to be deferred until they are easier than be undertaken through structured teamwork. It is theorized that this way of organizing is successful because it fits with the motivations of the participants, the key technologies of FLOSS collaboration and the nature of software as an IT artifact. The theory, and the empirical findings in which it is grounded, are important because they enable a systematic approach to understanding the implications of FLOSS development as a model for adaptation and the future of informationalized work. Accordingly, the discussion enumerates the conditions under which this theory of organizing is likely to be successful, many stemming directly from software—an IT artifact—as an object, rather than just a facilitator, of collaboration. These are used as a framework to analyze efforts to adapt the FLOSS model of organizing for self-organizing, virtual teams in other domains of work.

Introduction

What if you had to organize to not only do something great, but also to attract the very people you need to do those great things, without any money at all? How might that organizing—that way of working—look? A great deal of literature has studied the more common case of organization in which the future availability of resources is assumed: teams are studied working, but only after members are assigned; partnerships between businesses are studied after their members are engaged. Typically this inquiry rests on the knowledge that participants are paid for their involvement and, quid pro quo, they offer their working time as a resource for an active management pursuing a goal of organizational efficiency.

Increasingly, however, the future of work seems unlikely to look like this, particularly with the growth of virtual teams and distributed work supported by information systems. Simply offering money and then telling people what to do isn't always enough to attract the best and brightest, and even if they are attracted it might not be enough to hold onto them or to ensure that they do their best work. Skilled workers, especially in-demand knowledge workers, might better be understood and managed if they were perceived as acting like volunteers (e.g., Barnard et al. 1968; Cook 2008; Drucker 2002; Handy 1988; Malone 2004).

This paper examines the question of the impact of motivations on the organization of virtual work, particularly work where the participants are distributed volunteers. This question is doubly important to the field of Information Systems. Firstly, recently new phenomena with these characteristics, such as free 1 I am very grateful for the support and advice of Kevin Crowston, my PhD Advisor at the Syracuse University School of Information Studies and the US NSF (03-41475, 04–14468, 05-27457 and 07–08437).

Howison—Layered Collaboration. Version: 27 September 2009

Working Paper—Please do not cite without checking with author for updated version 2

and open source software development and Wikipedia, have emerged to great acclaim, each supported by information systems. Secondly, it is hoped that traditional business organizations, and particularly the IS function, can learn from these phenomena. These questions are doubly important because the phenomena offer potentially alternative methods of accomplishing work traditionally considered part of the IS function (software development and knowledge management) and they are occurring via innovative Information Systems.

Specifically this paper focuses on free (libre) and open source software development, herein abbreviated as FLOSS. FLOSS is a canonical type of distributed, online production (e.g.,von Hippel & von Krogh, 2003; McLure Wasko & Faraj, 2005). The projects studied in this paper are community-based FLOSS projects, meaning that they have no institutional existence (e.g. non-profit foundations) nor do they have significant corporate involvement; in this way the projects chosen epitomize what is most novel in the FLOSS phenomenon; its least hybridized form.

Existing research on FLOSS development has concentrated in three areas: inputs (including motivations), processes (such as coordination or governance) and outputs (such as implementations or software quality). It is established that FLOSS participants are driven by a variety of motivations (e.g., Feller et al., 2005; Ghosh et al., 2002; Lakhani & Wolf, 2003; Lakhani & von Hippel, 2003), including the need for software itself, learning, ideological commitment and, particularly for long-term participants, reputation, although perhaps not to the degree suggested by economists (e.g., Lerner & Tirole, 2002). While there is a growing contingent of participants who participate as part of a paid job, in the community-based projects that this paper focuses on most participants are participating in their “spare time” (Luthiger & Jungwirth, 2007). Process research has focused on coordination, documenting the prevalence of practices such as self-assignment of tasks (the essence of volunteerism), “short-cut” decision making processes as well as a tendency to “code first” and then work together on integration (e.g., Crowston et al., 2005; Yamauchi et al., 2000). Another line of research has examined knowledge flow processes between FLOSS projects (e.g., Daniel & Diamant, 2008). Literature examining the outputs of FLOSS projects includes research studying software quality (e.g., Schach et al., 2003) and work establishing a definition for IS success in the FLOSS context (e.g., Crowston et al., 2006). Unfortunately there are very few studies which link across these areas, linking motivations, organization and success, with the closest work being that which draws on the job design tradition (e.g., Hertel, 2007) or work contributed by academics with strong practitioner backgrounds in FLOSS, such as Michlmayr (2007, 2004) who emphasizes the volunteer environment as fundamental to the organization of successful FLOSS production. This paper contributes to existing literature on FLOSS by linking motivation and process, arguing that by looking at these together one can understand the FLOSS phenomenon better.

Research on the organization of work has paid particular attention to the concept of interdependence. A strong line of literature has argued that structures embedded in the work itself determine the type of organization most suited to that work (e.g., Thompson, 1967; Van de Ven et al., 1976; Malone & Crowston, 1994). Recently, however, this line of thinking has been challenged by studies driven by a practice view of work (e.g. Shea & Guzzo, 1987; Wageman, 1995; Wageman & Gordon, 2005). The challenge suggests that similar work can be accomplished well with very different patterns of interdependence, and moreover that patterns of appropriate interdependence are driven as much by factors such as individual preferences and technological affordances as by unchangeable requirements of work. This paper attends to a gap in this literature by introducing the impact of participant motivations on patterns of interdependence and work. It argues that they are important even when building software collaboratively, a task where the technical interdependence of the work has been held to be especially important (e.g., Herbsleb et al., 2001).

The overall purpose of this paper is empirically grounded theory development, which is undertaken though an unfolding arc of discovery, replication and formalization. Discovery consisted of four years of participant observation in a community-based FLOSS project, replication consisted of an archive-based field study in two similar FLOSS projects. Finally the theory is elaborated and formalized through a



rational expectations model of developer decision-making. The discussion of the paper is in two parts. Firstly I examine the specific role of the IT artifact (Benbasat & Zmud, 2003; Orlikowski & Iacono, 2001) in supporting this model of organizing, focusing on the affordances of IT artifacts, especially as the object of work and their interaction with the resource environment faced by these production communities. Secondly, drawing on this discussion, I examine the challenges of adapting FLOSS organization for other types of work and institutional environments, including the IS function in traditional, for-profit businesses.

Discovery: Participant Observation

The author participated in and observed the BibDesk project, which is a community-based FLOSS project to build a reference manager akin to Endnote. Participant observation began with the sensitizing concepts of motivation, coordination and dependency and continued, with periodic returns to the literature, for four years. There is insufficient space to relate this participation in detail, so I present only illustrative examples of the experiences that drove the remainder of this paper.

In particular two aspects of organization that had not been considered in the existing FLOSS literature particularly stood out: work (both mine and that of others) was accomplished primarily through short, individual tasks that built on previous work, while complex work was deferred indefinitely, only being undertaken when a changing codebase had made it easier.

2003 email (on discussing a desirable feature):

I really want to use this, but the conditions have never quite been right - either I was waiting for … RSS+RDF (now looks like it'll never happen) or … an XML bibliographic file format … (could happen now, but I ran out of free time).

2007 email (on checking in working code for this feature):

It was much easier than I expected it to be because the existing groups code (and search groups code) was very easy to extend. Kudos - I wouldn't have tried it if so much hadn't already been solved well.

Table 1: An episode from BibDesk, discussing the ability to subscribe to online reference lists. These two emails were sent four years apart: the complex work was deferred until other work, done for its own purposes, had made the original

desired feature possible to accomplish through short, individual work.

Table 1 illustrates these aspects through two emails from the project founder (not the researcher), written four years apart. The first email is a response to a suggestion I made in one of my first emails to the project, the project founder believed it would be a useful feature, but was not able to begin work on it. I also found the task too complicated for the periods of time I was able to devote to the project. The task was thus left languishing. Four years later, somewhat out of the blue, the project founder (by then relatively inactive) contributed the feature, emphasizing that, in the intervening years, work by others had made the task “much easier”. Further, the context of the discussion indicated that the work had been completed in a matter of days.

Introspection, afforded by participant observation, on similar episodes I experienced pointed to the involvement of two aspects of volunteer motivation. Firstly I was only able to work on the project in my “free time” and my free time did not come consistently, therefore I was not keen to take on tasks that I did not feel I could finish in the time I knew I had available. Secondly, I worked alone because I did not want to rely on the free time and commitment of others to finish my work; I felt I had “no right” to request their time and since their commitment was unpredictable I could not rely on their portion of shared work being completed. This experience agreed with my observation throughout the years that in almost all



cases there was just a single developer actively writing code for any particular change, something I confirmed through a systematic examination of the project archives (similar, but less formal, to that presented below).

Replication: Archival Case Studies

In order to deepen, strengthen and challenge the insights gained from participant observation, I undertook an archive-based field study. The specific goal of the study was to see whether the findings from the participant observation, specifically the layering of short, individual episodes of work and the deferral of complex work, could be replicated. For this reason cases similar to BibDesk and to each other were selected: Fire and Gaim, both community-based instant messaging clients hosted on Sourceforge.

Participant observation had indicated that work proceeds, and is inscribed in, many project venues, and a coherent understanding of the project’s organization could not be obtained from single venues, such as the mailing list, alone. Therefore data was collected to be as comprehensive as possible: Mailing lists, Source code repositories (CVS and SVN), Forums, Issue Trackers and Release Notes. Participant observation identified the period between two releases as a natural and meaningful periodization of the projects’ work life, so, using the concepts above, I analyzed an inter-release period (approximately 45 days) for each project, chosen to be close in calendar time so the projects work would be dealing with similar external contexts.

I developed a set of concepts for organizing the work of the projects. I defined a Task Outcome as a change to the shared outputs of the project, usually the software but also including documentation or the project website. A Task, then, was a series of Actions undertaken by Participants contributing to the Task Outcome. Documents, such as emails or CVS check-ins or log messages, provide archival evidence of these Actions. Table 2 shows definitions of these concepts.

Concept Definition Example

Document Archived Content Email message, Tracker comment, Release Note

Event An Event causes a Document, or many Documents, to be archived Sending an email, releasing a version

Participant A distinct individual involved with the project James Howison (the person), Sean Egan (the person)

Identifier A string identifying a Participant James Howison (the name), [email protected] (an email address)

Task Outcome A change to the shared output of the project A new feature, a fixed bug, updating documentation

Action Work which contributes to a Task Outcome writing a translation, requesting a feature, writing code

Task The sequence of Actions contributing to a particular Task Outcome Creating a new “buddy search”

Table 2: Concepts used in organizing archival records

I began with the release notes and the README file, which evolve over the period as the participant’s own categorization of their work by Task Outcome. I then worked to assign Documents relevant to each Task, working through the full set of project archives. I worked iteratively until I had exhausted the records from the source code repository (since they all necessarily alter the shared work product). I then worked through the relevant Documents, identifying Actions, as well as ascertaining which Participant performed the Action. These Actions were then classified, according to their contribution to the Task, as: 1) Management, 2) Review, 3) Production, 4) Documentation and 5) Support (primarily bug reports or feature requests, answering questions about code or testing code). Table 3 shows sample Tasks, with their



Actions and the codes applied to them. The top cell shows a Task in which multiple programmers worked; this is, perhaps, a common image of collaboration. The bottom cell shows the much more common case where only a single programmer worked on a Task.

CHAPTER 5. REPLICATION: FIRE & GAIM ARCHIVE STUDY 84

Table 5.3: Solo-only Additional Classification

Neither Supported Reviewed Rev. & Sup. Sum

Fire 24 25 1 2 52Gaim 11 5 13 2 31

Sum 35 30 14 4 83

some they reflected additional user reports of bugs against the version “in the wild”, but already

fixed in CVS (i.e. the Actions coded supporting follow the Actions coded Production.). Most of the

Reviewed tasks involved the creation of a translation which was checked in by a developer with CVS

access, although Gaim incorporated more non-translation user patches than did Fire.

Illustrative Tasks

This section presents an illustrative task for each of the categorizations presented above, in order to

give the reader a richer feel for the data, and lay the groundwork for illustrating the theory developed

in chapter 7. It is clear that not all similarly classified tasks as these presented here, so where

possible characteristic variations for each Task type are noted. The presentation begins with the

most collaborative, and least common, type of task and works its way to the least collaborative, and

most common, types of tasks. The full output for these tasks, including links to source Documents,

is presented in the Appendix (9.3).

Illustrative Co-Production Work

Table 5.4: Illustrative Co Work

# Date/Gap Actor (overall role) Action Code Applied

Gaim Task 2: manual browser security fix1 Jul 20 2002 kareemy (user) reports bug Use Info. Provision2 1D 5h 50m lschiere (dev) attempts diagnosis Code Info. Provision3 (undated) robot101 (p dev) writes patch Core Production4 20D 9h 41m seanegan (dev) checks in patch Review5 10D 18h 10m seanegan (dev) tweaks fix Polishing Prod.6 1D 20h 8m chipx86 (dev) re-writes fix Core Production7 1D 3h 20m seanegan (dev) move fix to branch Management Work

In late July/early August 2002, the Gaim project had a potentially serious bug: the ‘manual

browser’ setting could allow an attacker to gain additional privileges and delete files on a Gaim user’s

computer. It was a serious but not uncommon type of bug; the result of not properly sanitizing a

user’s input. The Actions contributing to the Task are shown in Table 5.4.

CHAPTER 5. REPLICATION: FIRE & GAIM ARCHIVE STUDY 86

This Task is far more indicative of the full dataset than the co-work task shown above. The

developers act without discussing their work before hand, and do not announce it on the mailing

lists or Trackers. The polishing here is a very small amount of work, but it is important (the first

polish actually fixes the build).

Illustrative Solo Work

Table 5.6: Illustrative Solo Work

# Date/Gap Actor (overall role) Action Code Applied

Fire Task 57: user list duplicate fix1 Dec 06 2002 gbooker (dev) fixes bug Core Production

Gaim Task 3: iconv library integrated1 Aug 02 2002 seanegan (dev) adds library Core Production2 19m 52s seanegan (dev) changes ChangeLog Documenting Work3 26m 10s seanegan (dev) integrates library Core Production

Fire Task 5: scroll on PgUp1 Nov 19 2002 nkocharh (p. dev) makes PgUp scroll Core Production

Fire Task 29: AIM buddy icons1 Oct 27 2002 gbooker (dev) checks in buddy icon code Core Production2 (same time) gbooker (dev) changes ChangeLog Documenting Work3 39m 3s gbooker (dev) add jpg icons Polishing4 1h 22m gbooker (dev) add bitmap icons Polishing5 12h 1m gbooker (dev) .buddyicon save Polishing6 1h 22m gbooker (dev) add bitmap icons Polishing7 3D 13h 1m gbooker (dev) fix IRC icons Polishing8 3D 18h 34m gbooker (dev) fix memory leak1 Polishing9 1h 6m 23s gbooker (dev) fix memory leak2 Polishing

Gaim Task 18: Finnish Translation (Reviewed Solo)1 (unknown) teroajk (trans.) writes Finnish trans. Core Production2 Jul 02 2002 robflynn (dev) checks in trans. Review Work3 (same time) robflynn (dev) thanks teroajk Management Work

The bulk of the work tasks done in the periods studied are classified as Solo work, just under

half of which is Supported in various ways, but where only a single Participant is actually changing

the software code. Since these are dominant and small, I have chosen one of each type to illustrate

this class of work, as shown in Table 5.6.

There are 30 tasks that only involve a single actor, and 9 of these only involve a single Action

(the others range from 2 to 8 in length, with 4 longer than 3 Actions). An example is ‘user list

duplicate fix’ (f 57), where gbooker, a core developer, makes a single check-in that fixes a situation

in which users were showing up twice in the user list. There is no indication in the archival record

as to how he became aware of the issue; it may have been via private email, but it is also likely that

he came across this small issue himself and, without seeking permission, planning or announcing his

intentions, fixed the bug.

Table 3: Illustrative Tasks. These tables show tasks as re-organized from the project archives, with Actions undertaken by Participants contributing to Task Outcomes. The Actions have been coded according to

their contribution to the outcome.

At this point the dataset was ready for analysis to see if the participant observation results could be replicated. I found clear evidence replicating the finding of work being undertaken in short and individual episodes. As shown in Figure 1, I found that ~80% of the 106 Tasks involved only a single participant writing code (but not the same single participant in each Task). A further ~10% of tasks were primarily programmed by a single participant, with a small amount of ‘polishing’ work, such as fixing a spelling mistake by another participant. Less than ~10% involved more than programmer, these I called Co-work. Even within the Co-work episodes only one involved any planning Actions, specifically management work to synchronize the work of two programmers. All Tasks were generally short, with both the mean



and median duration being shorter than 1 week (longer outliers are discussed below). The Co-work Tasks showed no signs of systematically greater complexity, such as involving more lines of code.

Figure 1: Tasks tended to involve only individual programmers. Figure shows tasks in Fire and Gaim classified

primarily by the number of programmers (polished work involved a single main programmer; others did only polishing work such as fixing a typo).

Figure 2: Complex tasks were deferred. The figure shows long running Tasks begun by requests by peripheral

participants (black circles). These were accepted by core participants (grey circles) but deferred until the inter-release period, when production work (grey triangles) was undertaken in short tasks with only single programmers.



There was also evidence that complex work was deferred. Figure 2 shows long running Tasks. The early Actions were all Support actions, usually feature requests or posts accepting a feature as desirable. The release period is shown on the horizontal axis, earlier for Gaim than Fire and close inspection shows that all the production work for these Tasks was completed relatively quickly during the release period, even those that had been outstanding for months.

Qualitative investigation of these tasks provides evidence that similar processes of deferral were undertaken; a feature request was acknowledged as desirable, but the work considered too complex to undertake. For example f_9 in Figure 2 consists of a feature request made in March 2003, then assigned to a developer as a signal of acceptance. Yet no work is done until October 2003, when the developer comments that an unrelated feature has simplified the request, “This is possible now with the ‘once’ option probably I will check it in the next week or so”. In the specific case of these Instant Messaging clients the addition of protocol specific libraries, written outside the project, facilitated ‘waves’ of resolution of feature requests. These Tasks are also striking for what did not occur: there was no evidence of detailed planning, assignment or breakdown of work towards these tasks, rather the arrival of a new library prompted individual short integrative tasks.

Overall the findings from the participant observation were replicated: the work in Fire and Gaim was undertaken overwhelmingly through individual, short episodes of work. There was very little evidence of planning work (only found in a single task) and no evidence of resource management. Complex work was deferred, rather than being broken down into its components and undertaken collaboratively, only likely to be undertaken when and if a single participant could accomplish it in a short period of time. These results provide depth and context to earlier research results which found that FLOSS projects tend to have smaller and more frequent check-ins than commercial projects (Mockus, Fielding, & Herbsleb, 2002).

Formalization: Theory Elaboration

The replicated findings of the empirical work above pose a number of theoretically interesting questions: how are projects able to build complex interdependent shared artifacts through individual work and how are projects able to progress quickly enough to satisfy their users and developers, given the practice of deferring complex work? In order to answer these questions, and elaborate the growing understanding that the interaction between participant’s motivations and the organization of work is a key novelty in FLOSS production, I developed a formal model of developer decisions.

The model attempts to capture essential features of individual's decisions through a simplified, stylized model of human decision-making. These models are most familiar from micro-economics where they form the foundation of consumer choice theories, leading to well known predictions such as supply will equal demand if the price of a good is allowed to vary. They are also the foundation of game theory models, as well as the underlying model of action in multi-agent simulation models. In this context a model is a type of theory that theorizes about human behavior and examines the implications of that theorization through logical, formal analysis (Kaplan, 1964). The simplifying assumptions will be laid out and justified, then once the basic model has been used to make analytic points, many will be relaxed to systematically consider the impact of the complex of empirical reality on the suggestions of the model.

The model to be developed below draws particularly on conceptualizations of two concepts: motivation and the practice of writing software. Together these allow us to model the agent’s decisions about whether to work and the task that they would perform.



Expectancy-Valence Motivation

The model uses an expectancy-valance model of decision-making (Vroom, 1964). This is a process theory of motivation whose essence is the suggestion that the “attractiveness of a particular task and the energy invested in it will depend a great deal on the extent to which the employee believes its accomplishment will lead to valued outcomes” (Steers, Mowday, & Shapiro, 2004).

Figure 3: Expectancy-Valance model of motivation. Adapted from (Samson and Daft 2005, p. 534)

Figure 3 shows that there are two separate expectancies in this theory. The first is Expectancy-Performance (E⇒P), which argues that the individual calculates the “probability that effort will lead to desired performance”. The second is Performance-Output (P⇒O), which argues that the individual also calculates the “Probability that effort will lead to desired outcome”. Either expectation could turn out to be unfounded; the individual could be ‘blocked’ at each stage in the process. For example a programmer might choose a task that is too difficult or time consuming and fail to create working code. Or despite having produced a patch that implements a new feature on their personal machine, in the time they were working changes by others to the codebase could render their code unusable.

Porter and Lawler (1968) introduced the important idea that individuals will learn from such failures, as expressed by Steers et al. (2004, p. 381), “if superior performance in the past failed to lead to superior rewards, employee effort may suffer as incentives and the reward system lose credibility in the employee's eyes.” The implication for the FLOSS environment is that failures, particularly at the (P⇒O) stage, after their effort has been expended, will undermine participant motivation.

Writing Software

When programmers speak with each other about software they often talk about a “stack” of software and draw diagrams that look similar to that in Figure 4, which shows the overall architecture of Apple’s OS X operating system. These illustrate a fundamental feature of software: it is built in layers. The lower layers, such as an operating system, provide services to the higher layers, such as a windowing toolkit. Only the very top layers, applications, provide direct utility to users. They are, in fact, called applications because they “apply” the technologies to users’ problems. The user doesn't perceive these lower layers directly; they perceive them mediated by higher layers.



Figure 4: Apple's Architecture Stack for OS X. A “layer cake diagram”

This layering is true not only at the very broad stroke of an operating system, but is also true within a particular application. For example the ability for a user to search their email relies on (“applies”) at least two lower layers: the ability to match text like words, and the ability to display the search results (email display).

In addition to, or perhaps as a result of, being built from layers, software is additive. That is to say that additional layers can be added without necessarily changing the lower layers. Furthermore, if a layer is no longer needed it can be removed without necessarily affecting layers below it (and since it is not being used there are no layers above it). This is, of course, merely a way of modeling software development and it does simplify reality. It is quite possible to build software in monolithic chunks, without the layering described here, yet it is equally possible to build it through layers and the layer metaphor is very useful in modeling the task that developers face in building FLOSS over time.

The fact that software can be built in layers gives rise to two important types of dependencies between software layers. Figure 5 illustrates these relationships. From top to bottom the layers depend on each other functionally; without these layers the code will not compile and the application simply will not be able to run. In the diagrams to follow all higher layers depend on an unbroken stack of lower layers, with the higher layers said to have a functional dependency on the layer beneath it.

Figure 5: All layers have functional dependencies on those below them. Gray layers have direct utility, and white layers have utility dependencies on gray levels above them.

Figure 5 also shows the second type of dependency, called a utility dependency. Some layers of software have no direct utility to the user. Rather they depend on higher layers to expose their functionality, thereby releasing their value to a user. In these diagrams layers that have direct utility are colored in gray, while layers that rely on higher layers for their utility are colored white.

From the perspective of development these two types of dependency have two implications. The first is that a missing functional dependency removes the utility from layers that depend on it, since without a full stack the software can't run and the “gray” layer cannot deliver its utility to the user. Figure 6 shows this situation.



Figure 6: Without a network stack, shown missing as a box without a border, an email client is incapable of delivering its utility. The lack of utility is shown by giving the gray box a dotted line

The second implication is that there is no restriction that lower layers cannot also have direct utility; it is not the case that all utility must exist in the top layer alone. Figure 7 illustrates this situation with two features of an instant messaging client: buddy display and buddy search. Buddy search clearly depends on being able to display buddies, otherwise the results can’t be displayed or acted upon. Yet buddy display is already useful, even without the addition of buddy search. Search has a functional dependency on display, but display does not have a utility dependency on search. This is shown in these diagrams by stacking two gray boxes on top of each other. With these constructs described we now turn to the model itself, describing the agent’s decision equation, building up needed assumptions and finally considering how the model plays out through multiple turns.

Figure 7: Layers with direct utility can also be built upon, so that there is a functional dependency without a utility dependency, shown with gray on gray.

Model

The agents in rational choice models are making a choice between alternatives, such as choosing which basket of products to buy, or which investments to make. To make their choice they assess the benefits and the costs of each course of action and are constrained to choose the course of action that yields the greatest net benefit to them (Eq. 1). Benefits and Costs do not have to be limited to be entirely selfish, it is possible to argue that a benefit for others is also an outcome that will please the rational agent, and therefore result in an increased benefit to that individual. Likewise there is no need to assume that a benefit for others is a cost to the agent, although that is a common assumption in market competition models (where a sale to a competitor is a sale lost to others). The basic model is simple: an agent will make a choice to act when that choice yields the greatest difference between benefits and costs.

Costs are most usefully understood as “opportunity costs” which are the benefits forgone by not choosing the next most attractive alternative. For example if an individual is choosing between eating an orange or an apple, the cost of eating the orange is the enjoyment/sustenance—the utility—that the apple would have provided and vice versa. Eq. 2 shows the condition which must hold to undertake the choice.

Of course an agent cannot see the future; they can only make their decision on their expectations, their estimates, of both the benefits and the costs of the action. In short there is a risk that the full benefit will not be realized, while there is no risk that the opportunity cost will be incurred. This allows restating the



left-hand side of the decision equation, where Uoutcome is the Utility derived from the outcome and R is the risk that the agent’s expectations are wrong, and their decision will not lead to the desired outcome (Eq. 3).

(Eq. 1) Benefit > Cost (Eq. 2) Bchoice > Balternative (Eq. 3) E(Bchoice) > Uoutcome x (1-

Risk)

The Expectancy-Valance theories of motivation outlined above helps to understand risk here, pointing out that there are in fact two different expectancies in play and a risk at each stage. The first is the expectancy that the actor’s effort, e, will result in a certain performance, p, which can be written as a probability: P(e⇒p). The second is that that performance will yield the expected outcomes, o, and thus the benefit: P(p⇒o). These probabilities are expressing the probability of the successful outcome, so there is no need to subtract from 1. Now the decision condition can be further restated, with all components being expected values:

(Eq. 4) E(Bchoice) > E(Uoutcome) x E(P(e⇒p)) x E(P(p⇒o))

In actually, of course, there are real values for P(e⇒p) and P(p⇒o), which will determine whether the agent, having committed to the choice, will in fact receive the benefit. The agent doesn’t know these real values in advance, but experience may reveal those to the agents over time. In short the agents can learn that their expectations are wrong, and will attempt to adjust them towards the real values. However agents are limited in their ability to predict the future regardless of experience due to its complexity: the agents are therefore said to have be bounded rationality (Simon, 1957).

To illustrate this imagine a rational agent trying to decide whether to sell a magic wand prop, or to wave it in the air to magically produce money. Uoutcome is the value of that money, P(e⇒p) is 1, since the agent presumably can wave a wand if he chooses to (and knows this) but, since our agent doesn’t believe in magic, E(P(p⇒o)) is zero. A rational agent with these beliefs will always choose to sell the wand. Suppose a second agent does believe wholeheartedly in magic, E(P(p⇒o))=1, they will choose to wave the wand, forgoing the selling opportunity. Of course, since the real value of P(p⇒o) is 0, the agent will not receive the expected benefit. Eventually the agent will adjust their expectations.

Conversely imagine an agent faced with the choice as to whether to try to make it in professional sports by entering the draft, or alternatively to spend the week of the draft on vacation. The rewards of success, Uoutcome, are high, and there is a reasonable expectation that excellent performance at the selection combine will lead to being selected and therefore getting paid, E(P(p⇒o))=1, since the real value of P(p⇒o) is 1 by rule and is well-known (drafted players receive guaranteed high-paying contracts). The agent, however, is realistic about their skill levels and knows that there is zero chance of playing well enough to be selected, P(e⇒p)=0. The agent will choose to go on vacation instead.

Assumptions

This section details a set of assumptions that are necessary for analytical clarity. These assumptions are stylized but aim to capture important aspects of the FLOSS situation. Unlike many analytical models most assumptions in fact make the task harder for the project. Nonetheless some will be relaxed in the discussion below, after the initial analytic point has been made. This practice provides clarity to the presentation but not all can be relaxed in the space available here. The assumptions are summarized in Table 4 in the order they are introduced in the text.



The model considers agents who are potential developers to a FLOSS project. It is assumed that agents have a limited amount of spare time, which is outside their normal course of life including things such as paid work, family life etc. It is also assumed that these agents regularly use the software outside their spare time, perhaps for work, for study or for managing a family vacation.

Initially, it is assumed that agents are only motivated by a desire to improve the software so that it improves the effectiveness of their other activities (Assumption 1 in Table 4). That is to say that their motivations for participation are entirely instrumental. Given the research on FLOSS motivations discussed above this is a substantial assumption and will be relaxed below. The improvement in effectiveness is therefore the value of Uoutcome and is known to the agent.

Table 4: Assumptions. The check mark shows that the assumption will be relaxed later in this paper

1. Participants will only work for a utility payoff (the software itself) ✓

2. Participants are motivated only by their own use of the software ✓

3. Participants are good, but not perfect, judges of task complexity

4. Participants know the limitations of their judgment (expectations approach reality)

5. All participants have the same set of skills and availability ✓

6. Participants only know their free time for the next turn

7. There are no exogenous sources of code or solutions ✓

8. Participants can build on existing layers without assistance from authors

9. Contributions are always shared under an open source license

The regular use of the software allows the agent to see opportunities to improve the software (and thereby the effectiveness of the rest of their activities). These opportunities could be to remove annoyances, such as a clunky interface or data-loss risking bugs, or to extend the capabilities of the software through new features. In terms of the simplification of software development described above both of these outcomes involve the creation of a layer of software, which can either be thought of as re-writing an existing layer to fix a bug or adding a new layer to extend features. For simplicity we assume that a new layer is being added.

Also for simplicity the choice facing the agent is constrained to be binary: they either choose to spend their time attempting to contribute to a FLOSS project or they choose not to. What they do with their spare time otherwise is immaterial, but for the sake of narrative we will model it as though the other choice available to an agent is to meditate. The agents are assumed to be good meditators and meditation is assumed to yield some benefit in the rest of their life (through improved focus or, perhaps, karma). Meditation, therefore, is equivalent to the ‘null’ choice in investment models, which is usually to place one’s money in a bank account accruing low but certain interest. In this model the non-code choice is a choice to meditate, which always produces a known payoff. Choosing to code means that the agent looses the benefits of meditation, so the known payoff of meditation is always the opportunity cost of choosing to code.

The model requires the agents to make two assessments of their expectations. First they have to estimate whether the effort they have available can result in the needed performance, estimating P(e⇒p). They inspect the current codebase and make their best estimate of the amount of time it would take them to build the required layer. Of course this depends on a number of factors. Firstly they have to be able to read and understand the existing codebase. Secondly, they have to estimate their skill levels and thirdly, the complexity of the task. These elements enable them to assess the difficulty of the task and thus the time likely required for the task that they then compare against the time they have available. The agent



sets their expectation of P(e⇒p) based on the chance that they will be able to complete the task with the time available. For example if the time they had available was three hours and they just need to fix a spelling mistake then their estimate of P(e⇒p) would be high, but if they needed to integrate a new spell checking library in that three hours then the estimate of P(e⇒p) would be very low.

Having agents make this assessment requires further assumptions (Assumptions 2, 3 & 4). Initially all agents are assumed to have the same level of skill (this is relaxed below). They are assumed to be good, but not perfect, judges of their skill level. Agents are also assumed to be good, but not perfect, judges of the complexity of the tasks, and are assumed to be good but not perfect at understanding the current codebase. The agents are assumed to know their limitations. These assumptions create a small chance of failure every time a developer undertakes a task. At the stage of comparing complexity to time available, agents are assumed to know their time availability for the length of the turn, but not beyond that (Assumption 6). Agents will not rely on possible availability in future turns (this is relaxed below).

The second assessment that the agents make is to assess P(p⇒o) which is an assessment of the probability that accomplishing the task set forth will enable them to use the application in such a way as to unlock the utility that motivated them and achieve the expected rise in productivity. For the case of individual work this is set to, and is expected to be, 1 (i.e. certain). This reflects the fact that the agent has the codebase, a compiler and can compile their layer with the application. In short this is an assumption that the agent is able to successfully integrate their changes into the application.

It is also assumed, at this stage, that there is no source of exogenous code or solutions; the development effort of the developers is the only source of advancement for the project (Assumption 7). This rules out outsourcing through payment or the discovery of libraries of code from outside the project. This is an obvious simplification and will be relaxed below.

Further it is assumed that it is possible to build on existing code without needing to speak with the original author(s) (Assumption 8). This doesn't necessarily imply that the code is perfectly readable or perfectly documented, but that the developers are, with time, effort and experimentation, able to read and understand how to use it. The difficulty of doing so is incorporated into the agent's decision about their probability of success.

Finally there are two assumptions about contributions, once they are successfully coded. Firstly, it is assumed that the agents all share their contributions and do so under an open source license (Assumption 9). It should be noted that this model is not attempting to explain this decision to reveal, rather it is attempting to consider decisions as to the style of work (individual or in groups) undertaken. Nonetheless, this is justified by the understanding that once a feature or fix is accepted into the public code-base, others will refrain from removing or undoing it (provided it is functional). The decision to share is therefore rational because this ensures that the layer that the agent’s builds will continue to function and deliver productivity improvements (Uoutcome is an assessment of continuing future benefit). This group commitment therefore saves the agent considerable future maintenance costs, much in the same way that corporate IS departments attempt to minimize internal customizations to ERP systems, especially if those might break during upgrades.

Secondly, contributions are shared under an open source license (a license that respects the OSI principles (Assumption 9). This has three important implications: contributions are not revocable; the contributor cannot withdraw them. This does not mean that they cannot be appropriately altered, but that even if a developer were to regret their decision to contribute, they would not be able to remove the layer. This is a result of the use of an open license. An open-source license also ensures that contributed code can be relied upon and used by others: derivative works are allowed and no royalties must be paid.



Model analysis

With these assumptions and background, it is possible to consider an individual agent making a code or meditate decision. Each participant consults their current set of motivating outcomes and the current codebase and assesses whether they can, given their skills and available time, undertake a development task, making their best assessment of the easiest way to change the codebase to achieve the desired outcome. If they estimate that the benefits outweigh the costs they begin work.

If they successfully complete the work it is available to all the other developers in the next period, for others to assess their options. Unsatisfied motivations where the developer either chose not to act or did not successfully complete the work survive through the next turn (i.e. participants return to the codebase from time to time and reconsider work they previously rejected).

Individual, layered work can proceed

The simplest situation is that a participant inspects the codebase and their set of desires and finds a task which is sufficiently motivating, but is also within their abilities given the time known to be available to them. Such a situation is shown in Figure 8, where a gray layer (depicting utility to its developer) is layered atop an existing gray layer.

Figure 8: As development proceeds over time through layering, functional dependencies become backwards only dependencies. They depend only on what is already present.

These situations can be called “backwards-only” dependencies: all that is relied on is the current codebase and its permanent availability (as guaranteed in the FLOSS context). If previously contributed layers could be removed then the payoff would not be guaranteed, since if the layers were removed the code would lack its functional dependencies and would be unable to release the utility desired by the developer. The dependency is “backwards” in time, depending on actions already completed, irrevocable (and therefore certain), actions of others.

The “missing step” problem

A second situation faced by a participant would be inspecting the current code base and their desires and seeing that the work needed to implement a desired feature is greater than their skills will allow them to accomplish in the time they know they have available; they expect that if they were to start they would fail. This can be understood as setting E(P(e⇒p)) so low that meditation will always provide a higher expected return, regardless of the size of Uoutcome. The agent wishes to implement the code to provide a desired feature, yet often in programming the complexity is not in using the final method calls, but in setting up the stack of calls and code that support the desired feature. In our graphic simplification this can be represented by depicting the feature as two separate layers, as in Figure 9.



Figure 9: A missing functional dependency becomes both a forwards and backwards dependency.

An individual agent under the assumptions above will not work to try to implement both layers, nor is it rational to work on either in isolation. This is because without the white missing step, the payoff of the gray layer is not available (a missing functional dependency). Without the potential to finish a gray layer in the time available the white layer will not be built (since it is missing a utility dependency). This is a fundamental dilemma in collaboration; it is in fact just a stylized and contextualized way of restating a core problem of collective action; the complexity of work is beyond the individual capabilities of participants. The following section presents two solutions to this situation: collaboration, which is well known, and deferral, which is believed to be novel.

Two solutions

1. Interdependent collaboration

A natural way to resolve this situation is to have agents communicate and potentially make agreements between themselves. In this way they are free to discover other participants who are also motivated by the New Feature in Figure 9. Together they can assess that if both of them work together they can accomplish the work; one works on Needed Step and the other on New Feature, as depicted in Figure 10. The capacity to work together opens the way to resolving the dilemma.

Figure 10: The missing functional dependency can be added if two developers are able to work concurrently, although the risk of non-completion rises due to partner failure and coordination costs.

While this seems a reasonable solution, even under the assumptions in place in this model, such collaboration introduces new risks that could undermine motivation and reduce volunteers’ participation in projects. From the perspective of either developer, this agreement introduces a new source of non-completion risk. This is because any developer's collaborator also has a chance of failure, P(e⇒p) < 1, and therefore may not complete their part of the agreement, rendering the payoff unavailable (either because a functional or a payoff dependency is unsatisfied.) From the perspective of the first developer this means that regardless of their ability to complete their part of the task, the reward may not be available. This can be incorporated into the model as a change in the expectation of the second part of the risk term, E(P(p⇒o)), where there is a risk that the expected outcome will not eventuate, regardless of the success in initial performance. Of course this cuts both ways, reducing the expected value of the



agreement and effort multiplicatively, sharply decreasing the likelihood of agreement and action. Essentially each agent's E(P(e⇒p)) becomes their partner's E(P(p⇒o)). For example, if there is an individual chance of success for each developer of 0.8, the overall chance of success is 0.64, meaning that the overall utility of the work would need to be substantially higher if the agreement is to be performed.

In addition, concurrent development introduces a new, well-known, problem. For two layers to work together they have to suit each other, what Crowston (2003) calls a “usability dependency”. In the model so far this integration has been assumed to be easy because the developers have only been building on finished code and it is assumed they can understand this without discussion with the authors. This is not true of concurrent work because it is not available for inspection as it is being simultaneously developed. This can be called a usability coordination cost and this extra difficulty can be modeled by increasing the risk of non-completion (for either participant), by decreasing P(e⇒p). Furthermore this is known to participants—and known to affect their partner—so it is therefore transferred to the expectation of the P(p⇒o) term, as above. Representing the increased risk of concurrent programming as θ this makes the collaborative decision condition:

(Eq. 5) E(Bchoice) > E(Uoutcome) x E(P(e⇒p)self x θ) x E(P(e⇒p)other x θ)

Since both agent’s P(e⇒p) < 1and θ < 1 work conducted in this manner will always be more risky than if it could have been conducted through individual steps with immediate utility payoffs.2

2. Deferring complex work

There is another possibility available without introducing communication and agreements: this is for the developer to defer the work for the current turn, and to wait and see how the codebase changes over time. It is possible that—through the work of others on the project—the situation will have changed sufficiently that New Feature is now possible with only individual work within one period. In short, from the perspective of a single participant, Needed Step simply appears, and turns the dilemma into a relatively simple backwards-only dependency.

What trickery is this? Needed Step is a layer without a utility payoff and therefore will never be built by participants. It can't come from an exogenous source, because we are assuming that these do not exist (but see below). How then does Needed Step emerge? The answer has to do with the extraordinary flexibility of software and the situated nature of the developer's cognition. Initially a task may seem to require work that is otherwise valueless (since it has a utility dependency on as yet uncompleted work), but as other work—perhaps just individual backwards-only work—changes the software over time, another way to build New Feature may become apparent. Importantly the changes in the codebase would have been made for their own sake, not as part of a plan to eventually build New Feature. This is the situation I encountered in participant observation and depicted in Table 1, on page 3, where the founder of BibDesk waited four years to implement a desired feature, but only after code written for an entirely different reason made the task much easier.

This can occur because a developer makes their best assessment of the easiest way to change the code to achieve their desired outcomes and bases their calculation of E(P(e⇒p) on that assessment. The Needed Step/New Feature dilemma is therefore not a hard fact—it is not a “structural requirement” of a task 2 This models for two participants only, but there is nothing stopping larger numbers of participants agreeing to take on even more complicated tasks together. However these sort of agreements are exponentially less likely as the failure of any single individual undermines the payoff for all, and further increases risk through extra coordination effort which is now between three or more simultaneously developing components, rather than two. One could also add other transactions costs, such as communicative effort, to the model, further decreasing the riskiness and cost of collaboration.



(Wageman, 1995)—but the result of a developer's cognition. And the cognition of developers—their estimation of the work needed to build New Feature—is highly situated: it responds to the codebase as it is now, not to all possible configurations of code. As the codebase changes, new and often surprising ways to accomplish tasks emerge. In this way, as depicted in Figure 11, potentially problematic interpersonal dependencies, requiring trust and communication, can be converted to two backwards-only dependencies, and accomplished through individual work alone.

Figure 11: A missing step dilemma can become two separate backwards-only dependencies, if the missing functional dependency proves to have an alternative which itself has a payoff. Note the elongated and indeterminate time scale.

The idea of “productive deferral” can be incorporated into the rational choice model with an acknowledgement that the deferred work may not ever be completed, and if it is it will be delayed and therefore reduce the utility of the feature. Note however that agents are not choosing to defer the work as an alternative to both working and meditating; deferral does not take any time so the benefits of meditation are still available. Note also that deferral is also not a commitment on the behalf of the agent to undertaking the work in future. In this way one can remodel the decision as between (a) working uncertainly now and likely failing and (b) meditating now and possibly working more easily later. For deferral to be preferred to collaboration, then, the effect of uncertainty and delay only must be lower than the multiplicative combination of collaboration risks shown above. It is relevant that deferral eases the implications of choosing not to work; the opportunity to work is not one-time, nor does a single agent's decision not to work affect the ability of other agents to work in the future.

There is no need to over-state this point; it is enough that deferral can and does happen. Certainly it does not always happen and for some types of tasks it probably never happens. Even when it does there is no way to estimate when it might occur successfully. In any case deferring work in the hope it gets easier is far from a wonderful solution: it is at best slow and from an organizational perspective is quite often totally ineffective, especially in circumstances where the time-cost of upfront investment operates (see below). Nonetheless, deferral is a novel solution to the collaboration dilemma and one that is in-keeping with the motivational and technological environment of FLOSS development.

Extensions

This model is useful but simple and a number of extensions are immediately apparent. This section considers just three extensions, designed to consider the impact of three empirical aspects of FLOSS discussed in the literature. Firstly participants in FLOSS projects have different areas of expertise and skill/productivity levels (sometimes varying by orders of magnitude; see González-Barahona and Robles-Martinez (2003) for a critical discussion of the “code god” assumption), secondly FLOSS projects can make use of exogenous sources of code and thirdly, participants are known to be motivated by things other than the simple instrumentality of the software.3

3 The assumption that agents are only aware of their spare time for the next turn can also be relaxed. This allows sequential collaboration. In practice this is very similar to concurrent collaboration, but the additional coordination cost is replaced by a discount factor to account for the delay in achieving the desired outcome.



Unequal skill distribution.

The model above assumes that all participants have the same skills and productivity; this can be relaxed by modeling this as a distribution. The immediate impact of this is to allow the existence of developers for whom the implementation of Needed Step and New Feature (from Figure 9) is converted to a single step. This might be for two reasons. Firstly, the developer might have experience of Needed Step through another program, and is therefore able to implement it quickly. Secondly, the developer is able, due to their superior skills and productivity, to complete both of the steps in the free time they know they have available to them. Graphically this either merges the white and gray boxes, or it enables some participants to build two boxes within one turn.

Relaxing this assumption leads to a more realistic model where some tasks are hard for some developers while being easy for others. Indeed it is often said of open source projects that they have “code gods” who are an order of magnitude more productive, and whose work makes leaps on top of which other developers can build smaller, but still useful, contributions. Changing this assumption would complicate the calculations of risk in collaboration, since one developer might have less chance of failure than the other and others might be happy to work with them.

Just as there is a range of tasks with different difficulties and skill requirements, there can be a range of developers with different skill and productivity profiles. In this way the project can speed through some Needed Step dilemmas, provided a developer exists for whom the task is comparably easy and for whom it provides sufficient utility. This points to the importance of continual recruitment, above and beyond added generic effort: by widening the diversity of contributors the project has more chance of solving these thorny issues. This is true even if contributors cannot contribute large amounts of time. Having uncommonly productive members might also assist the project by making deferral more effective for other members by keeping the codebase changing in ways that might make complex work easier. For such reasons it might be appropriate for the project to be more concerned about attracting new, skilled participants than organizing in ways that make most efficient use of the spare time of existing participants.

Exogenous change

In the real world, FLOSS projects do not exist on their own; rather they are part of an ecosystem of software and other projects. Although differing licenses reduce the possibility of code movement between some sets of projects, in general developers have a great deal of software at their disposal. This is especially true of libraries, which are packaged and documented for re-use. These libraries can provide significant functional services. By relaxing the assumption that no solutions or code are exogenously available it is possible for individual developers to overcome the Needed Step dilemma by recognizing a library as providing the step, adapting it and pursuing New Feature in the course of their single turn, in a manner analogous to re-conceptualizing the problem with assistance. The developer, therefore, is assessing not just the current codebase but also the codebase of other projects and out to the whole ecosystem of (compatible) FLOSS code. Further, libraries are “bundles” of potential features that are designed to be leveraged. Their addition can spark new rounds of creativity amongst developers, perhaps working on tasks that were too complex earlier and therefore deferred.

Other motivations: Reputation and Learning

The literature on FLOSS motivations, discussed above, is clear: instrumental motivations (for the software itself) are important but they are not the only drivers of activity, as assumed in the model above. Two other motivations stand out: Reputation and Learning, as key examples of extrinsic and intrinsic motivations, respectively.



The importance of reputation is, perhaps, stronger in the conceptual literature than in the empirical literature but is nonetheless important because it could motivate developers to take on tasks without certainty of completion or immediate payoff in the software. As long as the project is careful with assigning credit, individuals can increase their reputations by taking on tasks that are known to be collectively valuable but which are not otherwise motivating. An example of this might be tasks such as managing infrastructure or undertaking the infrastructural work represented by Needed Step above. Reputation, as a type of external reward, could even motivate unpleasant work, just as financial rewards do.

This relaxation allows projects to proceed through Needed Step blockages without resorting to work with direct interpersonal interdependencies, still working only through layered individual work. Yet reputation seems likely to be important for working in concurrent or sequential modes as well, since reputation can be modeled as revealed quality and commitment. Since participants can see the public successes of other's efforts (and are relatively shielded from their private failures) they may be more willing to trust others and enter into agreements for concurrent or sequential work. Note that reputation would take time to build, so is unlikely to be operative in the very early stages of a project, only once the project has established itself as well-known and valuable, allowing reputation to have value outside the project itself.

Learning is part of a set of intrinsic motivations that also includes sheer enjoyment of the work or an ideological commitment to free software. Once intrinsic motivations are allowed in the model the situation can vary quite significantly because they change the types of payoffs permitted. Intrinsic motivations allow participants to implement steps that were previously ruled out because they did not provide immediate functional payoffs. This has the helpful effect of making it possible to turn a ‘white’ box (a step with functionality but no immediate instrumental utility) into a ‘gray’ box where the payoff is, for example, the learning the developer anticipates during development. This allows intrinsically motivated developers to choose to implement gaps, such as Needed Step, only because they will learn from the activity, regardless of whether they, or someone else, ever implements the New Feature that has a functional dependency on the Needed Step. Of course their contribution could enable another to build New Feature more easily (but this won't have been the original intention or motivation).

Furthermore intrinsic motivations mean that even ultimately unsuccessful work has value to the developer, since one can learn from failure, or simply enjoy the process. This reduces the perceived risk for the developer: one can say “hey, I'll give it a try and even if it doesn't work out I'll at least have learnt something”. Given also the ability to communicate, and thereby get opportunistic coaching from an interested and skilled community, coding to learn appears to be a very powerful motivator. Formally this could be incorporated in the model by adding (not multiplying) a new term to Eq. 4 on the benefit side reflecting the expected utility of the experience itself, E(Uexperience). Crucially, this term is unaffected by the risk of failure (or any of the multiplicative risks of collaboration), thereby making work more likely to be undertaken. Successful work done for intrinsic reasons can bridge motivational gaps in the project and such work can provide layers that make the work of other participants much easier, supporting a whole new raft of backwards-only tasks. This helps to clarify why intrinsic motivations are so important to volunteer work.

Discussion

The theory developed in this paper emphasizes how much can be accomplished without risky interdependent collaboration (particularly when intrinsic motivations, such as learning, are considered) and clarifies the emergence of a novel solution to the collaboration problem, that of productive deferral. The model of organizing presented in this paper is entwined with affordances of IT artifacts, four of which are highlighted below. Understanding these better improves analysis of the challenges in adapting FLOSS organizing for other work, including the traditional IS function.



Collaboration affordances of the IT artifact

Firstly software can be built in relatively small layers, particularly if an appropriate architecture is chosen4. Those small additions can be relatively easy to integrate and can have independent payoffs, even for very small additions, such as adding a search function. The ability to build complex, interdependent work in immediately motivating layers is very important to the model of organizing presented in this paper. However, it is clear that much work is not like this. For example an airplane certainly can be built in layers: first the fuselage, then the engines, and finally the wings. But until it is complete none of these steps provide any utility payoff. Small steps added to an existing base, each with their own sufficient instrumental payoff seems to be particular to informationalized work.

Secondly, software has very low instantiation and distribution costs. By instantiation costs I mean the costs of moving from a design to a useful artifact (and not the process of creating the design). For software this is moving from software code to a running application and is very cheap, simply requiring a computer and a compiler. For other work, however, such as building a house, this can be very expensive. While one could conceive of a community collectively altering and layering a digital design for a house, the fact that there is a comparatively high cost of applying such alterations to the finished artifact means that the use value of the changes is very hard to realize, undermining the types of motivation seen in FLOSS projects.

Distribution costs are similarly low for software, which is usually delivered via the network at no marginal bandwidth cost for the user. This is important if small layers are to spread out to the community and provide the basis for other’s work. Prior to internet software delivery, updates involved printing CDs and shipping them to customers, a much more expensive proposition. Extremely low instantiation and distribution costs are very important to the model of collaboration presented in this paper and are a characteristic of IT artifacts as an object of collaboration.

Thirdly software is rewindable; as participants add layers they do not commit the entire project to retaining them forever; changes can be undone, especially when source code management systems like CVS are used. Even when another developer commits to a shared source code tree, it is possible for others to decide whether they will include those changes in their compiled application. This is quite unlike the great majority of other work, such as customer service or financial advice, where actions and their impact are hard or impossible to reverse. In such cases trust becomes a much more important issue. Gallivan (2001) in a meta-analysis of FLOSS case studies highlighted the surprising finding that trust was not a commonly discussed element of FLOSS organization, suggesting that control must be playing the missing role. The model presented in this paper, however, suggests that with a rewindable and non-revocable IT artifact as the object of collaboration, neither trust nor control is as important for collaboration as has hitherto been the case.

The fourth enabling role of the IT artifact relates to the venue of collaboration, rather than software as an object of collaboration. In short IT enables collaboration without investment, resisting the deadline pressures that necessarily accompany it. Community-based software projects are able to take advantage of a set of collaboration tools, from email to download hosting to bug trackers and versioned software repositories, which are themselves software and usually free software. As such there is no financial cost to set up a project, host it and to make it available for others to discover and build upon. While service providers such as Sourceforge do play an important role in facilitating this, and do bear bandwidth costs, many FLOSS projects are able to host their own infrastructure, using excess capacity in personal or business connections. This means that projects can begin without investing money, and they can take on 4 Note that an architecture that supports layering might be quite different from the modular architectures often suggested as fundamental to good software and even to attracting volunteer participants (Baldwin & Clark, 2001, 2006; MacCormack et al., 2006). A successful modular decomposition of a software problem assumes knowledge of an appropriate end-point; layerability is more about the ease of extension than it is about information hiding and complexity reduction.



new participants without marginal financial costs. Upfront investment, even non-profit oriented investment, brings with it the opportunity costs of money, especially the time-cost of money, which entails deadline pressures. When deadlines are important then the tactic of productive deferral is of reduced usefulness and there may be no alternative to working with interpersonal dependencies and therefore bearing the risks and costs outlined above.

Challenges for Adaptation

Much of the interest in FLOSS and its development stems from the difficulties encountered in IS development, even when co-located, together with difficulties encountered in distributed work more generally, especially when crossing organizational boundaries. FLOSS seems to solve these two difficulties by combining them and do so without needing financial investment; a truly remarkable achievement. This suggests that many useful lessons can be extracted from the FLOSS model of organizing. Yet the theory presented in this paper, particularly the fundamental role of affordances of IT artifacts, suggests caution. The remainder of this section demonstrates the usefulness of the theory developed in this paper by examining attempted adaptations and outlining the theory’s implications in each context.

Adaptation seems likely to be most successful in areas that have similar technological affordances. Wikipedia was inspired by FLOSS development; at its center is an IT artifact—the wiki—that can effectively be built in layers and is non-revocable and strongly rewindable. Instantiation and distribution costs are, however, higher for Wikipedia, despite its digital nature. This is because the database is stored centrally and each use is its own set of instantiation and distribution, requiring server time and bandwidth from a central location. In this way a contribution to Wikipedia requires continual maintenance costs if it is to deliver any use value. Bearing these financial costs is a key function of the Wikipedia Foundation.

Open Hardware is a label applied to efforts to draw on techniques from FLOSS to build hardware, rather than software. The aim of the Open Hardware movement is to radically lower the cost of hardware and to radically increase the speed of innovation. Examples include projects like the Simputer and OScar (Open Source Car). These have been less successful than that of Wikipedia. The primary impediment to repeating the success of the FLOSS model of organization is that hardware has high instantiation and distribution costs. A circuit board must be designed before it is printed and transported to where it is needed; all this must happen before, not during, the integration process for any new feature or bug fix. For this reason Open Hardware has proceeded in two ways. The first is focusing on the design stage, sharing schematics and other documents, yet this has a clear unsatisfied utility dependency. The second is to take advantage of the increasing informationalization of hardware—essentially turning hardware into software—through downloadable firmware or hardware that is more like software, such as Field Programmable Gate Arrays.

There have also been calls for bringing FLOSS organization to voluntary political activity, such as groups seeking to contribute to various “calls for comment” in government decision making (e.g., Cogburn et al., 2005). Some aspects of this work seem promising for a FLOSS model of contribution: the work is informationalized (producing an electronic written document) and can be built in layers. It is quite plausible that the participants are individually motivated and little upfront investment is required. Yet two aspects limit the applicability of the theory of organizing presented in this paper. The first is that the processes these efforts are focused upon have inherent deadlines because contributions have to be finished and submitted at a certain time set by governments. The second is that the overt intention of the activity, and likely its motivation, is dependent on the document having an effect on political decision making and the real world. The path to such effect is not impossible, many have identified epistemic communities as effective in policy making (Haas et al., 1977). Yet even when successful the payoff is necessarily delayed and individual layers do not have their own payoffs. In these ways the work is more similar to attempting concurrent development of a single layer of software, and the risks of collaboration are not defrayed.



By far the most hoped for adaptation of the FLOSS form of organizing is to bring it to productive hybridization with the IS function of for-profit enterprises. This hope has taken two main forms. The first is sometimes known as “inner source” (e.g., Dinkelacker et al., 2002), where a firm attempts to generate an open source community within its corporate boundaries, examples include HP and the US DoD’s forge.mil. The second is to integrate FLOSS components into the firm’s IS strategy, both for internal IS and for the production of IS for sale.

Inner Source presents significant adaptation challenges. It is relatively simple to replicate the IT infrastructure of FLOSS inside a corporation; indeed selling such systems is a large part of Sourceforge’s and Collab.Net’s business models. Yet unsurprisingly, simple importation of technology is not sufficient to replicate a sociotechnical phenomenon. Inner Source struggles with two key issues, the first is the de-emphasizing of individual motivations and the second is the dominance of upfront investment and market-focused deadlines. Individual utility motivations seem unlikely to be as prevalent inside a corporate boundary, especially when building for external markets, and intrinsic motivations, such as learning and fun, are undermined by management, rather than individuals deciding the direction of their own work. This leaves Inner Source efforts in much the same motivational and payoff quandary faced by internal knowledge management systems. Firms inherently face market-driven deadlines, undermining the potential for productive deferral. In these circumstances Inner Source seems most likely to work in organizations able to sustain a “free time” culture of exploration and learning. A second possibility for effective adaptation is in firms which have significant non-marketed infrastructure needs. In this case, however, limiting the community to just those inside the corporation does not seem necessary and extending the community beyond the boundaries of the firm has seen success in IBM’s founding and extension of the Eclipse community.

The ability for firms to adapt FLOSS production into their IS function depends in part on the extent to which a firm can be a relatively passive consumer of the project, or whether their strategy requires them to actively develop the code. The first case is problematic only to the extent of ensuring that the FLOSS licenses match corporate strategies; the theory in this paper does not speak to this issue and clearly many organizations are able to find appropriate matches and use FLOSS software.

If, however, the corporate strategy requires active influence over the project there are significant challenges. Clearly corporate collaboration with FLOSS projects is possible, in fact there are many highly successful examples, such as IBM working with the Apache Foundation, replacing their internally developed webserver (WebSphere) with Apache’s httpd. Yet the theory articulated in this paper helps to clarify the issues that need to be resolved. The theory speaks most clearly to whether or not the firm can afford to “fit in” with the small layers and deferral of complex work, or whether their market imperatives generate deadlines and a strategic need for secrecy. The case of Apple’s Safari browser and the open source khtml project illustrates this difficulty. Apple wished to build a new web browser for their operating system. Apple’s market strategy calls for high secrecy during product development, and market pressures place a strong premium on rapid time to market. As part of a desire to build a compatible and high quality browser quickly, Apple based their Safari product on the khtml open source html rendering library. The library is under the LGPL license so Apple was within their legal rights to work in secret and only had to release their modifications once Safari was finished and distributed. Yet secrecy was not the only driver, by taking the work in-house, Apple was able to move much more quickly than the khtml project, short circuiting slow processes of layering and eliminating the need for productive deferral, solving complexity through high-trust, face to face work within their internal programming teams.

When Apple released Safari they did indeed release their modifications, seeking to gain goodwill from the open source community and to share on-going maintenance and development costs. Yet the khtml project was quite displeased. This was, in part, because the modifications were too large and had branched from khtml too long ago for them to be easily integrated; the work did not proceed in observable, short and evolutionary changes. One of the khtml authors wrote:



Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's [sic] with Apple to at least get access to the history of their internal [version control system] and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.

And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist. Maybe for Apple - at the very least for their marketing people. Clear? 5

This story stands in strong contrast to IBM’s adoption of apache. For IBM there was no need for secrecy since IBM was generating its revenue from services and higher-value added software, further up the stack. Further the httpd server was already capable enough so that IBM was able to fit in with the FLOSS model of working in small, visible steps. Their contributions keep the project active, and may provide volunteer participants with the sorts of “missing steps” that make their work e

LAYERED COLLABORATIONjames.howison.name/pubs/HowisonLayeredCollaboration.pdf · AND OPEN SOURCE...

Documents

Transcript of LAYERED COLLABORATIONjames.howison.name/pubs/HowisonLayeredCollaboration.pdf · AND OPEN SOURCE...