A Survey of Open Source Software Evolution Studies

Transcription

1 A Survey of Open Source Software Evolution Studies Muhammad Aufeef Chauhan M.Sc. Software Engineering Mälardalen University Västerås, Sweden Abstract The characteristic of a software system to easily accommodate changes over time is referred as software evolution. This characteristic enables software systems to incorporate new requirements in order to meet business objectives of the stakeholders. This study is conducted to explore different aspects associated with evolution of open source software (OSS) systems. The study of the OSS systems is interesting because such systems are evolved without strict development processes and with involvement of independent individuals or teams. In this paper, a systematic survey of studies related to OSS evolution is presented. The objective of this study is to obtain an overview of the existing published material related to OSS evolution to investigate that how software evolvability is addressed during development of such systems. The studies for this purpose are selected using pre-defined search strategy and a multi step procedure of selection. The analysis of primary studies is resulted in four major categories of OSS evolution including software evolution trends and patterns, process support in evolution, evolvability characteristics addressed in OSS evolution studies, and OSS evolution with respect to software architecture. A comprehensive overview and synthesis of the different categories along with related studies is also presented. Keywords: systematic mapping study, open source software, software evolution, evolvability Disclaimer: The material presented in this paper is an extract from the research conducted during my software engineering project course with another researcher Ms. Hongyu Pei-Breivold at Malardalen University. The research was conducted under supervision of Dr. Ali Babar at IT- University of Copenhagen in Denmark as research supervisor and Professor Ivica Crnkovic at Malardalen University as course supervisor. A part of the information presented in this study will be published in paper: Hongyu Pei-Breivold, Muhammad Aufeef Chauhan, Muhammad Ali Babar: 'A Systematic Review of Studies of Open Source Software Evolution', 17th Asia Pacific Software Engineering Conference (APSEC), IEEE, Sydney, Australia. The writing on the detailed analysis of research results is in process and will be published in the appropriate journal. The copyrights policy of the corresponding publishing editor would apply. 1. Introduction Software evolution reflects a process of progressive change in the attributes of the evolving entity or that of one or more of its constituent elements [35]. Specifically, software evolution is related to how software systems evolve over time [58]. Such systems are evolved after repeated modifications and results in increasing complexity. If the systems are not designed to easily accommodate changes, the complexity may also lead to huge modification cost. Hence, one of the principle challenges in software evolution is the ability of software to evolve over time to meet the changing requirements of stakeholders [39]. In this context, software evolvability is an attribute that bears on the ability of a system to accommodate changes in its requirements throughout the system s lifespan with the least possible cost while maintaining architectural integrity [47]. To analyze the evolution of the OSS systems, the researchers have accessed the code bases of a large number of evolving software systems along with history of releases and change logs. There are a large number of studies published on OSS characteristics and evolution patterns by examining sequences of code versions or releases using statistical analysis. The easily accessible data about different aspects of OSS projects also provides researchers with immense number of opportunities to validate the prior studies of proprietary software evolution [32] and to study how evolvability has been addressed in OSS evolution. The main objective of this research is to systematically select the published literature and provide an overview of OSS evolution. The literature is analyzed to find out how software evolvability is addressed during development and evolution of OSS. The information on the metrics that are used by researchers for measuring OSS evolution from different perspectives such as growth patterns, complexity patterns, processes and evolution effort estimation is also presented. The detailed research questions are: What are the publication editors and publication trends of OSS studies in different years? Which research groups are actively engaged and have a long term interest in OSS evolution research? What are the main research themes that are explored in the scientific literature regarding OSS evolution, and analysis of quality attributes related to evolvability?

2 What are the metrics that are used for OSS evolution measurement and analysis? Are there any limitations in using these metrics? The organization of rest of the paper is as follows. Section 2 describes the research method used. Section 3 presents and discusses the findings from this review. Section 4 presents the related work. Section 5 discusses validity threats of the review. Section 6 concludes the paper and section 7 lists the references of selected studies for this mapping study. 2. Research methodology This research was undertaken as a systematic study [29] that is a process of assessing and interpreting all available research related to a particular research topic. In the first step, the review protocol was designed based on the guidelines for systematic study. The protocol specified the background of the study, detailed research questions, search strategy for electronic databases, inclusion and exclusion criteria for study selection and data extraction along with its synthesis. The inclusion criteria focused on including studies in English that had been published in workshops, conferences, peer reviewed journals and as book chapters. The material published until the end of 2009 was included for this study. The articles published as prefaces, editorials, summaries of tutorials, panels and poster sessions were not included. The search was performed on a selected set of electronic databases that includes ACM Digital Library, IEEE Explorer, Compendex, Science Direct Elsevier, SpringerLink, Wiley InterScience and ISI Web of Science. The generic search string used to search target studies in electronic databases was like: "open source software" OR "libre software" OR "free software" OR "FOSS" OR "F/OSS" OR "F/OSSD" OR "FOSSD" OR "FLOSS" OR "F/LOSS" OR "OSSD". The terms in generic search strings were used to construct customized search queries for each electronic database to produce optimum search results. The search in electronic databases was performed in two stages. At the first stage, the papers published until the end of 2008 had been searched and then a separate complimentary search was performed for 2009 publications. After merging the search results and removing duplicates there were 11,439 papers published until 2008 and 1,921 papers published in In the first step of filtration; papers were filtered only on the basis of titles. The selected set of papers after the first step of filtration was screened on the basis of abstract. After scanning all the papers by titles and abstracts, 134 papers were selected. In the final stage, the papers were screened after reading full paper text and 41 papers were selected for this mapping study. The process of filtration was performed manually by researchers. The paper selection process involved at least two researchers to decide whether to include or exclude a paper. A paper was excluded if both researchers considered it irrelevant. Any disagreement was resolved through discussions and involvement of the researcher supervisor. The studies for research were selected after multiple filtration steps as described in previous paragraph. In the first step, search in the electronic database was performed using search terms to identify relevant studies. In the second step, identified studies were excluded after reading title and abstract based on inclusion and exclusion criteria. In the final step, primary studies were obtained after reading the full text. The multi step filtration process was chosen to make sure that no relevant material is missed out in the set of selected studies. All the papers from the final set of 41 studies were thoroughly read for data extraction and synthesis. The data extraction process was managed through bibliographical management tool EndNote and Spreadsheets. The data extraction was driven by a form shown in table I and data was extracted manually after reading target studies. For the data synthesis, the extracted data for similarities was inspected and combined to compare the results that had been presented in individual selected studies. TABLE I. Extracted Data Study identity Bibliographic references Type of study Focus of the study Research method used for data collection Data analysis Metrics used Constraints and limitations 3. Results DATA EXTRACTION FORM Description Unique identity for the study Author, year of publication, title and source of publication Book, journal paper, conference paper, workshop paper Main topic area and aspect of open source software being investigated Included technique for the design of the study, e.g. case study, survey, experiment, interview to obtain data, observation Qualitative or quantitative analysis of data The metrics used in data collection for analysis Identified constraints and limitations in each study The data collected from selected studies was analyzed and synthesized to find out answers of the research questions. The different subsection describes the result of this study.

3 3.1 Publication editors, publication trends and active research groups The search was performed in multiple electronic databases. The largest number of selected papers (22 papers) was published by IEEE. The second largest number of papers (9 papers) was published by ACM, while four selected papers were published by John Wiley & Sons in its Journal of Software Maintenance and Evolution. The list of publication editors along with total number of publications is shown in table II. The table II will help researchers to focus their search on the publications editors that are more likely to publish material related to OSS evolution. TABLE II. PUBLICATION EDITORS Publication editors No. of Publications IEEE Explorer 22 ACM Digital Library 9 John Wiley & Sons, Ltd. 4 Elsevier B.V. 1 IEE Proc.-Softw. 1 IET Softw. 1 IGI PUBLISHING 1 Science Direct 1 Springer 1 The trend of publication of studies on OSS evolution over years shows a positive growth except for year Only three papers on OSS evolution were published in that year. In year 2009, eleven papers were published showing that a good number of researchers are expected to address OSS evolution in coming years. The detail about number of papers publishes in each year is presented in table III. TABLE III. PULICATION TREND OVER YEARS Year No. of Publications After classification of studies into different categories, it is found that that the evolution trends and patterns is the most focused research area with 23 studies published on this topic. There are ten studies on the role of process support in evolution. However, quite few numbers of studies are addressing the characteristics of evolvability and the role of software architecture in OSS evolution, with five and three studies respectively. It is also observed there are not many researchers who have long term interest in OSS evolution research. There are only three authors who have published greater than or equal to three studies as a first author on OSS evolution. Adrea Capiluppi is at first place with seven publications, Gregorio Robles stands second with four publications and Israel Herraiz is third with three publications. 3.2 Categories of the reviewed studies The selected papers were examined on the basis of their similarities in terms of research topics and contents, and then organized into different categories. The metrics used for assessing OSS evolution as well as the analysis methodologies used to collect data in each study were also examined. After examining the research topics, and analyzing data and findings addressed in each study; four main categories of themes are identified. These main categories are further divided into sub categories to group primary studies that share similar characteristics in terms of specific research focus, concept and context. The categories and sub categories are elaborated in the corresponding sub sections. The studies that are classified into the category of OSS evolution trends and patterns address software growth, software maintenance and prediction about software evolution. Other categories deal with OSS evolution process support, evolvability characteristics and OSS evolution at software architecture level. For each category of theme, related studies are described along with the metrics that are used to quantitatively or qualitatively analyze the OSS evolution OSS Evolution Trends and Patterns The studies that investigated the trends of evolution in different OSS systems and identified patterns of growth had been classified and elaborated in this section. On the basis of the main theme, the studies are further classified into three different aspects. The aspects are software growth, software maintenance and evolution economics, and prediction of software evolution Software Growth Software growth modeling can be used to predict software evolution, maintainability and other characteristics [30]. Moreover, many OSS studies focus on utilizing the OSS evolution data to verify Lehman s laws of software evolution [33]. The findings of these studies either conform to or diverge from the growth behavior of proprietary software. It is essential that the measures of software growth can actually represent and quantify the notion of software

4 growth in order to obtain a reasonable comparison among the results from different studies. However, it is noticed that there are conflicting interpretations of some important operational definitions with respect to the use of metrics that are used to measure software growth patterns. Some examples of the operational definitions that exhibit varying interpretations are system growth, system change, and size. System growth is measured by using the metric of percentage growth over time. There exist diverse interpretations of rate of growth. For instance, one interpretation is to analyze and plot growth data with respect to the release sequence number (RSN) as used by Schach [48] and Simmons [49]. Another interpretation of rate of growth is reflected by Godfrey et al. [23]. It is based on plotting growth rates against calendar dates rather than release numbers. This interpretation of rate of growth suggests that the plotting according to the release numbers may lead to dips in the function curves because of the fact that development and stable releases follow different patterns. This interpretation is further confirmed by Thomas et al. [52] which show that due to the new temporal variables introduced by OSS, the rate of growth of OSS should be computed with respect to temporal variables such as the release date. It was also validated that different conclusions can be drawn when software evolution data is analyzed with respect to the release date rather than RSN. Therefore, different interpretations of rate of growth can pose a threat to the analysis of the OSS evolutionary behavior. A variety of metrics are used to measure system change as well. Xie et al. use changes to program elements such as types, global variables, function signatures and bodies to measure modifications in an OSS system [56]. They plot cumulative numbers of addition and deletion types of changes to these program and reported that the majority of modifications are made in the functions. Smith et al. use the count of all the different files that have been added, modified and deleted between two subsequent releases to measure system changes [50]. However, this method may lead to different results depending upon the conventions used to measure changes. An example of such convention is that whether or not to consider the changes in comment lines or minor changes in a single source line as a modification in system. Lehman suggests using the number of modules to quantify program size [32]. He argues that this metric is more consistent than considering source lines of code. However, there are different interpretations of a module in studies of OSS. For instance, Simmons et al. [49] treat a file as a module while Capiluppi [11] studies OSS systems evolution with alternatively considering the file and the directory as a module. He discovers that different OSS evolutionary behavior is observed depending on whether a file or a directory is treated as a module. Conley and Sproull use number of uncommented lines of code (LOC) to measure growth [23]. They claim that using number of source files can result in losing some of the information about the evolution of the system, especially at the subsystem level due to the variation in the size of files. They also assume that the total number of uncommented LOC grows roughly at the same rate as the number of source files. However, this assumption is not fully validated in a broader scope and it is only verified in some of the large packages in Debian GNU and Linux [27]. The definition of LOC also varies and different studies interpret LOC in different ways [40]. The interpretation depends on the tools used for analysis and available data sources. Koch s definition of LOC considers all types of files; including comments and documentation [30]. Godfrey [23] and Robles [24] use LOC in two ways either by including blank lines and comments in source files (for example in.c and.h files) or ignoring blank lines and comments. This kind of counting applies only to source files and does not take care of other source artifacts such as configuration files, make files and documentation. Even the term source file is defined in different ways. For example, Smith et al. consider only files with extension.c as source files [50]. Therefore, for systems involving a variety of source file extensions, different assumptions regarding file extensions and their association to the source code can lead to different values of size analysis. This affects the analysis results of different aspects of evolutionary behaviors [45]. The studies that are classified in sub category of software growth are using a variety of metrics as shown in table IV. TABLE IV. METRICS USED TO MEASURE GROWTH - I Study Metrics [1] Number of packages, classes, total lines of code. [2] Types of extracted changes: addition, deletion and modification of source code modules in successive versions of software. [11] Initial size, current size, folders as modules, files as modules, average module size, days through versions, versions, version rate and delta size. [17] Source file, source folder, size, RSN (release sequence number), level and depth of a folder with respect to folder tree; and number of files added, modified or deleted. [23] Lines of code (LOC) in source files as a function [43] of the time in days. [24] Lines of source code, the number of packages, the number of changed and unchanged packages. [28] LOC (lines of code), number of directories, total size in Kbytes, average and median LOC for header and source files, number of modules (treating files as modules) for each subsystem and complete system. [30] Number of LOC added to a file (including all text e.g. also commentaries) [41] Overall project growth in terms of functions over time and LOC over time.

5 Table IV. METRICS USED TO MEASURE GROWTH II Study Metrics [46] Lines of source code (LOSC), the number and size of packages [49] Lines of code (LOC), executable LOC, functions added over each release, number of functions. [50] Size in number of source code files; number of files added, modified or deleted between two subsequent releases; and average complexity. [52] Rate of growth with respect to release sequence number (RSN). [54] Number of modules, bugs, bug fixing and requirement implementation in each release [56] Source code metrics including lines of code and number of modules Software Maintenance and Evolution Economics Another perspective in understanding OSS evolution trends is to analyze how software has evolved in terms of development and maintenance cost. Moreover, software evolvability is related to both business and technical perspectives. The choice of maintenance decisions from technical perspective needs to be balanced with economic evaluation to mitigate risks. Capra et al. analyze the quality degradation effect of OSS by measuring the evolution of maintenance costs over time [19]. The metric used in this study is function points analysis. One assumption in this study is that the maintenance cost is proportional to the time elapsed between the releases of two subsequent versions. Another study by Capra proposes an empirical model to measure evolutionary reuse and development cost. This is an indicator of the effect of maintenance decisions made by OSS developers and source lines of code (SLOC) is used as a metric [18] Prediction of Software Evolution The OSS evolution can be predicted using history data. The modeling of software growth is considered essential for developing prediction models. There are only three papers that address this phenomenon. Herraiz et al. present the use of data about software size over time that is collected from source code management repository, to predict future evolution of an OSS system [26]. Source code s lines of code (SLOC) metric is used for counting program text that is not a comment or blank line regardless of the number of statements or fragments of statements on the line. All the lines defining program headers, declarations, executable and non-executable statements are excluded. Therefore, the results may vary if other types of files are selected. Ye uses changes made in source code to indirectly predict the maintenance effort of OSS [57]. The metrics that are used include; lag time between starting a maintenance task and closing the task, source code change at module level (number of modules added, deleted and modified), and source code change at line level (number of source LOC added, deleted and modified) in one maintenance task. In this study, all module level changes are treated in the same manner irrespective of the amount of changes as well as the effort for line level changes. This may produce less accurate results. Raja et al. uses data from data from monthly defect reports to build up time series model [42]. This model is used to predict patterns of OSS evolution defects The Role of process support in Software Evolution The software development process also affects the evolution of OSS systems. Bouktif et al. present a feedback driven quality assessment technique to continuously analyze OSS evolution [10]. This approach utilizes the data sources from version control systems to provide services that mitigate software degradation. Arafat and Riehle use the amount of comments in a given source code body as an indicator of its maintainability [3]. They focus on comment density; a code metric that is consistently followed by successful OSS projects. In their study, Capiluppi and Beecher investigated the effected of source code repository in which OSS are retained on evolution and concluded that these repositories act as exogenous factor and is a differentiating characteristic of evolvability of OSS [12]. Beecher et al. extend the work of Capiluppi and Beecher by investigating a large number of repositories and strengthen the results of Capiluppi and Beecher [7]. Koponen presents an evaluation framework that includes attributes for evaluating activity, efficiency and traceability of defect management and maintenance processes. The traditional staged model represents the software lifecycle as a sequence of stages and was built mainly by observing traditional software development [8]. Capiluppi et al. revise the staged model for its applicability to OSS evolution [14]. Asklund and Bendix examine the configuration management process and analyze how process and tool support influences the OSS evolution [4] Evolvability Characteristics of OSS The evolvability of software systems is influenced by number of product related factors. Three main factors that contribute to evolvability are code understandability, complexity and modularity. Capiluppi et al. identify code understandability as a key aspect for maintainability [15]. This study only focuses on code structure measures such as code size, average size of modules, number of macro and micro modules. These measures are used to calculate code indistinctness as an indicator of code understandability.

6 The complexity of a software system directly affects its evolvability. The list of commonly used metrics is presented in table V. McCabe s cyclomatic complexity [36] is most commonly used method as shown in table V. Six of the selected studies are using this metric in order to investigate complexity. This metric measures the complexity in terms of number of independent paths in the control flow graph. Halstead complexity [36] is another metric that is used to measure the complexity of a program module directly from source code. This metric focuses on computational complexity. These two metrics measure complexity in different ways and can show contradictory results even on same studies. The study by Simmons et al in an example of such cases and shows the increase in the complexity of calculation logic with the decline in structure complexity [49]. TABLE V. METRICS USED TO MEASURE COMPLEXITY Study Metrics [1][13][21] McCabe s cyclomatic complexity. [17][49] [56] [16] System size and the evolving structure of the software [17][49] Halstead complexity. [41] Overall project complexity, average complexity of all functions, average complexity of functions added. [49] Overall release complexity and average function complexity using McCabe and Halstead complexity metrics. [56] Complexity in terms of common coupling and average number of function calls per function. Besides McCabe and Halstead indexes, some simple indicators of complexity are also used at system, components and functions level. Calls per functions metric is one of these metrics and it indicates the complexity of a function and it is the average of number of calls per function with respect with respect to the total number of calls for functions of the whole system. Coupling, interface complexity and complexity of data structures are also used to measure complexity. However, none of the selected papers are explicitly using calls per function, coupling, interface complexity and complexity of data structures as measurements for complexity. One of the possible reasons may be that it is very hard to compute these measurements without the presence of proper documentation, which is often not available for OSS systems. Modularity of a software system is determined by the number of distinct and logically cohesive subunits. The number of modules in a software system reduces its complexity. Commonly used metrics that are used to measure modularity are shown in table VI. It is clear from the table that different metrics are dealing with different levels of abstraction. Liu and Iyer [34], and Simmons et al [49] studied modularity at both the class and file level. Their studies provide information regarding software functionality. Conley and Sproull argue that studying modularity at that level does not capture interface information [21]. They suggest that the the use of the package at the module or component level is more appropriate for assessment of software modularity than using classes or files. Inter module dependency is also considered an important indicator of complexity but none of the selected studies has explored this characteristic. TABLE VI. METRICS USED TO MEASURE MODULARITY Study Metrics [21] Total number of lines of code, number of concrete and abstract classes, afferent and efferent coupling [24] Dependencies between packages [34] Measured modularity considering file as a module [49] (class level) [41] Correlation between functions added and functions modified [49] Number of classes and number of files for each release The Role of the Software Architecture in OSS Evolution The architecture of software systems is considered one of the most important attribute for software evolvability [20, 22, 37] but there is a lack of research that investigates the relation between software architecture and OSS [38]. There are not many measurements proposed to study OSS evolution at architecture level. However, a study by Capiluppi and Beecher addresses the structured characteristics by computing number of calls into (fan-in) and number of calls from (fan-out) a component [12]. This study considers functions as the basis unit for analysis and three attributes; fan-in, fan-out and instability are considered important for static architecture evaluation. 4. Related and Future Work There are a small number of studies that have explored the literature to find out evolvability related characteristics and are only confined to evolution with respect to architecture. Some studies like by Godfrey and Tu [23], and Nakagawa et al. [38] has investigated the evolution of OSS at architecture level and confirms that there is a lack of research that investigates the relation between software architecture and OSS. They also describe in detail about how software architecture is treated in OSS and the effect of planned evolution along with preventive maintenance on OSS development. Nakagawa et al. explore the relation

7 between software architecture and quality of OSS systems, and propose some architecture refactoring techniques. This study also proposes that architecture refactoring is important to improve maintainability and usability of OSS systems. The process of forward and reverse architectural repair to avoid architectural drift is described by Tran et al. as well [53]. But none of these studies have provided an overall overview of all the aspects of OSS evolution like mapping study that is presented in this paper. This study presents a comprehensive analysis of the metrics that are used to study different aspects of OSS evolution. The pros and cons of different metrics are also elaborated. The results of this study can be used to study evolution of OSS systems in better way by choosing the metrics that have least negative impacts on results. Complexity of the OSS systems also needs to be investigated by using more reliable metrics for object oriented paradigm. These metrics include inter module dependency, calls per function, coupling, interface complexity and complexity of data structures. 5. Validity of the Study The following types of validity issues were considered and addressed while preparing the results for this study. Conclusion validity is referred as the relationship between the treatment and the outcome [55]. A threat to conclusion validity could be biased in data extraction. This was addressed by defining a data extraction form. This form ensured the consistence extraction of relevant data to answer the research questions. The findings and implications are based on the data extracted using data extraction form. Internal validity is related to the connection between the observation and proposed explanations [55]. This ensures that drawn conclusions are true. Selection bias could be the possible threat to internal validity. This threat was avoided by a through selection process. Study selection was done according to the inclusion and exclusion criteria and had been verified by research supervisor. Construct validity ensures that the construction of the study is related to the research problem and selected sources of information are relevant [55]. One possible threat to the construct validity could be bias in selection process and this threat had been resolved by specifying a research protocol. The research protocol included research questions and objectives, inclusion and exclusion criteria, optimized search strings for target electronic data sources, search strategy and strategy for data extraction. The research was conducted following the guidelines that had been mentioned in research protocol. 6. Conclusion This systematic mapping study is based upon 41 primary studies of open source software evolution. According to the research topics of the studies, the primary studies have been classified into four main categories of themes. These categories are evolution trends and patterns, the role of process support in OSS software evolution, evolvability characteristics of OSS, and software architecture support in OSS evolution. The first category is further divided into three sub categories. The sub categories are software growth, software maintenance and evolution economics and prediction of software evolution. A comprehensive overview of these categories along with subcategories and related studies is discussed. In the category of evolution trends and patterns, most of the papers focus on using different metrics to analyze OSS evolution over time. Few papers have addressed other aspects like maintenance effort and even fewer papers utilize the historical evolution data for prediction of OSS evolution and development. The researchers have used a large number of metrics at different levels of granularities like at class level, file level and module level to measure OSS evolution. The review of the studies has also shown that different interpretations of the same terms like module, lines of code and rate of growth may result in conflicting conclusions. Different aspects that appear to have impact on the OSS evolution process are covered in the category of the role of process support in OSS software evolution. These aspects include commenting practice, OSS evolution and maintenance evaluation model, structures and quality characteristics of resources such as repositories, and tools that support data retrieval for evolution analysis. Different characteristics that are related to evolvability are addressed under the category of evolvability characteristics. These characteristics include determinism, understandability, modularity and complexity. However, many characteristics such as changeability, extensibility, testability, and modifiability are not addressed in selected studies. The lack of analysis on OSS evolvability characteristics makes it harder to predict OSS evolution. The last category of selected studies examines the OSS evolution at software architecture level. It is found that although architecture of software systems is recognized an important artifact to fulfilling the quality requirements of a system, only few papers address OSS evolution at architectural level. The fact that it is very hard for software system to evolve without proper architecture makes it is very important for researchers to put more focus on architecture related studies of OSS systems evolution.

8 7. References [1] Al-Ajlan, A.: The Evolution of Open Source Software Using Eclipse Metrics, International Conference on New Trends in Information and Service Science, IEEE Computer Society, pp , [2] Ali, S., and Maqbool, O.: Monitoring software evolution using multiple types of changes, International Conference on Emerging Technologies, pp , [3] Arafat, O., and Riehle, D.: The commenting practice of open source, Conference on Object Oriented Programming Systems Languages and Applications, ACM, pp , [4] Asklund, U., and Bendix, L.: A study of configuration management in open source software projects, IEE Proceedings-Software, 149, (1), pp , [5] Bachmann, A., and Bernstein, A.: Software process data quality and characteristics: a historical view on open and closed source projects, Proceedings of the Joint International ERCIM Workshops on Principles of Software Evolution (IWPSE) and Software Evolution (Evol) Workshops, ACM, pp , [6] Baldwin, C.Y., and Clark, K.B.: Design rules: The power of modularity, The MIT Press, [7] Beecher, K., Capiluppi, A., and Boldyreff, C.: Identifying exogenous drivers and evolutionary stages in FLOSS projects, Journal of Systems and Software, 82, (5), pp , [8] Bennett, and Rajlich: Software maintenance and evolution: a roadmap. Proceedings of the Conference on The Future of Software Engineering, Limerick, Ireland, [9] Bennett, K.H., and Rajlich, V.T.: Software maintenance and evolution: a roadmap, The Future of Software Engineering, ACM New York, pp , [10] Bouktif, S., Antoniol, G., and Merlo, E.: A feedback based quality assessment to support open source software evolution: the grass case study, International Conference on Software Maintenance, pp , [11] Capiluppi, A.: Models for the evolution of OS projects, International Conference on Software Maintenance, pp , [12] Capiluppi, A., and Beecher, K.: Structural Complexity and Decay in FLOSS Systems: An Inter-Repository Study, 13th European Conference on Software Maintenance and Reengineering (CSMR), [13] Capiluppi, A., Faria, A.E., and Ramil, J.F.: Exploring the relationship between cumulative change and complexity in an open source system, European Conference on Software Maintenance and Reengineering (CSMR), [14] Capiluppi, A., González-Barahona, J.M., Herraiz, I., and Robles, G.: Adapting the staged model for software evolution to free/libre/open source software, Ninth International Workshop on Principles of Software Evolution, ACM, [15] Capiluppi, A., Morisio, M., and Lago, P.: Evolution of understandability in oss projects, Eighth Euromicro Working Conference on Software Maintenance and Reengineering, pp , [16] Capiluppi, A., Morisio, M., and Ramil, J.F.: Structural evolution of an open source system: a case study, Proceedings of the 12 th IEEE International Workshop on Program Comprehension, [17] Capiluppi, A., Ramil, J.F., and e Informatica, D.A.: Studying the evolution of open source systems at different levels of granularity: Two case studies, Proceedings of the 7 th International Workshop on Principles of Software Evolution, pp , [18] Capra, E.: Mining open source web repositories to measure the cost of evolutionary reuse, International Conference on Digital Information Management, pp , [19] Capra, E., Francalanci, C., and Merlo, F.: The economics of open source software: an empirical analysis of maintenance costs, International Conference on Software Maintenance, pp , [20] Clements, P., Kazman, R., and Klein, M.: Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, [21] Conley, C.A., and Sproull, L.: Easier Said than Done: An Empirical Investigation of Software Design and Quality in Open Source Software Development, 42 nd Hawaii International Conference on System Sciences, [22] Garlan, D.: Software architecture: a roadmap, in Editor (Ed.)^(Eds.): Book Software architecture: a roadmap, The Future of Software Engineering, ACM Press New York, pp , [23] Godfrey, M.W., and Tu, Q.: Evolution in open source software: A case study, International Conference on Software Maintenance, pp , [24] Gonzalez-Barahona, J.M., Robles, G., Michlmayr, M., Amor, J.J., and German, D.M.: Macro-level software evolution: a case study of a large software compilation, Empirical Software Engineering, 14, (3), pp , [25] Herraiz, I., Gonzalez-Barahona, J.M., and Robles, G.: Determinism and evolution, International Working Conference on Mining Software Repositories, ACM, pp. 1-10, [26] Herraiz, I., Gonzalez-Barahona, J.M., Robles, G., and German, D.M.: On the prediction of the evolution of libre software projects, International Conference on Software Maintenance, pp , [27] Herraiz, I., Robles, G., Gonzalez-Barahona, J.M., Capiluppi, A., and Ramil, J.F.: Comparison between SLOCs and number of files as size metrics for software evolution analysis, Conference on Software Maintenance and Reengineering, 2006.

9 [28] Izurieta, C., and Bieman, J.: The evolution of freebsd and linux, Proceedings of the IEEE/ACM International Symposium on Empirical Software Engineering, [29] Kitchenham, B., and Charters, S.: Guidelines for performing systematic literature reviews in software engineering, Evidence Based Software Engineering, [30] Koch, S.: Evolution of open source software systems a large-scale investigation, Journal of Software Maintenance and Evolution: Research and Practice, [31] Koponen, T.: Evaluation Framework for Open Source Software Maintenance, International Conference on Software Engineering Advances, pp , [32] Lehman, M.M., Perry, D.E., and Ramil, J.F.: On evidence supporting the FEAST hypothesis and the laws ofsoftware evolution, the 5 th International Symposium on Software Metrics, pp , [33] Lehman, M.M., Ramil, J.F., Wernick, P.D., Perry, D.E., and Turski, W.M.: Metrics and laws of software evolutionthe nineties view, International Symposium on Software Metrics, [34] Liu, X., and Iyer, B.: Design architecture, developer networks, and performance of Open Source Software projects, Approaches to Information System Development, [35] Madhavji, N.H., Fernandez-Ramil, J., and Perry, D.: Software Evolution and Feedback: Theory and Practice, John Wiley & Sons, [36] McCabe, T.J.: A complexity measure, IEEE Transactions on Software Engineering, pp , [37] Medvidovic, N., Taylor, R.N., and Rosenblum, D.S.: An Architecture-Based Approach to Software Evolution, International Workshop on the Principles of Software Evolution, [38] Nakagawa, E.Y., de Sousa, E.P.M., de Brito Murata, K., de Faria Andery, G., and Morelli, L.B.: Software Architecture Relevance in Open Source Software Evolution: A Case Study, 32 nd International Computer Software and Applications Conference, IEEE, pp , [39] Nehaniv, C.L., and Wernick, P.: Introduction to Software Evolvability 2007, 3 rd International IEEE Workshop on Software Evolvability, [40] Park, R.E.: Software Size Measurement: A Framework for Counting Source Statements. Software Engineering Institute, Carnegie Mellon University, [41] Paulson, J.W., Succi, G., and Eberlein, A.: An empirical study of open-source and closed-source software products, IEEE Transactions on Software Engineering, 30, (4), pp , [42] Raja, U., Hale, D.P., and Hale, J.E.: Modeling software evolution defects: a time series approach, Journal of Software Maintenance and Evolution: Research and Practice, 21, (1), pp , [43] Robles, G., Amor, J.J., Gonzalez-Barahona, J.M., and Herraiz, I.: Evolution and growth in large libre software projects, 8 th International Workshop on Principles of Software Evolution, pp , [44] Robles, G., González-Barahona, J.M., Izquierdo- Cortazar, D., and Herraiz, I.: Tools for the study of the usual data sources found in libre software projects, International Journal of Open Source Software and Processes, 1, (1), pp , [45] Robles, G., Gonzalez-Barahona, J.M., and Merelo, J.J.: Beyond source code: The importance of other artifacts in software development (a case study), The Journal of Systems & Software, 79, (9), pp , [46] Robles, G., Gonzalez-Barahona, J.M., Michlmayr, M., and Amor, J.J.: Mining large software compilations over time: another perspective of software evolution, International Workshop on Mining Software Repositories, ACM, [47] Rowe, D., Leaney, J., and Lowe, D.: Defining systems evolvability-a taxonomy of change, International Conference and Workshop: Engineering of Computer-Based Systems, pp , [48] Schach, S.R., Jin, B., Wright, D.R., Heller, G.Z., and Offutt, A.J.: Maintainability of the Linux kernel, IEE Proceedings-Software, 149, (1), pp , [49] Simmons, M.M., Vercellone-Smith, P., and Laplante, P.A.: Understanding Open Source Software through Software Archaeology: The Case of Nethack, 30 th Annual IEEE/NASA Software Engineering Workshop, pp , [50] Smith, N., Capiluppi, A., and Ramil, J.F.: A study of open source software evolution data using qualitative simulation, Software Process Improvement and Practice, 10, (3), pp , [51] Suh, S.D., and Neamtiu, I.: Studying Software Evolution for Taming Software Complexity, 21 st Australian Software Engineering Conference, [52] Thomas, L.G., Schach, S.R., Heller, G.Z., and Offutt, J.: Impact of release intervals on empirical research into software evolution, with application to the maintainability of Linux, Software, IET, 3, (1), pp , [53] Tran, J.B., Godfrey, M.W., Lee, E.H.S., and Holt, R.C.: Architectural repair of open source software, 8 th International Workshop on Program Comprehension, pp , [54] Wang, Y., Guo, D., and Shi, H.: Measuring the evolution of open source software systems with their communities, ACM SIGSOFT Software Engineering Notes, 32, (6), pp. 7, [55] Wohlin, C., Höst, M., Runeson, P., Ohlsson, M.C., Regnell, B., and Wesslén, A.: Experimentation in software engineering: an introduction, Kluwer Academic Pub, [56] Xie, G., Chen, J., and Neamtiu, I.: Towards a better understanding of software evolution: An empirical study on open source software, International Conference on Software Maintenance, 2009.

10 [57] Yu, L.: Indirectly predicting the maintenance effort of open-source software, Journal of Software Maintenance and Evolution: Research and Practice, 18, (5), pp , [58] Yu, L., Ramaswamy, S., and Bush, J.: Symbiosis and Software Evolvability, IT Professional, 10, (4), pp , 2008.