@inproceedings{6780,
  keywords = {Coordination, FLOSS, document genre, Stigmergy},
  author = {Kevin Crowston and Carsten Østerlund and James Howison and Francesco Bolici},
  title = {Work as coordination and coordination as work:  A process perspective on FLOSS development projects},
  abstract = {Coordination in work teams has been a topic of perennial interest in organizational studies. The starting point of much of the literature is a conceptual separation between the work itself, on the one hand, and activities undertaken to coordinate the work, on the other, labelled articulation work or coordination mechanisms. We suggest that the analytic duality between work and coordination arises in part from an information processing perspective on work that assumes an input, process and outcome model. In this perspective, it is natural to consider the process and coordination of the process as separate activities. However, in contrast, one can envision work processes as clustering around the outcome of the work. Each process contributes to the evolving work at hand but at the same time takes its clues for what to do next (i.e., input) from the evolving work product. In this case, the separation of discrete coordination and work events dissolves in a process perspective, for which analyzing interactions rather than self-standing actions is preferred. Out of this conundrum arises the question: how can we understand coordination as an inseparable part of work and the outcome of work itself? 

The paper investigates this question in the setting of free and open source software (FLOSS) development projects. In FLOSS projects, we find little evidence of overt coordination of development activities. Rather, we argue, coordination takes place primarily through the work itself, i.e., through the shared software source code. We present evidence showing how the software code posted by FLOSS developers serves as an outcome of their work and a coordination device at one and the same time. This approach is supported by socio-material nature of software code itself and by commonly adopted approaches to software development in the FLOSS community. 

To explain these results theoretically, we draw inspiration from the literature on documenting work demonstrating how documents can be both model of work and models for work. Extending this perspective we argue that work itself can serve not only as a model of work but more importantly a model for future work. Specifically, we argue that work outcomes, e.g., software code, can serve as a model for work by 1) invoking typified actions in response to recurrent situations, 2) being part of larger formalized structures of legitimate work activities, and being 3) visible, 4) mobile 5) and combinable.
},
  year = {2011},
  journal = {Third International Symposium on Process Organization Studies},
  month = {6/2011},
  address = {Corfu, Greece},
  language = {eng},
}