Difficulties of Initiating an OSS Development Project and Community

Increasingly, organizations might choose to release their code in anopen source fashion. However, simply making large tracts of source codeavailable to the general development community is unlikely to be suc-cessful, since there is then no organizational memory or persistent traceof the design decisions through which the code base evolved to that state.Thus, making the source code of Netscape available in the Mozilla projectwas not sufficient in itself to immediately instantiate a vibrant OSS project(although some very good OSS development tools have emerged as by-products). In most OSS projects, changelogs and mailing lists provide amechanism whereby new developers can read themselves into the designethos of the project, in itself perhaps not the most efficient mechanism toachieve this. Gorman (2003) describes the phenomenon in the Linuxvirtual memory (VM) management subproject whereby new developersmay complain about the use of the buddy allocator algorithm, which datesfrom the 1970s, for physical page allocation, as they feel the slab alloca-tor algorithm might be better, for example. However, they fail to appreci-ate the design rationale in the evolution of the project which led to thatchoice.

Furthermore, the principle of “having a taillight to follow,” which oftenguides OSS development as developers incrementally grow an initialproject, may perhaps not be robust enough for development if OSS prod-ucts are to be produced in vertical domains where domain knowledge iscritical (an issue discussed in the next section). Linus Torvalds’s apparentinability to successfully manage a small development team at Transmeta(Torvalds and Diamond 2001) suggests that the concept may be tooephemeral and individualistic to provide any continuities to general soft-ware project management.

Negative Implications of Excessive Modularity

Modularity is necessary in OSS for a number of reasons. Firstly, as previ-ously mentioned, it allows work to be partitioned among the global poolof developers. Also, as projects progress, the learning curve of the rationalebehind requirements, design decisions, and so on becomes extremelysteep. Thus, to facilitate the recruitment of new contributors, developersneed to be able to reduce their learning focus below the level of the overallproject. Modularity helps achieve this; thus, it is a sine qua non for OSS.Indeed, many OSS projects were rewritten to be more modular before theycould be successfully developed in an OSS mode, including Sendmail,Samba, and even Linux itself (Feller and Fitzgerald 2002; Narduzzo andRossi 2003). However, the cognitive challenge in designing a highlymodular architecture of autonomous modules with minimal interdepen-dencies is certainly not trivial (Narduzzo and Rossi 2003).

Also, the increase in modularity increases the risk of one of the well-known and insidious problems in software engineering: that of commoncoupling between modules, where modules make references to variablesand structures in other modules which are not absolutely necessary. Thus,changes to data structures and variables in seemingly unrelated modulescan have major follow-on implications. In this way, OSS systems evolve tobecome very difficult, if not impossible, to maintain in the long run. Someevidence of such a phenomenon being potentially imminent in the caseof Linux may be inferred from Rusovan, Lawford, and Parnas ( in this volume), and also in a study of the modularity of Linux (Schach,Jin, and Wright 2002).