Technical Coordination in Open Source Software Development James D. Herbsleb School of Computer Science Carnegie Mellon University

2 Meanings of “Open Source”  Legal and pragmatic arrangements to ensure availability of source code  Development process − Open community − Widely dispersed contributors − Emulated in many other contexts − Seems relatively free of coordination problems

3 Multi-site Delay multi sitesingle site Network Element A Network Element B Work Days Last Modification - First Modification All changes July 1997 to July,1999 Modification Request (MR) interval

4 Coordination  “Managing dependencies between activities” ( Malone & Crowston, 1994)  Are many kinds of dependencies, we are focusing on depedencies among engineering decisions, e.g., − Selecting or designing algorithm − Selecting or designing data structure − Selecting object model − Writing the termination condition for a loop − Etc., etc.  Coordination issues are pervasive in software engineering

5 Assumptions  Decisions are a reasonable unit of “progress” in software project  Decision-making consumes resources (calendar time and effort)  Decisions tend to be highly mutually constraining  The “coordination problem” is avoiding constraint violation  Constraint violation produces defects

Application Domain Software Design Domain Functionality Development Work

Application Domain Software Design Domain Software Functionality Decisions Constraints Development Work

Application Domain Software Design Domain Software Functionality time people Decisions Constraints

Application Domain Software Domain Software Functionality time people Coordination

10 Number of people involved in decision + Density of interdependence among decisions + Automatic constraint enforcement Effectiveness of communication among decision-makers Visibility of constraints among decisions Reduced productivity + Increased cycle time + Coordination breakdowns: Violations of mutual constraints among engineering decisions Defects (when violations are not discovered and fixed) + + Rework (when violations are discovered and fixed) “Macro” Theory of Coordination

11 Number of people involved in decision + Density of interdependence among decisions + Automatic constraint enforcement Effectiveness of communication among decision-makers Visibility of constraints among decisions Reduced productivity + Increased cycle time + Coordination breakdowns: Violations of mutual constraints among engineering decisions Defects (when violations are not discovered and fixed) + + Rework (when violations are discovered and fixed) Coordination and Open Source  Development work done by users − Eliminates enormous communication problem − Constraints imposed by implicit requirements are apparent − Simpler, smaller product

12 Number of people involved in decision + Density of interdependence among decisions + Automatic constraint enforcement Effectiveness of communication among decision-makers Visibility of constraints among decisions Reduced productivity + Increased cycle time + Coordination breakdowns: Violations of mutual constraints among engineering decisions Defects (when violations are not discovered and fixed) + + Rework (when violations are discovered and fixed) Coordination and Open Source  Management structure − Minimal -- core group with commit privileges − Decision-making by those with demonstrated technical merit − Participation mirrors dependencies

13 Number of people involved in decision + Density of interdependence among decisions + Automatic constraint enforcement Effectiveness of communication among decision-makers Visibility of constraints among decisions Reduced productivity + Increased cycle time + Coordination breakdowns: Violations of mutual constraints among engineering decisions Defects (when violations are not discovered and fixed) + + Rework (when violations are discovered and fixed) Coordination and Open Source  Open, archived technical discussions − Draws on very large pool of potential experts − Newbies can catch up with minimal distractions to existing staff − Preserves design rationale

14 Technical Coordination Modeled as CSP  Constraint satisfaction problem − a project is a large set of mutually-constraining decisions, which are represented as − n variables x 1, x 2,..., x n whose − values are taken from finite, discrete domains D 1, D 2,..., D n − constraints p k (x k1, x k2,..., x kn ) are predicates defined on − the Cartesian product D k1 x D K2 x... x D kj.  Solving CSP is equivalent to finding an assignment for all variables that satisfy all constraints Formulation of CSP taken from Yokoo and Ishida, Search Algorithms for Agents, in G. Weiss (Ed.) Multiagent Systems, Cambridge, MA: MIT Press, 1999.

15 Modeling Coordination -- “Micro” Theory  Create models to explore influence of − Ways of assigning decisions to agents − Communication practices and tools − Properties of constraint network, e.g., Average distance between nodes Clustering  Open source process is a region in this “model space”  Empirically test hypotheses