Jymit Khondhu
email: jkhondhu@hotmail.co.uk

Andrea Capiluppi
email: andrea.capiluppi@brunel.ac.uk

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

Is It All Lost? A Study of Inactive Open Source Projects

Keywords: Open Source, Inactive Projects, Maintainability Index

Open Source Software (OSS) proponents suggest that when developers lose interest in their project, their last duty is to "hand it off to a competent successor." However, the mechanisms of such a hand-off are not clear, or widely known among OSS developers. As a result, many OSS projects, after a certain long period of evolution, stop evolving, in fact becoming "inactive" or "abandoned" projects. This paper presents an analysis of the population of projects contained within one of the largest OSS repositories available (SourceForge.net), in order to describe how projects abandoned by their developers can be identified, and to discuss the attributes and characteristics of these inactive projects. In particular, the paper attempts to differentiate projects that experienced maintainability issues from those that are inactive for other reasons, in order to be able to correlate common characteristics to the "failure" of these projects.

Introduction

The vast diffusion of Open Source Software (OSS), and the availability of several (hundreds of) thousands of OSS projects, has started to show that this online phenomenon is not always successful [START_REF] Wiggins | Reclassifying success and tragedy in floss projects[END_REF][START_REF] Schweik | Success and abandonment in open source commons: Selected findings from an empirical study of sourceforge.net projects[END_REF]. A lack of activity by developers, and a low interest by users, show that many OSS projects, after a certain long period of evolution, stop evolving, and in fact become "inactive" projects. This phenomenon has been observed before, and metrics have been developed to automatically detect inactivity, or to correlate which characteristics are more relevant to such inactive projects [START_REF] Schweik | Internet Success: A Study of Open Source Software Commons[END_REF]: how many days, months or years in "lack of activity" are necessary to tag a project as inactive? How much should two subsequent releases be apart to declare that a project's development is inevitably facing a downturn? On the other hand, is a specific programming language more likely to cause inactivity in projects? A specific application domain (games, office productivity, etc.)? A specific OSS license?

Although the semi-automatic detection of inactivity can produce useful insights on the general trends of large sets of OSS projects, any set of assumptions used to produce figures of inactive projects could be criticized for its inclusion criteria, or for not being validated with external factors. One could inadvertently misclassify dormant projects as "inactive"; projects could be renamed in the meantime, or even just moved to dedicated repositories. 3The information on such inferred inactivity has relevant external effects: from an end-user's point of view, organizations and private users would not want to invest money or time to deploy or evaluate inactive projects, or those with few or no contributors to perform future maintenance. From a developers' point of view, the original authors should take the responsibility to inform others that they are no longer interested (or able) to support or enhance their project. Or, as Raymond [15, p.26] suggested: "When you lose interest in a program, your last duty to it is to hand it off to a competent successor."

This would introduce one of the most powerful mechanisms in OSS development, namely the possibility for another developer to take over the project from one or more previous developers who lost interest in it [START_REF] Raymond | The Cathedral and the Bazaar[END_REF][START_REF] Capiluppi | Adapting the 'staged model for software evolution' to free/libre/open source software[END_REF]. Thus, we identified two key motivations for accurately labelling inactive or abandoned projects:

1. The ability to clearly distinguish alive projects from the clutter, so as to give confidence to potential users and adopters; 2. To implement one of the most powerful mechanisms of OSS development, namely the ability for other developers to "take over" inactive or abandoned projects, in order to sustain a new phase of development, managed and sustained by someone other than the original creators.

This paper studies the abandonment of OSS projects without inferring their lack of activity with measures. It studies the abandoned projects by spidering a specific HTML tag (i.e., < inactive >) that the authors are encouraged to use in specific cases for their projects on SourceForge. 4 When developers do not intend to continue working on their projects any longer, they have the ability of placing such a tag onto the SourceForge "main" project page,5 thus sending a clear indication to potential users about the lack of maintenance and support; but also to other developers, who can follow a specific process to become the new maintainers and owners of the project, if they want to do so. 6A fundamental reason for studying abandoned projects is to analyze what type of resources have been left behind when developers "moved on", their quality, and whether one of the reasons for such abandonment is because those resources have become ultimately unmaintainable. Both as a user and as a prospective new contributing developer, it is important to understand the quality of an abandoned project and its resources, its general maintainability, and how it progressed over time, also in relation to taking over "control" of the overall project, or potentially the reuse of some of its carefully designed internal components [START_REF] Capiluppi | Software reuse in open source: A case study[END_REF]. Therefore, this paper has three objectives: 1. To quantify the phenomenon of abandonment of OSS projects on the Source-Forge repository; 2. To investigate whether the abandonment of these projects should be linked with issues of maintainability of the source code itself; 3. To discuss the quality of the resources that were left behind for others to reuse or "upcycle."

The remainder of this paper proceeds as follows. Section 2 presents the research design. Section 3 presents the results of our study. Section 4 positions this study with respect to previous work in this area. We conclude in Section 5.

Research Design

Research Strategy

We adopted the Goal-Question-Metric approach as the overall research strategy [START_REF] Basili | The Goal Question Metric Approach[END_REF].

Goal. The overall goal of this study is to develop an understanding of the scale, nature and characteristics of abandonment of OSS projects. We defined two sub-goals: (1) to quantify abandonment of OSS projects, and (2) to evaluate the quality of the code that was left abandoned by developers.

Questions. This paper addresses the following research questions:

1. How many "active," "dormant" and "inactive" projects exist in SourceForge? 2. Do these categories achieve similar growth patterns? 3. Do these categories result in comparable quality and maintainability attributes?

Metrics and Definitions. We used the following metrics and definitions in this study:

-Category of projects: in this study we aim to produce three clusters of projects: the "active" ones, whose activity is updated and recent; the "dormant" ones, whose activity is visible in the past evolution, but it has stopped (for any reason) for a defined period (e.g., one year, two years, etc.); and the "inactive" ones, that have been explicitly tagged as such by the previous developers.

-Latest update: in this study we will extract the latest recorded activity for any Sourceforge project by parsing the specific dateUpdated tag on each project's summary page. -Inactive project: in principle, the inactivity of an OSS project should be evaluated by pre-defining an interval of time when no development effort is registered by its contributors, in terms of commits, messages on the mailing lists or public releases. The SourceForge repository places the specific < inactive > HTML tag 7 on the project pages that show no sign of activity. This could be either be directly communicated by a project's administrators (i.e., an "abandoned" project), or inferred from activity logs (i.e., an "inactive" project). The possibility of isolated inactive projects, and the availability of the source code, is one of the fundamental characteristics of OSS development, which allows new developers to take over and manage an abandoned project [START_REF] Capiluppi | Adapting the 'staged model for software evolution' to free/libre/open source software[END_REF]. where HV avg measures the average Halstead metric per module (function, method, class, file or the whole system), CC avg the average McCabe index per module and LOG avg the average lines of code per module.

-

Data Collection and Analysis

In this subsection we detail the steps undertaken to perform this empirical study.

1. SRDA database query: in order to have an initial list of all the projects contained in the SourceForge archive, we queried the SRDA database [START_REF] Gao | A research collaboratory for the open source software research[END_REF]. 8 In the data-dump of September 2012, the total number of SourceForge projects retrieved in the SRDA database is 174,845, and their unique names were recorded. 2. Status extraction: each of the project IDs was used to compose a URL relative to the SourceForge online structure. 9 The retrieved page contains a generic summary of the status of the project, along with information on its programming languages, the intended audience, the date of the latest update to the project and so on. The tag "inactive" was searched for all the projects, and a subpool of inactive projects was identified. This additional attribute is not available from the SRDA database, and it had to be specifically extracted. [START_REF] Capiluppi | Adapting the 'staged model for software evolution' to free/libre/open source software[END_REF]. Latest activity extraction: from the same summary page, we extracted, per project, the latest recorded date of activity, which is automatically copied by SourceForge from the list of activities of the project. 10 The information on the latest activity date served to discriminate between an "active" and a "dormant" project. If no activity was registered throughout the last year since the analysis (i.e., since November 2011), a project was categorized as "dormant" (instead of abandoned as proposed in [START_REF] Schweik | Success and abandonment in open source commons: Selected findings from an empirical study of sourceforge.net projects[END_REF]). As a result of this step, we obtained a subpool of active projects, and another subpool of dormant projects. The inactive projects, when their latest activity flagged them also as dormant, were discarded from the subpool of dormant ones, in order to have mutually exclusive subsets. 4. Sampling of projects: three equally sized samples of 25 projects each were randomly extracted from the three subsets of projects ("active," "inactive" and "dormant"), respectively. An SQL "random" statement was used to extract the three samples. Each of the projects in all the samples IDs was used to compose a URL relative to retrieve the relative code repository in the SourceForge online structure.11 5. Three-point selection: considering the number of revisions of a project, three data points were considered:

-Initial Point -IP : this point refers to the first revision that was committed into the code repository of the project; -Final Point -FP : the last available point in the evolution log, corresponding to the latest available revision N contained in the repository of the project;

-Middle Point -MP : considering the final point, the middle point is evaluated dividing by two the overall number of revisions N contained in the repository. In this way, we observed a system in three points not temporally, but logically equidistant. 6. Evaluation of size: the size of each project in the samples of the three categories ("active," "dormant" and "inactive") was evaluated using the sloccount 12 tool, that measures the physical lines of code (SLOCs) rather than the overall number of lines in a class, file or a whole system. The size was evaluated in the three points mentioned above (IP, MP and FP), and boxplots were produced to compare the growth in size of the projects in the different samples. 7. Calculation of the Maintainability Index (MI): the maintainability index (MI) can be used to evaluate single functions, classes, files, compounds (as packages, namespaces, etc.) and even a system as a whole. The general understanding of such index is that with an M I ≥ 85, the function or the compound can be considered to have a good maintainability; with an index 85 > M I ≥ 65 the compound has a moderate maintainability; while for a M I < 65 the compound should be considered as a difficult to maintain compound, signaling low quality pieces of code. In this work, the index was used to compare and contrast the projects within the abandoned sub-pool, and to evaluate the changes in such index when considering the evolution of the projects, before the abandonment, rather than as an absolute measure.

The MI was evaluated for all the systems in the three samples, and along the three points forming their life-cycles: an automated Perl script 13 from the Understand suite 14 was used to evaluate the MI of each compound, as well as the system-wide MI.

Results

As outlined in Section 2, we defined two sub-goals. The first, that of quantifying the abandonment of OSS projects, is addressed by research questions one and two listed in Section 2.1. Subsections 3.1 and 3.2 address these research questions, respectively. The second goal, that of evaluating the quality of the code left behind by developers is operationalized by research question three, and is addressed in Subsection 3.3.

A Classification of Project Activity Status

To address the first research question, How many 'active,' 'dormant' and 'inactive' projects exist in SourceForge?, we conducted a characterization of the pool of over 174,000 projects in SourceForge (as of November 2012), into three major clusters: "active," "inactive" and "dormant."

The inactive cluster was the easiest to evaluate: as reported in the sections above, the specific "inactive" tag was searched in each of the projects' summary pages. As depicted in Figure 1, the pool of SourceForge projects contains over 10,000 projects tagged as "inactive" by their own developers (as of November 2012). The inactive projects represents around 6% of the overall population of the hosted projects.

The "active" and "dormant" clusters of projects were evaluated more subjectively: given the date of sampling (DS) at 11/2012, and knowing the date of the latest activity (LA) for each project, at first it was decided to evaluate as "active" those projects whose latest update was within a year (i.e., 365 days) of the date of sampling, "dormant" otherwise. We used the formulas below:

LA -DS < 365 =⇒ active (2) LA -DS > 365 =⇒ dormant (3)
Using this approach, over 86% of Sourceforge projects were classified as "dormant," i.e., there is no recorded activity in their latest year on SourceForge. Only some 7% of projects have experienced an update within the last year. These initial three clusters are visible in the left part of Figure 1.

Using two years (i.e., 730 days) as a threshold for the latest activity, some 65% of projects were classified as "dormant," while some 28% were classified as "active" (that is, development occurred in the last two years). This second set of clusters are visible in the right-hand side of Figure 1.

These results form an updated picture of what is well known of OSS portals by researchers and practitioners: on the one hand, OSS portals tend to host an increasingly large number of projects. On the other hand, the large number of inactive and dormant projects has started to become an issue of space (i.e., should abandoned projects be erased from repositories?), as well as of credibility of the overall OSS community (i.e., are OSS projects doomed to failure?).

A further investigation of the inactive projects resulted in a clustering of three subsets: 1. Inactive "moved" projects: some of those projects were moved from SourceForge to their own servers, and were tagged as inactive (but "moved") to indicate to interested developers where to find the up-to-date releases or the repository that hosts the source code. The number of moved projects represents some 14% of the overall inactive projects. 2. Inactive "stale" projects: a larger portion of the inactive projects are additionally tagged as "stale" projects, therefore indicating to other interested Fig. 1. Clusters of "active," "inactive" and "dormant" projects in Sourceforge, using different thresholds (as of 11/2012) developers that the project is properly "dead" and it could benefit from further attention and development. 15 SourceForge makes sure also to record the date since when those projects were declared as "stale," which becomes an additional piece of information for the evaluation of such systems. Over 60% of the inactive projects are also categorized as stale, as shown in Figure 2. 3. Other inactive projects: the remaining 23% of the inactive projects provide no further information on specific details regarding when the project was declared inactive.

The remainder of the analysis in this paper focuses only on the projects which were appropriately tagged as "stale" by their developers, to produce a more thorough understanding of what sort of resources were left behind by the original developers for others to take over.

Growth Patterns Across Categories

The second research question was defined as: do these categories achieve similar growth patterns? As described above, three points were considered: the size of a project in its "first revision" under the versioning system (i.e., its initial point - IP); in its latest revision (i.e., its final point -FP); and in the revision midway between the first and the latest (i.e., its midway point -MP). The size of the systems was evaluated with the sloccount tool for the IP, MP and FP points. The size in SLOCs of the systems are shown, per point, in the Appendix section (Tables 2, 3 and4).

The distribution of size per project and point, and across samples was visualized using boxplot diagrams to take into consideration the distribution of very diverse projects in the same sample. The distribution per sample, and relative to the initial point (IP) is shown in Figure 3. The other boxplot distributions, albeit similar to the one reported below, are not displayed due to space limitations.

The boxplots in Figure 3 show that the distribution of size (in SLOCs) among the "active" projects is generally larger than the other samples ("dormant" and "inactive"). Such disparity is clearly visible (albeit not reported as a graph) also in the other analyzed points (MP and FP): the outliers of the dormant and inactive projects (shown in Figure 3) exacerbate the difference between few outstanding projects and the more general projects in the MP and FP points.

Despite the large variances (indicated by the whiskers and the outliers of Figure 3), we report the averages and medians of these distributions among samples and in the three points IP, MP and FP (Table 1). In both the average and median measurements, and across samples, the average system increases its size along the three points, but the average active system achieves a growth of 7 times (or 6 times for the medians) between the initial and final points of its growth. "Dormant" and "inactive" projects appear less distinguishable in what they achieve in their growth.

The results of the growth analysis suggest that there is a difference between the analyzed samples, hence between the described clusters: "active" projects begin as larger (in size) than both "dormant" and "inactive" projects, and they grow considerably larger than the other samples along their lifecycle. Whether or not a dormant project returns in an active state, the difference with active projects still persist. These differences in size will be evaluated in the next section by monitoring their maintainability indexes along the three selected points.

Quality and Maintainability Across Categories

The third research question defined in Section 2 was: do the categories result in comparable quality and maintainability attributes? The overall objective of this is to assess whether there is a difference in the quality of projects across the different categories (active, inactive and dormant).

In this section, the issue of quality is discussed by measuring and monitoring the Maintainability Index [START_REF] Oman | Construction and testing of polynomials predicting software maintainability[END_REF] of the projects composing the abandoned subpool. The index has been used several times in the past [START_REF] Fioravanti | Estimation and prediction metrics for adaptive maintenance effort of object-oriented systems[END_REF], especially to evaluate the effect of the index on the resulting maintenance needed, but the index has also been exposed to various criticism [START_REF] Heitlager | A practical model for measuring maintainability[END_REF].

Code quality is a multi-dimensional attribute that cannot be evaluated only by a static analysis, as the one that we performed and reported below. Nonetheless, the maintainability index (MI) offers an advantage over other low-level metrics and measurements (such as the Kemerer and Chidamber suite of objectoriented metrics, the cyclomatic complexity or others): such index can be used to evaluate single functions, classes, files, compounds (as packages, namespaces, etc.) but also whole systems.

In this study, MIs were used more to compare and contrast the projects within the samples, and to evaluate the changes in such index when considering the evolution of the projects, before the abandonment, rather than as an absolute measure.

The maintainability indexes for the projects composing the samples are reported in the right-hand side of Tables 2, 3 and 4 included in the appendix) for the IP, MP and FP points. In particular, we were interested in two aspects:

(1) whether the maintainability indexes are comparable across samples and categories; and (2) whether the projects in the "inactive" sample have clearly issues with their quality, reflected in low maintainability indexes.

Figure 4 shows the distribution of MIs within the samples in the initial point (IP, top of the figure) and of the latest available revision (FP, bottom of the figure). Two things can be observed: first, that the "active" sample shows a boxplot which achieves less variability between IP and FP (reflected in a more compact boxplot). Second, the difference between samples is not evident. The average scores in the maintainability indexes show that "active" projects are slightly higher than the other samples, but in general the samples seem to decrease their quality with their growth. This is more evident in those projects that achieve large changes of size (reflected in Tables 2, 3 and4).

The second aspect that was investigated was related to the relative change in overall maintainability between the initial and the final point of each project, and it was measured with a Delta, defined as:

Delta(M I) p = M I(f p) p -M I(ip) p M I(ip) p (4)
where M I(f p) p represents the maintainability index at the final point for project 'p' and M I(ip) p the MI in the initial point for the same project 'p.' No relative changes were recorded in proximity of smaller changes, i.e. when the Delta was less than 1%. If the Delta was positive, nil or the change was minimal, we put a in the last column of Tables 2, 3 and 4. If there was a substantial negative change, we recorded it with a X in the same column.

As shown in the tables, 14 projects in the "active" sample scored a positive change (or an equal score) between IP and FP in their MIs. On the other hand, 11 projects experience a substantial negative change in their MIs. The proportion of "dormant" projects with an increasing or stable MI to those with a decreasing MI is 16 to 9; the proportion for "inactive" projects is 17 to 8. This shows that the majority of "dormant" and "inactive" systems are left (or abandoned) with a similar or increased maintainability, in comparison to their initial status.

If the results were confirmed in a larger sample, or the whole population of inactive projects, the implications would be straightforward:

-From a developer's perspective, one would want to take over projects which are inactive, and that showed some degree of growth (otherwise they could be perceived as "toy systems" that were developed over a short time and abandoned soon after storing in an OSS repository); -From a commercial stakeholder's perspective aiming to participate in OSS development [START_REF] Capiluppi | Exploring the role of commercial stakeholders in open source software evolution[END_REF], the project to take over (or get involved in) should have a certain minimum degree of quality and maintainability. The MI could be a useful metric to show this quality of compounds, such as files, classes, modules and even the whole system, at various points of its evolution, and ensuring that the quality or maintainability was not compromised too significantly in its evolution. The MI may be a simple alternative to the plethora of more extensive evaluation methods and frameworks that have been proposed so far to evaluate open source products [START_REF] Stol | A comparison framework for open source software evaluation methods[END_REF].

However, further research is needed to investigate this in more detail and to confirm these findings.

Discussion

Comparison to Related Work

This study positions itself in the area of the categorization of OSS projects: the abandonment of OSS projects has been extensively studied in the past in [START_REF] Schweik | Success and abandonment in open source commons: Selected findings from an empirical study of sourceforge.net projects[END_REF][START_REF] Howison | The Perils and Pitfalls of Mining Sourceforge[END_REF] and in [START_REF] English | Identifying success and tragedy of floss commons: A preliminary classification of sourceforge.net projects[END_REF][START_REF] Capiluppi | Characteristics of open source projects[END_REF], firmly establishing that the vast majority of OSS projects suffers from the "abandonment tragedy." What the present study contributes is an understanding of how developers are currently handing over projects to others, by means of signaling the inactivity of their projects through a specific tag. Also, different from other studies, we did not try to predict the inactivity or projects based on specific coding characteristics (such as languages, application domain, and so forth), but we used readily available identifiers to infer a project's inactivity.

The maintainability of OSS packages has been studied, in a slightly different formula by Samoladas et al. [START_REF] Samoladas | Open source software development should strive for even greater code maintainability[END_REF], and was also reproduced with OSS projects by Heitlager et al. [START_REF] Heitlager | A practical model for measuring maintainability[END_REF]. Rather than analyzing single compounds, we have used the MI as a system-level metric, but without inferring quality or maintainability in an absolute way, rather pointing at a relative change between points of the evolution.

Existing studies on the maintainability of OSS projects have shown that evolving software tends to decrease its quality and maintainability [START_REF] Bakota | A cost model based on software maintainability[END_REF][START_REF] Schach | Maintainability of the Linux Kernel[END_REF]. We found that this is not necessarily true, given a pool of projects and analyzing their growth of lines of code and maintainability indexes.

Maintainability studies have been performed also to predict the quality of OSS projects using well-known design metrics [START_REF] Zhou | Predicting the maintainability of open source software using design metrics[END_REF]: using the MI metric as a response, and object-oriented metrics (such as the depth of inheritance tree, average response per class, etc.) as input factors, it was found that OSS projects written in Java show a dependency between the MI and the control flow of the program itself, hence validating the MI as a metric for maintainability. We used this result to acknowledge the value of MI as a metric.

Finally, it has been noted that studies of maintainability in the OSS domain are flawed by the quality of data that is available for investigation [START_REF] Yu | Measuring the maintainability of open-source software[END_REF]. Given the number of resources that OSS projects make available (change logs, mailing lists, source code, etc.), and the diversity in quality in each source, it becomes inevitable to avoid a strict comparison between projects to assess which one has more quality. What we produced in this study was rather an assessment, per project and not inter-project, of how these quality measurements change, and how to interpret them.

Limitations of this Study

We are aware of a few limitations of this study, which we discuss next. Since we have not studied any causal relationships, we do not discuss threats to internal validity.

Construct validity refers to the extent to which a concept is correctly operationalized, i.e., whether the researcher is measuring what he or she meant to measure. In particular, a key construct that we operationalized is abandonment of OSS projects, for which we defined three categories: active, dormant, and inactive. We relied on (ex-)maintainers of OSS projects who have indicated their projects to be inactive, using the inactive tag; active and dormant projects were distinguished by measuring the latest activity for each project (see Section 3). As shown in Fig. 1, results depend on how the terms "active" and "dormant" are operationalized.

Growth of OSS projects was another construct that we measured, which we operationalized using source lines of code (SLOC) as a metric. We believe that SLOC is the most useful metric to measure size, as it is source code that developers are dealing with. (For that reason, measuring size using memory footprint or number of files or classes, to mention two alternatives, is less useful). Important here is that we only measured the projects at three points: the initial point (size of first revision in the source repository), the final point (last revision in the source repository), and the middle point which is logically positioned between IP and FP.

External validity refers to the extent to which a study's findings can be generalized, or in which other settings the findings are valid. While the results of the classification of SourceForge projects into clusters has been performed on all in the SourceForge repository, we extracted three samples (size 25) that were randomly chosen from the three sets of projects (active, dormant and inactive). While the samples were chosen at random (using SQL's random statement), a different and larger set of samples may result in a different set of findings. Replication and extension of this study should be performed so as to overcome this limitation.

Reliability of a study refers to the degree to which a study can be repeated while attaining the same results. In this paper, we have provided an extensive description of the research method and operationalization, as well as pointers to relevant sources and tools. This description can help other researchers to replicate or extend this study using the same methodology. While results of one study can be "revelatory," research results need to be replicated and confirmed with other studies and research methods, so as to triangulate findings.

Conclusion and Future Work

This paper positioned itself in the practice (and duty) of OSS developers to hand off their project to other developers when they lose interest in its further development. The study started off by clustering the population of SourceForge projects into three clusters, using both objective (i.e. the "inactive" tag that can describe an OSS project), and subjective indicators (i.e., the amount of days that a project remains without updates) to draw an updated picture of the status of the projects on one of the largest OSS portals. We isolated projects that are inactive because they have been moved to another portal, and other projects that have been classified as "stale," and therefore properly abandoned by the original developers. We further identified as "dormant" those projects whose latest date of activity was over a year from the date of the analysis (November 2012). Projects with updated activity were characterized as "active."

Using a sample of "active," "dormant" and "inactive" projects, we investigated whether differences could be detected in terms of the projects' overall growth: we found that "active" projects start generally as larger than "dormant" and "inactive," and that they grow consistently larger than the other two clusters.

Finally, we investigated whether projects in the different categories show differences between them by using the maintainability index (MI): we selected this metric since it produces a useful system-wide measurement, ensuring not to use it as an absolute measure, but rather observing its relative change. The study revealed that the majority of "inactive" projects' MIs increase or remain stable. This result is important for other developers and potential commercial stakeholders to evaluate whether a project is worth taking over, or whether its quality has degraded excessively.

We identified a number of potential research directions for future work. Firstly, this study should be replicated on a larger sample of projects, so as to confirm these results, which will help in improving the generalizability of these findings. Secondly, whether or not the maintainability index is a useful metric to reflect the quality of an open source project as perceived by commercial stakeholders remains an open issue. While this paper presents quantitative results, we believe that triangulation of these results through qualitative studies would be the next step so as to increase the confidence in the findings presented in this paper.

Fig. 2 .

 2 Fig. 2. Distribution of inactive projects in SourceForge (as of 11/2012)

Fig. 3 .

 3 Fig. 3. Boxplots of size (in SLOCs) across samples, initial point (ip)

Fig. 4 .

 4 Fig. 4. Boxplots for the maintainability indexes across samples, initial point (IP, top) and final point (FP, below)

  Number of lines of code (LOC) measures the physical size of the program code, excluding blank lines and comments.

	-Percentage of lines of comments with respect to the number of lines of
	code (PerCM) describes the documentation and self-descriptiveness of the
	code.
	-Halstead Volume (HV). Halstead [10] defined four metrics that can be
	measured from a program's source code: n1 (the number of distinct oper-
	ators), n2 (the number of distinct operands), N1 (the total number of op-
	erators) and N2 (the total number of operands). Based on them, Halstead
	defined program vocabulary n (given by n = n1 + n2) and program length
	N (given by N = N1 + N2). Finally, he defined Volume, a composite metric
	given by the formula V = N * (LOG2n). -Cyclomatic Complexity (CC). Proposed by McCabe [13], this metric
	counts the number of independent paths in the control flow graph of a pro-
	gram component. Its value depends on the number of branches caused by
	conditional statements (if-then-else). It measures the structural complex-
	ity of the component.
	-Maintainability Index (MI): based on the definitions above, the Software
	Engineering Institute (SEI) has developed a maintainability index defined
	as follows:
	171-5.2ln(HV avg )-0.23CC avg -16.2ln(LOC avg )+50.0sin √	2.46COM (1)

Table 1 .

 1 Size growth in the sample of "active," "dormant" and "inactive" projects -Average and median values (in SLOCs)

	Average	IP	MP	FP
	Active	7,680	24,486	50,189
	Dormant	5,585	12,361	16,862
	Inactive	4,056	7,775	15,014
	Median	IP	MP	FP
	Active	4,789	12,361	20,217
	Dormant	1,114	3,047	4,520
	Inactive	720	2,163	3,267

Table 2 .

 2 Size growth and maintainability indexes in the sample of "active" projects

			SLOCs		Maintainability Index
	Project ID	IP	MP	FP	IP	MP	FP	∆ ≥ 0?
	adirectoryimp	10,818 11,918 12,202	152.43 156.34 156.06
	Cw-evolver	2,449 4,147 5,994	120.73 123.63 131.53
	eid2ldap	444	5,697 7,606	122.75 139.79 134.35
	Enrich-ege	780	139,857 88,878	170.17 141.71 141.6	X
	eps2pgf	2,372 8,014 19,315	153.13 153.11 155.68
	fenixweb	8,555 8,777 9,817	138.95 140.35 140.31
	flugbuchz	12,313 5,941 47,587	137.33 134.87 135.85	X
	fluidcubed	749	774	887	132.35 144.72 144.55
	foxtrot	450	2,161 5,156	143.28 140.03 137.59	X
	ieplugin4rm	14,071 18,619 25,355	144.58 144.72 140.68	X
	javajson	318	2,620 3,345	95.83	138.65 137.84
	loconetovertap 557	5,107 9,622	145.57 140.97 129.66	X
	micepfl	6,812 39,458 47,716	122.5	137.23 135.26
	midiagentsystem 4,789 9,007 13,329	145.81 141.66 140.92	X
	mythtvplayer	9,545 11,700 20,217	133.07 132.23 133.27
	oswing	31,476 64,856 128,879	145.53 143.62 144.64
	quartica	17,086 12,205 101,063	154.78 149.78 137.09	X
	rcpforms	1,861 22,039 74,036	161.3	139.66 137.62	X
	resteasy	2,220 79,237 151,681	180.08 155.32 151.46	X
	spl	35,488 55,560 257,447	125.08 151.88 135.24
	vizkit	6,444 9,542 40,130	142.37 139.2	141.01
	xith3d	5,658 51,062 122,811	169.66 153.38 153.62	X
	xmms2-qtcli	1,157 2,074 2,486	138.65 126.97 124.68	X
	yaco	15,397 41,445 58,550	96.88	116.34 112.82
	zmkk	201	325	605	104.68 115.7	116.22

Table 3 .

 3 Size growth and maintainability indexes in the sample of "dormant" projects

			SLOCs		MaintainabilityIndex
	Project ID	IP	MP	FP	IP	MP	FP	∆ ≥ 0?
	build-status	1,075 1,075 1,572	154.73 154.73 153.59
	dbtoolbox	7,146 8,541 9,214	161.47 160.14 159.95
	dekware	45,693 46,181 46,644	113.36 113.36 111.79	X
	dynolab	190	553	841	146.22 178.44 170.14
	emfincpp	260	1,229 3,226	154.24 154.53 154.53
	fit7h-projects	66	192	201	143.08 124.21 123.98	X
	gcts	1,114 1,611 642	148.75 147.92 155.48
	gerber2eps	1,201 9,616 9,652	135.62 126.74 127.1	X
	hemus	14,229 88,665 139,147	111.36 104.78 99.24	X
	jrdesktop	6,206 11,327 12,104	127.46 139.36 138.63
	libnary	9,159 9,792 10,059	86.01	90.92	89.82
	llads	381	46,843 56,182	114.81 124.15 124.22
	msgtext	253	4,431 4,520	111.97 135.17 135.02
	nexplorer	18,111 19,574 19,523	142.06 149.51 150.54
	numenor	348	1,981 2,734	135.55 138.92 142.37
	osgmaxexp	4,229 6,632 8,448	139.94 140.55 137.48	X
	overflowandroid 308	5,140 2,055	111.18 112.16 86.18	X
	psimpl	4,051 3,047 10,283	133.69 133.7	127.28	X
	siprop	21,429 68,828 108,816	153.39 158.3	158.41
	svnauthzctl	905	941	1,075	83.65	82.65	82.95
	tbltools	1,804 2,949 5,688	145.66 140.11 146.52
	vmatrixlib	1,048 1,108 1,377	139.98 148.04 146.3
	yahoofinanceapi 1,288 1,834 2,339	138.09 142.41 148.17
	ybwopenpilot	820	1,729 1,949	161.9	156.33 153.98	X
	zcommons-mojos 454	800	1,212	140.05 130.82 130.82	X

Table 4 .

 4 Size growth and maintainability indexes in the sample of "inactive" projects

			SLOCs		Maintainability Index
	Project ID	IP	MP	FP	IP	MP	FP	∆ ≥ 0?
	aesop-server	489	489	489	128.12 128.12 128.12
	arduinoforum 508	576	1,426	124.42 123.03 112.33	X
	artgarden	1,990 2,349 2,649	132.97 133.39 130.96	X
	carjam	2,484 2,495 3,267	153.72 153.54 147.18	X
	cgiscaler	42,901 29,488 58,958	135.67 135.9	137.47
	cherrygis	9,374 9,510 10,436	135.19 135.46 138.24
	csamegame	2,753 2,753 2,753	129.06 129.06 128.69
	cuatroenraya 189	342	1,190	128.99 127.88 115.77	X
	doubles	1,028 3,857 6,130	107.31 132.27 124.25
	foobar1914	665	1,051 1,904	139.89 167.5	169.52
	gimp-vs	1,536 6,073 151,164	107.48 118.58 125.27
	icbor	576	7,907 3,488	116.74 140.23 139.76
	icepidgen	921	919	13,061	180.88 181.01 144.27	X
	icerp	577	2,163 4,763	146.57 159.44 148.71
	javimojamucho 154	704	1,457	144.43 145.74 160.45
	jnetclip	285	285	285	135.39 135.39 135.39
	kino	7,328 93,385 81,883	123.13 122.63 127.73
	minigames	428	428	404	87.96	87.96	90.35
	pycdk	104	152	152	88.32	131.74 131.74
	tankz	634	705	848	139.15 135.03 139.05
	timeedition	10,532 10,532 10,532	156.66 156.66 156.66
	tuxnotebook	12,353 12,375 9,903	117.96 117.9	114.31	X
	unlesbar	720	1,974 3,713	159.78 155.53 152.72	X
	utopicengine	2,710 2,947 3,370	136.7	141.58 141.19
	webappservicefi 151	913	1,136	144.11 129.09 129.09	X

As an example, the Moodle CMS was moved from SourceForge to its own dedicated repository, after they have "outgrown it."

http://sourceforge.net

See for instance the main page of the busiprocess project, http://sourceforge. net/projects/busiprocess/.

The process is detailed, for the SourceForge repository, at http://sourceforge. net/apps/trac/sourceforge/wiki/Abandoned\%20Project\%20Takeovers.

The table that lists the projects is named trove agg.

The homepage of any Sourceforge project 'p' hosted appears in the form http: //sourceforge.net/project/p.

This is coded within the summary page of each project and marked with the <dateUpdated> tag.

The repository of any Sourceforge project 'p' can be found under their "develop" page under http://sourceforge.net/project/p/develop, and marked with the <code> tag.

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

Available at http://scitools.com/plugins/perl_scripts/acjf_maint_index_ halstead.pl

Understand by Scitools, http://scitools.com/index.php

For instance, by being developed in a parallel branch onto another OSS repository as GitHub, as anecdotally reported in http://www.quora.com/ What-is-the-appeal-of-GitHub-com

Acknowledgements. The authors would like to thank Dr Angela Lozano for

the feedback on an early draft of the paper. This work was supported, in part, by Science Foundation Ireland grant 10/CE/I1855 to Lero-the Irish Software Engineering Research Centre (www.lero.ie).


M M Mahbubul

Imed Hammouda
email: imed.hammouda@tut.fi

Socio-Technical Congruence in OSS Projects: Exploring Conway's Law in FreeBSD

Software development requires effective communication, coordination and collaboration among developers working on interdependent modules of the same project. The need for coordination is even more evident in open source projects where development is often more dispersed and distributed. In this paper, we study the match between the coordination needs established by the technical domain (i.e. source code) and the actual coordination activities carried out by the development team, such hypothetical match is also known as socio-technical congruence. We carry out our study by empirically examining Conway's law in FreeBSD project. Our study shows that the congruence measure is significantly high in FreeBSD and that the congruence value remains stable as the project matured.

Introduction

Investigating socio-technical congruence in software development projects has become an active research area in the last decade [START_REF] Kwan | Conway's Law Revisited: The Evidence for a Task-Based Perspective[END_REF]. Socio-technical congruence can be defined as the match between the coordination needs established by the technical domain (i.e., the architectural dependency in the software) and the actual coordination activities carried out by project members (i.e., within the members of the development team) [START_REF] Bendifallah | Work Structures And Shifts: An Empirical Analysis Of Software Specification Teamwork[END_REF]. This coordination need can be determined by analyzing the assignments of people to a technical entity such as a source code module, and the technical dependencies among the technical entities [START_REF] Bendifallah | Work Structures And Shifts: An Empirical Analysis Of Software Specification Teamwork[END_REF]. Socio-technical congruence not only has been used as a measure for a number of project properties such as software build success [START_REF] Raymond | The new hackers dictionary[END_REF] but also as a means for software engineering tasks like architecture recovery [START_REF] Bowman | Software Architecture Recovery Using Conway's Law[END_REF].

In most of research on socio-technical congruence, Conway's law [START_REF] De Souza | Supporting collaborative software development through the visualization of socio-technical dependencies[END_REF] is often presented as a guide and a basis for the underlying study. Conway's Law in its purest form states that "the organizations that design systems are constrained to produce systems which are copies of the communication structures of these organizations" [START_REF] Conway | How Do Committees Invent?[END_REF]. In other words, the product architecture often reflects the organizational structure of the development team [START_REF] Conway | How Do Committees Invent?[END_REF] [START_REF] Bendifallah | Work Structures And Shifts: An Empirical Analysis Of Software Specification Teamwork[END_REF]. In [START_REF] Jongdae | Extracting Development Organization from Open Source Software, 16th APSEC[END_REF], Conway's law is considered homomorphic and thus claimed to be true in reverse as well. This means the communication pattern within developer community should reflect the architectural dependency in the software. Thus, the notion of socio-technical congruence is actually a conceptualization of Conway's law.

Studying socio-technical congruence in open source software has its own questions and hypotheses, for those products are peer-produced, crowdsourced systems where centralized planning and control of architecture is difficult. Furthermore, the evolution of such systems, and their underlying architecture, is not bound to any pre-defined plans [START_REF] Scacchi | Understanding the requirements for developing open source software systems[END_REF]. Surprisingly, this research area has not been given much attention among open source researchers [START_REF] Bolici | Coordination without discussion? Sociotechnical congruence and Stigmergy in Free and Open Source Software projects[END_REF].

In this paper, we study Conway's Law and Reverse Conway's Law, as a lens for socio-technical congruence, in the context of open source development projects by proposing a novel evaluation and measurement technique. We further explore the significance of socio-technical congruence as the project matures. To investigate our research problem, we focused on a popular open source project, FreeBSD, which is an advanced operating systems for computing platforms. We carried out our study empirically by analyzing the software repository of the project in a semi-automatic way.

The remaining of the paper is organized as follows. Section 2 introduces a number of key concepts that this study uses. Motivation and related work is presented in Section 3. We then introduce the research questions explored in this paper and our study design in Section 4 and 5 respectively. Results are reported and discussed in Section 6. Possible limitations and threats to validity are highlighted in Section 7. Finally, Section 8 concludes the papers and shed light on future research.

Definitions

In this paper we interpreted Conway's law (and reverse Conway's law) as a measure to verify the extent to which the communication pattern of the contributing members is due to the communication needs established by the concrete architecture and vice versa. In examining this the following concepts are defined.

Developer Contribution

Developer contribution to the software can be defined as the code contribution or any form of commit made to the code base.

Concrete Architecture

Concrete architecture of a software presents the relationship among components of a software (e.g., modules, files or packages) based on the actual design and implementation. In this work, header file inclusions dependency at code file level were used to derive the concrete architecture. In this architecture two files, and their corresponding packages, were linked if the two files have an inclusion dependency.

Concrete Coordination Network

Concrete Coordination Network is a social network in which two developers have a relationship if they have communication history as seen by the mailing archives representing the social and technical interactions among the developers.

Derived Architecture

Derived architecture defines an architecture of the software where any two components (e.g., packages or code files) are related if there are developer(s) who have either (a) contributed to both the components, or (b) have communication at organizational level (e.g., through email). For instance consider that developer D1 has contributed to packages P1 and P2, and developer D2 has contributed to package P3. Also consider that both developers has communication at organizational level as shown in Fig. 1(a). Thus according to the definition, packages P1, P2 and P3 are linked to each others in the Derived Architecture (Fig. 1(b)).

Motivation and Related Work

In this section we discuss the significance of Conway's law and socio-technical congruence in the field of software engineering citing related works from existing literature. Conway's law was stated 30 years ago by Melvin Conway as the means to emphasize the need of coordination in software development [START_REF] Conway | How Do Committees Invent?[END_REF]. Until then researchers have long argued that the mirroring effect of the software architecture and the communication pattern of the developer community plays a pivotal role in coordinating the development work [START_REF] Nagappan | Architectures, Coordination, and Distance: Conway's Law and Beyond[END_REF]. A central question arises "Does Conway's law matter in the modern era of software development?". As reported in [START_REF] Kwan | Conway's Law Revisited: The Evidence for a Task-Based Perspective[END_REF], Conway's law still matters in the domain of software development and the product quality is strongly affected by the organizational structure [START_REF] Brooks | The Mythical Man-Month, Anniversary Edition[END_REF]. Also with the advent of global software engineering where development teams are distributed across the world, the impact of organizational structure on Conways law and its implications on quality is significant [START_REF] Nagappan | The influence of organizational structure on software quality: an empirical case study[END_REF].

In the domain of software engineering, socio-technical congruence as a conceptualization of Conway's law was first coined in [START_REF] Cataldo | Identification of coordination requirements: Implications for the design of collaboration and awareness tools[END_REF]. In this paper, sociotechnical congruence was employed as a fine-grained measure of coordination that can be used to diagnose coordination problems in the development team. Also, evidence from studies [START_REF] Cataldo | Identification of coordination requirements: Implications for the design of collaboration and awareness tools[END_REF] shows that higher congruence leads to faster completion of modification requests. This concept has been identified as an important element for product design in the field of engineering [START_REF] Browning | Applying the design structure matrix to system decomposition and integration problems: a review and new directions[END_REF] and management science [START_REF] Sosa | The misalignment of product architecture and organizational structure in complex product development[END_REF] as well. Researchers also argued that such congruence is a natural consequence and a desired property for collaborative development activities [START_REF] Browning | Applying the design structure matrix to system decomposition and integration problems: a review and new directions[END_REF], such as software engineering.

Socio-Technical Congruence and OSS Development

In the epoch of OSS projects, there exists a significant number of successful software systems whose volume and complexity are as compound as that of their proprietary counterparts. Such large and successful OSS projects often consist of hundreds and even thousands of developers contributing to the development of the project. Developers working in such projects are not strictly bound to any organizational rules, regulation and structure. Rather they voluntarily join and contribute to the project. OSS developers belong to discrete geographical locations of significant background, timezone, language and cultural distances. Often an OSS project is developed and evolved through the collaboration among the developers using simple communication media like email, wiki, chat [START_REF] Yamauchi | Collaboration with Lean Media: How Open-source Software Succeeds[END_REF] as well as revision tracking systems (such as CVS, SVN) to store and access the software code they produce [START_REF] Fogel | Open Source Development with CVS: Learn How to Work With Open Source Software[END_REF].

This unconventional organizational structure and practices of OSS projects combing with the inherent complexity of the software development (as discussed above) brings forth the question, "why such projects succeed and can sociotechnical congruence be conceived as an implicit driving force for such success?". Surprisingly, socio-technical congruence as a research area has not been given much attention among open source researchers. In this paper, we infer that socio-technical congruence is an endogenous driver for successful OSS projects, and examines its existence in OSS project though empirical evidences.

Research Questions

Our research objective in this paper is to study the applicability of Conway's law as a means of verifying the socio-technical congruence on large, distributed and evolving OSS projects. In great part because of the specific characteristics of the OSS projects and yet having revolutionary success, it is most likely that the OSS development process implicitly encompasses the notion of sociotechnical congruence. Thus, we targeted the following research questions.

(a) How does the communication patterns of OSS developer community resemble the architecture of the software?

Conway's law can be interpreted as the first explicit recognition that the communication pattern of the organization has an inevitable impact on the product [START_REF] Herbsleb | Splitting the Organization and Integrating the Code: Conways Law Revisited[END_REF]. Thus there must exist a correspondence between the community structure and the software structure. Our point of interest here is that if such homomorphic force between the software model and its development organization exists in OSS projects, then it could be effectively used to conceptualize the architecture of legacy systems. It can also be used as a metric to assess the quality and maintainability of the system as well.

(b) How does the architecture of the software resemble the collaboration patterns of OSS developer community?

Conway's law pointed out [START_REF] Conway | How Do Committees Invent?[END_REF] that only the organizational arrangements can be optimized with respect to the system concept. This observation enforces the need for a stable and modular design of the system in order to facilitate effective communication, coordination among the developers. With geographically distributed development setup, as in OSS projects, co-ordination becomes more challenging due to location, time, and cultural differences, and the need for a stable design becomes even more evident [START_REF] Nagappan | Architectures, Coordination, and Distance: Conway's Law and Beyond[END_REF]. For this kind of organizational setup, a clearly separable and stable architectural design would be the basis for assigning task to the developers [START_REF] Nagappan | Architectures, Coordination, and Distance: Conway's Law and Beyond[END_REF] and a key to the success of the project. In other words, the collaboration pattern of the developer community should mirror the architecture of the software which should remain stable during the evolution of the project.

(c) Does the socio-technical congruence evolve as the project matures?

Our intension is to examine how the socio-technical congruence evolves as the project matures. We are particularly interested in deriving any visible pattern of such congruence during the evolution. But relating such trends in congruence in OSS projects with its success parameters are out of the scope of this study.

Study Design

Case and Subject Selection

To investigate our research questions, we focused on a popular open source project, FreeBSD, which is an advanced operating system for modern server, desktop, and embedded computer platforms [24]. It is derived from BSD, the version of UNIX developed at the University of California, Berkeley. Selection of this project as a case study was influenced by the facts that FreeBSD's code base has undergone continuous development, improvement, and optimization for thirty years [24]. The project has been developed and maintained by a large team of individuals. Also, FreeBSD has gained considerable attention in earlier research on the evolution of OSS projects [START_REF] Jingwei | Empirical Evidence for SOC Dynamics in Software Evolution[END_REF] [17] [START_REF] Herraiz | On the prediction of the evolution of libre software projects[END_REF].

Data Sources

In literature [START_REF] Kwan | Conway's Law Revisited: The Evidence for a Task-Based Perspective[END_REF] a great emphasis was given to leveraging software repositories along with the communication data for deriving technical dependencies as well as developers coordination patterns. In OSS projects, repository data is stored and maintained through different data management systems, e.g., source code repository (SVN or CVS), change logs, mailing archive, bug reporting systems, and communication channels. These data sources are highly accepted and utilized medium for empirical studies on OSS projects [START_REF] Mathieu | A framework for analyzing and visualizing open source software ecosystems[END_REF][26] [START_REF] Wang | Measuring the Evolution of Open Source Software Systems with their Communities[END_REF]. In FreeBSD project, the development and communication history is maintained through SVN repositories and mailing archives. Following is the description of these sources and the data extracted for this study.

1. Source code repository: FreeBSD has two release branches, stable and production releases. In this study, SVN repositories of the stable releases were collected. Fig. 3 provides detail of these stable releases and the data collected from each release. 2. Mailing list archive: In OSS projects, email archives provide a useful trace of the task-oriented communication and co-ordination activities of the developers during the evolution of the project [START_REF] Zhang | Network Analysis of OSS Evolution: An Empirical Study on ArgoUML Project[END_REF]. In the FreeBSD project, email archives are categorized according to their purpose. For instance, there are email for project development (e.g., commits), stable release planning, chat, user emails, bug reports. These archives contain all mailing lists since 1994 and are updated every week [24]. Fig. 4 provides detail on the FreeBSD email archives that were extracted for this study. These email archives contain the detail of the commit records made for each stable release and are only used by the developer community. These archives thus give more accurate history of contributions than the bug reporting system which is often used by the the passive users for different purposes.

Data Collection Procedure

Data collection from source code repositories: Each stable release of the FreeBSD project was downloaded from the SVN repository to the local directory. Fig. 3 lists the stable releases and associated detail of each release.

To extract data from each of these releases, a parser was written in Java. This parser searched through each directory of a stable release, read through the files in a directory and parsed relevant data. The data that were parsed from each file were listed in Fig. 3. As FreeBSD was written in C and C++, included header files were identified from the #include directive in each code file. The parser excluded all the library header files and kept only the user defined header files. Also the copyright directive in a file contains information of the developer name, email and the copyright year. The parser extracted each of these information from the copyright directive. The developers that were found in this process were considered as the contributors to that file for that stable release. The parsed data for each stable release was stored in excel files. To read/write excel files Apache POI [START_REF]Apache POI-Java API for Microsoft Documents[END_REF] was used. The number of code files and packages read from each stable release was shown in Fig. 3.

Data collection from email archives:

The email archives that concern CVS/SVN commits and general discussions (e.g., on stable releases and the chat entries) were extracted from FreeBSD email archive as shown in Fig. 4. For extracting data from each email entry, a data extraction program was written in Java. This data extractor used the web interface of the email archives (link is provided in Fig. 4). Thus each email was read as an HTML page and the data was extracted using Jsoup html parser [START_REF]jsoup: Java HTML Parser[END_REF]. Data that was extracted from each email entry is listed in Fig. 4. This data was then stored in excel files according to the archive name and year. Then the email data was sorted according to each stable release as follows: (a) emails were categorized into a specific release if the release number was mentioned in email subject (e.g., SVN commit emails provide release number in email subject) and (b) other emails (e.g., freeBSD-stable, freeBSD-chat and most of the CVS commit emails) for which the release numbers were not mentioned, the posting dates were checked. In this case, for instance, an email was categorized to stable release 3 if its posting date fall between the release date of stable release 2 and 3. The rationale here is that developers would commit to the code base and discuss on its release strategy before it is officially released.

After categorizing emails to each stable release, the subject of a CVS/SVN commit email was parsed. This subject mentioned the path to the repository to which the commit was made. From this subject, the directory path, package name, and if provided, the name of the modified code file and the stable release number were identified. Sender name for each of these CVS/SVN commit email was considered as a contributor to the code base for that release. Contributors found in this process were combined with the contributors found from the code base to get list of developers who contributed to each stable release. Fig. 5 lists release wise distribution of the number of developers and email entries identified through this process. Data preprocessing: Data that was extracted and parsed following the above process contained anomalies data in many cases. For instance, developer names and email addresses might contain punctuation characters like, semi-colons, inverted comas, brackets, unnecessary white space, and hyphens. Furthermore, parsers may parsed data inappropriately in some cases. For example, copyright text "All rights reserved" can be treated as part of developer name while parsing copyright directive from a code file. To clean such anomalies data and punctuation characters, data cleaning programs were written in Java. To ensure the correctness of this process, we performed a manual checking on a randomly selected data to verify their correctness.

Analysis Procedure

This section discussed the methods used to construct the communication networks, architectures and to measure socio-technical congruence (defined in section 2) utilizing the data collected from the FreeBSD project.

Developer Contribution: Release-wise developer contribution was measured in two ways, (a) from the copyright information provided in each source code file of a release and (b) from the commits made by a developer for a release. Fig. 6(a) shows a sample contribution made by developer John Birrell in stable release 3.

Concrete Architecture:

The concrete architecture of a stable release was constructed based on header file inclusion dependency as defined in section 2.2. This inclusion dependency relation was used in earlier works [START_REF] Dayani-Fard | Improving the build architecture of legacy C/C++ software systems[END_REF] [START_REF] Kazman | Playing Detective: Reconstructing Software Architecture from Available Evidence[END_REF] to construct architecture of legacy C/C++ software systems.

Then higher level abstraction of this architecture was built to get the package level concrete architecture. In this architecture, package p1 and p2 had a relationship if file f1 in package p1 had an inclusion dependency with a file f2 in package p2 or vice-versa. Relationship between packages were weighted which Thus this network shows the actual communication need among the developers which is based on the design of the software (i.e., the concrete architecture). This network is essential due to the fact that if two subsystems are to communicate, it is likely to have communication between the developers of the two subsystems [START_REF] Conway | How Do Committees Invent?[END_REF]. The former congruence illustrates the match between the architectural dependency and the architecture produced due to the communication structure of the community. And the latter congruence depicts the match between the actual coordination activities in the community and the coordination need established by the architectural dependency of the software. To be precise, these congruences verify Conway's law and the reverse Conway's law, respectively. Both form of congruences were determined for each stable release. A partial snapshot of the congruence between Concrete and Derived Architectures of stable release 3 is shown in Fig. 9.

To construct the networks and architectures and to measure socio-technical congruence and Conway's law, Java programs were written.

Result Interpretation: To measure the extent to which Conway's law holds for each stable release of the FreeBSD project, percentile value was calculated for (a) the congruence value and the corresponding Concrete Architecture, and (b) the congruence value and corresponding Coordination Network. These percentile values were plotted in a graph against the stable releases to conceptu-

Results

Resemblance of Communication Pattern to Software Architecture

Our study target in this work was to verify the extent to which the communication patterns of the members of the developer community resembles the actual architectural dependencies. To achieve this, we collected historical data from the FreeBSD project and measured such resemblance for each stable release. The resemblance process consists of determining the concrete architecture and derived architecture for each stable release. Then, the congruence between the two architectures and corresponding percentile measure of Conway's law for each release was measured. The result of this process is reported in Fig. 10. Column 2 and 3 in this figure show the number of relations between packages identified by the respective architectures. The congruence relationships and the percentile value for each release indicate the extent to which the two architectures of the software overlap with each other. Here the percentile value is measured between the congruence and the concrete architecture, because the intension is to measure the extent to which the derived architecture approximates the concrete architecture.

The percentile values suggest that around 76% to 82% overlap between the two architecutres are found from stable release 3 onward. Whereas for the earlier three releases it is between 66% to 73%. It is worth to mention here that we noted considerable drift in the congruence value for the first three releases of the FreeBSD project. Thus we excluded them from our observation, considering this period as a restructuring and reformation period of FreeBSD after being forked. However, this observation is a positive sign towards the sociotechnical congrucence, and can be an implicit charactersitcs of OSS development process. From this result, we can safely say that to a considerable extent the Fig. 10. Resemblance of communication pattern to software architecture communication of the contributing developers in the community is actually due to the coordination need as identified by the architectural dependency. Now the question is, does the derived architecture actually resembles the concrete architecture, and can it be used to recover the architecture of the legacy software? By examining Fig. 10 it is evident that the derived architecture is overestimating the concrete architecture for all the releases. For instance, in stable release 4, the derived architecture identifies 153 relations among the 19 packages, whereas concrete architecture shows only 49. Thus, it is not possible to resemble the concrete architecture from the derived architecture. Yet, the following observation can be offered.

To a great part, the communication pattern of the contributing members within the community is due to the communication needs established by the concrete architecture.

The interdependency among the packages in the concrete architecture influences their contributors to communicate at community level. This supports the existence of Conway's law within the FreeBSD development process. None-theless, both the architectures overlap considerably. Thus the derived architecture can be used in authenticating the architecture recovered by traditional reverse engineering process.

This over estimation by the derived architecture can be justified in a way that this architecture was derived from the communication record of their contributing developers. And the developers in the community can communicate and collaborate on issues that might be outside of the scope of the actual code implementation and commits. For instance, FreeBSD-chat archive collects only the email threads related to the general discussion. These discussions generate additional relationships among the contributing developers which were not due to only common contribution. In the derived architecture these relationships create additional links between the packages. Yet it can also be possible that some of the links between packages in the derived architecture reflect valid re-lationships for the release, as the concrete architecture might not identify all the links that actually exists for that release.

Resemblance of Software Architecture to Communication Pattern

Conventional wisdom supports that the socio-technical congruence measured in reverse (i.e., reverse Conway's law) should hold as well. That is the communication pattern identified by the concrete architecture should simulate the actual communication pattern of the contributing community members. To measure this we constructed the coordination network and the derived coordination network. These networks show the communication among the contributing developers identified by the actual communication through email and by the concrete architecture, respectively. Then the congruence between these two networks and corresponding percentile value was calculated for each stable release. The percentile value indicates the extent to which both networks overlap. Relationships identified by each of these networks are presented in Fig. 11. It can be noted that the architecture of FreeBSD remains quite stable in terms of number of packages (Fig. 3) and their interdependency as identified by the concrete architecture (column 3 of Fig. 10). Thus it can be ascertained that

The architectural design of the software remains stable during its evolution.

As can be seen from Fig. 11 the congruence values remain in-between 71% to 88% from stable release 3 to 9 (ignoring the first three releases as discussed in section 6.1). This result is closely tied with the results reported in Fig. 10. This implies that socio-technical congruence in reverse also holds for FreeBSD. And the communication pattern of contributing developer community simulates the underlying architectural dependency of the software to a gereat extent. Yet the derived coordination network is not able to estimate the coordination network, the former network overestimates the later one, similar to the derived architecture. Instead the following observatioin can be offered.

The communication need defined by the architectural design and interdependency among the modules of the software is effectively embedded within the communication pattern of the developer community of the FreeBSD project.

Again the over estimation by the derived coordination network can be vindicated as follows, this network was derived from package level concrete architecture. Thus developers contributing to a package or to the related packages were considered to have communication among them. This lead to a number of relationships among developers in the derived coordination architecture who might not have contributed to the same code files, but to the same packages. Yet these relationships among contributing developers should be taken as a suggestion to improve the coordination further in the community.

Evolution of Socio-Technical Congruence in FreeBSD Project

To conceptualize the evolution of socio-technical congruence in FreeBSD we plotted the congruence values in graph against the stable releases. As shown in Fig. 12 the congruence values remains stable around 76% to 82% starting from stable release 3. Similar trend can be notified in Fig. 13 where the congruence value remains stable within the range 71% to 88% starting from stable release 3. Based on these observations it can be stated that with the maturation of the project, the communication pattern among developers get more structured following the need of communication based on their tasks. This socio-technical congruence pattern of communication among the community memebrs becomes a traditional practice as the project evolves. Thus it can be affirmed that

The socio-technical congruence in FreeBSD project remains stable during its evolution. The following aspects have been identified which could lead to threats to validity of this study.

External validity (how results can be generalized): As case study subject, FreeBSD project was selected, which has been used popularly in the OSS evolution studies. Also, FreeBSD is a large and well established OSS project with over thirty years of evolution history. Yet the findings may not generalize to other OSS projects. This threat can only be countered by doing additional case studies with projects from different domains, which is a part of our future work.

Internal validity (confounding factors can influence the findings): Missing historical data -the study has been able to make use only of available data. It is possible, for instance, that there are commit records and developer chat entries other than that recorded in the emails. Also other email archives may contain relevant data. Thus, we make no claim on the completeness of the email entries with relevance to this study target.

Construct validity (relationship between theory and observation):

In this study, part of the email entries were categorized to specific stable release according to their date of post. The reasoning here is that developers commit and discuss on release planning before the product is officially released. Yet, we do not claim the perfection of this approach.

Conclusions

In this paper we evaluated the concept of Conway's law as a means of verifying the socio-technical congruence within the context of FreeBSD project. According to our judgment the congruence measure is significantly high in FreeBSD project which has a stable evolution history for the last seven releases of the project. In other words, the communication pattern of the contributing members within FreeBSD community are due to the communication need established by the concrete architecture. Having such high congruence between the code and the community would resolve many contemporary questions that cannot be answered otherwise. For instance, in identifying exact community member(s) to contract for an specific issue [START_REF] Syeed | Tool Assisted Analysis of Open Source Projects: A Multi-facet Challenge[END_REF], it is required to trace which community members collaborates and exchange knowledge based on their task level responsibility.

This congruence is a desired property for collaborative development activities [START_REF] Browning | Applying the design structure matrix to system decomposition and integration problems: a review and new directions[END_REF] and the reported result conforms the same for collaborative open source community. This result also creates a favorable basis to explore its implications on the OSS projects concerning the quality, success, and sustainability, which were already examined and confirmed in closed source projects.

Also, the results reported in this work hold for a specific OSS project, hence the study suffers from lack of generalizability. Thus a part of our future work is to extend and examine the findings in other OSS project, preferably to the BSD group and operating system domain.

Fig. 1 .

 1 Fig. 1. (a) Concrete Coordination Network with contribution to code base (b) Corresponding Derived Architecture

Fig. 2 .

 2 Fig. 2. (a) Concrete architecture with contributing developers (b) Corresponding Derived Coordination Network

Fig. 3 .Fig. 4 .

 34 Fig. 3. Stable Releases of FreeBSD

Fig. 5 .

 5 Fig. 5. Number of contributors and emails identified for stable releases

Fig. 6 .

 6 Fig. 6. (a) Sample contributions made by developer John Birrell (b) Sample relationships in Concrete Coordination Network

Fig. 7 .

 7 Fig. 7. (a) Code file level Concrete Architecture (b) Package level Concrete Architecture

Fig. 8 .

 8 Fig. 8. (a) Derived Architecture (b) Derived Coordination Network

Fig. 9 .

 9 Fig. 9. (a) Concrete Architecture (b) Derived Architecture (c) Congruence

Fig. 11 .

 11 Fig. 11. Resemblance of software architecture to communication pattern

Fig. 12 .

 12 Fig. 12. Evolution of Conway's law at architectural level

Fig. 13 .

 13 Fig. 13. Evolution of Conway's law at organizational level