Quantifying Reuse in OSS: A Large-Scale Empirical Study

Introduction

Software reuse refers to the incorporation of existing software artifacts to systems, different than the ones that they have been originally developed for (Krueger, 1992). Nowadays, it is generally accepted that reuse practices are beneficial for systems’ development since they increase productivity and potentially improve system product quality (Lim, 1994; Frakes & Kang, 2005; Ajila & Wu, 2007). In this context, the reuse opportunities that open source software repositories provide, through the enormous amount of available software projects, are considered an interesting research domain (Marri, Thummalapenta, & Xie, 2009). However, in order for the aforementioned OSS reuse benefits to be fully exploited, a systematic process is needed. As a first step towards such a systematic approach we consider the understanding of the underlying reuse mechanisms that exist in OSS projects.

Reuse is established as a common phenomenon during software projects’ development (Heinemann, Deissenboeck, Gleirscher, Hummel, & Irlbeck, 2011). In order to understand the phenomenon of OSS reuse, the different types of reuse must be investigated. Software reuse is discriminated in three types: white-box, black-box and glass-box reuse. The first case, i.e. white-box reuse, refers to source code reuse, where the external source code is incorporated in the project files. In this case, the internal structure of the reused source code is exposed to the developers, and the source code can potentially be modified (Capiluppi, Stol, & Boldyreff, 2011). The second case, i.e. black-box reuse, refers to the reuse of external libraries in binary form, where the source code in not visible and therefore, not modifiable. The third case, i.e. glass-box reuse, refers to the reuse of the source code, but without changes. Since white-box reuse can entail additional effort for modification and maintenance (Sametinger, 1999), it is expected to occur less frequently compared to the other two types of reuse (Schwittek & Eicker, 2013). In cases of white-box reuse, maintenance effort is allocated both to project elements, i.e. elements internally developed by the project members, and reused elements. An indicator of the required maintenance effort is considered to be the design quality of the system (Bauer, Heinemann, & Deissenboeck, 2012). Although the design quality of OSS systems depends on additional factors, e.g. project maturity, we investigate the effect of reuse practices on systems’ design quality. Thus, we measure projects’ structural quality and investigate the effect of reused elements to the overall product quality.

A software reuse process includes the identification of candidate reuse artefacts and, whenever possible, their incorporation in systems under development. However, as projects evolve over time, their requirements and desired functionality change as well (Koch & Schneider, 2002). Therefore, engineers need to revisit their decisions on the employed reused elements, so as to examine if they need to be substituted, maintained, or removed (Bangerth & Heister, 2013). The modification of reused components can occur for several reasons: removal of reused functionality, upgrade of reused library or substitution of reused library (Bangerth & Heister, 2013). In this work, we investigate how the reuse decisions evolve over time, in order to provide insights on how real-world reuse occurs. More specifically, we argue that reuse modification decisions indicate how systematically reuse practices are applied throughout projects’ lifecycle (Yu, 2006). Nonetheless, the reuse modification decisions entail additional effort during development. However, the aforementioned argument is not evaluated from previous studies, because of their research setup. Until now, studies that measure OSS reuse examine reuse practices in several projects, but only for isolated versions. In this study we measure the frequency and magnitude of such modifications. As a first approach to comprehend the rationale behind such modifications, we investigate if they are quality-driven, i.e. if the developers’ focus on the design quality of the newly incorporated reused elements. The implications of modifying the reused elements during projects’ evolution is studied by Dietrich, Jezek, & Brada, 2014 and Raemaekers, van Deursen, & Visser, 2012, although from a different perspective. More specifically, these studies focus on incompatibility issues that arise from library upgrades.