The Role of Modularity in Free/Open Source Software Development

Abstract

Software design and development in Free/Open Source projects are analyzed through the lens of the theory of modularity applied to complex systems. We show that both the architecture of the artifacts (software) and the organization of the projects benefited from the paradigm of modularity in an original and effective manner. In particular, our analysis on empirical evidence suggests that three main shortcuts to modular design have been introduced and effectively applied. First, some successful projects inherited previously existing modular architecture, rather than designing new modular systems from scratch. Second, popular modular systems, like GNU/Linux kernel, evolved from an initial integrated structure through a process of evolutionary adaptation. Third, the development of modular software took advantage of the violation of one fundamental rule of modularity, that is, information hiding. Through these three routines, the projects can exploit the benefits of modularity, such as concurrent engineering, division of labor, decentralized and parallel development; at the same time, these routines lessen some of the problems posed by the design of modular architectures, namely imperfect decompositions of interdependent components. Implications and extensions of Free/Open Source projects experience are discussed in the conclusions.

Coordination of Joint Search in Distributed Innovation Processes: Lessons from the Effects of Initial Code Release in Open Source Software Development

“…David and Ghosh (2008) have shown that the structure of the technical interdependencies between the different modules composing Linux have a certain degree of correspondence to the pattern of social ties the authors of those modules have built through past collaboration. A similar perspective emerges from the analysis undertaken by Narduzzo and Rossi (2005) in their effort to define modularity in the OSS context. In OSS the architecture of the software is likely to be constantly changed over time, and so is the degree of modularization it embodies.…”

“…In self-organized social bodies it is however difficult for architects to master the process in the same way they could do in a firm. The main problem is that it is very difficult to develop a fullfledged architecture at the beginning of a self-organized process of development: self-organization by nature implies a bottom up approach to coordination (von Krogh et al, 2012;David & Rullani, 2008;Lanzara & Morner, 2005), involving the risk that developers split into different and potentially incompatible software (Dalle & Juillen, 2003;Narduzzo & Rossi, 2005). The potential of providing coordination by leadership is limited by the same factors.…”

“…First, the coordination challenge is particularly demanding: open source software development requires coordinating many independent developers who work in a self-organized fashion (von Hippel & von Krogh, 2003). Second, the stakes are very high: there is a high risk that developers split into different and potentially incompatible software (Dalle & Juillen, 2003;Narduzzo & Rossi, 2005). Third, the available coordination mechanisms are less powerful than in other settings: the set of available coordination mechanisms is restricted due to the lack of direct supervision and authority in a selforganized community without employment contracts, which by nature implies a bottom-up approach to coordination (von Krogh et al, 2012;David & Rullani, 2008;Lanzara & Morner, 2005).…”

“…Self-organized social bodies lack a principal with the authority to direct subordinates. This leads to difficulties in developing a full-fledged architecture in the beginning and the need to instead rely on architectures that are emergent (Narduzzo & Rossi, 2005). The extent to which the need for coordination can be reduced by a modular product architecture is, therefore, restricted.…”

Information policies and open source software in developing countries

“…We call them community‐led projects. The high–high case usually comes up when a software project has a stable design and when it is structurally possible to break it in many independent modules that are suitable for large‐scale team development (Narduzzo & Rossi, 2005). In many cases, the design originates from an established standard.…”