Why Not Improve Coordination in Distributed Software Development by Stealing Good Ideas from Open Source

Software projects are increasingly distributed among many sites, often located at great distance, both geographic and cultural, from one another. This creates the potential for enormous problems, whose effects run the gamut from enormous cumulative delay through complete breakdown and failure [1]. Open source projects are remarkable in that they usually must solve all the problems of distributed development, using only very simple communication tools such as e-mail, listservs, newsroups, and change management systems such as CVS or Bugzilla. In a case study of the Apache server [3], the authors identified several techniques used to coordinate the work. These techniques can be summarized as follows: • A small, elite team of capable developers, each with distinctive expertise, all of whom have commit privileges. Each is trusted by the others to make changes to the server code. • The core team coordinates their work informally, by informing others about what they are doing, asking recognized experts in the group when in doubt, and by reviewing all changes to the code. • In order to join the core group, candidates must clearly demonstrate competence, commitment to the work, and nearly always develop a needed specialty. • The core group creates the vast majority of new functionality. • A much larger group submits bug fixes. Proposed fixes are reviewed and acted upon by the core group. Bug fixes generally have fewer interdependencies than new functionality, since most of the work is usually finding the problem. • A much larger group yet tests the code, through actual use, and submits problem reports. • There is no formal requirements process – the requirements are determined implicitly, as whatever the developers actually build. Presumably, features are selected based on what individual developers themselves need in the product. • Work is not assigned; individuals choose what work they will do. The choices are constrained, however, by various motivations that are not fully understood. For example, it can be assumed that developers try to maximize the chance that their code will be included in a release, and will enhance their reputation. These techniques, as effective as they indisputably are for open source development, have certain limitations. Among them are the following: • The core group cannot exceed some maximum size, say 15, or the overhead for the informal style of coordination will become overwhelming. • The largest system that can be built is constrained by the size of …