![](bg2.png)
knowledge transfer. Intriguingly, many traditional coordination mechanisms seem not
to be used by FLOSS development teams [1]. Yet, “little is known about how people
in these communities coordinate software development across different settings, or
about what software processes, work practices, and organizational contexts are neces-
sary to their success” [2]. Given the economic, legal and social implication, an analy-
sis of the coordination practices of FLOSS teams could be useful to better understand
the FLOSS phenomenon per se. As well, distributed teams of all sorts are increas-
ingly used in many organizations. The analysis of practices adopted by FLOSS teams
could be useful to managers considering adoption of this organizational form.
In the paper, coordination practices in FLOSS development processes are analyzed
by adopting a process theory, i.e. we investigate which tasks are accomplished, how
and by whom they are assigned, coordinate, and performed. To understand the pro-
jects’ coordination practices, we selected four representative FLOSS projects and
inductively coded the steps involved in fixing various bugs as recorded in the pro-
jects’ bug tracking systems to reveal the nature of the processes adopted. We decided
to examine the bug fixing process for three reasons. First, bug fixing provides “a
microcosm of coordination problems” [3]. Second, a quick response to bugs has been
mentioned as a particular strength of the FLOSS process: as Raymond [4] puts it,
“given enough eyeballs, all bugs are shallow”. Finally, it is a process that involves the
entire developer community and thus poses particular coordination problems.
To ground our discussion, we will first briefly introduce the bug fixing process,
which consists of the tasks needed to correct software bugs. Crowston [3] described
the bug fixing process observed at a commercial software company (to our knowl-
edge, no description of the bug fixing process as performed in distributed teams is
provided in the literature).
The process is started by a customer who finds a problem when using a software
system. The problem is reported (sometimes automatically or by the customer) to the
company’s response center. In the attempt to solve the problem, personnel in the
center look in a database of known bugs. If a match is found, the fix is returned to the
customer; otherwise, after identifying the affected product, the bug report is for-
warded to an engineer in the marketing center. The assigned engineer tries to repro-
duce the problem and identify the cause (possibly requesting additional information
from the reporter to do so). If the bug is real, the bug report is forwarded to the man-
ager responsible for the module affected by the bug. The manager then assigns the
bug to the software engineer responsible for that module. The software engineering
diagnoses the problem (if she finds that the problem is in a different module, the
report is forwarded to the right engineer) and designs a fix. The proposed fix is
shared with other engineers responsible for modules that might be affected. When the
feedback from those engineers is positive, the proposed design is transformed into
lines of code. If changes in other module are needed, the software engineer also asks
the responsible engineers for changes. The proposed fix is then tested, the eventual
changed modules are sent to the integration manager. After approving, the integration
manager recompiles the system, tests the entire system and releases the new software
in the form of a patch.
The remainder of the paper is organized as follows. In section 2 we stress the rele-
vance of process theory and explain why we adopted such a theoretical approach. The
research methodology adopted to study the bug fixing process is described in Section
3. In Section 4 we describe and discuss the study’s results. Finally, in Section 5 we
draw some conclusions and propose future research directions.
22