Claudia Ayala
email: cayala@essi.upc.edu

Daniela Cruzes
email: dcruzes@idi.ntnu.no

Xavier Franch
email: franch@essi.upc.edu

Reidar Conradi
email: conradi@idi.ntnu.no

Towards Improving OSS Products Selection-Matching Selectors and OSS Communities Perspectives

Keywords: Open Source Software, selection, information rendering strategy, empirical study

Adopting third-party software is becoming an economical and strategic need for today organizations. A fundamental part of its successful adoption is the informed selection of products that best fit the organization needs. One of the main current problems hampering selection, specially of OSS products is the vast amount of unstructured, incomplete, evolvable and widespread information about products that highly increases the risks of taking a wrong decision. In this paper, we aim to inform and provide evidence to OSS communities that help them to envisage improvements on their information rendering strategies to satisfy industrial OSS selectors' needs. Our results are from the matching between the informational needs of 23 OSS selectors from diverse software-intensive organizations, and the in-depth study of 9 OSS communities of different sizes and domains. The results evidenced specific areas of improvement that might help to enhance the industrial OSS selection practice.

Introduction

Nowadays, the use of Open Source Software (OSS) provided by OSS communities is revolutionizing the software industry [START_REF] Ayala | Five Facts on the Adoption of Open Source Software[END_REF]. The fact that OSS products are freely available has influenced not only their significant adoption, but also the way that software is developed and commercialized [START_REF] Fitzgerald | The Transformation of Open Source Software[END_REF]. Thus, fostering OSS adoption has been recognized as a crucial task for progressing towards improvements in a great variety of application areas [START_REF] Simmons | Towards an Ontology for Open Source Software Development[END_REF].

The potential advantages of adopting OSS greatly depend on the ability to select the most suitable product for the task at hand [START_REF] Boeg | Certifying Software Component Attributes[END_REF]. Improper selection of an OSS product may result in wrong strategic decisions with subsequent economic loss and adverse effects on the business processes of the organizations [START_REF] Jadhav | Evaluating and Selecting Software Packages: A review[END_REF].

In recent years there has been a plethora of proposals aimed to support software products selection, usually suggesting sets of evaluation criteria to evaluate and decide the most suitable alternative(s) (see [START_REF] Jadhav | Evaluating and Selecting Software Packages: A review[END_REF], [START_REF] Li | A State-of-the-Practice Survey of Risk Management in Development with Off-the-Shelf Software Components[END_REF], [START_REF] Merilinna | State of the Art and Practice of Open-Source Component Integration[END_REF], for comprehensive surveys). However, a recent survey about industrial OSS selection practices [START_REF] Ayala | Selection of Third Party Software in Off-The-Shelf-Based Software Development -An Interview Study with Industrial Practitioners[END_REF] shows that these proposals have not been greatly adopted in the industrial practice. Instead, in order to face time-to-market demands and reducing the potential risks, selectors (i.e., the person(s) in charge of the selection process) just base most of their decisions on their experience and tend to limit the use of OSS products to those that are already known and used by the development team. While the value of experience is important, the fact that it is currently considered as the most influential factor for selecting components is at the same time hampering the adoption and fully exploitation of the potential benefits of the high variety of OSS products in the marketplace. Furthermore, such study evidenced that one of the key problems is that selectors are struggling not only with the current diversity of OSS products available in the marketplace, but also with the great deal of widespread, incomplete, heterogeneous, and unstructured information describing each of them (e.g., formal/informal documentation, tutorials, comments in forums, internal experiences) that makes difficult to face a suitable selection process under time-to-market pressures [START_REF] Bertoa | A Survey on the Quality Information Provided by Software Component Vendors[END_REF], [START_REF] Boeg | Certifying Software Component Attributes[END_REF], [START_REF] Li | Development with Off-The-Shelf Components: 10 Facts[END_REF]. In addition, the study emphasized that the main source for gathering OSS product information is the OSS community website.

In this context, in order to contribute to enable suitable OSS selection processes we need to envisage more pragmatic approaches than suggesting sets of evaluation criteria (especially when the evidence shows that the data to fill in these criteria is not usually available). Therefore, the goal of this study is to explore the following research questions: RQ1. How much of the information required by OSS selectors for performing a suitable selection process is actually provided by OSS communities? RQ2: Are there OSS community characteristics that seem to influence its level of readiness for supporting OSS selection?

With RQ1, we want to investigate the gap between the information "provided" by OSS communities on their OSS community websites and the information required by OSS selectors to perform an informed selection. RQ2 aims to explore whether some OSS community characteristic(s) seem to affect its readiness (i.e., the degree that the community covers the needs of OSS selectors). By answering these research questions, this paper aims to inform and provide evidence to OSS communities that help them to envisage improvements on their information rendering strategies. It is a first step to raise their awareness on areas that are required to improve the OSS selection industrial practice. This paper reports our results from a study about the matching of 9 OSS communities vs. the needs of 23 industrial OSS selectors.

The rest of the paper is organized as follows: Section 2 provides a brief background of the OSS literature and marketing principles that emphasize the importance of dealing with information rendering aspects and their influence on OSS products selection. Section 3 describes the methodological approach followed to perform the study. Section 4 presents the results obtained from the study, while Section 5 provides a discussion of main findings. Threats to validity are presented in Section 6. Section 7 summarizes the conclusions and future work.

Background

OSS research has largely ignored one interesting aspect that is becoming crucial for OSS projects: first-impression management [START_REF] Choi | Managing First of New Open Source Software Projects[END_REF]. Impression management theory refers to the process by which individuals or organizations try to control or manage the impressions that others form of them [START_REF] Winter | Electronic Window Dressing: Impression Management with Websites[END_REF]. Due to the ever-increasing amount of information available on the Internet and the need to make quick choices among competing alternatives, first-impression management has been adopted as one of the main theoretical lenses in marketing literature. Choi et al [START_REF] Choi | Managing First of New Open Source Software Projects[END_REF] demonstrated that the OSS community website plays a critical role in attracting developers and users to the community. The mature status of well-known OSS projects likely attracts users given their greater activity and vitality. Furthermore some OSS products have become de facto standards. However this pathway is unavailable for most of the OSS projects and those newly initiated projects that struggle to attract users and contributors [6].

In the context of OSS selection if an OSS project is poorly presented and potential selectors feel that the community does not invest much care in providing the needed information for selection, they might formulate negative opinions about the project and fail to consider it as a candidate even if it might represent a promising alternative. Thus, poor first impressions not only impact on the rate of potential users in the short run, they can also produce negative externalities for the project in the long run. For instance, they might lose the synergies derived from collaborating with companies, such as greater project activity, higher user's base and popularity [START_REF] Choi | Managing First of New Open Source Software Projects[END_REF].

Several initiatives exist to develop a framework for the assessment of OSS products. Most of these initiatives suggest different kinds of criteria such as functionality, maturity, and the strategy of the organization around OSS. Relevant examples are: OpenBRR (Open Business Readiness Rating) [START_REF] Openbrr | Business Readiness Rating for Open Source A Proposed Open Standard to Facilitate Assessment and Adoption of Open Source Software[END_REF], QSOS (Qualification and Selection of Open Source software) [START_REF] Semeteys | Method for Qualification and Selection of Open Source software (QSOS) version 1.6[END_REF], or OSMM (Navica Open Source Maturity Model) [START_REF] Golden | Succeeding with Open Source[END_REF]. The evaluation criteria are further explored by, for instance, Cruz et al. [START_REF] Cruz | Evaluation Criteria for Free/Open Source Software Products Based on Project Analysis[END_REF], the QualOSS Model Framework [START_REF] Ciokolwski | Towards a Comprehensive Approach for Assessing Open Source Projects[END_REF], and the QualiPSo model of OSS trustworthiness [START_REF] Del Bianco | Quality of Open Source Software: The QualiPSo Trustworthiness Model[END_REF]. In addition, the factors that might attract developers to participate in OSS projects in order to sustain the vitality of the community have been also studied [START_REF] Bonaccorsi | Business firms' engagement in community projects. Empirical evidence and further developments of the research[END_REF], [START_REF] Choi | Managing First of New Open Source Software Projects[END_REF], [START_REF] Denner | Attractiveness of Free and Open Source Projects[END_REF], [START_REF] Hauge | Adoption of open source software in softwareintensive organizations -A systematic literature review[END_REF]. However, as far as we know, there are not empirical studies that consider the needs of industrial OSS selectors as a way to improve first impression management.

Consolidated works from the marketing research have developed relevant tactics to help to influence first impression in a positive way [START_REF] Wolfe | Impression Management in the Feedback-Seeking Process: A Literature Review and Research Agenda[END_REF]. We think that dealing with first impression management is important for OSS research for two main reasons: 1) OSS community contributors typically join OSS projects by first becoming selectors, subsequently as users and then evolving into contributors [START_REF] Choi | Managing First of New Open Source Software Projects[END_REF], therefore first impression management is a potential way to attract OSS potential users. 2) Marketing strategies are becoming crucial to pose OSS products into the marketplace given that nowadays the OSS phenomenon has evolved into a more commercially viable form, where both volunteers and commercial organizations collaborate in its ongoing development [START_REF] Ayala | Five Facts on the Adoption of Open Source Software[END_REF].

One of the initial grounds of first-impression management is to explore the needs of the potential users and to envisage the improvement tactics. Therefore, this study was designed to explore how the needs of OSS selectors are covered by OSS communities in order to raise observations that may serve to envisage suitable improvement tactics.

The Study

The study performed in this work was exploratory and aimed to investigate the research questions introduced above. Our main research strategy consisted of the indepth study of 9 OSS community-based projects and exploring how these communities covered the informational needs of 23 industrial OSS selectors.

Sampling

The target population of the study was OSS community projects. Since the variety of OSS projects is quite wide not only regarding domain and size, but also regarding activity and popularity, we approached a stratified random sampling for improving its representativeness as well as the analysis of the results. We used the Ohloh.net directory as the reference directory for selecting OSS projects. We choose Ohloh as it is one of the largest and up-to-date OSS directories available, and has been widely used to create historical reports about the changing demographics of OSS projects.

From the 437,982 OSS projects referenced in Ohloh by February 2010, we ordered them with respect to their number of users and downloads. Then, we divided such a list into three equal parts (that were considered as stratums). Subsequently, we randomly selected 3 projects from each stratum. Table 1 summarizes the projects that fall into each stratum and provides a brief description of each of them.

Data Collection Instrument

In order to assess the OSS projects in a homogeneous way, we developed a data collection instrument based on the survey reported in [START_REF] Ayala | Selection of Third Party Software in Off-The-Shelf-Based Software Development -An Interview Study with Industrial Practitioners[END_REF]. This survey provides data about the information that is required in order to perform an informed OSS selection. 23 OSS selectors from 20 small and medium organizations in Spain, Norway and Luxembourg participated in the survey. It consisted of semi-structured interviews that were recorded in audio and then transcribed to text. We had access to the raw data from the respondents of such study (audio and text documents). From the responses of the selectors that participated in the study we elicited a total of 85 informational needs (i.e., specific information that they referred as needed for making informed decisions). We arranged similar answers using content analysis [START_REF] Krippendorff | Content Analysis[END_REF]. This process resulted in 21 informational needs. It is important to remark that similar efforts for establishing important evaluation criteria for selecting OSS products have been done in the literature as stated in section 2. Our primary goal was to assess if the information required by the selectors was provided by the OSS communities.

MediaCoder

It is a free universal batch media transcoder, which integrates most popular audio/video codecs and tools into an all-in-one solution.

New codecs and tools are added in constantly as well as support for new devices.

StatusNet

StatusNet (formerly Laconica) is a microblogging service. Users post short (140 character) notices that are broadcast to their friends and fans using the Web, RSS, or instant messages.

In order to improve the quality of the data collection instrument, it was pre-tested with three researchers. Consequently, we decided to arrange the 21 informational needs in categories and subcategories that provided a more understandable, structured and informative way of collecting them. For instance, the informational need Time of the product in the market was grouped in the sub-category History of the Product which at its time was grouped in the category To ensure technological stability and evolution of the OSS product and its provider. This arrangement demonstrated to provide researchers with a better understanding of the informational needs and their contexts; it therefore enhanced the information gathering process. As a result, the 21 informational needs originally gathered were grouped into 8 categories and 3 subcategories. The data collection instrument also gather information as: whether the informational need was provided or not by the OSS community; where the information was found, the time required to skim the OSS community website to find the information, and further comments from the researchers that performed and/or reviewed the OSS community. As it can be noted, our intention was not only to explore if the informational needs were available but also to have a first impression about how it was advertised, and how difficult it was to extract it. The resulting data collection instrument is shown in Table 2 and it also provides an example to illustrate the kind of information that was gathered.

Results of the exploration

Status

Where Further comments 1 Compliance with client's functional requirements List of main functional requirements of the OSS project.

(1)

The list of features provided seems quite comprehensive. If further information is required, there is an email available. We asked for further information about the product and our request was quickly processed. 2 To ensure technological stability and evolution of the OSS product and its provider Is it a commercial firm leading the community?

The community is lead by a single company called Agile42

List of companies/organizations collaborating in the community.

×

There is no information about any other company participating in the community.

History of the product.

Study Procedures and Data Analysis

Each OSS project was assessed using the data collection instrument introduced above. Two different researchers were in charge of assessing each OSS community website. Subsequently, they discussed and agreed the observations. Once all OSS projects were explored and reviewed, the whole research team held discussion meetings to analyze the data and consolidate the results.

Results of the Study

Results are grouped in two subsections according to the research questions introduced above.

T a b l e 3 s h o w s a s u m m a r y o f t h e r e s u l t s f r o m t h e a n a l y s i s o f t h e 9 O S S communities. In order to provide insights of the coverage of each OSS community to the selectors' needs, we assigned relative weights to each category of the data collection instrument as shown at the right side of each category in Table 3. Such assignment was based on the number of selectors' responses grouped into the category. For instance, the category Compliance with client's functional requirements had 18 similar responses; therefore its relative weight with respect to the 85 selector's responses resulted in 21.18%. The category Availability and quality of the documentation grouped 3 responses; therefore its weight was 3.53%. Based on such weights we calculated the percentage of coverage of each community to the categories of the data collection instrument. The last row of Table 3 shows the final coverage of each OSS community to the OSS selectors needs. These weights allow us to summarize our findings and provide useful insights to the reader to identify and understand the categories where there is a higher need of improvements.

How much of the information required by selectors is provided by OSS communities?

We found that the most important informational need belonging to the category Compliance with client's functional requirements was covered by all the analyzed projects. All of them show (with diverse levels of detail) a list of features of the OSS product.

The information required To ensure technological stability and evolution of the OSS product and its provider was poorly covered by most of the studied OSS communities. In addition, the coverage of informational needs belonging to this category was very diverse (see Standard Deviation in last column of Table 3). Most of the analyzed communities failed to clarify the kind of involvement of commercial firms. While in some cases it was clear that the leader of the community was a commercial firm and that several companies were also collaborating in the community under diverse schemas (coding, sponsoring, donating, etc.), in some other cases this information was not clear. The case of MediaCoder was outstanding as the project has radically changed its OSS nature by a purely commercial approach. At this respect, we found controversial comments in Ohloh claiming that MediaCoder should not be listed therein anymore mainly because the source code is not actually available and this violates one of the principles of OSS [23]. Other projects that did not offer clear information about the involvement of companies were FluentNHibernate and StatusNet, our observations regarding these projects led us to realize that such lack of clarity might come from the fact that these communities are currently in the process of defining a new business strategy by establishing commercial entities for making business around the products (e.g., selling expert support). Furthermore, basic informational needs as Time of the product in the market and Versions of the product available were not provided by several communities, especially those with a commercial orientation.

The informational needs grouped in the category Evidence of Successful OSS product usage were the ones that most communities failed to cover. None of the studied projects covered all the informational needs belonging to this category. Any of the OSS projects offered information about the number of downloads. Only two communities stated the number of registered users. Five projects stated a list of companies that have successfully used the product, and just one project offered comments from users of the product.

The informational needs belonging to the category Ease of OSS integration were mostly covered by the studied projects. The only informational need that was not successfully covered by most projects was related to the Hardware requirements needed to ensure the correct functioning of the OSS product. MediaCoder also failed to provide well-commented code and programming language (this is again due to the fact that it does not provide the source code of the product).

Regarding the category Availability of support, in all projects it was explicitly stated whether they provide non-free support, while free support was commonly characterized by wikis, email lists, IRC channels, and forums.

Most projects, excepting two (MediaCoder and StatusNet) offered clear information regarding Licensing terms. As mentioned above, these two projects were facing a business model change and therefore their licensing schemas were not clearly stated. Finally, regarding the Availability of documentation, almost all projects offered documentation for final users and for developers and most of them offered a variety of languages.

Summarizing, we found that the analyzed OSS projects cover the selectors' needs in a diverse degree. Such coverage ranges from 44.96% to 80.89%. Further discussions are provided in section 5.

4.2

Are there OSS project characteristics that influence its level of readiness for supporting selection?

The assessment of the 9 OSS community projects leads us to state some observations regarding characteristics that might affect the information rendering aspects of OSS communities and therefore their readiness for supporting selection. The most relevant ones suggest that two interrelated characteristics seem to affect the information rendering aspects of OSS projects: the involvement of commercial firms and the stratums that the projects belong to.

We observed substantial differences among the 3 Stratums. Surprisingly, all OSS projects from Stratum 1 have a close involvement of commercial firms in the community. This finding is in line with the results from the study reported in [START_REF] Bonaccorsi | Business firms' engagement in community projects. Empirical evidence and further developments of the research[END_REF] that evidenced that firms coordinate, develop code for, or provide libraries to one third of the 300 most active OSS projects in SourceForge. Projects from Stratum 2 did not have commercial firms leading the projects, instead they referred to volunteer-based communities that fully adhered to the Free Software Foundation (FSF) and two of them (Gimp and Grub) were part of the GNU project that advocate for the "free software" philosophy. Projects from the Stratum 3 also show a high involvement of commercial firms. While MediaCoder is currently a purely commercial project, Fluent NHibernate and StatusNet are facing a transition stage for becoming businessoriented OSS communities. These facts are in line with the "commercialization" of OSS predicted by [START_REF] Fitzgerald | The Transformation of Open Source Software[END_REF].

The involvement of firms in the OSS communities seems to influence their aesthetic appearance and information rendering aspects. For instance, Agilo for Scrum is an OSS project entirely governed and led by the company Agile42, and so its website is more oriented to business (i.e., selling services around the product) than to promote the involvement of potential contributors to the community. In the case of the Joomla!, the involvement of firms seems to be quite different as even if firms are quite involved in the project, the project is governed by the community. Thus, its website reflects a strong interest to promote resources for consolidating the community and attract contributors. It also offers several schemas for companies and organizations to participate in the community (i.e., donations, selling services around the product, merchandizing). The website of Subclipse is led by the company CollabNet and the provided resources are more oriented to final users (i.e., instructions on how to install the plugging) than to contribute to the community. Other examples are FluentNHibernate and StatusNet that are currently approaching business oriented models and are also improving the aesthetic appearance of their portals. Therefore, we suggest that: as higher the involvement of commercial firms is, the lesser seems to be the attention paid to promote the involvement of potential contributors in the community.

Communities without commercial firms involved shared several commonalities. It seems that they are mostly aimed to provide technical resources to strengthen the developers' community than aesthetic and attractive resources. This coincides with some studies that emphasize that some OSS projects mostly leaded by community programmers often value substance over form and some exhibit an antipathy for marketing and public relations work [START_REF] Fogel | Producing Open Source Software: How to Run a Successful Free Software Project[END_REF]. In all cases, these OSS projects provide mailing lists, forums and wikis aimed to enable the collaboration among the members.

Thus, our results might suggest that it would be useful to distinguish among: Commercial OSS, Foundation-based OSS, and Community-based OSS in order to better understand and assess the implications of selecting each kind of OSS product.

Discussion of Results

The previous section aimed to present a comprehensive view of the results. This section aims at emphasizing and discussing the most important findings and observations. One of the main difficulties we faced in our OSS projects assessment was that the information-even if it was sometimes available-was not directly accessible. We had to browse the project website and explore among help files, manuals, or even demos. This fact increased the time spent on skimming the portal to find the information and definitely rules out any possibility of trying to automate the search for the information as previously stated by [START_REF] Bertoa | A Survey on the Quality Information Provided by Software Component Vendors[END_REF].

Even if we found that the involvement of commercial firms and the stratums seem to have a significant influence on information rendering aspects, the coverage of selectors' needs varies from project to project.

OSS communities are not aware of the importance of making some information available. We observed that some informational needs are actually known by OSS communities but are not explicitly provided by them. For instance, most of the analyzed projects did not explicitly offer information about the Number or registered users in the community, Time of the product in the market, or List of companies using the product (if any). So, we hope that the results provided here help to raise the awareness of the importance of providing such information. In addition, there are categories that seem to be almost always provided (i.e., Compliance with client's functional requirements and Availability of support) while there are others that are not fully covered (e.g., To ensure technological stability and evolution of the OSS product and its provider) or are not covered by any of the studied project as Availability of test results.

Providing such evidence is important to envisage the corresponding improvement strategies and increase the competitive advantage of the OSS products.

Threats to Validity

This section discusses the threats to validity of our study in terms of construct, internal, and external validity, as suggested by [START_REF] Robson | Real World Research: A Resource for Social Scientists and Practitionerresearchers[END_REF] and [START_REF] Wohlin | Experimentation in Software Engineering -An Introduction[END_REF]. It furthermore emphasizes the corresponding strategies used to deal with these threats.

Construct Validity

Regarding construct validity, our study was supported by 2 main principles: rigorous planning of the study, and the establishment of protocols and instruments for data collection and data analysis. The data collection instrument was carefully designed taking into account the informational needs of selectors elicited from a semistructured interview further reported in [START_REF] Ayala | Selection of Third Party Software in Off-The-Shelf-Based Software Development -An Interview Study with Industrial Practitioners[END_REF], as detailed in section 3.2. This allows us to focus the study on the information that is really needed by the industrial OSS selection practice. In addition, the data collection instrument was pre-tested and enhanced by creating categories and subcategories for grouping informational needs (as detailed in section 3.2). This allows us to improve its understandability and therefore to improve the data gathering process.

Internal Validity

Regarding internal validity, we tried hard to envisage and harmonize the data gathering and the subsequent data analysis strategies. With respect to the data gathering strategy, we took relevant decisions for approaching a better understanding of the availability of the information for covering the selectors' needs. One of the most relevant decisions was to avoid the non-deterministic factors inherent to the OSS selection processes. These non-deterministic factors refer to contextual issues that greatly affect the OSS selection decision. For instance, even if an OSS project provides a list of functional characteristics of the product, it might happen that such a list is not detailed enough for the context of the selection project and the selector have to face such a lack of detail by testing the product himself or by looking for further information in forums, email lists, etc. The strategies for facing (or not) such lack of information depend on the amount of time and resources that a company is willing and able to invest in the selection process [START_REF] Cruz | Evaluation Criteria for Free/Open Source Software Products Based on Project Analysis[END_REF]. Therefore, to avoid such potential issues we decided to focus our observations just on whether the informational need was covered or not and on how the information was provided.

In addition, we decided that two different researchers independently faced the assessment of each OSS community projects using the data collection instrument. Subsequently they discussed their results in order to agree and merge them. This helps us to deal with the potential subjectivity of the assessment of each researcher. Furthermore, it is important to mention that the researchers participating in the study are impartial parties and do not have any kind of involvement with any of the OSS communities analyzed. In this sense, we consider that there is no any intentional bias regarding the data gathered.

External Validity

Regarding external validity, it is important to highlight that the character of our study is exploratory, and hence we did not aim to make universal generalizations beyond the studied setting, but also provide some observations that might serve as a departing point for further investigations and improvements. Having this in mind, we discuss some mitigation strategies used in the study. One of the main threats of external validity of the study is that we approached a small set of OSS community projects and these projects might not represent the whole variety of OSS projects. We tried to mitigate any possible bias related to this by having a stratified random sampling so that the studied OSS communities were diverse regarding size, application domain, popularity and success.

The informational needs used as a base to decide the informational coverage of OSS projects were elicited from industrial OSS selectors. While extracting such needs from the industrial practice is a good point to strengthen the external validity of our observations, we are aware that eliciting such needs from 23 selectors might not represent all real needs. However, we think that such results are useful to have a first approximation to the problem and might serve as a basis to envisage future studies.

Finally, other issues that might affect the presented results (especially the time spent skimming the OSS projects for finding and understanding the information) are: a) As mentioned above, the assessment of each OSS project was performed using a strategy that avoids the non-deterministic nature of the OSS selection processes (i.e., just capturing whether the informational need was covered or not and further observations about how it was provided). At this respect, we are aware that in the industrial OSS selection practice the complexity and time for gathering the OSS products information is actually higher. Thus, we would like to stand out that the metrics (weights and time for assessing each OSS project) provided in Table 3 are just intending to offer insights of the coverage of each OSS community to the selectors' needs. In any case these metrics are aimed to be representative of the assessment of OSS projects for any specific OSS selection process.

b) The researchers in charge of analyzing the OSS communities were not experts in any of the approached domains. So, we may say that the performance of researchers that performed the data gathered process would be more similar to "novice selectors" than experienced selectors that might perform better in finding and analyzing the OSS communities.

Conclusions and Future Work

This study presents our results of exploring the current gap between the "required" information needed by 23 industrial OSS selectors for making informed decisions and the information "provided" by 9 OSS communities. The obtained results would contribute to research and practice: a) by informing OSS communities about information rendering aspects that could be improved to attract industrial users. b) by informing OSS selection researchers about informational limitations that might help them to calibrate their OSS selection proposals.

Our future work focus on complementing the results from the study reported here with further information that allows OSS communities to elaborate their tactics of improvement based on the selectors' feedback [START_REF] Wolfe | Impression Management in the Feedback-Seeking Process: A Literature Review and Research Agenda[END_REF].

Table 1 .

 1 Stratified random sampling

	Stratum Name	Description
		Agilo for Scrum	It is one of the most widely used Scrum tools, offering many features to support Scrum and software development teams.
	1	Joomla	It is an award-winning content management system (CMS), which enables to build Web sites and powerful online applications.
		Subclipse	It is an Eclipse Team Provider plug-in providing support for Subversion within the Eclipse IDE.

2 Gimp GIMP is an acronym for GNU Image Manipulation Program. It is a freely distributed program for such tasks as photo retouching, image composition and image authoring. GNU Grub GRUB is the GRand Unified Bootloader for GNU IpTables iptables is the user space command line program used to configure the Linux 2.4.x and 2.6.x IPv4 packet filtering ruleset. It is targeted towards system administrators. 3 Fluent NHibernate A fluent API for simplifying the entity mapping of NHibernate. Add compile time safety, testability, and improved readability to NHibernate projects.

Table 2 .

 2 Data collection instrument. Example of the assessment of the Agilo for Scrum project1

	Category/ Subcategory/ Informational Need

of the researchers: TP + CA Date of the assessment: 11/2010 -reviewed 02/2011 Mean time required for skimming the webpage: 4 hours

  Most of their services are not free. They have a commercial license where they provide further professional services. They also offer a blog , Goog le groups for commenting things about the product, and a Wiki for free. The page is more oriented to business (the community is lead by a company called Agile42). A wiki is provided to report bugs and to inform about possible further involvement with the community as contributors. Name

		Time of the product in the market.	×	I navigated through the wiki and could not find this information
		Versions of the product available.	×
	3 Evidence of successful OSS product usage
		Number of registered users	×
			(2)	There is documentation about success stories in companies as: ASDIS, eBuddy,
		List of companies using the product		be2, Ericsson, DHD24, Hypoport, Princenton Finantial systems and RES
				software among others.
		Number of downloads	×
		Ratings and comments from users
	4 Ease of OSS product integration
		Interoperability issues
		List of software system and subsystems		Windows/MAC/Linux, andTrac 0.11. The information was widespread and it was
		required to ensure the correct functioning of		not easy to gather it.
		the product.
		Hardware requirements	×
		Suitability of Code
		Well-commented code		Very well commented
		Programming language		Python
	5	Availability of support Free services Very basic ones. Non-Free services (3) (4) Personalized services. In addition there is an improved version of the product that is not OSS.
	6 Availab ility o f Te sts Results
		Tests done by the OSS community	×
		Tests done by an external party	×
	7 Licensing terms
		Availability of detailed information about the	(5)	There are 2 licensing schemas. One that complies with the Apache Software
		licensing terms and explicitly state if they are		License, and a non OSS (offering an improved version of the product)
		listed by the OSS initiative
	8 Availability of documentation
		Documentation for final users	(6)	The documentation quality seems acceptable
		Documentation for developers	(7)	The documentation for integrators is very basic and scarce
		Available languages of the documentation		Only English
	General comments: (1) http://www.agile42.com/cms/pages/featu res/; (2) http ://www.agile42.com/cms/pages/references/ ; (3) https://dev.agile42.com/wiki
	http://groups.google.com/group/agilo/topics http://agile 42.com/cms/blog/; (4) http://agile42.com/cms/pages/support/; (5)
	http://agile42.com/cms/pages/agilo/; (6) http://agile42.com/cms/pages/agilo-documentation/; (7) https://dev.agile42.com/wiki/agilo/dev

Some textual comments from users as: "The Agile project approach allowed be2 the ability to monitor the project's performance every two weeks, and to evaluate the performance and quality. agile42 did a perfect job in training and coaching distributed Scrum teams based in both Germany and Armenia for this project. agile42 has been an indispensable link for a successful company transformation." Dave Sharrock, Director IT, be2 S.à.r.l….

Table 3 .

 3 Summary of results

	Category/Subcategory/ Informational Need		Agilo for Scrum	Joomla Subclipse Gimp	GNU Grub	IpTables	Fluent NHibe rnate	Media Coder	StatusNet Std Dev.
	Compliance with client's functional requirements (21.18%)	21.18	21.18	21.18	21.18 21.18	21.18	21.18	21.18	21.18	0
	List of main functional requirements
	of the OSS project.
	To ensure technological stability and
	evolution of the OSS product and its	5.30	15.89	10.59	21.18 21.18	21.18	10.59	5.30	0	7.28
	provider (21.18%)
	Is the project governed by a commercial firm or by the community?	commercial community commercial GNU	GNU community	No t clear commercial	Not clear
	List of companies/organizations
	collaborating in the community
	(others than the leader)
	History of the product.
	Time of the product in the market.
	Versions of the product available.
	Evidence of successful OSS product usage (12.94%)	6.47	6.47	3.24	3.24	3.24	0	0	0	3.24	2.53
	Number of registered users
	List of companies using the product
	Number of downloads
	Ratings and comments from users
	Ease of OSS product integration (12.94%)	9.71	9.71	12.94	12.94	9.71	9.71	6.47	9.71	9,71	1.94
	Interoperability issues
	List of software system and
	subsystems required to ensure the
	correct functioning of the product.
	Hardware requirements
	Suitability of Code
	Well-commented code
	Programming language
	Availability of support (11.76%)		11.76	11.76	11.76	11.76 11.76	11.76	11.76	11.76	11.76	0
	Free services
	Non-Free services
	Availability of test results (9.41%)		0	0	0	0	0	0	0	0	0	0
	Tests done by the OSS community
	Tests done by an external party
	Licensing terms (7.06%)			7.06	7.06	7.06	7.06	7.06	7.06	7.06	0	0	2.77
	Availability of detailed information
	about the licensing terms and explicitly state if they are listed by the									Not clear
	OSS initiative
	Availability of documentation (3.53%)	2.6	3.53	2.60	3.53	3.53	3.53	2.60	0.25	3.53	1.06
	Documentation for final users
	Documentation for integrators
	Available documentation languages	of	the	Only English	Several	Only English	Several Several Several	Only English	Only English	Several
	Mean time spent by the two
	researchers for skimming the portal	4:00	4:50	3:05	3:02	3:03	3.50	2:25	3:00	2:43
	(hrs):
	Resulting percentage of coverage of the portal to the needs of selectors:	64.07	75.59	66.13	80.89 80.89	74.42	62.90	44.96	49.41	12.13


Quinn C Taylor

Jonathan L Krein

Alexander C Maclean
email: amaclean@byu.net

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

An Analysis of Author Contribution Patterns in Eclipse Foundation Project Source Code

Collaborative development is a key tenet of open source software, but if not properly understood and managed, it can become a liability. We examine author contribution data for the newest revision of 251,633 Java source files in 592 Eclipse projects. We use this observational data to analyze collaboration patterns within files, and to explore relationships between file size, author count, and code authorship. We calculate author entropy to characterize the contributions of multiple authors to a given file, with an eye toward understanding the degree of collaboration and the most common interaction patterns.

Introduction

Software development is an inherently complex activity, often involving a high degree of collaboration between multiple individuals and teams, particularly when creating large software systems. Interactions between individual contributors can affect virtually all aspects of software development, including design, implementation, testing, maintenance, complexity, and quality.

Collaboration involves cooperation, communication, and coordination, and generally implies some governing organizational structure. The organization has an effect on the structure of the software being developed, as per "Conway's Law" [START_REF] Conway | How Do Committees Invent?[END_REF]; presumably applying equally to proprietary and open source software. Brooks noted that potential communication channels increase as the square of the number of contributors [START_REF] Brooks | The Mythical Man-Month: Essays on Software Engineering[END_REF]. Thus, there is benefit to understanding and managing collaboration so it does not become a liability.

Analyzing collaboration data can help explain how people work together to develop software. Studies by Bird [START_REF] Bird | Chapels in the Bazaar? Latent Social Structure in OSS[END_REF], Ducheneaut [START_REF] Ducheneaut | Socialization in an Open Source Software Community: A Socio-Technical Analysis[END_REF], Gilbert [START_REF] Gilbert | CodeSaw: A Social Visualization of Distributed Software Development[END_REF], Mockus [START_REF] Mockus | Two Case Studies of Open Source Software Development: Apache and Mozilla[END_REF], Dinh-Trong [START_REF] Dinh-Trong | The FreeBSD Project: A Replication Case Stdy of Open Source Development[END_REF], and others have examined interactions between open source developers by correlating communication records (such as email) with source code changes. Such approaches can expose patterns which reinforce contributor roles and module boundaries, but may not be feasible for all projects (particularly if email archives are unavailable) and can be difficult to compare or aggregate across disparate projects.

In addition to examining collaboration across projects and modules, there is value in understanding how contributors collaborate within files. Having a sense of what constitutes "typical" collaboration for a project can provide valuable context. For example, if most files in a project have one or two authors, a file with 10 authors may merit additional scrutiny. In open source projects, unorganized and organic contributions may be evidence of the bazaar rather than the cathedral [START_REF] Raymond | The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary[END_REF]. In any case, simply knowing can help set expectations.

This paper both replicates and extends earlier results [START_REF] Taylor | Author Entropy: A Metric for Characterization of Software Authorship Patterns[END_REF]. Our research goals center around detecting, characterizing, and understanding patterns of collaboration within source code files. Our primary research questions are:

1. How often do n authors contribute to a given file?

We anticipate that most files have a single author, and as the number of authors increases, the count of files with that many authors will decrease. 2. Is there a higher degree of collaboration in small or large files?

We anticipate that there will be a positive correlation between file size and author count, partially because larger files have more code, and the potential for more distinct functionalities and individual responsibilities. 3. Do files contain similar proportions of contributions from each author, or is there a dominant author who is the clear "owner" of a given file, and if so, how dominant is that author?

We anticipate that most source files will have one author who contributes significantly more code than any other single author, and that this author's dominance will be inversely related to the number of contributing authors. 4. Is there a uniform or uneven distribution of collaboration across projects?

We anticipate that there will be a few "core" projects which are highly collaborative, and many ancillary projects which are less collaborative.

Methodology

We conducted an observational study on existing Eclipse projects by extracting author attribution data for Java source code files from git repositories. In this section we describe the process we used to select and obtain the data.

Project and File Selection

We chose to analyze Eclipse Foundation projects for several reasons, including:

-the number and variety of Eclipse-related projects, -use of easily-recognizable programming languages, -the ability to locally clone remote git repositories, -a track record of sustained development activity, -the existence of corporate-sponsored open source development projects.

We selected Java source files for our analysis, since over 92% of the source files in the repositories are Java, and Eclipse is so closely aligned with Java. We mined data from 251,633 files in 592 projects. We included auto-generated code in our analysis, since the inclusion of such files allows us to accurately characterize the state of the project to which they belong.

Extraction and Calculation

The first step in calculating author collaboration is to count how many authors have contributed to a file and the number of lines contributed by each one. Summarizing raw line counts with a single representative statistic per file allows for detailed statistical analysis of collaboration trends. In this paper, we use: (1) the percentage of lines attributed to the most dominant author in each file, and (2) author entropy (see Section 3 for details). These numbers can help characterize some aspects of author contribution patterns.

We created a bash script to locally clone each remote git repository and use 'git blame' to count the number of lines attributed to each author for each matching file. For each file in a project, the file path and line counts attributed to each author were recorded.

We then wrote a simple CLI tool to process this data and calculate the percentage of lines written by each author. Author entropy for each file was calculated using Equation 1. We also normalized entropy by dividing by the maximum possible entropy for each file, shown in Equation 2.

Limitations of the Data

We draw data only from git, a source control management (SCM) system that preserves snapshots of file state over time. We do not consider other collaboration mechanisms, such as email archives, forums, etc., although this could be a very interesting extension of this work.

It it important to note that the SCM record of who "owns" a line of code only identifies the individual who committed the most recent change affecting that line. It does not guarantee that the contributor actually conceived of, wrote, or even understands the code. By itself, it also does not tell us the genesis of a line; it could be new, a minor tweak, or a formatting change.

Because we consider only the latest revision of each file, this data cannot be used to make any inferences about collaboration over time. Without historical data, we can see the result of collaboration, but not the nature of the evolution of such collaboration.

Lastly, because we record author counts but not relative ordering of contributions from various authors, this data does not fully capture or express the amount of disorder. Because only percentages by each author are considered, the data makes no distinction between files with orderly, segregated blocks of contributions and files in which authors' contributions are all mixed together.

Author Entropy

Author entropy is a summary statistic that quantifies the mixture of authors' contributions to a file. Contribution percentages are weighted using logarithms and summed; the resulting value conveys more information about the distribution than a simple average, and can expose interesting authorship patterns more readily than raw line counts. Taylor et al [START_REF] Taylor | Author Entropy: A Metric for Characterization of Software Authorship Patterns[END_REF] introduced author entropy and examined distributions in a proof-of-concept study with SourceForge data. A follow-on paper [START_REF] Casebolt | Author Entropy vs. File Size in the GNOME Suite of Applications[END_REF] examined author entropy in GNOME application source.

Entropy originated in the field of thermodynamics, which defines it as the disorder or randomness of molecules in a system. Entropy has also been defined in terms of probability theory and used in the fields of information theory [START_REF] Shannon | A Mathematical Theory of Communication[END_REF] and machine learning [START_REF] Mitchell | Machine Learning[END_REF].

We apply entropy as a measure of collaboration between individual contributors. Specifically, we consider entropy of source code by counting the number of lines attributed to each author. This definition of entropy allows us to quantify the mixture of author contributions to a file.

Calculating Entropy

Entropy formulae are nearly identical across domains, and generally vary only in symbolic representation and constant multipliers. We use a formulation very similar to that used in machine learning.

If F is a file, A is the number of authors, and p i is the proportion of the text attributed to author i, then the entropy of the file is defined as:

E(F ) ≡ - A i=1 (p i • log 2 p i ) (1)
E(F ) is maximized when all authors contributed equal proportions of text in a file (∀ i, p i = 1 A ). The upper limit of E(F ) is a function of A:

E max (F ) ≡ log 2 A (2)
We use log 2 for historical reasons tied to information theory (essentially, calculating the number of bits required to encode information). Although any logarithmic base would suffice, it is convenient that using log 2 results in entropy values in the range (0,1] for a binary classification.

Normalizing Entropy

Because the maximum possible entropy for a file is a function of the number of authors, intuitive understanding of entropy can be difficult. For example, an entropy value of 1.0 is the maximum possible for a file with 2 authors, but comparatively low for a file with 10 authors. Dividing E by E max produces a normalized value in the range (0,1] which represents the percentage of maximum entropy. Normalized entropy can be easier to understand, and in some cases more appropriate for comparisons between disparate files.

Interpreting Collaboration

A high degree of collaboration within a given source file is not inherently good or bad; as with any metric, context is key. Without knowledge about additional factors such as a project's state, organization, and development conditions, interpreting collaboration is purely speculative. To illustrate this point, we list below a variety of factors that could influence author entropy.

Low entropy could result from factors as varied as:

-Well-architected and modular software.

-Excellent communication and coordination.

-Lack of involvement from potential contributors. -A disciplined team in which each person "owns" a module.

-A gatekeeper who gets credit for code written by others.

-Code that few people understand.

-Code that was reformatted and old attributions lost.

-Code with exhaustive unit tests, known to be correct.

-Code with negligible unit tests and unknown defects.

-Auto-generated code that no human actually "wrote." -Critical code that few people are allowed to modify.

-Mature code with little or no need for maintenance.

-Stale code that isn't touched, even if it needs fixing.

-Dead code which is no longer used or modified.

High entropy could result from factors as varied as:

-Code with high coupling or many inter-dependencies.

-Unrelated code entities being stored in a single file.

-Adding manpower to a late project (Brooks' law).

-Extremely buggy code that is constantly patched.

-Extremely stable code that is well-maintained.

-Enhancements or fixes that touch several files. -Contributors joining or leaving a project team.

-Actively evolving code or refactoring activity.

-Miscommunication or lack of clear direction.

-Healthy collaboration between contributors.

-Overlapping responsibilities of contributors.

-Agile development or team programming.

-Potential for integration-stage problems.

-Continuous integration testing and fixes. Such a menagerie of disparate factors is not a flaw in the metric itself, but rather suggests that any metric can easily be misinterpreted without proper context. For example, a file with high entropy written by several experts is likely of higher quality than a file written by one novice author. Two files may have similar entropies despite a large size difference. A recent contributor may understand a file better than the original author who wrote it years ago. Correlating author entropy with other metrics and observations can help distinguish between "good" and "bad" entropy and provide valuable new insights.

Author entropy cannot directly indicate other attributes of the source code. For example, file length is obscured since files of different size but equal proportions of contribution have the same entropy. Entropy also does not reflect quality or the relative importance of contributions, such as new functionality, bug fixes, comments, whitespace, or formatting. Although different entropy calculation techniques could opt to account for such factors, there is no way to deduce the weighting of such factors from a single number.

Results

The line count of the source files we examined ranged from 1 to 228,089, with a median of 89. The extreme right-tail skew (97.5% have 1,000 lines or fewer, 92.5% have 500 or fewer) suggests that the data may have an exponential distribution. Plotting the data with a log 10 transformation produces a histogram (Figure 1) that closely resembles a normal distribution. A Q-Q plot showed that the population fits a log-normal distribution quite well, although the long tail caused higher residual deviations in the upper range. We also examined the files with 10 lines or fewer and found that nearly all of them were related to unit tests; several projects have extensive tests with Java source files that specify in and out conditions, but have little or no code. Excluding these left-tail outliers greatly improved the fit of the Q-Q plot in the low range. To answer our first research question, we plotted the frequencies of files with n authors. The resulting histogram was an exponential decay curve, and when plotted with a logarithmic scale, a near-perfect log-linear decay is evident (see Figure 2). This confirms our hypothesis that most files have a single author, and that the number of files with n authors decreases as n increases. It is also strikingly similar to Lotka's Law [START_REF] Lotka | The frequency distribution of scientific productivity[END_REF], which states that the number of authors who contribute n scientific publications is about 1/n a of those with one publication, where a is nearly always 2. Lotka's law predicts about 60% of authors publish only once; in our data, 58.22% of the files have one author. Fig. 2. Frequency of number of authors contributing to a given file.

To answer our second research question, we plotted file size distributions grouped by author count (see Figure 3). The log-linear increase in average file size as the number of authors increases confirms our hypothesis that, on average, there is more collaboration (i.e., more authors) in large files. However, we must note that there is a degree of uncertainty due to the decreasing sample sizes for higher author counts and the extreme outliers for lower author counts. We augmented Figure 3 with two additional data series: (1) the average number of lines in a file, and (2) the average number of lines contributed per author to a file. Note that there is a pronounced dip between 1 and 10 authors, but a fairly consistent average throughout. Although evaluating the causes and ramifications of this trend are beyond the scope of this paper, we find this to be an interesting topic for future work.

To answer our third research question, we plotted the number of lines in files with two or more authors against the percentage of lines attributed to the most dominant author in each file (see Figure 4). We also plotted the distributions of author dominance for all files with a given author count (see Figure 5). These plots confirm our hypothesis that most files have a dominant author, and that the percentage of lines attributed to that author generally decreases as the count of contributing authors increases. We find it noteworthy that author dominance diverges increasingly from the lower bound ( 1x ). This suggests that in Eclipse projects, more authors contributing to a file does not imply balanced contributions; rather, a single author usually dominates the others.

To answer our fourth research question, we plotted the number of lines in a project against the number of unique authors contributing to it for all 592 projects (see Figure 6). Over 83% of the projects have 10 or fewer unique authors, and some significant outliers have much larger numbers of authors. We also manually examined the 211 files with 11 or more authors. Nearly all of these files came from a handful of projects, all of which were among the top 25 projects with the most authors. These projects include:

-org.eclipse.ui.workbench (Eclipse IDE interface) -org.eclipse.jdt.core (Java Development Tools) -org.eclipse.cdt (C/C++ Development Tooling) -org.eclipse.pdt (PHP Development Tools) -org.eclipse.birt.report (Business Intelligence and Reporting Tools) -org.eclipse.jface (UI application framework/toolkit based on SWT)

The nature and role of these highly-collaborative projects confirms our hypothesis that collaboration is not distributed uniformly, but is concentrated in a few core projects. This phenomenon is also related to our second research question, about the relationship between collaboration and file size.

Additional Questions

In addition to our primary research questions, we also replicated some results from prior related work to verify whether the assertions made therein still hold for broader data. These results are related to distributions of author entropy (see Section 3) over varying file sizes and author counts.

In [START_REF] Taylor | Author Entropy: A Metric for Characterization of Software Authorship Patterns[END_REF] we found a positive relationship between author count and entropy (entropy rises as the number of authors increases). We found the same trend in Eclipse source code, although it breaks down somewhat for 11 or more authors due to sparseness of data (see Figure 7). Although the entropy metric is inherently biased toward higher values (particularly when there are more authors), any file can have low entropy when one of the authors is extremely dominant. However, because the maximum possible entropy for a given file is a function of the number of authors, it can be difficult to compare entropies for files with different number of authors. For this reason, we use normalized entropy, which always falls in the range [0,1] regardless of author count, and thus represents the percentage of maximum possible entropy.

Interestingly, the data exhibits a trend previously observed [START_REF] Taylor | Author Entropy: A Metric for Characterization of Software Authorship Patterns[END_REF] in a very constrained set of SourceForge data: distributions of normalized entropy tend to center around 0.6 (or 60% of maximum possible entropy) as the author count increases. Even as the data becomes more sparse for higher author counts, the distributions tend to converge on the same range.

Casebolt [START_REF] Casebolt | Author Entropy vs. File Size in the GNOME Suite of Applications[END_REF] examined two-author source code files and observed an inverse relationship between file size and entropy (small files have high entropy and vice versa). A similar pattern occurs in our data, as shown in Figure 8(a). Unfortunately, it is impossible to discern how many data points share the same location. The task is even more hopeless when all files (not just those with two authors) are included in the same plot, as in Figure 8(b). To better understand the distribution and density of these data, we borrow a tool used by Krein [START_REF] Krein | Impact of Programming Language Fragmentation on Developer Productivity: a SourceForge Empirical Study[END_REF] to visualize language entropy: 3D height maps. This technique generates an image in which densely-populated regions appear as elevated terrain (see Figure 9). 1 (adding depth). Starting from the back/left, the curves represent files in which one author "owns" all lines but one, two, etc. The disproportionate distribution of files on the furthest curves suggests that one-and two-line edits are probably extremely common occurrences in the projects we examined. This may be a manifestation of many small bug fixes, refactorings, interface changes, etc.

Future Work

Although this paper both replicates and adds to the results of prior work [START_REF] Taylor | Author Entropy: A Metric for Characterization of Software Authorship Patterns[END_REF], we also see several promising ways to extend this research.

First, statistical analysis of author entropy over time, including how entropy of files, modules, and projects change over time, and why. One limitation of this paper is that we examine only the most recent version of each file; we do not consider previous versions of existing files, or files which once existed but have since been deleted. We see significant value in understanding not only code ownership, but the degree of the resulting disorder, and how it is related to and caused by the development processes at play within a project.

Second, correlation of entropy with other code ownership measurements, communication records (such as email), and development roles. This could build on studies such as those by Bird [START_REF] Bird | Chapels in the Bazaar? Latent Social Structure in OSS[END_REF], Mockus [START_REF] Mockus | Two Case Studies of Open Source Software Development: Apache and Mozilla[END_REF], Dinh-Trong [START_REF] Dinh-Trong | The FreeBSD Project: A Replication Case Stdy of Open Source Development[END_REF], Jensen [START_REF] Jensen | Role Migration and Advancement Processes in OSSD Projects: A Comparative Case Study[END_REF], and von Krogh [START_REF] Krogh | Community, Joining, and Specialization in Open Source Software Innovation: A Case Study[END_REF], among others. Understanding how conributor roles and project organization affect source code entropy could help OSS project administrators (or "core team") to more effectively analyze and organize contributors' efforts.

Conclusion

We discovered that author attribution data for source code files can provide insight into the nature of collaboration between source code contributors. As researchers, we seek to understand how people work together to develop complex systems, and to explain success or failure based on the data at our disposal. We are fascinated by the patterns of order which seem to naturally fall into place amid the organic chaos of free-form interactions.

Our study revealed similar authorship patterns in a vastly different code base than prior work, and suggested interesting new patterns we had not previously considered. Author entropy continues to be an interesting and useful metric for characterizing contributor interactions. Future research will improve our ability to link collaborative activity with the underlying factors that influence it, and facilitate improvements that enhance the quality of the software we produce.

Fig. 1 .

 1 Fig. 1. Frequency of file sizes (in number of lines).

  the average number of lines per file.Lower circles represent the average number of lines per author per file.

Fig. 3 .

 3 Fig. 3. Author count vs. file size (in number of lines).

Fig. 4 .

 4 Fig. 4. Line count vs. percent written by dominant author for files with 2+ authors.

Fig. 5 .

 5 Fig. 5. Author count vs. author dominance. Circles represent the curve 1x .

Fig. 6 .

 6 Fig.6. Author count vs. total number of lines for all 592 projects.

Fig. 7 .

 7 Fig. 7. Author count vs. (a) entropy and (b) normalized entropy.

Fig. 8 .

 8 Fig. 8. Normalized entropy vs. line count for (a) two authors and (b) all files.

Fig. 9 .

 9 Fig. 9. Height map of line count vs. normalized entropy (same data as Figure 8b).

Figure 9

 9 Figure 9 is an adaptation of both Figure 8(b) (adding height) and Figure 1(adding depth). Starting from the back/left, the curves represent files in which one author "owns" all lines but one, two, etc. The disproportionate distribution of files on the furthest curves suggests that one-and two-line edits are probably extremely common occurrences in the projects we examined. This may be a manifestation of many small bug fixes, refactorings, interface changes, etc.