On the Nonmaintainability of Open-Source Software

A major strength of open-source software is that the source code is open to scrutiny by anyone who chooses to examine it. Accordingly, it is reasonable to assume that the quality of open-source software will be higher than that of closed-source software. After all, closed-source software is examined by only a limited number of individuals, all of whom are paid to do so. It seems equally reasonable to conclude that open-source software is superior to closed-source software in other ways as well, including maintainability. Again, the argument is that the scrutiny by a large number of volunteers leads to a better product. On the other hand, the fact that open-source software is a product of an amorphous group of individuals, rather than a hierarchical development team, means that there is no single person who is in charge of an open-source software product. As a result, modifications can be made to an individual module that could have a deleterious effect on the maintainability of the open-source software product as a whole. An example of this is the introduction of common coupling into an open-source software product. The coupling between two units of a software product is a measure of the degree of interaction between those units [1–3] and, hence, of the dependency between the units. Modules X and Y are common (global) coupled if X and Y share references to the same global variable. It has been shown [4] that coupling is related to fault-proneness. Coupling has not yet been explicitly shown to be related to maintainability. On the other hand, there is as yet no precise definition of maintainability, and therefore there are no generally accepted metrics for maintainability. Nevertheless, if a module is fault-prone then it will have to undergo repeated maintenance, and the resulting frequent changes are likely to compromise its maintainability. Furthermore, these frequent changes will not always be restricted to the fault-prone module itself; it is not uncommon to have to modify more than one module to fix a single fault. Thus, the fault-proneness of one module can adversely affect the maintainability of a number of other modules. In other words, it is easy to believe that common coupling can have a deleterious effect on maintainability. Common coupling has another disadvantage, namely, the number of instances of common coupling between a module M and the rest of the product can increase even if no change whatsoever …

[1]  Stephen R. Schach,et al.  Maintainability of the Linux kernel , 2002, IEE Proc. Softw..

[2]  A. Jefferson Offutt,et al.  A software metric system for module coupling , 1993, J. Syst. Softw..

[3]  Lionel C. Briand,et al.  A comprehensive empirical validation of design measures for object-oriented systems , 1998, Proceedings Fifth International Software Metrics Symposium. Metrics (Cat. No.98TB100262).

[4]  Stephen R. Schach,et al.  Quality Impacts of Clandestine Common Coupling , 2003, Software Quality Journal.

[5]  Glenford J. Myers,et al.  Structured Design , 1974, IBM Syst. J..

[6]  Stephen R. Schach,et al.  Object-oriented and classical software engineering , 1995 .