The Bug Fixing Process in Proprietary and Free/Libre Open Source Software: A Coordination Theory Analysis

Keywords: Free/Libre Open Source Software, Software Maintenance, Coordination Theory, Linux, Bug Fixing

INTRODUCTION

To support business process transformation, we must first be able to represent business processes in a way that allows us to compare and contrast them or to design new ones (Malone et al., 1999). Consider the software problem (bug) fixing process, a process that I will use as a source for examples

in this chapter. Customers having problems with a piece of software (a bug) report the problems to its developers, who (they hope) eventually provide some kind of solution (a bug fix). In this chapter, I compare the bug fixing processes for a proprietary minicomputer operating system and for the Free/Libre Open Source Software (FLOSS)1 Linux kernel project. The company I studied had an elaborate process to receive problem reports, filter out duplicates of known problems, identify which modules of the system are apparently at fault for novel problems, and route the reports to the software engineers responsible for those modules. Along the way, an engineer might develop a work-around (i.e., a way to avoid the problem); the responsible software engineer might develop a change to the code of part of the system (i.e., a patch) to fix it. The patch would then be sent to other groups who test it, integrate it into the total system, and, eventually, send it to the customers who originally had the problem. (A more detailed description of this process appears below.) The Linux bug fixing process (which has evolved over time) has a similar but different set of steps. The description and comparison of these processes raise several questions that are key for business process transformation: Why is the process structured this way, with finely divided responsibility for different parts of the process? In what ways are the two processes (proprietary and FLOSS) similar or different and what are the implications of these similarities and differences? And, more simply, how else could software development organizations approach problem fixing?