Andrea Capiluppi
email: a.capiluppi@uel.ac.uk

Cornelia Boldyreff
email: c.boldyreff@uel.ac.uk

Klaas-Jan Stol
email: klaas-jan.stol@lero.ie

Successful Reuse of Software Components: A Report from the Open Source Perspective

Keywords: Software reuse, OSS components, component-based software development

A promising way of software reuse is Component-Based Software Development (CBSD). There is an increasing number of OSS products available that can be freely used in product development. However, OSS communities themselves have not yet taken full advantage of the "reuse mechanism". Many OSS projects duplicate effort and code, even when sharing the same application domain and topic. One successful counter-example is the FFMpeg multimedia project, since several of its components are widely and consistently reused into other OSS projects. This paper documents the history of the libavcodec library of components from the FFMpeg project, which at present is reused in more than 140 OSS projects. Most of the recipients use it as a blackbox component, although a number of OSS projects keep a copy of it in their repositories, and modify it as such. In both cases, we argue that libavcodec is a successful example of reusable OSS library of components.

Introduction

Reuse of software components is one of the most promising assets of software engineering [START_REF] Basili | Support for comprehensive reuse[END_REF]. Enhanced productivity (as less code needs to be written), increased quality (since assets proven in one project can be carried through to the next) and improved business performance (lower costs, shorter time-to-market) are often pinpointed as the main benefits of developing software from a stock of reusable components [START_REF] Sommerville | Software Engineering[END_REF][START_REF] Sametinger | Software engineering with reusable components[END_REF].

Although much research has focused on the reuse of Off-The-Shelf (OTS) components, both Commercial OTS (COTS) and OSS, in corporate software production [START_REF] Li | Development with off-the-shelf components: 10 facts[END_REF][START_REF] Torchiano | Overlooked aspects of cots-based development[END_REF], the reusability "of" OSS projects "in" other OSS projects has only started to draw the attention of researchers and developers in OSS communities [START_REF] Lang | Free and proprietary software in cots-based software development[END_REF][START_REF] Mockus | Large-scale code reuse in open source software[END_REF][START_REF] Capiluppi | Identifying and improving reusability based on coupling patterns[END_REF]. A vast amount of code is created daily, modified and stored in OSS repositories, yet, software reuse is rarely perceived by OSS developers as a critical success factor in their projects or processes. For different and composite reasons [START_REF] Senyard | How to have a successful free software project[END_REF], using other OSS projects as components is typically not considered as a way to build new OSS products. As an example, a search for the "FTP client" topic in the SourceForge repository 1 results in more than 350 different projects, each implementing similar features in the same domain. As a result, much functionality is duplicated in similar products, with little sharing of existing components.

The interest of practitioners and researchers in the topic of software reuse has focused on two predominant questions: [START_REF] Abi-Antoun | A case study in re-engineering to enforce architectural control flow and data sharing[END_REF] how to select an OSS component to be reused in another (potentially commercial) software system, and (2) how to provide potential re-users with a level of objective "trust" in available OSS components. This interest is based on a sound reasoning; given the increasing amount of source code and documentation created and modified daily, it starts to be a (commercially) viable solution to browse for components in existing code and select existing, working resources to reuse as building blocks of new software systems, rather than building them from scratch.

Among the reported cases of successful reuse within OSS systems, components with clearly defined requirements, and hardly affecting the overall design (i.e., the "S" and "P" types of systems following the original S-P-E classification by Lehman [START_REF] Lehman | Programs, life cycles, and laws of software evolution[END_REF]) have often proven the typical reused resources by OSS projects. Reported examples include the "internationalization" component (which produces different output text depending on the language of the system), or the "install" module for Perl subsystems (involved in compiling the code, test and install it in the appropriate locations) [START_REF] Mockus | Large-scale code reuse in open source software[END_REF]. Little is known about successful cases of OSS reuse, and an understanding of internal characteristics of what makes a component reusable in the OSS context is lacking.

The main focus of this paper is to report on the successful reuse of the components of the FFMpeg project. This project is a cornerstone component in the multimedia domain; several dozens of OSS projects reuse parts of FFMpeg, and this wide-spread of reuse is mostly based upon the libavcodec library of components. In the domain of OSS multimedia applications, this library is now established as the most widely adopted and reused audio/video codec (coding and decoding) resource. Its reuse by other OSS projects is so widespread since it represents a cross-cutting resource for a wide range of systems, from single-user video and audio players to converters and multimedia frameworks.

This paper makes two contributions: first, it establishes that the libavcodec component (contained in FFMpeg) is an "evolving and reusable" component (an "E" type of system [START_REF] Lehman | Programs, life cycles, and laws of software evolution[END_REF]), and as such it poses several interesting challenges when other projects integrate it. Second, it presents two scenarios that have emerged in the reuse of this resource: on the one hand, the majority of the cases the libavcodec component is reused as a "black-box", as such incurring into the synchronization issues due to the co-evolution "project+component". On the other hand, a subset of OSS projects apply a "white-box" reuse strategy, by maintaining a private copy of libavcodec. The latter scenario is empirically 1 http://sourceforge.net/ analyzed in order to obtain a better understanding of how the component not only is reused, but also integrated into the main system. The two scenarios are summarized in Figure 1: as an example, the MPlayer project keeps a "copy" of the library in its repository (white-box reuse), while the VLC project, at compilation time, requires the user to provide the location of an up-to-date version of the FFMpeg project (black-box reuse).

Background and Related Work

The OSS approach to software development has gained much attention in the empirical Software Engineering research community, mostly due to the availability of software and non-software artifacts (e.g., bug tracking systems and mailing lists). Although the majority of published works have a non OSS-related rationale, some researchers have started to collect evidence specifically related to OSS systems. Among these late emerging areas, the topics of OSS components and architectures have been investigated both within research works [START_REF] Majchrowski | An operational approach for selecting open source components in a software development project[END_REF][START_REF] Hauge | An Empirical Study on Selection of Open Source Software -Preliminary Results[END_REF][START_REF] Capiluppi | Software engineering in practice: Design and architectures of floss systems[END_REF][START_REF] Li | Development with off-the-shelf components: 10 facts[END_REF], and through specifically funded EU projects (QualiPSo2 -Quality Platform for Open Source Software and QUALOSS3 -QUALity in Open Source Software). This research directly responds to the need of identifying and extracting existing OSS components [START_REF] Arief | Software architectures and open source software -Where can research leverage the most[END_REF], or of providing options for choosing the best OSS component for inclusion in a software system [START_REF] Hauge | An Empirical Study on Selection of Open Source Software -Preliminary Results[END_REF].

This work is also related to the study of software architectures, in the forms of hierarchical and coupling views. Previous works ( [START_REF] Hofmeister | Applied Software Architecture[END_REF][START_REF] Kruchten | The 4+1 view model of architecture[END_REF][START_REF] Tu | The build-time software architecture view[END_REF]) have defined and used different views of architecture of a software system. For example, Kruchten [START_REF] Kruchten | The 4+1 view model of architecture[END_REF] refers to a "4+1" view model to describe a system involving logical, process, physical, development views, and use-cases. This model defines different perspectives for different stakeholders; the present work uses the concepts of logical ("hierarchical") and process ("coupling") views to establish a comparison between these two views. Similarly, [START_REF] Hofmeister | Applied Software Architecture[END_REF] defines four architectural views of software systems, which in turn focus on coarser degrees of granularity (conceptual, or the abstract design level; module, or the concrete design level; code, or components level; and execution level). As stated above, the present research focuses on the views which are closer to the work of software developers, such as, for instance, the folder or the file level. In the selection of attributes, the limit is on those that it is possible to derive from projects found in existing OSS repositories with a reasonable effort. Hierarchical ("abstract design level") and coupling ("component level") views can both provide insight into how developers deal with macro and micro-components of software systems, respectively.

With reference to software decay, past SE literature has firmly established that software architectures and the associated code degrade over time [START_REF] Eick | Does code decay? assessing the evidence from change management data[END_REF], and that the pressure on software systems to evolve in order not to become obsolete plays a major role in their evolution [START_REF] Lehman | Programs, cities, students, limits to growth? Programming Methodology[END_REF]. As a result, software systems have the progressive tendency to loose their original structure, which makes it difficult to understand and further maintain them [START_REF] Schmerl | Discovering architectures from running systems[END_REF]. Among the most common discrepancies between the original and the degraded structures, the phenomenon of highly coupled, and lowly cohesive, modules has already been known since 1972 [START_REF] Parnas | On the criteria to be used in decomposing systems into modules[END_REF] and is an established topic of research. Architectural recovery is one of the recognized counter-measures to this decay [START_REF] Dueñas | Architecture recovery for software evolution[END_REF]. Several earlier works have been focused on the architectural recovery of proprietary [START_REF] Dueñas | Architecture recovery for software evolution[END_REF], closed academic [START_REF] Abi-Antoun | A case study in re-engineering to enforce architectural control flow and data sharing[END_REF], COTS [START_REF] Avgeriou | Resolving architectural mismatches of cots through architectural reconciliation[END_REF] and FLOSS [START_REF] Bowman | Linux as a case study: its extracted software architecture[END_REF][START_REF] Godfrey | Secrets from the monster: Extracting mozilla's software architecture[END_REF][START_REF] Tran | Architectural repair of open source software[END_REF] systems; in all of these studies, systems were selected in a specific state of evolution, and their internal structures analysed for discrepancies between the folder-structure and concrete architectures [START_REF] Tran | Architectural repair of open source software[END_REF]. Repair actions have been formulated as frameworks [START_REF] Sartipi | A pattern matching framework for software architecture recovery and restructuring[END_REF], methodologies [START_REF] Krikhaar | A two-phase process for software architecture improvement[END_REF] or guidelines and concrete advice to developers [START_REF] Tran | Architectural repair of open source software[END_REF].

Empirical Approach

The approach of building by decomposition into, and the composition of, several components is a common scenario when considering OSS systems. Perhaps the best-known example are Linux distributions, which are collections of projects, libraries and components, which request or provide services to components via connections. This has been reported in various studies [START_REF] German | A model to understand the building and running inter-dependencies of software[END_REF][START_REF] Li | Development with off-the-shelf components: 10 facts[END_REF], especially relating to the issues of OSS licenses [START_REF] German | License integration patterns: Addressing license mismatches in component-based development[END_REF]. Apart from systems composed of subsystems which are already OSS projects, it is essential that empirical knowledge on reuse and domain engineering is based on finer-grained components, smaller than entire systems (as in the LAMP -Linux, Apache, MySQL, Python/Perl/PHP -stack of reuse).

The FFMpeg project has been chosen as an example of software reuse for several reasons:

1. It has a long history of evolution as a multimedia player, that has grown and refined several build-level components throughout its life-cycle. Some of these components appear like "E" type systems, instead of traditional "S" or "P" types, with lower propensity for software evolution. 2. Several of its core developers have been collaborating also in the MPlayer 4project, one of the most commonly used multimedia players across OSS communities. Eventually, the libavcodec component has been incorporated (among others from FFMpeg) into the main development trunk of MPlayer, increasing FFMpeg's visibility and wide-spread usage. 3. Its components are currently reused on different platforms and architectures, both in static-and in dynamic-linking. Static linking involves the inclusion of source code at compile-time, while dynamic linking involves the inclusion of a binary library at runtime. 4. Finally, the static-linking reuse of the FFMpeg components presents two opposite scenarios: either a black-box reuse strategy, with "update propagation" issues reported when the latest version of a project has to be compiled against a particular version of the FFMpeg components [START_REF] Orsila | Update propagation practices in highly reusable open source components[END_REF]; or the whitebox reuse strategy, with copies of the components being deployed in the repositories of other projects which are managed independently from the their original development branch.

Definitions and Operationalization

This paper is built on top of two basic architectural principles: the concept of build-level components [START_REF] De Jonge | Build-level components[END_REF] and the principle of architectural decay along the evolution of software systems [START_REF] Eick | Does code decay? assessing the evidence from change management data[END_REF]. The build-level components are "directory hierarchies containing ingredients of an application's build process, such as source files, build and configuration files, libraries, and so on. Components are then formed by directories and serve as unit of composition" [START_REF] De Jonge | Build-level components[END_REF], and these compose the "folder-structure" or "tree-structure" of a software system [START_REF] Capiluppi | The evolution of source folder structure in actively evolved open source systems[END_REF][START_REF] De Jonge | Source tree composition[END_REF].

In this paper we use terminology and definitions provided in related and well-known past studies. The definition of common coupling (intended for both object-oriented [START_REF] Arisholm | Dynamic coupling measurement for object-oriented software[END_REF][START_REF] Li | Object-oriented metrics that predict maintainability[END_REF] and procedural [START_REF] Fenton | Software metrics: a practical and rigorous approach[END_REF] languages). The following operational definitions have been used:

-Coupling: this is the union of all the includes, dependencies and functions calls (i.e., the common coupling) of all source files as extracted by the Doxygen tool 5 . Since the empirical study is based on the definition of build-level components, two further conversions have been made:

1. The file-to-file and the functions-to-functions couplings have been converted into folder-to-folder couplings, considering the folder that each of the above elements belongs to. A stronger coupling link between folder A and B will be found when many elements within A call elements of folder B. 2. Since the behavior of "build-level components" is studied here, the couplings to subfolders of a component have also been redirected to the component alone; hence a coupling A → B/C (with C being a subfolder of B) is reduced to A → B. -Connection: distilling the couplings as defined above, one could say, in a Boolean manner, whether two folders are linked by a connection or not, disregarding the strength of the link itself. The overall number of these connections for the FFMpeg project is recorded monthly in Figure 2; the connections of a folder to itself are not counted (for the encapsulation principle), while the two-way connection A → B and B → A is counted just once (since we are only interested in which folders are involved in a connection). -Cohesion: for each component, the sum of all couplings, in percentage, between its own elements (files and functions); -Outbound coupling (fan-out): for each component, the percentage of couplings directed from any of its elements to elements of other components, as in requests of services. A component with a large fan-out, or "controlling" many components provides an indication of poor design, since the component is probably performing more than one function. -Inbound coupling (fan-in): for each component, the percentage of couplings directed to it from all the other components, as in "provision of services". A component with high fan-in is likely to perform often-needed tasks, invoked by many components, which is regarded as an acceptable design behavior.

The source code repository (CVS) of FFMpeg was parsed monthly, resulting in some 100 temporal points, after which the tree structures were extracted for each of these points. On the one hand, the number of source folders of the corresponding tree is recorded in Figure 2. On the other hand, in order to produce an accurate description of the tree structure as suggested by [START_REF] Tran | Architectural repair of open source software[END_REF], each month's data has been further parsed using Doxygen, with the aim of extracting the common coupling among the elements (i.e., source files and headers, and source functions) of the systems. The analysis of size growth has been performed using the sloccount tool6 .

Description of the FFMPeg System

As mentioned above, the FFMpeg system has successfully become a highly visible OSS project partly due to its components, libavcodec in particular, which have been integrated into a large number of OSS projects in the multimedia domain.

Fig. 2. Growth of folders and connections

In terms of a global system's design, the FFMpeg project does not yet provide a clear description of either its internal design, or how the architecture is decoupled into components and connectors. Nonetheless, by visualizing its source tree composition [START_REF] De Jonge | Source tree composition[END_REF], the folders containing the source code files appear to be semantically rich, in line with the definitions of build-level components [START_REF] De Jonge | Build-level components[END_REF], and source tree composition [START_REF] Capiluppi | The evolution of source folder structure in actively evolved open source systems[END_REF][START_REF] De Jonge | Source tree composition[END_REF]. The first column of Table 1 summarizes which folders currently contain source code and subfolders within FFMpeg.

As shown, some components act as containers for other subfolders, apart from source files, as shown in columns 2 and 3, respectively. Typically these subfolders have the role of specifying/restricting the functionalities of the main folder in particular areas (e.g., the libavutil folder which is further divided into the various supported architectures -x86, ARM, PPC, etc.). The fourth column also describes the main functionalities of the component. It can be observed that each directory provides the build and configuration files for itself and the subfolders contained, following the definition of build-level components. The fifth column of Table 1 lists the month when the component was first detected in the repository. Apart from the miscellaneous tools component, each of these are currently reused as OSS components in other multimedia projects as development libraries, for example, the libavutil component is currently redistributed as the libavutil-dev package).

Table 1 shows that the main components of this system have originated at different dates, and that the older ones (i.e., libavcodec) are typically more articulated into several directories and multiple files. The libavcodec component was created relatively early in the history of this system (08/2001), and it has now grown to some 220 thousand lines of code (KSLOC) alone.

As is visible in the time-line of Figure 3, other components have coalesced since then; each component appears modularized around a specific "function", according to the "Description" column in Table 1, and as such have become

Results and Discussion

This section provides the results of the empirical investigation into both the growth in size, and the evolution of connections between the components of FFMpeg. For each build-level component summarized in Table 1, a study of its relative change in terms of the contained SLOC (source lines of code) along its life-cycle has been undertaken. In addition, a study of the architectural connections has been performed, by analyzing temporally:

1. How many couplings were actually involved with elements of the same component (as per the definition of cohesion given above), and 2. How many couplings consisted of links to or from other components (as per the definition of inbound and outbound couplings).

Size Growth of FFMpeg Components

As a general result, two main behaviors can be observed, which have been clustered in the two graphs of Figure 4; on the top graph, three components (libavcodec, libavutil and libavformat) show a linear growth as a general trend (relative to the maximum size achieved by each). In the following, these components will be referred to as "E-type". On the other hand, the rest of FFMpeg components show a traditional library behavior, and will be referred as either "S-type" or "P-type" systems.

Size Growth in E-Type Components. Considering Figure 4 (top), the libavcodec component started out as a medium-sized component (18 KSLOCs), but currently its size has reached over 220 KSLOCs, an increase of 1, 100%. Also, the libavformat component has moved through a comparable pattern of growth (250% increase), but with a smaller size overall (from 14 to 50 KSLOC).

Although reusable resources are often regarded as "S-type" and "P-type" systems, since their evolutionary patterns manifest a reluctance to growth (as in the typical behavior of software libraries), these two components achieve an "Etype" evolutionary pattern even when heavily reused by several other projects.

The studied cases appear to be driven mostly by adaptive maintenance, since new audio and video formats are constantly added and refined among the functions of these components. Expressing these observations in biological terms, these software components appear and grow as "fruits" from the main "plant" ("trunk" in the version control system). Furthermore, these components behave as "climacteric" fruits, meaning that they ripen off the parent plant (and in some cases, they must be picked in order to ripen). These FFMpeg components have achieved an evolution even when separated from the project they belonged to, similarly to climacteric fruits.

Size Growth in S-and P-Type Components. On the other hand, the remaining components show a more traditional, library-style type of evolution: the bottom part of Figure 4 details the relative growth of these components. Libpostproc and libswscale appear hardly changing at all, even if they have been formed for several years in the main project. Libavdevice, when created, was already at 80% of its current state; libavfilter, instead, although achieving a larger growth, does so since it was created at a very small stage (600 SLOC), which has now doubled (1,4 KSLOCs). These resources are effectively library-type of systems, and their reuse is simplified by the relative stability of their characteristics, meaning the type of problem they solve. Using the same analogy as above, the components ("fruits") following this behavior are unlikely ripen any further once they have been picked. Outside of the main trunk of development, these components remain unchanged, even when incorporated into other OSS projects.

Architectural Growth of FFMpeg Components

The observations related to the growth in size have been used to cluster the components based on their coupling patterns. As mentioned above, each of the 100 monthly check-outs of the FFMpeg system have been analyzed in order to extract the common couplings of each element (functions or files), and these common couplings have been later converted into connections between components.

As observed also with the growth in size, the E-type components present a steadily increasing growth of couplings compared to the S-and P-type components. The former also display a more modularized growth pattern, resulting in a more stable and defined behavior.

Coupling patterns in E-type components. Figure 5 proposes the visualization of the three E-type components as identified above. For each component, 4 trends are displayed:

1. The overall amount of its common couplings; 2. The amount of couplings directed towards its elements (cohesion, labeled "self"); 3. The amount of its outbound couplings (fan-out, labeled "out"); 4. The amount of its inbound couplings (fan-in, labeled "in"); Each component has a continuous growth trend regarding the number of couplings affecting it. The libavutil component has one sudden discontinuity in this growth, which will be later explained. As a common trend, it is also visible that both the libavcodec and libavformat components have a strong cohesion factor, which maintains over the 75% threshold throughout their evolution. This means that, in these two components, more than 75% of the total number of couplings are consistently between internal elements. The cohesion of libavutil, on the other hand, degrades until it becomes very low, revealing a very high fan-in; after the restructuring at around 1/5 of its lifecyle, this component becomes a pure server, fully providing services to other components (more than 90% of all its couplings -around 3,500 -come from external components).

When observing the three components as part of a common, larger system, the changes in one component become relevant to the other components as well. As an example, the general trend of libavcodec is intertwined to the other two components in the following ways:

1. The overall number of couplings towards its own elements decreased during a time interval when no further couplings were added, therefore its cohesion has degraded; 2. At the same time, its fan-out suddenly increased, topping some 17% at the latest studied point: observing carefully, the larger amount of requests of service were more and more directed towards libavutil, which around the same period experienced a sudden increase of its fan-in; 3. Also, the fan-in of libavcodec decreased: originally, the major cause of this was due to numerous requests from the libavformat component. Throughout the evolution, these links were converted into connections to libavutil instead.

Performing a similar analysis for libavformat, it becomes clear that its fan-out degrades, becoming gradually larger, the reason being an increasingly stronger link to the elements of both libavcodec and libavutil. This form of inter-component dependencies is a form of architectural decay: at the latest available data point (08/20009), this has been reproduced in Figure 6.

This graph shows the typical trade-offs between encapsulation and decomposition: several of the common files accessed by both libavformat and libavcodec have been lately moved to a third location (libavutil), that acts as a server to both. This in turns has a negative effect on reusability: when trying to use the functionalities of libavcodec, it will be necessary to import also the contents of libavutil. Even worse, when trying to reuse the attributes of libavformat, the connections to both libavutil and libavcodec have to be restored. Coupling patterns in S-and P-type components. The characteristics of the E-type components as described above can be summarized as follows: large cohesion, fan-out under a certain threshold, and clear, defined behavior as a component (e.g., pure "server" as achieved by the libavutil component).

The second cluster of components identified above (the "S-" and "P-type") revealed several discrepancies from the results observed in subsection 4.2. A list of key results is summarized here: 1. As also observed for the growth of components, the number of couplings affecting this second cluster of components reveals a difference of one (libswscale, libavdevice and libavfilter) and even two (libpostproc) orders of magnitude with respect to the E-type components. 2. Slowly growing trends in the number of couplings were observed in libavdevice and libavfilter, but their cohesion remains stable. On the other hand, a high fan-out was consistently observed in both, with values of 0.7 and 0.5, respectively. Observing more closely, these dependencies are directed towards the three E-type components defined above. This suggests that these components are not yet properly designed, also due to their relatively young age: their potential reuse is subsumed to the inclusion of other FFMpeg libraries as well.

As a summary, this second type of components can be classified as slowly growing, less cohesive and more connected with other components in the same system. They can be acceptable reusable candidates, but only in conjunction with the whole, hosting project (i.e., FFMpeg).

Deployment of libavcodec in other OSS projects

The three components libavcodec, libavformat and libavutil have been characterized above as highly reusable, based on coupling patterns and size growth attributes. In order to observe how these components are actually reused and deployed in new hosting systems, this Section summarizes the study of the deployment of the libavcodec component in 4 OSS projects: avifile7 , avidemux 8 , MPlayer and xine 9 .

The selection of these projects for the deployment study is based on their current reuse of these components. Each project hosts a copy of the libavcodec component in their code repositories, therefore implementing a white-box reuse strategy of this resource. The issue to investigate is whether these hosting projects maintain the internal characteristics of the original libavcodec, hosted in the FFMpeg project. In order to do so, the coupling attributes of this folder have been extracted from each OSS project, and the number of connected folders has been counted, together with the total number of couplings. Each graph in the Figure 7 represents a hosting project: the libavcodec copy presents some degree of cohesion (the re-entrant arrow), and its specific fan-in and fan-out (inwards and outwards arrows, respectively). The number of connections (i.e., distinct source folders) responsible for the fan-in and fan-out are displayed by the number in the circle. The following observations can be made:

-The total amount of couplings in each copy is always lower than the original FFMpeg copy: this means that not the whole FFMpeg project is reused, but only some specific resources; -In each copy, the ratio f anin/f anout is approximately 2:1. In the xine copy, this is reversed: this is due to the fact that apparently xine does not host a copy of the libavformat component; -For each graph, the connections between libavcodec and libavutil, and between libavcodec and libavformat have been specifically detailed: the fan-in from libavformat alone has typically the same order of magnitude than all the remaining fan-in; -The fan-out towards libavutil typically accounts for a much larger ratio. This is a confirmation of the presence of a consistent dependency between libavcodec and libavutil, which therefore must be reused together. The avidemux project moved the necessary dependencies to libavutil within the libavcodec component; therefore no build-level component for libavutil is detectable.

Threats to Validity

We are aware of a few limitations of this study, which we discuss next. Since we do not claim any causal relationships, we do not discuss threats to internal validity. Construct validity. We used common coupling to represent inter-software component connections. Furthermore, the build-level components presented in Table 1 are automatically assigned (though probably accurate), but could be only subcomponents of a larger component (e.g., composed of both libavutil and libavcodec).

External validity. External validity is concerned with the extent to which the results of our study can be generalized. In our study, we have focused on one case study (FFMPeg), which is written mostly in C. Performing a similar study on a system written in, for instance, an object-oriented language, the results could be quite different. However, it is not our goal to present generalizations based on our results. Rather, the aim of this paper is to document a successful case of OSS reuse by other OSS projects.

Conclusions

Empirical studies of reusability of OSS resources should proceed in two strands: first, they should provide mechanisms to select the best candidate component to act as a building block in a new system; second, they should document successful cases of reuse, where an OSS component(s) has been deployed in other OSS projects. This paper attempts to give a contribution to the second strand by empirically analysing the FFMpeg project, whose components are currently widely reused in several multimedia OSS applications. The empirical study was performed on a monthly basis during the last 8 years of its development: the characteristics of its size, the evolutionary growth and its coupling patterns were extracted, in order to identify and understand the attributes that made its components a successful case of OSS reusable resources. After having studied these characteristics, 4 OSS projects were selected among the ones implementing a white-box reuse of the FFMpeg components: the deployment and the reuse of these components was studied from the perspective of their interaction with their hosting systems.

In the FFMpeg study, a number of findings were obtained: first, it was found that several of its build-level components make for a good start in the selection of reusable components. They coalesce, grow and become available at various points in the life cycle of this project, and all of them are currently available as building blocks for other OSS projects to use. Second, it was possible to classify at least two types of components: one set presents the characteristics of evolutionary (E-type) systems, with a sustained growth throughout. The other set, albeit with a more recent formation, is mostly unchanged, therefore manifesting the typical attributes of reusable libraries.

The two clusters were compared again in the study of the connections between components: the first set showed components with either a clearly defined behavior, or an excellent cohesion of its elements. It was also found that each of these three components becomes more connected to the others, as forming one single super-component. The second set appeared less stable, with accounts of large fan-out, which called for a poor design of the components.

One of the reusable resources found within FFMpeg (i.e., libavcodec) were analysed when deployed into 4 OSS systems performing a white-box reuse: its cohesion pattern appeared similar to the original copy of libavcodec, while it emerged with more clarity that at present its reuse is facilitated when the libavformat and libavutil components are reused too.

Acknowledgements

The authors would like to thank Daniel German for the clarification on the potential conflicts of licenses in the FFMpeg project, Thomas Knowles for the insightful discussions, and Nicola Sabbi for the insider knowledge of the MPlayer system. The work of Klaas-Jan Stol is partially funded by IRCSET under grant no. RS/2008/134 and by Science Foundation Ireland grant 03/CE2/I303 1 to Lero (www.lero.ie).

Fig. 1 .

 1 Fig. 1. Black-box and white-box reuse

Fig. 3 .

 3 Fig. 3. Inception dates of components

Fig. 4 .

 4 Fig. 4. E-type (top) and S-and P-type of components (bottom) -growth in size

Fig. 5 .Fig. 6 .

 56 Fig. 5. E-type components -coupling patterns

Fig. 7 .

 7 Fig. 7. Deployment and reuse of libavcodec

Table 1 .

 1 FFMpeg (build-level) components better reusable in other systems (and are in fact repackaged as distinct OSS projects).

	Name	Folders Files Description	Date
	libavcodec	12	625 Extensive audio/video codec library	08/2001
	libpostproc	1	5 Library containing video postprocessing routines 10/2001
	libavformat	1	205 Audio/video container mux and demux library	12/2002
	libavutil	8	70 Shared routines and helper library	08/2005
	libswscale	6	20 Video scaling library	08/2006
	tools	1	4 Miscellaneous utilities	07/2007
	libavdevice	1	16 Device handling library	12/2007
	libavfilter	1	11 Video filtering library	02/2008

http://www.qualipso.org/

http://www.qualoss.org/

MPlayer, http://www.mplayerhq.hu

http://www.stack.nl/ ~dimitri/doxygen/

http://www.dwheeler.com/sloccount/

http://avifile.sourceforge.net/

http://fixounet.free.fr/avidemux/

http://www.xine-project.org/home


Alexander C Maclean
email: amaclean@byu.edu

Landon J Pratt
email: landonjpratt@byu.edu

Charles D Knutson
email: knutson@cs.byu.edu

Eric K Ringger
email: ringger@cs.byu.edu

Knowledge Homogeneity and Specialization in the Apache HTTP Server Project

We present an analysis of developer communication in the Apache HTTP Server project. Using topic modeling techniques we expose latent conceptual sub-communities arising from developer specialization within the greater developer population. However, we found that among the major contributors to the project, very little specialization exists. We present theories to explain this phenomenon, and suggest further research.

Introduction

Private information is "information possessed by a relatively small segment of the population" [START_REF] Krein | The problem of private information in large software organizations[END_REF]. For example, in development organizations certain individuals specialize and become de facto leaders within conceptual domains. Latent roles develop and define structure and vulnerability within an organization. In practice, these individuals become centers of private information subcommunities and thereby control the shape and flow of information within that sub-community. The identities of these individuals are latent in that there is often no obvious correlation between the overt organizational structure and the centers of knowledge within that structure.

We should be clear that private information is neither inherently good nor bad. Instead, its influence is context specific. Private information refers to information known to an individual or small set of individuals, not necessarily information that is hoarded or deliberately withheld. Rather, private information exists as a natural byproduct of organizational learning. A deeper discussion is presented by Krein, et al [START_REF] Krein | The problem of private information in large software organizations[END_REF].

Specialization

Developer specialization is a form of private information in which developers within an organization become expert in a particular concept domain. Example domains might include UI developers, "the database guy," or any small group of developers who are essential to interacting with a particular piece of the product.

Specialization is often found in large organizations where the scope of the project is such that no single person has the time or capacity to master all aspects of a product. Organizations benefit from specialization by minimizing the overlap of skill acquisition since it can be time consuming and expensive. Individuals benefit from specialization through job security and decreased initial training requirements.

Although beneficial when viewed from a schedule and budget perspective, specialization introduces risk into an organization. For example, in an organization with two core developers, is it appropriate to put both of them on the same plane for a business trip? Or, what contingency should the organization put into place in the event that these two developers decide to retire? While development organizations could certainly recover from the untimely departure of specialized developers, and other developers exist who are capable enough to fill the roles, could the overall organization recover from the delays imposed by the resulting loss in productivity and stay competitive in an aggressive marketplace?

Developing a contingency plan for unexpected change is relatively straightforward when the specialized roles are overtly expressed in the organizational structure or are generally understood among the developers. However, danger arises when the roles are latent and therefore difficult to identify.

The Apache HTTP Server Project

The Apache HTTP Server (httpd) is an open-source HTTP server implementation and the leading HTTP server with 59% market share as of January 2011 [3]. The project is maintained by a group of volunteers from around the world who collaborate through the use of online tools such as email and chat [2]. Most importantly for this analysis, project tenets stipulate that all development and managerial communication must happen in the publicly available mailing lists.

We are interested in this project because of its open-development philosophy (anyone who proves their worth within the meritocracy can contribute) as well as its success. We would like to use open source projects such as those maintained by the Apache Foundation as an analogue for all software development organizations. Whereas it is difficult and rife with legal issues to obtain source code and developer communications from closed source enterprises, it is comparatively trivial to obtain the same information from the Apache Foundation. If we can show that open source projects behave like their closed source counterparts we can circumvent this roadblock.

Reference Organizations

The authors are personally familiar with three large software development organizations that each exhibit evidence of private information. Each organization is unique with regards to the degree of geographic distribution and size, yet all contain easily identifiable private information. These organizations are presented as references against which we may compare the Apache HTTP Server project. For consistency we refer to the organizations by number, even though we also identify Organization 2 by name.

For each of these organizations we note the degree of geographic distribution in an effort to illustrate that private information exists whether or not developers are collocated. Since the httpd project is massively distributed, it is important to show that private information is not necessarily caused by lack of face-to-face communication.

Organization 1 Organization 1 builds and maintains a large suite of software products comprised of both legacy and new components. The legacy engine is highly complex and is central to the success of the suite. Although a large organization develops the products and builds new features, only two developers may change the legacy engine. Both of the developers have been with the company for over twenty years. Most products in this organization target either consumer grade computers or cloud-based computing systems.

This organization is somewhat distributed (and is growing more distributed over time). However, a large portion of the developers are still collocated.

Organization 2 Organization 2, IBM, is large (426,751 employees, with gross revenues of $99 billion in 2010 [1]) and builds many disparate products. Despite well-established corporate practices, Krein, et al, still found that "loss of specialized information arises from both reorganization and loss of employees" and that "employee loss. . . creates information gaps" [START_REF] Krein | The problem of private information in large software organizations[END_REF]. Their study specifically targeted extended stakeholders1 , and therefore is not a direct analogue to a development organization. However, it illustrates some of the organizational fragility that arises from private information.

IBM is largely distributed, and has employees in more than 40 countries [1]. Many IBM employees telecommute, further increasing the distributed nature of the organization.

Organization 3 Organization 3 is large but still smaller than both organizations 1 and 2. Developers often specialize and become centers of conceptual communities surrounding hardware interfaces, user interfaces, network communication, fault tolerance, and other product specific topics. Unlike Organization 1, this organization primarily develops software that is shipped in embedded devices.

This organization is lightly distributed across half a dozen different locations. However, members of individual product groups are all collocated.

Private Information

Krein, et al, presented the problem of private information, a framework for understanding communication dynamics within a distributed organization. They studied extended stakeholders in an effort to understand how specialized information flows between stakeholders [START_REF] Krein | The problem of private information in large software organizations[END_REF]. While inspired by Hayek's work in economics [START_REF] Hayek | The use of knowledge in society[END_REF], Krein's work represents the first application of the notion of private information to software organizations. Since Krein, et al, is an introductory study, few methods exist to aid us in practice. Still, the concept of private information is a powerful guiding metaphor and provides a framework within which to study knowledge homogeneity and specialization.

Goal

In order to discover pockets of private information within the Apache HTTP Server community, and thereby identify developer specialization, we analyzed committer email records and commit history. The goal was to identify two phenomenon: 1) committers who write exclusively about a particular topic, or 2) topics that are only discussed by a small set of committers. The first case indicates committers who specialize in a particular topic. The second case indicates topics that are dominated by particular committers.

Data

We gathered data for this study from the Apache Foundation during February of 2011. Our data set consists of the commit history and email archives for the Apache HTTP Server Project, spanning sixteen years (2/27/1995 -1/31/2011).

Mailing Lists

The mailing list archives for the Apache Software Foundation are freely available. They consist of files stored in the mbox format that contain all of the communication on a given channel for a particular month. For this paper we only analyze the "dev" channel of the mailing lists for the httpd project and refer to it as "the mailing list." This channel should represent communication regarding project development. It consists of 124,938 messages and 166 developers2 (see Section 3.1). The mailing lists were imported into PostgreSQL.

Developer contribution to the mailing list is not uniform. Instead, a small subset of developers generate most of the traffic (see Figures 1 and2). Figure 1 shows the number of messages sent per developer for the entire time period. Note the power law distribution of developer email traffic. Figure 2 shows the same activity in 2009, illustrating that the activity patterns are consistent regardless of time window.

Subversion Repository

The commit history for the project consists of 46,336 revisions by 134 developers. However, as with mailing list activity, a small group of developers committed a majority of the changes to the project (see Figure 3). This behavior has been demonstrated in previous studies [START_REF] Krein | Impact of programming language fragmentation on developer productivity: a sourceforge empirical study[END_REF]. In order to identify private information in the Apache HTTP Server community, we first had to associate email topics with developers. To do so, we 1) mapped the committers to email records, 2) cleaned the email records to remove extraneous information, 3) identified topics of discussion in the resulting messages, and 4) constructed a social network model from committers and topics.

Developer/Email Mapping

Mailing lists for the httpd project are not associated with SVN, and therefore are generally tied to the usernames employed by the versioning software. The only exception is contributors who send email from their Apache email addresses, which are formatted as <svn-username>@apache.org or <svn-username>@<project-name>.apache.org. In either case, the mailing lists simply identify contributors by their email addresses, most of which are non-Apache email addresses and therefore can't be attributed directly to an Apache committer. In addition, many individuals sent emails from multiple email addresses and from clients that employ differing email formatting conventions. We used a simple algorithm to map email addresses to committers:

if email address ends with apache.org then use all text before the "@" symbol as the committer username else if from header contains a name (e.g., "John Lawrence Smith" <jls@nowhere.com>) then if first name and last name match those of a committer listed on the Apache Foundation Website3 then map the email address to the committer else ignore the email address end if else ignore the email address end if end if Due to the small number of committers registered to the project, a manual analysis of a random subset of the email was sufficient to confirm that this method accurately categorized the email on the mailing list.

Email Cleaning

We preprocessed the messages to extract the information contributed by the sender and remove information contributed by others, thereby improving the accuracy of the identified topics. The email messages are in MIME format. Preprocessing consisted of seven steps:

1. Remove all sections of the multipart emails that were not "text/plain." 2. Remove all header lines. 3. Remove lines that were most likely quoted text from a previous email. We identified four patterns that denoted quoted text (see Table 1). 4. Remove signatures by deleting all contiguous lines following --\n until encountering an empty line. 5. Remove all instances of the author's name (see Section 3.3). 6. Remove a list of stopwords4 . 7. Tokenize the messages such that words consist of groups of letters and underscores.

Identification Action Lines that started with ">" Line removed Sections that started with --------forwarded message or ----------forwarded message

Following text removed

Lines like <so-and-so> (wrote|writes):

Line removed

Lines like

On <date> <so-and-so> (wrote|writes):

Line removed

Table 1. Quoted text identification. [START_REF] Wang | Topics over time: a non-Markov continuous-time model of topical trends[END_REF] used a similar cleaning scheme but indicated that doing so may remove inline responses. However, we found that in this dataset inline responses were generally made to lines of text that started with ">," and therefore only the quoted text was removed. Of a random sample of 100 emails, this process did not remove any lines of text that were not quotes, and only failed to remove all of the quoted text in three instances.

Wang and McCallum

Topic Identification

In order to identify latent roles and groups in the httpd community that may suggest private information, we extracted topics from messages sent by developers on the mailing list. These topics were identified in an unsupervised/unbiased regex match pattern regexp string cmd regex t expression preg regular register pcre posix compiled regexec regcomp library pmatch rm so ap pregcomp Fig. 5. The top twenty terms in the regular expression topic. Term importance decreases from left to right, where "regex" is the most important term.

fashion using Latent Dirichlet Allocation (LDA), a Bayesian probabilistic topic model that clusters words from the corpus into topics [START_REF] Blei | Latent dirichlet allocation[END_REF]. "Topics" are probability distributions over the vocabulary words (terms) in the corpus, based upon word collocation within messages. In the process of topic identification, words in the emails are attributed to topics and a mixture of topics is deduced for each message in a manner that depends upon collocation of words within messages. We utilized the MALLET [START_REF] Kachites | Mallet: A machine learning for language toolkit[END_REF] implementation of LDA to identify 200 topics from the email corpus and assign message topic probabilities. Figure 5 shows the top twenty terms in the regular expression topic.

Our initial tests using LDA to identify topics from the email messages resulted in topics that contained author names. We removed the author's name from each email to avoid identifying these name-heavy topics. Although grouping author names with terms provided interesting insight into developer prominence, including the names diluted the topics and decreased the likelihood that less prolific developers would be associated with a given topic.

Social Network Analysis

From the topics assigned to email messages by LDA we created a two-mode social network consisting of topic nodes and committer nodes. Connections only exist between topic nodes and committer nodes: no inter-topic or inter-committer edges exist. Edge weight between a topic committer and a topic is determined by the weighted proportion of the messages attributed to the committer that refer to the topic, where weighted proportion is This calculation allows committers whose communications on the mailing list are voluminous to dwarf those who contribute less frequently. This seems appropriate in light of the intent of the metric to identify those who have or control knowledge about individual topics. However, it is worth noting that the metric does not capture subtleties, such as committers who specialize in a particular subject, but whose contributions to the project are relatively minor.

Results

If specialization exists within the httpd community, we should see distinct communities develop around topics. In addition, unique groups of developers should congregate around specialized subtopics. We examined the data from both angles: topical affinity and topic communities.

LDA Results

We used LDA to identify 200 topics that summarize the communication on the mailing list. The most prevalent topic described 2% of the text contained in the messages. Figure 6 shows a stacked bar chart of topic proportions over the entire corpus, where each segment of the stacked bar represents a single topic. The median topic described 0.3% of the text contained in the messages. Notably no topics dominated the discussion.

Despite stripping developer names from the emails, a few topics exist that are centered around prominent committers to the project. These topics likely result from other members of the community referring to these more prominent members. We ignored developer-centric topics in our analysis. Although they may indicate private information about a developer, they do not indicate private information about the project.

Topical Affinity

One measure of developer communication is topical affinity-how much a developer discusses a particular topic. In Figure 7 we see a network that contains the top 22 developers by topical affinity. Note how clusters of topics gather around certain developers. Note also that a small number of developers discuss these topics in such volume that most of the developers are filtered out of this network. This threshold was discovered visually. There is a clear threshold at which the network stabilizes into a small subset of prolific authors.

Regardless of the edge weight threshold, the network looks the same, albeit more or less connected. This trend directly contradicts experience in the three reference organizations (see Section 1.3). If private information exists we would expect to see distinct groups appear within the network as the lower threshold for edge inclusion increased. Instead, we see a core group of developers to whom all topics are connected more heavily than to any specialized group.

Topic Communities

We examined the communities that form around major topics, such as voting, SSL, licenses, security, patching, module development, CGI, configuration, regular expressions, and error handling. In each case, the resulting community was comprised almost exclusively of the core developers. Figure 8 is indicative of the groups that form around topics. In the network, all of the top ten developers are attached to the topic. This pattern repeats itself for all non-developer specific topics. In several cases concepts were split among multiple topics. However, the communities that congregated around the combined topics were also composed of the core developers.

Specialization

Because there are no prominent groups in our network of topics and developers, we must conclude that there is little specialization among the core group of developers in the Apache HTTP Server project. This result is especially surprising in light of our reference organizations which exhibit clear specialization. Instead, all of the core developers discuss all major topics with varying degrees of prominence. This suggests that instead of specializing, the core group of developers discuss all of the topics and make decisions as a whole.

In Figure 9 each bar represents a committer and the magnitude of the bar indicates the number of topics for which the committer was either the first, second, or third most prolific commenter (200 topics, 600 total first, second, or third ranks). A small number of core developers dominate the discussions on each topic.

Validation

In order to validate our findings, we contacted Dr. Justin Erenkrantz who served as Director of the Apache Software Foundation from 2005 to 2010 and as President from 2007 to 2010. Dr. Erenkrantz, a substantial contributor to the httpd project, corroborated our findings that suggest that little specialization exists among the core developers. This validated our interpretation of the distribution of topic usage in the project. In addition, his corroboration was in stark contrast to the results obtained in the study by Krein, et al [START_REF] Krein | The problem of private information in large software organizations[END_REF], where the stakeholders were well aware of specialization and private information within the organization.

Threats to Validity

Here we mention two threats to the validity of our study: minor contributors and email text selection.

Minor Contributors

While our edge weight metric identifies those who are most vocal about a particular topic, it does not identify lesser commenters who specialize in that topic. Further work is required to determine whether minor contributors to the project likewise lack specialization. We suspect that developers who commit infrequently must specialize because they don't have enough familiarity with the system to change multiple components without unintended consequences.

Email Text Selection

In this study we used only the "text/plain" sections of the emails. However, developers can create emails that only contain "text/html" sections. Although HTML was not common in this project, it could slightly bias the results against an individual who always creates emails this way. However, this was not the case with the most prolific contributors, and therefore should not bias the study significantly.

Future Work

This analysis has unearthed a multitude of additional questions, some of which we list here.

Hidden Private Information

In this study we used topics gleaned from email messages to determine that there was little specialization in the community and corroborated our results through member checking. However, our results were based upon communication and members' impressions. To more fully explain specialization in the httpd project we must look at the commit patterns of developers. If the commit patterns indicate that the core developers work on everything, then our results are confirmed. If they indicate the opposite, then there is an assumption by the developers of a lack of specialization when in fact they do specialize. This result would have fascinating social implications.

Developer Tenure

During the dot com boom, conventional wisdom maintained that the average developer tenure in a job was 18 months. A study by Fallick, Fleischman, and Rebitzer [START_REF] Fallick | Job-hopping in Silicon Valley: Some evidence concerning the microfoundations of a high-technology cluster[END_REF] seems to indicate that average tenure in Silicon Valley has grown to around 4.2 years. However, their work revolved around developer mobility, not tenure, and extrapolating 4.2 years is statistically unsound 5 . Nevertheless, the numbers used in their study still cast heavy doubt on the previous figure of 18 months.

In contrast, the median tenure of developers on the Apache HTTP Server project is 3.7 years. Is this tenure significantly different from the median tenure of developers in traditional, closed source, closed development organizations? Also, when a developer is employed by a company, the company can expect the developer to spend a certain amount of time each week on assigned projects. Is the effort exerted by volunteer6 developers analogous to that of an employee?

Topic Analysis in a Mid-Sized Organization

Only 134 developers have ever committed to the Apache HTTP Server project. Of those 134 developers, the top 30 are responsible for 75% of the commits. Comparing the httpd project to more traditional, closed source organizations of comparable size would provide insight into whether or not the behavior in this FOSS community differes significantly. Ideally this study would involve both collocated development organizations and distributed organizations in order to identify any effect that geographic distribution may have.

Cross Project Comparison in Apache

If knowledge homogeneity is a symptom of open development, we would expect to see the same kind of knowledge distribution in other projects in the Apache Foundation. All projects within the foundation are governed by a similar set of rules, and all are maintained by volunteer developers. Future work should explore the degree to which specialization appears within other projects.

Knowledge and Email Communication

In this paper we have been primarily concerned with topic specialization in email messages in the Apache HTTP Server project. However, further work is required to determine the degree to which analysis of topics in email messages identifies knowledge distribution in an open source organization.

Conclusions

Lack of specialization within this community may result from a myriad of reasons. Here we explore several factors that may perpetuate this homogeneous knowledge base.

Organizational Resiliency

Development of the Apache HTTP Server is performed by volunteers, most of whom are paid by external organizations to develop the product. Incentives for the external organizations vary, but one common element holds: developers are potentially transient. At any point a sponsoring entity may decide that a developer is required for an internal project either temporarily or permanently. Although the developer may continue to contribute on personal time, it is unlikely that he or she will be able to contribute anywhere near previous levels. If that developer holds unique specialized knowledge, the knowledge is essentially lost.

By spreading the knowledge across the core members of the organization, this organizational threat is mitigated. We doubt that the organization consciously promulgated a policy of knowledge homogeneity, but rather reacted to organizational fluidity.

Small Group of Core Developers

A second, related factor may be the relatively small size of the core group of developers. The question becomes: on what are the developers working? If the core group spends much of their time working on bug fixes, then the management of bug priority could homogenize the developer communication. If the developers work together on new features, feature timeline could lead to a homogeneous workgroup-all developers work on the same feature to get it out the door for the next release.

Small Project Size

A third, trivial, reason, may be that the project is simply too small to require developer specialization. It may be the case that the conceptual domain of the project is small enough that a single developer can, and does, comprehend that entire space. If so, then there is no need for specialization in a project of this size.

However, this reason seems highly unlikely. The conceptual domain contains complicated subdomains such as SSL, user authentication, OS specific tailoring, and transfer protocols. We don't believe that the required depth of knowledge in these subdomains is sufficiently shallow that developers can operate with a broad overview of knowledge.

Voting

Lastly, organizational culture within the httpd project could require homogeneity. Releases and major commits to the project must be approved by a vote of the Project Management Committe (PMC), a group of the more seasoned developers. Informed votes require that members of the PMC are familiar with all aspects of the project and ensure that they are kept abreast of developments.

Software Engineering Taxonomy

Regardless of the reasons behind the observed knowledge homogeneity, the implications are fascinating and motivate further exploration. By better understanding the similarities and differences between various types of development organizations-be they open or closed source, open or closed development, geographically distributed or collocated, large or small, embedded, desktop, or cloud-we continue to develop a working taxonomy of the software engineering landscape. This taxonomy informs our analysis of future projects and enables better comparison between domains.

Fig. 1 .

 1 Fig. 1. Messages per developer. Each bar represents a single developer, sorted by number of messages.

Fig. 2 .Fig. 3 .Fig. 4 .

 234 Fig. 2. Messages per developer in 2009. Each bar represents a single developer, sorted by number of messages.

  All messages attributed to committer c, i:Message index, mi: Message i from Mc, pt(x): Proportion of message x attributed to topic t.

Fig. 6 .

 6 Fig. 6. Proportion of communication for which each topic is the dominant topic in a message.

Fig. 7 .

 7 Fig. 7. The top 22 developers on the mailing list by topical affinity. Dark nodes are topics, light nodes are developers. Note that there are strong clusterings of topics around certain developers.

Fig. 8 .

 8 Fig. 8. Developers who discuss the voting topic. Proximity indicates volume of communication.

Fig. 9 .

 9 Fig. 9. Each bar represents the number of times an individual was the first, second, or third most prolific communicator in a topic in 2010. There is one bar per developer.

Non-developers.

Not all registered committers actually made changes to the project.

http://people.apache.org/committer-index.html

Removing stopwords improves the accuracy of LDA by removing commonly occuring terms that are not topic specific.

Fallick, Fleischman, and Rebitzer did not make this extrapolation in their paper.

We realize that most of the prominent developers in an open source projects are employed by external organizations and paid to contribute to the project. However, the question is still legitimate.

Acknowledgements

The authors would like to thank Dr. Justin Erenkrantz for his willingness to provide validation and insight regarding the Apache HTTP Server community.

Jan--95

Jul--95 Jan--96 Jul--96 Jan--97 Jul--97 Jan--98 Jul--98 Jan--99 Jul--99 Jan--00 Jul--00 Jan--01 Jul--01 Jan--02 Jul--02 Jan--03 Jul--03 Jan--04 Jul--04 Jan--05 Jul--05 Jan--06 Jul--06 Jan--07 Jul--07 Jan--08 Jul--08 Jan--09 Jul--09 Jan--10 Jul--10 Jan--11

# of commits per month