Coordination practices within FLOSS
development teams:
The bug fixing process
Kevin Crowston
1
and Barbara Scozzi
2
1
Syracuse University School of Information Studies
4–206 Centre for Science and Technology
Syracuse, NY 13244–4100, U.S.A.
2
Politecnico di Bari - Dipartimento di Ingegneria Meccanica e Gestionale
Viale Iapigia 182 70126 Bari, Italy
Abstract. Free/Libre Open Source Software (FLOSS) is primarily developed
by distributed teams. Developers contribute from around the world and coordi-
nate their activity almost exclusively by means of email and bulletin boards.
FLOSS development teams some how profit from the advantages and evade the
challenges of distributed software development. Despite the relevance of the
FLOSS both for research and practice, few studies have investigated the work
practices adopted by these development teams. In this paper we investigate the
structure and the coordination practices adopted by development teams during
the bug-fixing process, which is considered one of main areas of FLOSS pro-
ject success. In particular, based on a codification of the messages recorded in
the bug tracking system of four projects, we identify the accomplished tasks,
the adopted coordination mechanisms, and the role undertaken by both the
FLOSS development team and the FLOSS community. We conclude with sug-
gestions for further research.
1 Introduction
In this paper, we investigate the coordination practices for software bug fixing used in
Free/Libre Open Source Software (FLOSS) development teams. FLOSS is a broad
term used to embrace software developed and released under an “open source” li-
cense allowing inspection, modification and redistribution of the software’s source
without charge. There are thousands of FLOSS projects, spanning a wide range of
applications. Due to their size, success and influence, the Linux operating system and
the Apache Web Server (and related projects) are the most well known, but hundreds
of others are in widespread use, including projects on Internet infrastructure (e.g.,
sendmail, bind), user applications (e.g., Mozilla, OpenOffice) and programming lan-
guages (e.g., Perl, Python, gcc).
FLOSS development projects represent an interesting investigation area for re-
searchers interested in the analysis of coordination practices within distributed teams.
Many FLOSS development teams seem to benefit from the advantages of distributed
work without suffering from its drawbacks, such as difficulties in coordination and
Crowston K. and Scozzi B. (2004).
Coordination practices within FLOSS development teams: The bug fixing process.
In Proceedings of the 1st International Workshop on Computer Supported Activity Coordination, pages 21-30
DOI: 10.5220/0002683000210030
Copyright
c
SciTePress
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
2 Processes as theory
Most theories in organizational and information system research are variance theo-
ries, comprising constructs or variables and propositions or hypotheses linking them.
Such theories predict the levels of dependent or outcome variables from the levels of
independent or predictor variables, where the predictors are seen as necessary and
sufficient for the outcomes. An alternative to a variance theory is a process theory [5].
Rather than relating levels of variables, process theories explain how outcomes of
interest develop through a sequence of events [6]. Typically, process theories are of
some transient process leading to exceptional outcomes, e.g., events leading up to an
organizational change or to acceptance of a system. However, we will focus instead
on what might be called “everyday” processes: those performed regularly to create an
organization’s products or services. ” For example, Sabherwal and Robey [7] de-
scribed and compared the processes of information systems development for 50 pro-
jects to develop five clusters of similar processes.
Kaplan [8, p. 593] states that process theories can be “valuable aids in understand-
ing issues pertaining to designing and implementing information systems, assessing
their impacts, and anticipating and managing the processes of change associated with
them”. The main advantage of process theories is that they can deal with more com-
plex causal relationships than variance theories, and provide an explanation of how
the inputs and outputs are related, rather than simply noting the relationship. Repre-
senting a process as a sequence of activities provides insight into the linkage between
individual work and processes, since individuals perform the various activities that
comprise the process. As individuals change what they do, they change how they
perform these activities and thus their participation in the process. Conversely, proc-
ess changes demand different performances from individuals. Information and Com-
munication Technologies use might simply make individuals more efficient or effec-
tive at the activities they have always performed. However, an interesting class of
impacts involves changing which individuals perform which activities and how ac-
tivities are coordinated. The analysis is the aim of this paper.
3 Research methodology
To address our research question, how are bug fixes coordinated in FLOSS pro-
jects, a multiple case study of different FLOSS projects has been carried out. In this
section, we discuss sample selection and data sources, data collection and data analy-
sis. Projects to be studied have been selected among those available on Sourceforge,
(http://sourceforge .net/), a web-based system that supports more than 75,000 FLOSS
projects. Projects have access to a home page, a source code control system (CVS),
mailing lists, a bug tracking system, software to manage activities and permanent file
database. We selected several projects to study in-depth by employing a theoretical
sampling strategy. First, we chose projects for which data we need for our analysis
are publicly available (not all projects allow public access to the bug tracking sys-
tem). Second, we chose teams with more than 8 members, since smaller projects
seemed less likely to experience significant coordination problems. Finally, in the
attempt to link coordination practices to project success, we tried to select more and
23
less successful development teams.
To this aim we used the definitions
of success proposed by [9], who
suggest that a project is successful
if it is active, the resulting soft-
ware is downloaded and used and
the code matures. Based on these
criteria, 4 FLOSS projects were
selected for analysis. A brief de-
scription of the projects is reported
in Table 1. Based on the definition
proposed in [9], Kicq, Gaim and
PhPmyAdmin were chosen as
examples of effective projects
because they are active, the result-
ing software is downloaded and
used and the code has been matur-
ing. DynAPI was chosen as an
example of a less effective project
because the number of downloads,
programming activity and rapidly
decreased in the months leading up
to the study.
We collected data indicative of
the success of each project, such as
its level of activity, number of
downloads and development
status. We then collected data from
the archives of the bug tracking
system, the tool used to support
the bug fixing process [10].. These data are useful because they are unobtrusive
measures of the team’s behaviors [11]. An example bug report in shown in Figure 1.
In the bug tracking system, each bug has a request ID, a summary (what the bug is
about), a category (the kind of bug, e.g., system, interface), the name of the team
member (or user) who submitted it, and the name of the team member it was assigned
to. As well, individuals can post messages regarding the bug, such as further symp-
toms, requests for more information, etc. From this system, we extracted data about
who submitted the bugs, who fixed them and the sequence of messages involved in
the fix. By examining the name of the messages senders, we can identify the project
and community members who are involved in the bug fixing process. Demographic
information for the projects and developers and data from the bug tracking system
were collected in the period 17–24 November 2002. We examined 31 closed bugs for
Kicq, 95 closed bugs for DynAPI, 51 bugs for Gaim and 51 for PhPMyAdmin.
Fig. 1. Example bug report and followup mes-
sages (adapted from http://sourceforge.net/
tracker/index.php?func=detail&aid=206585
&group_id=332&atid=100332)
24
Table 1. Four examined projects.
KICQ DynAPI Gaim PhpMyAdmin
Goal ICQ client
for the KDE
project
Enhance the
DynAPI Dy-
namic HTML
Library
Multi-
platform
AIM client
Web-based data-
base administra-
tion
Development
Status
4 Beta, 5
Production
Stable
5 Production
Stable
5 Production
Stable
5 Production
Stable
License GPL LGPL, GPL GPL GPL
Open bugs
/total number of
bugs
26 /88 45/220 269 /1499 29 /639
Team members 9 11 9 9
For each of the selected bug reports, we carefully examined the text of the ex-
changed messages to identify the task carried out by each sender. By inductively
coding the text of the messages in the bug tracking systems of the four projects, we
identified the different elementary tasks carried out during the bug fixing process. For
example the message:
“I’ve been getting this same error every FIRST time I load the dynapi in NS (win32).
After reloading, it will work… loading/init problem?”
Table 2. Coded tasks in the bug fixing process
1.0.0 Submit (S)
1.1.0 Submit bug (code errors)
1.1.1 Submit symptoms
1.1.2 Provide code back trace (BT)
1.2.0 Submit problems
1.2.1 Submit incompatibility problems
(NC)
2.0.0. Assign
2.1.0 Bug self-assignment (A*)
2.2.0 Bug assignment (A)
3.0.0 Analyze
3.1.0 Contribute to bug identification
3.1.1Report similar problems (R )
3.1.2 Share opinions about the bug (T)
3.2.0 Verify impossibility to fix the bug
3.2.1 Verify bug already fixed (AF)
3.2.2.Verify bug irreproducibility (NR)
3.2.3 Verify need for a not yet sup-
ported function (NS)
3.2.4 Verify identified bug as inten-
tionally introduced (NCP)
3.3.0 Ask for more details
3.3.1 Ask for Code version/command
line (V)
3.3.2 Ask for code back trace/examples
(RBT/E)
3.4.0 Identify bug causes (G)
3.4.1 Identify and explain error (EE)
3.4.2 Identify and explain bug causes
different from code (PNC)
4.0.0 Fix
4.1.0 Propose temporary solutions (AC)
4.2.0 Provide problem solution (SP)
4.3.0 Provide debugging code (F)
5.0.0 Test & Post
5.1.0 Test/approve bug solution
5.1.1 Verify application correctness W
5.2.0 Post patches (PP)
5.3.0 Identify further problems with pro-
posed patch (FNW)
6.0.0 Close
6.1.0 Close fixed bug/problem
6.2.0 Closed not fixed bug/problems
6.2.1 Close irreproducible bug (CNR)
and close it
6.2.2 Close bug that asks for not yet
supported function (CNS)
6.2.3 Close bug identified as intention-
ally introduced (CNCP)
25
Bug
ID
Sum-
mary
Assigned to Submitter
206585
crash with
icq chat
bills khub
Task Person Comments
(S) Khub
(V) denis asks what version khub is running
(R) robvnl reports the same problem as khub. submits information about the operat-
ing systems and the libraries (Qt/kde)
(V denis asks again what version both users are running
(W) khub reports the most recent version of kicq works
(T) robvnl reports version information
(C)
bug closed
Fig. 2. Coded version of bug report in Fig.1.
represents a report submitted by a user (someone other than the person who initially
identified and submitted the bug). Such a user contributed to bug analysis. In particu-
lar, her message has been coded as “report similar problems”. Table 2 shows the list
of task types that were developed for the coding. The lowest level elementary task
types were successively grouped into 6 main types of tasks, namely Submit, Assign,
Analyze, Fix, Test & Post, and Close.
Each process starts with a bug submission (S) and finishes with bug closing (C).
Submitters may submit problems/symptoms associated with bugs (Ss), incompatibil-
ity problems (NC) or/and also provide information about code back trace (BT). After
submission, the team’s project managers or administrators should assign the bug to
someone to be fixed ((A); (A*) if they self-assign the bug). Other members of the
community may report similar problems they encountered (R), discuss bug causes
(T), identify bug causes (G) and/or verify the impossibility of fixing the bug. Bug
fixing may be followed by a test and the submission of a patch (TP). This is a coordi-
nation task. However, as later explained, in the examined projects, this type of task is
often neglected. In most cases, but not always, team members spontaneously decide
to fix (F) the bug. Before doing that, they often ask more information to better under-
stand bug causes (An). The bug is then closed (C). Bugs can may be closed either
because they have been fixed or they cannot be fixed (i.e. they are not reproducible
(CNR), involve functions not supported yet (CNS) and/or are intentionally introduced
to add new functionality in the future (CNCP). Notice that the closing activity is usu-
ally attributed to a particular user.
A complete example of the coded version of a bug report (the one from Figure 1)
is shown in Figure 2.
26
4 Results
In Table 3, we describe the occurrences per task for the four projects and the average
number of tasks to fix bugs. A χ
2
test shows a significant difference in the distribu-
tion of task types across projects (p<0.001). For all projects, the most common task
sequence is submit, analyze, fix, close. In longer sequences, it is usually the analyze
task that is repeated more times. Data about the percentage of submitted, assigned and
fixed bugs both by team members and members external to the team for each project
are reported in Table 4. Table 5 provides some observations of the nature of the bugs
fixing process in the four projects.
5 Discussion
In the traditional bug fixing process, several tasks are coordination tasks. The search
for duplicate bugs as well as the numerous forward and verify tasks are coordination
mechanisms used to manage a dependency (Malone and Crowston’s [12] definition of
coordination). Database searching manages a dependency between two tasks that can
Table 3. Task occurrences and average number of tasks per projects.
Task
Project (bugs)
(S) (Ag) (An) (F) (TP) (C)
Avr. tasks per
bug
KICQ (31) 44 3 23 23 1 31 3.9
Dynapi (95) 121 0 83 57 16 95 4
Gaim (51) 56 0 65 29 12 51 4
Phpmyadmin (51) 53 1 69 49 10 51 4.4
Table 4. The bug fixing process: Main results.
Kicq DynAPI Gaim PhpMyAdmin
Bugs submitted by team mem-
bers
9.7% 21.1% 0% 21.6%
Bugs submitted by members
external to the team
90.3% 78.9% 100% 78.4%
Bug assigned/self-assigned
of which:
9.7% 0% 0% 2%
Assigned to team members 0% - - 100%
Self assigned 66% 0%
Assigned to members exter-
nal to the team
33% - - 0%
Bug fixed, of which: 74% 60% 56.9% 96%
Fixed by team members 70% 35.1% 79.3% 89.8%
Bug fixed by members exter-
nal to the team
30% 64.9% 20.7% 8.2%
27
have the same outcome. Forwarding and verifying tasks are coordination mechanisms
used to manage dependency between a task and the actor appropriate to perform that
task. In a large software company, many actors are involved, each of them carry out a
very specialized task.
The above analysis provides some interesting insights on the bug fixing process
for FLOSS development. Process sequences are averagely quite short (four tasks) and
they seem to be quite similar: submit, analyze, fix and close. As shown in Table 3,
formal task assignments are quite uncommon. Only few bugs are formally assigned.
Such a coordination activity seems rather to spontaneously emerge. Based on bug
description and analysis, those who have the competencies autonomously decide to
fix the bug. That activity is facilitated by the supplied backtrace and analysis often
undertaken by several contributors. The lack of assignment is one of main difference
differentiating the process as it occurs in FLOSS development team from the tradi-
tional commercial process. As briefly described in section 1, within traditional proc-
esses assignments are coordination activities frequently carried out.
Testing is also quite an uncommon task in the logs. Most of the proposed fixes are
directly posted presumably after personal testing. If no one describes the emergence
of new problems with these fixes, they are automatically posted and the attendant bug
closed. It is important also to note that some of the posted problems do not represent
real bugs, so they are directly closed with that explanation.
A further difference is that in these projects, the process is performed by few team
members (usually not more that two or three) working with a member of the larger
community. Team members (usually project managers or administrators) are most
involved in bug fixing. Surprisingly, only a few developers (of the team) are involved
in the process. Most of the community is composed by active users who submit bugs
or contribute to their analysis. However, only two or three members of the involved
community are involved in fixing tasks and can be referred to as co-developers.
We also noted striking differences in the level of contribution to the process. The
most active users in the projects carried out most of the tasks while most others con-
tributed only once or twice. As expected, the most widely dispersed type of action
was submitting a bug, while diagnosis and bug fixing activities were concentrated
among a few individuals.
As we have few members of the team and few members of the community (co-
developers) mostly involved in bug fixing and many users/members of the commu-
nity (active users) mostly involved in bug submission, the organizational models
proposed in the literature [13] seem to be valid for the bug fixing process. It would be
interesting to further investigate if those, among the active users also involved in bug
fixing, also contribute to software coding.
Also, based on the analysis of task carried out and the attendant coordination
mechanisms we argue that the bazaar metaphor proposed by [4] to describe the OSS
organization structure is still valid for the bug fixing process. As in a bazaar, the
actors involved in the process autonomously decide the schedule and contribution
modes for software development, making a central coordination action superfluous.
As apparently less successful, we expected to find that DynAPI had a smaller ac-
tive user base than the other projects. However, as noted above, data shows the oppo-
site. It seems likely that our estimation of the success of the two projects based on
activity levels is mistaken, or at least an over-simplification. We plan to further ex-
28
plore this hypothesis by examining a larger number of projects (e.g., to examine the
change in the population over time).
Table 5. Observed characteristics of the bug fixing processes in the four projects.
Kicq DynAPI Gaim PhpMyAdmin
Min task
sequence
2 2 2 2
Max task
sequence
6 12 6 11
Uncommon
tasks
Bug assign-
ment/ 3
Bug assign-
ment/ 0
Bug assign-
ment/ 0
Bug assign-
ment/ 1
Community
members
18 53 23 20
Team mem-
bers’ par-
ticipation
2 of 9 6 of 11 3 of 9 4 of 10
Most active
team mem-
bers
Role/ name
Project mgr
denis
Developer
davidvh
Admin
rainwater
Ext member
dcpascal also
active
Admin-
developer
warmenhoven
Developer
robflynn
Admin-
developer loic1
Admin-
developer lem9
Max posting
by single
community
member
2 6 4 3
Not fixable
bug closed
8 5 5 -
6 Conclusions
We investigated the coordination practices adopted within four FLOSS development
teams. In particular, we analyzed the bug fixing process, which is considered critical
for FLOSS’ success. The paper provided some interesting results. The process is
mostly sequential and composed of few steps, namely submit, analyze, fix and close.
Second, the process seems to lack traditional coordination mechanisms such as task
assignment. As a consequence, labour is not equally distributed among process ac-
tors. Few contribute heavily to all tasks whereas the majority just submit one or two
bugs. Third, the organization structure involved in the process resembles the one
proposed in the literature for the FLOSS development process. Few actors (core de-
velopers), usually team project managers or administrators, are mostly involved in
bug fixing bugs. Most of the involved actors are instead active users, who just submit
bug reports. In between are few actors, external to the team, who submit bugs and
contribute to fixing them. No evident association was found among coordination
practices and project success.
29
The paper contributes to fill a gap in the literature by providing a picture of the co-
ordination practices adopted within FLOSS development team. Besides, the paper
proposes an innovative research methodology (for the analysis of coordination prac-
tices FLOSS development teams) based on the collection of process data by elec-
tronic archives, the codification of message texts, and the analysis of codified infor-
mation supported by the coordination theory. However, the results are based on few
projects, so further analyses are necessary to validate them. In the future, we intend to
deepen the knowledge about the coordination practices adopted by the four projects
by directly interviewing some of the involved actors.
References
1. Mockus, A., R.T. Fielding, and J.D. Herbsleb, Two Case Studies Of Open Source Software
Development: Apache And Mozilla. ACM Transactions on Software Engineering and
Methodology, 2002. 11(3): p. 309–346.
2. Scacchi, W. Software Development Practices in Open Software Development Communi-
ties: A Comparative Case Study (Position Paper). 2002.
3. Crowston, K., A coordination theory approach to organizational process design. Organiza-
tion Science, 1997. 8(2): p. 157–175.
4. Raymond, E.S., The cathedral and the bazaar. First Monday, 1998. 3(3).
5. Markus, M.L. and D. Robey, Information technology and organizational change: Causal
structure in theory and research. Management Science, 1988. 34(5): p. 583–598.
6. Mohr, L.B., Explaining Organizational Behavior: The Limits and Possibilities of Theory
and Research. 1982, San Francisco: Jossey-Bass.
7. Sabherwal, R. and D. Robey, Reconciling variance and process strategies for studying
information system development. Information Systems Research, 1995. 6(4): p. 303–327.
8. Kaplan, B., Models of change and information systems research, in Information Systems
Research: Contemporary Approaches and Emergent Traditions, H.-E. Nissen, H.K. Klein,
and R. Hirschheim, Editors. 1991, Elsevier Science Publishers: Amsterdam. p. 593–611.
9. Crowston, K. and B. Scozzi, Open source software projects as virtual organizations:
Competency rallying for software development. IEE Proceedings Software, 2002. 149(1):
p. 3–17.
10. Herbsleb, J.D., et al., An Empirical Study of Global Software Development: Distance and
Speed, in Proceedings of the International Conference on Software Engineering (ICSE
2001). 2001: Toronto, Canada. p. 81–90.
11. Webb, E. and K.E. Weick, Unobtrusive measures in organizational theory: A reminder.
Administrative Science Quarterly, 1979. 24(4): p. 650–659.
12. Malone, T.W. and K. Crowston, The interdisciplinary study of coordination. Computing
Surveys, 1994. 26(1): p. 87–119.
13. Cox, A., Cathedrals, Bazaars and the Town Council. 1998.
30