@article {flosswp184,
	title = {Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code (updated)},
	year = {2005},
	note = {"For each design, we report data on the number of source files, the number of dependencies, the density of the DSM (i.e., the number of dependencies per source file pair) the propagation cost and the clustered cost. We also provide data on the average complexity of source files, in terms of the number of functions and lines of code."},
	month = {June},
	abstract = {This paper reports data from a study that seeks to characterize the differences in design structure between complex software products. In particular, we use Design Structure Matrices (DSMs) to map the dependencies between the elements of a design and define metrics that allow us to compare the structures of different designs. We first use these metrics to compare the architectures of two software products - the Linux operating system and the Mozilla web browser - that were developed via contrasting modes of organization: specifically, open source versus proprietary development. We then track the evolution of Mozilla, paying particular attention to a purposeful "re-design" effort that was undertaken with the intention of making the product more "modular." We find significant differences in structure between Linux and the first version of Mozilla, suggesting that Linux had a more modular architecture. We also find that the redesign of Mozilla resulted in an architecture that was significantly more modular than that of its predecessor, and indeed, than that of Linux. Our results, while exploratory, are consistent with a view that different modes of organization are associated with designs that possess different structures. However, we also illustrate that purposeful managerial actions can have a large impact on structure. This latter result is important given recent moves to release proprietary software into the public domain. These moves are likely to fail unless the product possesses an architecture that facilitates participation. Our paper provides evidence that a tightly-coupled design can be adapted to meet this objective.},
	keywords = {complexity, cost, dependencies, functions, lines of code, linux, loc, mozilla, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/maccormackrusnakbaldwin2.pdf},
	author = {Alan MacCormack and John Rusnak and Carliss Baldwin}
}
@article {flosswp138,
	title = {The Architecture of Cooperation: How Code Architecture Mitigates Free Riding in the Open Source Development Model},
	year = {2004},
	month = {January},
	abstract = {We argue that the architecture of a codebase is a critical factor that lies at the heart of the open source development process. To support this argument, we define two observable properties of an architecture: (1) its modularity and (2) its option values. Developers can make informed judgments about modularity and option value from early code releases. Their judgments in turn will influence their decisions to work and to contribute their code back to the community. We go on to suggest that the core of the open source development process can be thought of as two linked games played within a codebase architecture. The first game involves the implicit exchange of effort directed at the modules and option values of a codebase; the second is a Prisoners{\textquoteright} Dilemma game triggered by the irreducible costs of communicating. The implicit exchange of effort among developers is made possible by the the non-rivalrous nature of the codebase and by the modularity and option values of the codebase{\textquoteright}s architecture. This exchange creates value for all participants, both workers and free-riders. In contrast, the Prisoners{\textquoteright} Dilemma is a problem that must be surmounted if the exchanges are to take place. It can be addressed through a combination of reducing the costs of communication, providing rewards, and encouraging repeated interactions. Finally, the initial design and "opening up" of a codebase can be seen as a rational move by an architect who is seeking to test the environment in hopes of initiating exchanges of effort with other developers.},
	attachments = {https://flosshub.org/sites/flosshub.org/files/baldwinclark.pdf},
	author = {Carliss Baldwin}
}
