tributed with the FreeBSD operating system.(Many projects appear on more than one of thelocations just listed.) Following the reusedopen source code’s evolution and deploying thecorresponding components are also becomingless haphazard operations, with mechanismssuch as installable packages and anonymousConcurrent Versions System (CVS) access en-abling the automation of many operations.This special issue examines how the prolifera-tion and availability of open source are affect-ing software development practices.From a developer’s perspective, open sourceis a combination of two important properties:visible source code and a right to make (rela-tively) unencumbered derivatives. The motiva-tions behind the two properties are different,and each can occur in isolation—examples in-clude Microsoft’s shared source and libraryvendors’ code licenses for developing derivativeproducts from nonvisible source. Both proper-ties affect—in positive and negative ways—thesoftware artifacts (products) we develop andhow we develop them (process).
Influence on software products
The most obvious boon of open source tosoftware developers is the opportunity to basea design on existing software elements. Theopen source community gives us a rich base of reusable software, typically available at thecost of downloading the code from the Inter-net. So, in many cases we can select best-of-breed code to reuse in our system without hav-ing to reinvent the wheel. The resultingproducts benefit in two ways. First, the reusedopen source code will typically be of higherquality than the custom-developed code’s firstincarnation. Second, the functionality thereused element offers will often be far morecomplete than what the bespoke developmentwould afford. Products can easily incorporatea standardized, sophisticated open source ele-ment such as an XML parser, a sophisticatedscripting language, a regular-expression en-gine, or a relational database to satisfy re-quirements that in the past a custom-built,small-scale suboptimal implementation wouldhave fulfilled.Moreover, reuse granularity is not re-stricted by the artificial product boundaries of components distributed in binary form (whichmarketing considerations often impose).When reusing open source, code adoption canhappen at the level of a few lines of code, amethod, a class, a library, a component, a tool,or a complete system. Furthermore, whensoftware is available in source code form, wecan more easily port to our target platformand adjust its interfaces to suit our needs.Consequently, software reuse possibilitiesopen up on three axes:
to reuse (pro-moted by the available software’s breadth andprice),
to reuse it (diverse granularity andinterfacing options), and
to reuse it (in-herent portability of source code over most bi-nary packaged component technologies).Movement along all three axes increases thebreadth of software reuse opportunities in anydevelopment effort.In addition, source code’s availability letsus perpetually improve, fix, and support thereused elements. This factor often mitigatesthe risk of orphaned components or incom-patible evolution paths that are associatedwith the reuse of proprietary components.Also, by incorporating the source code of areused element into the system being built, de-velopers can achieve tight integration and asystem that can be maintained as a whole.On the other hand, many of the reuse op-tions that open source opens can isolate reusedcode from its original authors and maintainers,leading to divergent evolution paths or a fos-silized code base. Consider as an example a de-veloper reusing a regular-expressionlibrary bydirectly incorporating its source code into hisor her application (perhaps to port it into anembedded environment where the original li-brary couldn’t compile). The developer wouldhave to (expensively) reintroduce any new im-provements and fixes made on the original li-brary code into the modified version. The con-sequences can be dramatic, as in the case of the slow or lacking propagation of securityfixes. In cases where the software industry ismoving toward new technologies such as 64-bit architectures or Unicode character encod-ing, the effort of upgrading reused source codeelements might mean large-scale duplicationof effort. Reuse in source code form can alsoresult in undesired coupling between separatecomponents when programmers hack togetherthe adopted code into a working implementa-tion instead of using or designing modular in-terfaces. This problem is exacerbated whendevelopers fail to prune reused elements andend up dragging along unneeded dead code
The number ofopen sourceprojectsavailable todevelopers isstaggering.