Darren Forrest
email: forresda@eecs.orst.edu

Carlos Jensen
email: jenseca@eecs.orst.edu

Nitin Mohan
email: mohanni@eecs.orst.edu

Jennifer Davidson
email: davidsje@eecs.orst.edu

Exploring the Role of Outside Organizations in Free / Open Source Software Projects

Keywords: Governance, Contributor affiliation, Participation metrics, Community sustainability

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Free/Open Source Software (FOSS) development is a key part of our modern IT infrastructure, responsible for the running of core Internet and server infrastructure. The governance and management of FOSS projects is therefore an essential concern for the continued growth and evolution of the Internet. FOSS development differs from "traditional" closed-source software in a number of fundamental aspects. One important aspect is that it is not only possible for anyone to view and use FOSS code, but that projects depend on an open participation model where anyone can contribute, and where the best ideas win. This FOSS development ideology is a key strength, as it enables a large and diverse group of developers to pool resources to develop software benefiting everyone.

The culture surrounding FOSS projects can differ substantially, and studies have been done documenting these cultures [START_REF] Krogh | Community, joining, and specialization in open source software innovation: a case study[END_REF]. In general FOSS projects are seen as meritocracies, where an individual contributors' worth and influence is based upon the quantity and quality of their past contributions to the community. Because of this, despite the fact that FOSS participation is driven by altruism and collaboration [START_REF] Bonaccorsi | Why Open Source software can succeed[END_REF], there is inherent tension and competition within projects. "Because Apache is a meritocracy, even though all mailing list subscribers can express an opinion by voting, their action may be ignored unless they are recognized as serious contributors" [14].

This inherent competition may be part of the reason why many of FOSS projects are seen as hostile to those trying to join. In a meritocracy, increasing the number of participants means increased competition for resources, or in this case attention and influence. It may therefore be in contributors' interest to erect barriers to ensure fewer people join. Even if one adopts a more benign view of humanity, developers in a meritocracy that primarily rewards code contributions (as is the case with most FOSS projects) are unlikely to "waste" their time writing documentation or mentoring newcomers, as these activities are not rewarded. These factors may in part account for the perceived elitism of some long time FOSS contributors, which can manifest itself in hostility and flaming of newcomers [START_REF] Bergquist | The power of gifts: organizing social relationships in open source communities[END_REF][START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF].

Another common perception is that FOSS projects are predominantly driven by volunteer efforts. While this was true in the early days, and is still likely true for many smaller projects, studies have shown that a growing number of FOSS developers receive some form of compensation for participation [START_REF] Ghosh | The Orbiten Free Software Survey[END_REF]. This compensation can take a number of forms, including release time from other work or monetary or resource donations to fund the work of core project members. This is especially common in larger and more important projects [11].

To a certain extent, compensation is a necessary response to the increased needs of large and important projects. While smaller projects can afford to adopt a more adhoc work and leadership model, larger and more crucial projects require more oversight and leadership, something that is difficult to provide with volunteer effort. The fact that an increasing number of FOSS developers are making a living through these projects is a sign of a healthy eco-system. These economic incentives can change the dynamics of FOSS projects. Regardless of whether paid developers are in a leadership position initially, they will tend to drift toward such position because of the meritocracy system. They will be able to dedicate more time to the project, and thus gain more influence.

The distributed organization of FOSS projects and ability for anyone to modify the source code is at the core of what makes FOSS successful. This freedom has to be balanced against the needs of the community, which necessitates cooperation and coordination. The responsibility for managing FOSS projects is in the hands of project maintainers. These individuals manage the code; they are responsible for choosing which contributions to incorporate into a release, and who has the ability to submit code. Because of these powers, they have a measure of control over the direction and participation of the project above and beyond any planning or leadership activities [START_REF] Lessig | CODE and other laws of cyberspace[END_REF][START_REF] Scacchi | Free and open source development practices in the game community[END_REF].

Control of the code, and thus the direction of a FOSS project, is important. A project may end up alienating, or neglecting the needs of a subset of their users if these are not represented in the project. This is a very real problem. The code-base of the Linux Kernel for instance has ballooned [START_REF]System Size -eLinux[END_REF] as hardware manufacturers add support for high-performance hardware. While the rapid growth of the code-base may be of only minor concern to those running large data-centers, it can be a serious concern for those wishing to run Linux on minimal hardware.

Despite the importance of code, this is not the only way to contribute to projects. People contribute through bug reporting, documentation, mailing list discussions, mentorship, or governance. It is therefore important to track and understand how participation in these different activities contributes to the health of projects, and the influence different organizations exert through these activities. However, most FOSS projects and researchers focus on only one participation metric. This may lead to a distorted view of what is taking place within their community.

This knowledge is not just important to the projects themselves, but to potential FOSS adopters or developers. Understanding who is supporting and influencing the project is crucial to making better decisions about whether this is a project worth investing in. Having broad support is important; an indicator of the potential and sustainability of a project. The recent and highly public fork of the OpenOffice project should serve as an example of the risks that can be manifest if the direction of a project differs from the desires of the community. The Linux Foundation recognizes the importance of such information in risk analysis and issues a yearly report on its contributor base [START_REF] Kroah-Hartman | Linux kernel development: How fast it is going, who is doing it, what they are doing, and who is sponsoring it[END_REF]. Our research may enhance the risk analysis that businesses and other organizations must do by examining the importance of complimentary metrics.

In this exploratory work, we perform a preliminary analysis comparing different metrics tracking participation and influence in projects, whether businesses and other organizations are biased in their participation. To this end we focused on two research questions: RQ1: Does bug reporting correlate with code contributions for large organizations? RQ2: Is there evidence of participation bias, and if so in what direction do organizations tend to lean?

It is important to note that the purpose of our study is not to malign the sponsorship or participation of corporations or governments in FOSS, but to show how these may skew the dynamics of a FOSS project. This influence may not be negative; having professional developers on-board can make a project more successful. However, it is important to be aware of what impact sponsorship can have, and manage the influence that these may have.

In the next section of this paper we review related work. We then discuss our methodology and follow with our key findings, and describe their implications for the future study of FOSS communities and their governance. Given that this is an exploratory study, we follow up with a discussion of the limitations of the study, and important future work. Finally, we wrap up with our conclusions.

Related Work

There is a growing body of work examining the development practices and governance of FOSS projects [START_REF] Crowston | Effective work practices for software engineering: free/libre open source software development[END_REF]11,[START_REF] Ko | How power users help and hinder open bug reporting[END_REF][START_REF] Scacchi | Free and open source development practices in the game community[END_REF]. One finding is that FOSS community structure is incredibly diverse. Where one organization might have a well-defined structure of who is doing what, others may operate on a much more ad-hoc fashion.

A number of studies of FOSS communities have relied on bug reporting and code commit records. Ko and Chilana used bug reports to look at how power users impacted the bug reporting process. This can be an especially powerful approach when combined with linguistic analysis of bug reports [START_REF] Ko | How power users help and hinder open bug reporting[END_REF][START_REF] Ko | A Linguistic Analysis of How People Describe Software Problems[END_REF]. Sandusky and Gasser studied bug reports from the Mozilla project to investigate negotiations between reporters and developers [START_REF] Sandusky | Negotiation and the coordination of information and activity in distributed software problem management[END_REF]. Gall et al studied the evolution of FOSS projects using concurrent versions system (CVS) data for the PACS project [START_REF] Gall | CVS release history data for detecting logical couplings[END_REF]. German also used CVS data to study software evolution, but focused on visualization of the development process [START_REF] German | An empirical study of fine-grained software modifications[END_REF].

To the best of our knowledge no one has used an exhaustive set of project metrics to study FOSS participation. Bug reports, code commits and mailing lists have been used together to explore feature tracking [START_REF] Fischer | Analyzing and Relating Bug Report Data for Feature Tracking[END_REF], knowledge reuse [START_REF] Krogh | Knowledge Reuse in Open Source Software: An Exploratory Study of 15 Open Source Projects[END_REF], and the development process [START_REF] Mockus | Two case studies of open source software development: Apache and Mozilla[END_REF]. Antoniol et al. sought to connect bug reports with code repository information to allow for easier searching [START_REF] Antoniol | Mozilla: Closing the Circle[END_REF]. Each of these combined data from different sources, but did not examine the affiliations of the participants.

Nearest to our work is a series of surveys of FOSS developers and projects (although somewhat dated) [START_REF] Ghosh | The Orbiten Free Software Survey[END_REF][START_REF] Hars | Working for Free? -Motivations of Participating in Open Source Projects[END_REF][START_REF] Lakhani | Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects[END_REF][START_REF] David | FLOSS-US: The Free/Libre/Open Source Software Survey for 2003[END_REF]. These surveys covered a myriad of topics from demographics to ideology, methodology, and motivations of contributors. Most telling from these studies and further verified by [11] was the employment status of FOSS developers. According to [START_REF] Ghosh | The Orbiten Free Software Survey[END_REF], more than 50 percent of contributors are somehow compensated for FOSS development. Jensen found this to be especially true of core developers [11]. Nguyen et al. found that whether bug reporters are paid or voluntary has an effect on the time taken to resolve an issue for some projects [START_REF] Nguyen Duc | Impact of Stakeholder Type and Collaboration on Issue Resolution Time in OSS Projects[END_REF]. They also found that developers paid to work on FOSS projects were able to resolve more issues because of the increased amount of time those developers had for work on the project.

Most developers work on more than one FOSS project and development is dominated by a few core developers. More than 60% of FOSS participants work on two or more projects [START_REF] Hars | Working for Free? -Motivations of Participating in Open Source Projects[END_REF]. The Orbiten Free Software Survey covered 12,706 developers in 3,149 projects and found that the top 10% of respondents contributed more than 70% of the code. The top ten authors alone contributed almost 20% of all code [START_REF] Ghosh | The Orbiten Free Software Survey[END_REF]. This distribution coupled with the meritocracy model suggests that a small number of contributors have very heavy influence over the direction of projects.

According to Bonaccorsi and Rossi, individuals and firms have different motivations for participating in FOSS projects [START_REF] Bonaccorsi | Why Open Source software can succeed[END_REF]. Firms' motivations for contributing centered on the economic and technological, while individuals were driven by social and personal reasons. Ye and Kishida found that a desire to learn is one of the core motivations for individuals seeking to become involved in FOSS [START_REF] Ye | Toward an understanding of the motivation of open source software developers[END_REF]. They also found that community membership and reputation is important to developers.

Joining FOSS projects is not without costs or hurdles [START_REF] Krogh | Community, joining, and specialization in open source software innovation: a case study[END_REF]. Prospective contributors must familiarize themselves with the constantly changing software as well as any design decisions made or tools used. Von Krogh goes on to say that "the alleged hobbyist culture of open source may not apply at all" [START_REF] Krogh | Knowledge Reuse in Open Source Software: An Exploratory Study of 15 Open Source Projects[END_REF].

Methodology

In order to examine our two research questions, even in an exploratory fashion, we needed to carefully narrow our scope. The selection of projects was some concern to the design of the research. We found that many small and medium projects simply did not have enough contributors or sponsors to explore these issues. We therefore restricted our investigation to the Linux Kernel 2.6 and GCC.

We chose these projects because they use complete e-mail addresses in bugzilla and code repositories, data we needed to track contributors. These projects included a diverse enough population that we had a reasonable chance to find and study interesting behaviors. Finally these projects had open and widely available mailing list archives, for future exploration.

To gather data on participation in bug triaging (either as a reporter or as a debugger), we collected the complete bug report and revision history database for each project. We collected and analyzed more than 95% of the bug reports. The remaining bug reports were unavailable due to insufficient permissions, database errors or malformed content.

From these records we extracted the email addresses of anyone who contributed to bug reports. We took the domain from the email addresses and used the publicsuffix 1.0.2 python module (http://pypi.python.org/pypi/publicsuffix) to consolidate domains. The crowd-sourced public suffix effort by Mozilla helped us effectively collapse subdomains such as us.ibm.com and ca.ibm.com to ibm.com. For the purposes of this study we chose not to differentiate between different types of contributors to bug reports. While it is true that those reporting bugs have a different level of influence than those working to fix bugs, they all participate in the public debate about the improvement of the project.

Because we are interested in investigating the influence organizations have on projects, we chose to lump all contributors from an organization together. An organization with a very small number of very active contributors could have more influence than one having a large number of occasional contributors. In order to manage the long tail of occasional contributors, we capped our data such that each domain had to have at least five unique contributors to be included. While it is possible that this could lead to the exclusion of high-volume contributors, it is unlikely that this would affect our understanding of influence and sponsorship.

To make the analysis more meaningful, we grouped organizations together by type: email provider, corporate domain, FOSS project, FOSS umbrella organization, educational institution, government agency, technical association, and unknown. If an email account was provided through some paid relationship or free signup with no other membership requirement, the domain was categorized as an email provider. The same approach applied to domains that were clearly maintained by an individual. FOSS project domains received their own classification while domains that were specifically related to FOSS projects (or FOSS in general), but were not the project itself we categorized separately as a FOSS umbrella organization. Examples of this would be linux.com and gnu.org. Technical associations such as ieee.org and acm.org were categorized separately as well.

For code submissions we gathered the complete commit logs from the projects' code repository. From these we performed the same email parsing and categorization as we did for the bug repository. One central list of domains was used to reduce the risk of incorrect categorization between the two data sources.

Data from bug reports and code repository logs for the Linux Kernel 2.6 was collected from November 6th 2002, through July 29th, 2010. Data for GCC was collected from August 3rd, 1999 through July 30th, 2010.

Results and Discussion

If we look at the number of contributors by affiliation, those associated with email provider domains dominate bug reporting (Figure 1), with as many contributors in this category as there are in all the others combined. While the numbers are surprising, it is not an entirely unexpected result, as the barriers to submitting a bug report are generally low, and thus we expected broad participation. Second, a number of paid programmers are likely to not want to disclose their affiliation when reporting bugs in order to protect their employers, deflating the numbers for the other categories.

When we look at code contributions, we see a different trend. Contributors from email provider domains were eclipsed by those from corporate domains. This is also not surprising, since end-users are willing or able to contribute code. Furthermore, contributing code requires a greater time investment; therefore, we expect to see more dedicated, professional programmers. This matches the findings of the Linux Foundation's report that corporations are very active in the coding of the Linux Kernel [START_REF] Kroah-Hartman | Linux kernel development: How fast it is going, who is doing it, what they are doing, and who is sponsoring it[END_REF].

When we compare bug reporting and code contribution for the Kernel, it is clear that there is a shift in participation, with corporations and other organizations being more involved in coding rather than identifying problems or addressing the complaints of users. Keep in mind that diagrams in Figure 1 are on a logarithmic scale, so seemingly small differences can be very significant.

Another interesting finding is that in the Kernel project there are more unique code contributors from each of the different domain categories than bug reporters. This is somewhat distorted by our filtering of data, but it is still amazing how big the difference there is. Furthermore, because we are only tracking successful code submissions, the number of people trying to contribute code could be even larger. We do not see the same pattern for the GCC project, except for corporate contributors.

Fig. 1. Categories of participation for GCC and Linux Kernel. Logarithmic scale

So what is going on here? Assuming that bug reporters are not reporting massive numbers of bugs each while code contributors only ever submit one or a handful of code patches, it appears that the Kernel project is driven by a self-centered develop-

Unique Code Contributors

Unique Bug Reporters

ment philosophy rather than by community needs. By this we mean that people are contributing code because they think the features or improvements will be useful rather than because someone has requested such features or fixes. The discussion about the evolution of the project is not occurring in a public forum. This analysis however, only scratches the surface. In order to see what goes on, we need to look at individual organizations, and their participation in bug reporting and coding. Again, in order to more clearly see patterns we exclude email providers.

When we examine these tables we find that many top contributors in one column fail to appear in the other (matching pairs highlighted in blue). Only 55% of the organizations with the most code contributors are also in the top 20 in terms of bug reporters/fixers. For the Linux Kernel this drops to 30%. So what does this mean, and why does it matter? We believe this data shows that some organizations are strategic in how they invest their efforts, choosing to either leverage their strengths (for instance hardware manufacturers like AMD, ARM and TI who have special insight into their own products) or addressing their needs without necessarily contributing to the overall needs of the project (as expressed in the bugs being reported), exemplified here by Google and Novell, among others.

Other organizations choose a different approach, working much closer with the community, regardless of whether they are a hardware provider or services companies. Exemplars here are IBM, Intel, and Redhat, among others, who despite having a vested interest in supporting their own needs balance coding with community engagement. The next step is to see whether participant numbers translate to actual ac-tivity, as some organizations can have few people contributing a lot, or a lot of people contributing very little. Table 3 shows us that for the GCC project at least, the number of organizations that have more people working on the code rather than contributing and addressing bugs is small, only 8 total. However, if we look at the average number of contributions, we see another source of distortion. Except for the organizations highlighted, the average number of bug contributions per bug reporter is much smaller than the average code contributions per coder. Most organizations may therefore be even more biased toward code contributions than initially thought. When we turn our attention to the Linux Kernel project we see an even more biased situation. If we rank organizations by the ratio of code contributors to bug reporters/fixers, we find 33 organizations with a code bias, and then a very sharp drop-off. More importantly, the contributions of these code and bug contributors is even more lopsided than in the GCC case, with only the Kernel.org team having bug reporters who are more active than their code contributors.

Again, what does this mean? It is important to emphasize that there is nothing wrong with organizations contributing large amounts of code; these are very significant contributions. The concern however is that unless these organizations are otherwise engaged in the greater discussion about direction and governance, the contributions may not align with the needs of the project in question. Said another way, if organizations do not get involved in the community discussion (via bug reporting, in this case), they may be effectively ignoring the community.

One very likely situation is that these organizations are responding to bugs reported by their customers directly, or from internal users, circumventing the official bug reporting channels. While this might be understandable from a corporate perspective, this can make it harder to optimally allocate resources, prevent duplication of efforts and make debugging of complex problems difficult for the project overall. That said, we believe we see clear evidence of corporate strategies with regard to participation on FOSS emerging from our data. For instance, compare the participation of Google and IBM employees across both projects. While IBM does favor code contributions, they still actively participate in bug tracking. We could say that IBM seems to have a balanced approach to participation as the pattern is consistent across the two projects. Google on the other hand seems to consistently follow a very different policy, with very few people reporting bugs, and the bulk of employees focusing exclusively on code. While this could be a coincidence, the pattern seems clear, and it would be surprising to learn that there wasn't some corporate or incentive policy reinforcing this. Whether that is in the interest of the FOSS projects affected is an open question and one we don't attempt to answer, but it would likely be in the projects' interest to be aware of these patterns. It is entirely possible that some of these organizations have designated email addresses for reporting bugs, or employees dedicated to reporting such issues, thereby skewing our data. This is not entirely far-fetched. Submitting a bug report in the name of a development groups' email distribution list would ensure that the whole team is notified when someone comments or addresses the issue, as opposed to only the developer who reported the issue. Initial investigations suggest this is not the case, but this is an issue that should be explored in future studies.

Limitations

One of the problems we faced in this study was the categorization of contributors by organization type by looking at email domains. This may have led us to misclassify domains, something that would affect the data presented here. While this may have happened, we believe it to be an infrequent occurrence as our categories were relatively well defined.

One place where this may be an issue is in the case of ISPs, where it may be difficult to distinguish the emails of employees from customers. In most cases, additional investigation revealed business rules that dictated which addresses were available to customers and which were available only to employees. Second, participants may be contributing under a generic email address, even if their contribution is part of their work commitment. While we know this occurs, the scope should be limited as most organizations see being involved in FOSS projects as good publicity, or that their name adds extra credibility to their contributions.

A second potential limitation is our decision to exclude any domains with fewer than 5 contributors from the dataset. We did this because of the sheer number of domains we needed to categorize. By applying this filter we were left with some 500 domains from over 13,000 original domains. While we may have lost some highimpact contributors, our goal was to determine the impact of organizational, rather than individual, participation in FOSS projects. Given that these were very large projects, we feel that an entity dedicating so few resources out of the project total is unlikely to have that much influence. There will always be exceptions, but we believe the overall impact of this decision is negligible.

The projects included varying information in the CVS data. For example, the Linux Kernel has a very structured format for their code commits. Each code commit has an author as well as a list of additional individuals who sign-off, review, or are otherwise included in the commit log. GCC does not follow as rigorous of a process. This difference in practices could have had an effect on our results, with contributors being over or undercounted.

Finally, our analysis of contributions, both to the debate as well as to the code base was very simplistic; a simple count. We acknowledge the fact that not all code contributions or bug report interactions are created equal, some of these will be more important than others. A simple count gives a distorted view. However, without a rating or review system for contributions, we have no objective way of evaluating the impact of individual contributions.

Conclusions

We found that for these large projects, corporate developers dominate in terms of code contributions. This has important implications for project governance and our understanding of FOSS demographics. Large projects may not be accurately portrayed as grass-roots volunteer efforts.

The data suggests there exist two distinct communities within projects. While these communities may interact with each other through other means (e.g. mailing lists), there is a community of coders and a community of bug reporters. While this is not unexpected, it is unexpected to see that the most prolific code contributors seem not to interact with the bug reporters-we tracked any participation in bug reporting, not just the reporting of new bugs. This disconnect can in the long-term lead to alienation and declining participation of non-technical contributors.

We also found that many projects do not currently track this kind of data, or at least they do not make it publicly available. While there may be privacy concerns with posting email addresses or calling out individual developers or companies, this has to be balanced against users and other contributors' need to know. Without this information, FOSS users and possible contributors lack the necessary information to understand whether a project is well governed and healthy.

7

Future Work

In the future we plan to expand our scope both in terms of projects examined and metrics used. For instance, we hope to look at projects that range in size. Prior research has shown that projects studied are anomalies rather than the norm in the FOSS ecosystem. Examining how smaller projects are affected would give us a better picture and help their maintainers make better growth decisions. Our research primarily used publicly available data. While this is important for evaluating the transparency and inclusiveness of decision-making, we know we are missing part of the picture, including any private deliberations between maintainers. We hope to get the direct cooperation of projects to determine if understanding participation in FOSS projects differs with an inside view.

The involvement of government agencies warrants further investigation, as we believe that these agencies have much to offer the FOSS community. We wish to explore how these organizations contribute, and how to get them more involved.

Recent events in the OpenOffice/LibreOffice project have brought the issue of forking and the role of corporations in FOSS to the forefront. We plan to investigate these projects as well as others that have forked over governance issues to determine if our metrics are meaningful. Retrospective analysis, before and after the split, could give key insights and early warning signs to enable corrective actions if desired.

Bug reports and code commits are not the only means by which individuals are involved in FOSS development. In the future we plan to look at mailing lists, project governance, project documentation, and conduct developer interviews. These will give us a broader picture of FOSS development work. This may help in answering more difficult questions relating to measuring project health and success. We hope to better understand healthy participation.

Table 1 .

 1 GCC code contribution and bug reporting (top 20 domains)

	Unique code contributors	Unique bug reporters
	redhat.com	150 gnu.org	174
	gnu.org	104 redhat.com	61
	ibm.com	70 ibm.com	55
	adacore.com	55 debian.org	46
	codesourcery.com	47 sourceforge.net	35
	google.com	38 mit.edu	27
	apple.com	30 acm.org	26
	suse.com	29 intel.com	24
	gnat.com	23 hp.com	19
	intel.com	17 mpg.de	17
	amd.com	14 cmu.edu	16
	arm.com	14 berkeley.edu	16
	sourceforge.net	12 apple.com	15
	debian.org	10 nasa.gov	15
	inria.fr	9 utexas.edu	14
	ispras.ru	9 cern.ch	14
	st.com	8 stanford.edu	13
	acm.org	7 suse.com	13
	hp.com	7 gentoo.org	13
	kpitcummins.com	6 kth.se	12

Table 2 .

 2 Linux Kernel code contribution and bug reporting (top 20 domains)

	Unique code contributors	Unique bug reporters
	ibm.com	721 ibm.com	115
	intel.com	571 osdl.org	112
	fujitsu.com	478 intel.com	47
	redhat.com	409 gentoo.org	36
	kernel.org	367 redhat.com	32
	google.com	228 sourceforge.net	30
	ti.com	209 debian.org	26
	sgi.com	203 suse.com	22
	linutronix.de	187 hp.com	18
	novell.com	145 kernel.org	13
	suse.com	132 bigfoot.com	12
	amd.com	130 linux.com	12
	freescale.com	125 mit.edu	11
	nokia.com	104 hut.fi	10
	hp.com	96 ubuntu.com	9
	atheros.com	89 amd.com	9
	samsung.com	88 fujitsu.com	9
	infradead.org	83 cornell.edu	8
	mvista.com	81 ieee.org	8
	oracle.com	78 tudelft.nl	7

Table 3 .

 3 GCC contributions ordered by coder/bug reporter ratio

	Domain	Unique Contributors Code Bug Ratio	Contributions per contributor Code Bugs Ratio
	google.com	38	6	6.333	34.184	2.333	14.652
	codesourcery.com	47	8	5.875	43.766	43.875	0.998
	redhat.com	150	61	2.459	52.620	15.000	3.508
	suse.com	29	13	2.231	221.103	9.077	24.359
	apple.com	30	15	2.000	69.300	12.733	5.443
	arm.com	14	7	2.000	14.000	1.571	8.912
	ibm.com	70	55	1.273	21.314	4.945	4.310
	columbia.edu	5	5	1.000	17.200	1.400	12.286
	inria.fr	9	11	0.818	4.444	5.273	0.843
	st.com	8	10	0.800	12.500	1.900	6.579
	intel.com	17	24	0.708	138.765	1.958	70.871
	kpitcummins.com	6	10	0.600	1.167	2.200	0.530
	gnu.org	104	174	0.598	70.356 145.414	0.484
	gentoo.org	5	13	0.385	2.800	3.538	0.791
	hp.com	7	19	0.368	25.571	3.947	6.479
	sourceforge.net	12	35	0.343	14.500	3.743	3.874
	acm.org	7	26	0.269	16.286	2.423	6.721
	debian.org	10	46	0.217	19.700	10.478	1.880

Table 4 .

 4 Linux Kernel code commits to bug reporting ratio

	Domain	Unique Contributors Code Bug Ratio	Contributions per contributor Code Bugs Ratio
	fujitsu.com	478	9	53.111	18.866	1.333	14.153
	google.com	228	5	45.6	18.741	1.400	13.386
	sgi.com	203	7	29	42.291	12.857	3.289
	kernel.org	367	13	28.231	41.507	70.692	0.587
	amd.com	130	9	14.444	35.400	4.111	8.611
	infradead.org	83	6	13.833	140.759	42.333	3.325
	oracle.com	78	6	13	184.423	5.833	31.617
	redhat.com	409	32	12.781	132.770	5.438	24.415
	intel.com	571	47	12.149	79.783	29.319	2.721
	vmware.com	43	6	7.167	23.442	2.333	10.048
	ibm.com	721	115	6.270	43.431	7.530	5.768
	suse.com	132	22	6	391.856	22.500	17.416
	hp.com	96	18	5.333	54.448	3.778	14.412
	mit.edu	45	11	4.091	44.800	4.455	10.056
	linux.org.uk	20	5	4	723.850	87.600	8.263
	cam.ac.uk	21	6	3.5	52.476	2.667	19.676
	mandriva.com	21	7	3	57.857	1.286	44.990
	ubuntu.com	25	9	2.778	16.160	2.222	7.273
	acm.org	19	7	2.714	24.053	1.714	14.033
	debian.org	67	26	2.577	9.299	3.192	2.913
	gnu.org	17	7	2.429	36.588	1.571	23.290
	helsinki.fi	13	7	1.857	159.154	1.857	85.705
	sourceforge.net	54	30	1.8	21.857	1.000	21.857
	cmu.edu	11	7	1.571	10.636	1.571	6.770
	ieee.org	12	8	1.5	4.583	1.875	2.444
	linux.com	17	12	1.417	90.588	6.750	13.420
	gentoo.org	44	36	1.222	63.068	2.722	23.170
	berkeley.edu	6	5	1.2	4.333	1.400	3.095
	ethz.ch	6	5	1.2	3.833	3.800	1.009
	cvut.cz	8	7	1.143	22.500	3.000	7.500
	hut.fi	11	10	1.1	14.545	4.800	3.030
	uio.no	6	6	1	39.000	28.500	1.368
	altlinux.org	6	6	1	9.500	3.333	2.850
	tudelft.nl	6	7	0.857	6.167	1.714	3.598
	cern.ch	5	6	0.833	2.800	1.333	2.101
	osdl.org	27	112	0.241	1193.074	43.795	27.242

Acknowledgements

We would like to thank Andy Ko for his assistance with scripts to extract bug repository information from Bugzilla databases. We would also like to thank the Oregon State University HCI group for their input and feedback on the research.


Pratyush N Sharma

John Hulland
email: jhulland@uga.edu

Sherae Daniel

Examining Turnover in Open Source Software Projects Using Logistic Hierarchical Linear Modeling Approach

Keywords: Open Source Software, Turnover, Logistic Hierarchical Linear Modeling

Developer turnover in open source software projects is a critical and insufficiently researched problem. Previous research has focused on understanding the developer motivations to contribute using either the individual developer perspective or the project perspective. In this exploratory study we argue that because the developers are embedded in projects it is imperative to include both perspectives. We analyze turnover in open source software projects by including both individual developer level factors, as well as project specific factors. Using the Logistic Hierarchical Linear Modeling approach allows us to empirically examine the factors influencing developer turnover and also how these factors differ among developers and projects.

Introduction

Developer turnover in open source software (OSS) projects is a nontrivial issue because of the frequency with which it occurs and the difficulties new developers face in contributing to a project. Robles and Gonzales-Barahona [START_REF] Robles | Contributor Turnover in Libre Software Projects[END_REF] analyzed the evolution of some popular OSS projects (such as GIMP, Mozilla etc.) over a period of 7 years and found that these projects suffered from yearly turnover in core development teams and had to rely heavily on regeneration. Turnover is a critical problem in software development projects because it can lead to schedule overruns [START_REF] Collofello | A System Dynamics Software Process Simulator for Staffing Policies Decision Support[END_REF] and regenerating teams is a complicated issue [START_REF] Reel | Critical Success Factors In Software Projects[END_REF]. A majority of the OSS research concerns itself with a developer's motivation to contribute to OSS development [2; 3].

Prior studies have tended to focus on the explanation of developer activity levels using either the individual perspective [2; 3] or the project perspective [START_REF] Stewart | Impacts of License Choice and Organizational Sponsorship on User Interest and Development Activity in Open Source Software Projects[END_REF]. However, since OSS participants are embedded in projects it is important to relate characteristics of individuals and the characteristics of projects in which they function. Disaggregating all project level variables in an individual level analysis may lead to the violation of the assumption of independence of observations, since all developers will have the same value on each of the project variables. On the other hand, aggregating developer level variables to a project level analysis may lead to unused within group information [START_REF] Raudenbush | Hierarchical Linear Models (Second Edition)[END_REF]. None of the research studies have attempted to model turnover behavior in OSS in a comprehensive fashion taking into account both the developer level and project level factors. In order to address these limitations and expand the existing research, this exploratory study develops a model of turnover behavior in OSS by focusing on two levels: the developer level, which examines factors that may affect developers' decisions to become inactive, and the project level, which examines the factors that may influence the rates of turnover among projects.

Methodology

To explore and explain the nature and impact of a developer and project variables turnover, we used archival data. The sample of projects and participants was drawn from SourceForge (www.SourceForge.net). The sample contained data for 40 currently active projects on SourceForge and 201 developers.

Developer Level Variables

The following five developer level (level 1) variables, including the outcome variable, turnover, were collected -

• Turnover -Turnover was operationalized as a binary outcome variable. A developer was deemed active, coded as 0, if at least one CVS/SVN commit was made by him/her in a 2 month period; otherwise coded as 1. Joyce and Kraut [10] also followed a similar approach in their study of turnover from online newsgroups, however they chose an observation period of six months to determine turnover.

• Role of the Developer -A project may employ developers for various roles that range in the level and kind of expertise required 1 . We created two dummy variables Developer and Admin with the base group Other (which included all other roles) 2 .

• Number of Projects -The number of OSS projects undergoing active development that the developer was involved in.

• Past Activity Level -Past activity was operationalized as a binary variable 3 . A developer was deemed active in the past, coded as 0, if at least one CVS/SVN commit was made by him/her in the previous 10 month period; otherwise, we coded it as 1.

• Tenure -We approximate the tenure of a developer in months by using the date of joining SourceForge.net.

Project Level Variables

The following project level variables (level 2) were collected -

• Project Age -The date the project was registered is available on SourceForge. We calculate the age in number of months since its registration on SourceForge.

1 Some examples of roles developers may perform in the project are as administrators, developers, document writers, project managers, packagers, web designers, etc.

2 Roughly 25% roles belonged to the Other category. Since Developer and Admin dummies are correlated we also analyzed the data by merging Other and Admin categories to create a single Developer dummy variable. In doing so we found that the HLM results did not change appreciably. 3 Using a binary dummy variable for measuring turnover and past activity results in loss of variance information and right censoring of data in developer activity levels. Please see the limitations section for how we intend to remedy this problem in the future.

Examining Turnover in Open Source Software Projects Using Logistic Hierarchical Linear Modeling Approach 3

• Size of Project -The number of developers with commit access to the project's CVS/SVN code repository.

Statistical Models and Results

The Hierarchical Linear Modeling (HLM) technique allows researchers to model developer level outcomes within projects and model any between project differences that arise. The study was carried out in two parts and follows the approach recommended by Rumberger [START_REF] Rumberger | Dropping Out of Middle School: A Multi-Level Analysis of Students and Schools[END_REF]. In the first part a developer model of turnover was developed and tested with logistic regression using only developer level variables. This allows an analysis focused only on developer level variables. However, this not only ignores project level variables but also assumes that the effects of developer level variables on turnover do not vary from project to project. This assumption was tested in the second part of the study using logistic HLM analysis. The developer level model used in this part of the study was based on the results of the first part. It allowed us to focus the analysis on explaining between project differences in the predicted mean turnover rates (turnover characteristics adjusted for differences in developer characteristics between projects) and between project differences in the effects of developer level variables on turnover rates.

Logistic Models

A series of linear logistic models were developed and tested to measure the effect of developer level variables on turnover behavior. Turnover is a binary dependent variable that can be expressed as a probability p i , which takes on the value of unity if the developer i becomes inactive in the project, zero otherwise. The probability p is transformed into log of odds (or logit) which is expressed as:

Log [p i / (1-p i )] = β 0 + β 1 Past_Activity + β 2 Tenure + β 3 Developer + β 4 Admin + β 5 Number_of_Projects

Table 1 presents the exponentiated logistic coefficients, which represent the ratio of predicted odds of turnover with a one unit increase in the independent variable to the predicted odds without one unit increase. Thus, a value of one signifies no change in the odds of turnover. A value greater than (less than) one indicates that the odds of turnover increase (decrease) due to a unit change in independent variable. The univariate and multivariate estimates of Past_Activity are both significant. The univariate estimate suggests that inactive developers have 371.42% higher odds of turnover than developers that were active. Unsurprisingly, inactive developers did not become active at a later stage. The univariate estimate of Admin is also significant and suggests that administrators have 44.3% lower odds of turnover than the Other category. This means that administrators are more than twice as likely to remain active than developers with Other roles. Since Past_Activity and Admin were significant in the univariate estimates they were retained for further HLM analysis.

HLM Models

HLM analysis requires two types of models: a level 1 model to estimate the effects of developer level variables on turnover and a level 2 model to estimate the effect of project level variables on the coefficients of the level 1 analysis. We begin the analysis by modeling the unconditional model (base model) with no predictors at either level.

Unconditional Model

Log

[p ij / (1-p ij )] = β 0j β 0j = γ 00 + u 0j
This model allows us to ascertain the variability in the outcome variable at each of the two levels i.e. within project and between project variability. The results are shown in Table 2. The Null hypothesis H 0 : τ 00 = 0 is rejected (p = .028). This suggests that significant variation exists among projects in their turnover rates. The intraclass correlation coefficient (ICC) measures the proportion of variance in the outcome that is between projects [START_REF] Snijders | Multi Level Analysis: An Introduction to Basic and Advanced Multilevel Modeling[END_REF]. ICC values for our analysis suggest that 8.71% variation in turnover that can be explained by level 2 predictors resides between projects. Further, for a project with a typical turnover rate (with u 0j = 0), the expected log odds of turnover is .484. This corresponds to a probability of 1/ (1 + e (.484)) = .38. This means that for a typical developer in a typical project there is a 38% chance of turnover in a 2 month period.

Conditional Model

This model allows part of the variation in the intercept β 0 (mean turnover rates) to be explained by project level variables (project age and size),

Log [p ij / (
β 2j = γ 20
All the variables were grand mean centered to reduce multicollinearity concerns in group level estimation [START_REF] Raudenbush | Centering Predictors in Multilevel Analysis: Choices and consequences[END_REF]. Table 3 presents the results of the conditional model. The Null hypothesis H 0 : τ 00 = 0 fails to be rejected (p > .500). This means that after controlling for project size and age no significant variation remains to be explained.

Limitations & Future Directions

Like all empirical work this study is limited in many ways. First, the sample is biased toward more active projects. Such projects may have well developed infrastructures allowing retention of active members and/or a constant inflow of newer active members. Including less active projects in the future should allow for more robust and generalizable results. Second, the use of binary variables for turnover and past activity leads to loss of variance information and right censoring of the data. To address this critical issue in the future, we will rely on techniques such as survival modeling that allows inference from right censored data. Finally, we will seek a conceptual integration of developer and project level factors in modeling turnover rather than just an empirical integration.

Conclusion

In this preliminary study, we argued that taking both the developer and the project level factors into account will lead to a richer understanding of the issue of turnover in open source projects. Our analysis suggests that past activity, developer role, project size and project age are important predictors of turnover. We find that there exists a significant variation in mean turnover rates among projects on SourceForge a nd t hat p ro j e c t age and p ro j e c t s ize ac c o unt f o r a s i z ab le pro po rt io n o f this variation.

Table 1 .

 1 Predicted odds of turnover

	Variable	Univariate	Multivariate
		estimates	estimates
	Past_Activity	371.429**	431.724**
	Admin	.443*	.989
	Developer	1.104	.548
	Tenure	1.008	1.007
	Number_of_Projects	.981	1.038
	-2LL (initial = 266.583)		109.008
	Cox and Snell R 2		.543
	Nagelkerke R 2		.740
	Δχ 2 = 157.57 (p < .001)
		*p < 0.05, **p < .001

Table 2 .

 2 Unconditional Model

	Fixed effect		Coefficient	se	p value
	Average project mean γ 00		.484	.183	0.012
	Random effect	Variance	df	χ2	p value
		component
	Project mean, u oj	.314	39	57.48	.028
	Deviance (-2LL)	631.288
	Estimated parameters	2

Table 3 .

 3 Conditional Model

	Fixed effect	Coefficient	se		p value
	Average project mean γ 00	1.86	.49		0.001
	Proj_Age Slope γ 01	.005	.006		0.461
	Proj_Size Slope γ 02	-0.012	0.008		0.154
	Past_Activity Slope γ 10	5.951	1.161		0.000
	Admin Slope γ 20	0.041	0.527		0.938
	Random effect	Variance	df	χ2	p value
		component
	Project mean, u oj	0.057	37	29.48	>.500
	Deviance (-2LL)	477.808
	Estimated parameters	6

  The proportion of reduction in variance or variance explained at level 2 is .8184, implying that project size and age account for 81.84% of the explained variance at level 2. The Deviance (-2 Log Likelihood) is also significantly improved from the base model (ΔD = 153.48, χ2 df = 4, p < .001), suggesting a good model fit and a fully identified model4 .

Pratyush N Sharma 1 , John Hulland 2 and Sherae Daniel[START_REF] Collofello | A System Dynamics Software Process Simulator for Staffing Policies Decision Support[END_REF]

A conditional model that included all developer level variables did not further improve deviance and was rejected in favor of the more parsimonious model presented here.


Dirk Riehle

Sebastian Berschneider

A Model of Open Source Developer Foundations

Many community open source projects are of high economic relevance. As these projects mature, their leaders face a choice of continuing the project as is, making the project join an existing foundation, or creating their own foundation for the project. This article presents a model of open source developer foundations that project leaders can use to compare existing foundations with their needs or to design their own. The model is based on a three-iteration qualitative study involving interviews and supplementary materials review. To demonstrate its usefulness, we apply the model to nine foundations and present their organizational choices in a comparative table format.

Introduction

Community open source projects are open source software projects that are owned by a community of stakeholders [START_REF] Riehle | The Economic Motivation of Open Source: Stakeholder Perspectives[END_REF]. The Linux kernel, the Apache projects, and the Eclipse platform are examples of community open source software. Community owned projects are to be viewed in contrast to single-vendor open source projects like MySQL, SugarCRM, or Alfresco [START_REF] Riehle | The Single-Vendor Commercial Open Source Business Model[END_REF] that are owned and managed by a single stakeholder, the company. As community open source projects mature and become increasingly economically relevant, they face a choice: Continue as is, seek the protection of an existing open source foundation, or create their own foundation.

The benefits of an open source foundation for the projects are manifold [START_REF] Riehle | The Economic Case for Open Source Foundations[END_REF]. Most notably, the foundation acts as the legal representative of the projects. Thus, it can represent the projects' interests in court and protect the individual contributing software developers. Also, a foundation increases the projects' credibility and makes them less dependent on individual people, which in turn increases industry involvement and makes the projects more sustainable. Thus, the creation of a foundation is a natural step in the life-cycle of successful maturing community open source projects.

Open source foundations are similar to traditional consortia. In fact, many foundations chose to incorporate using legal forms typically chosen for consortia. The main difference is the choice of an open source license for the software being developed. By using an open source license, a foundation cannot exclude non-members from utilizing the software. Thus, the software is typically not considered competitively differentiating. This is most forcefully demonstrated by some foundations choosing a for-public-benefit organizational form rather than the for-member-benefit form that traditional consortia typically take. Today, dozens if not hundreds of such open source foundations exist. Next to large well-known foundations like the Linux Foundation, Apache Software Foundation, or the Eclipse Foundation, many smaller niche foundations exist, catering to the specific needs of their projects. These specific needs may be country, culture, or jurisdiction-specific (e.g. OpenPlans, Kuali, or WorldVistA), or they may be specific to a particular industry (e.g. TOPCASED, GENIVI, OpenAPC), or they may be specific to a particular horizontal layer in the technology stack (e.g. Drupal Foundation, Document Foundation, KDE e.V.) or any combination thereof.

Joining an existing foundation or creating a new one is a daunting task. First, a project considering joining an existing foundation has to ask itself whether the foundation matches the project's interests. Second, if the answer is no, the project has to consider creating its own foundation. For these processes, there is no guidance, yet the compatibility of a foundation with the projects' needs is a crucial factor in ensuring the project's sustainability.

In our analysis of open source foundations, we need to distinguish between developer foundations, created by software development firms, and IT user foundations, created by users of the software who are using open source to avoid vendor-lock-in and keep prices down. This paper is only about developer foundations.

This paper presents a qualitative analysis of the structure and processes of existing open source developer foundations. A three-step process of analyzing existing foundations led to a model of open source foundations that project leaders can use to compare existing foundations with their needs or design their own. The paper's resulting contributions are:

Research Process

This paper shows the result of an exploratory theory generation process for developer foundations; it does not yet quantitatively validate this theory. We use the terms "theory" and "model" of developer foundations interchangeably in this article. The theory was generated in a three-step iterative process. The first step created the first model, the second and third step created refined models based on additional qualitative research. The first and second step were performed by the second author under the guidance of the first author, the third step was performed by the first author alone. The second author is a student of the first author.

First Iteration: Initial Model

For the first iteration, the first author chose six different foundations for initial analysis. These six foundations were the Free Software Foundation, the Linux Foundation, the Apache Software Foundation, the Eclipse Foundation, the GENIVI consortium, and the Albatross community. These foundations were chosen for their breadth and maturity. The second author then gathered and analyzed these foundations, using the following data:

• Telephone interviews with foundation representatives • Email exchanges to clarify issues from the interviews • By-laws and other materials from the foundations' websites

The second author analyzed the materials using an open coding approach. He grouped the codes into initial categories that then became the building blocks of the first model [START_REF] Corbin | Qualitative Research[END_REF]. This led to the definition of sub-categories like "membership" and their possible values like "person" or "corporation".

Second Iteration: Qualitative Validation

For the second iteration, the first author provided four more foundations to the second author that were supposed to serve as a qualitative validation of the first-iteration model: Would the initial model be able to capture the complexity of these four new foundations? The four new foundations were the KDE, Mozilla, OpenAPC, and TOPCASED foundations.

The attempt to describe these four new foundations using the initial foundation model surfaced several problems with the initial model. For example, the initial model had not captured the possibility of financing a foundation through a for-profit subsidiary (Mozilla). Thus, the result of the second iteration was a revised model that enhanced several of the original model dimensions and added one more.

Third iteration: Categorization and Review

For the third iteration, the first author took over and created a stringent categorization hierarchy from the available data. For example, the rather broad single category Intellectual Property was split into subcategories Project License, Patent License Grant, and IP Ownership. The accompanying attribute values were rearranged accordingly and in-line with the original coding. The Albatross community was recognized as single-vendor-owned open source rather than community open source and consequently removed.

The resulting hierarchy of concepts and categories is called category, attribute, and possible value in Tables 1 and2, the final analysis result after the third iteration. We found this nomenclature to be more useful than the general terminology of categories and sub-categories. The resulting model was presented to the original corre-spondents of the second author from the first iteration of this research process. While not a representative survey, the generally positive feedback confirmed the quality of the model. A few minor corrections, mostly renaming of codes, was applied to the model. The result is the model presented in Section 3.

Model of Developer Foundations

Model overview

Tables 1 and2 show the final result of the combined three-step exploratory analysis using interviews and supplementary web and literature research. It presents the model as a stringent category hierarchy with

• column 1, "category", being the top category, • column 2, "attribute", being the first layer of sub-categories, and • column 3, "possible values", being a third layer of categories.

Column 4 contains short codes for the possible values provided in column 3. Column 5 describes constraints between the categories, providing a short form of capturing category interactions. Column 6 then provides some explanation of the meaning of the attribute (the first level of sub-categories).

The following Subsections explain the model categories.

The General model category

The General:Purpose of a developer foundation is to benefit the public (G:PB) or its members (G:MB). Member benefit does not exclude public benefit, however, it is not a primary goal of the foundation then. This choice of public vs. member benefit strongly influences how the foundation incorporates.

The General:Incorporation of a developer foundation is typically as a non-profit foundation (G:F) or a non-profit consortium (G:C). The difference is that a foundation serves the public and a consortium serves its members. The actual choice of the corporate form depends on the jurisdiction of incorporation. In the U.S.A., for example, the Apache Software Foundation is a 501(c)3 non-profit foundation, while the Eclipse Foundation is a 501(c)6 non-profit consortium. In Germany, they might have chosen the form of an e.V. or a GmbH. Most countries have forms of incorporation that support for-public-benefit or for-member-benefit organizations.

The General:Members of a developer foundation can be both natural persons (G:NP) or juristic persons (G:JP). Natural persons are people, and juristic persons are incorporated organizations. Any combination is possible, as are many restrictions. For example, the Mozilla Foundation has no members, the Free Software Foundation only has natural people (developers) as members, and the Linux Foundation has both natural and juristic persons as members.

The Philosophy model category

The Philosophy:Commercial Stance of a developer foundation can be that of a free-software-enforced (P:FSE) or closed-software-allowed (P:CSA) stance. Taking a free-software-enforced stance prevents taking enhancements to the open source software private, thereby limiting the business models possible with the software. Taking a closed-software-allowed stance allows a much broader range of business models, including those in which the open source software is enhanced without those enhancements being open sourced as well. The stance strongly determines the choice of a license. This is an abbreviation of a more complex discussion carried out elsewhere in more detail [START_REF] Stallman | Why Open Source Misses the Point[END_REF]. The Free Software Foundation and the KDE e.V. are examples of foundations that take the more restrictive free-software-enforced stance, while the Apache Software Foundation and the Eclipse Foundation are examples of foundations that take the more permissive closed-software-allowed stance. In general, the more commercially minded, the more likely a permissive stance.

The Philosophy:Development Model of a foundation can be open (P:OD) or closed (P:CD). In the case of open development, all or most of the development artifacts are available in public as they are being developed. In the case of closed development, the project communities keep the project artifacts to themselves and only release them to the public in major increments, if they release them at all. Legally, in the restrictive sense of a license choice, the software may still be open source, though. Closed development is fairly uncommon but it does happen; an example is GENIVI, a consortium developing a Linux-based stack for in-vehicle infotainment.

The Intellectual Property model category

The Intellectual Property:Project License that a foundation chooses can be any of the 50+ open source licenses that have been officially accepted by the Open Source Initiative (OSI) as such [START_REF]Open Source Licenses[END_REF]. Sometimes, foundations develop their own license, which then has to pass the OSI's license review process. Simplifying, we reduce the choice of license to either a reciprocal (e.g. GPL or AGPL) (IP:RL) or a permissive license (e.g. BSD or Apache license) (IP:PL).

• A reciprocal license forces software developers who are embedding the reciprocally-licensed software in a product to open source the embedding code when distributing the product. • A permissive license does not force the developer to open source the embedding software code when distributing the software.

There are many options, and this simplification does not do justice to the wealth of choices one faces in choosing or designing a license. German et al. discuss some these issues and their implications [START_REF] Daniel German | Understanding and Auditing the Licensing of Open Source Software Distributions[END_REF]. In general, a free-software-enforced stance (P:FSE) goes well with a reciprocal license, and an closed-source-allowed stance (P:CSA) goes well with a permissive license.

A foundation has the option of providing the same source code under multiple licenses to increase flexibility. Contributors typically are required to accept all licenses, as enforced through a contributor agreement, see below. The Mozilla Foundation, bundles three licenses (the foundation's MPL, the LGPL, and the GPL) into its socalled tri-license. Derivative projects can then chose which license to utilize.

Table 1: Model of Open Source Developer Foundations, Part 1

The Intellectual Property:Patent License Grant can be none (IP:NPG), for-use (IP:UPG), or for-use and embedding (IP:EPG).

• If no patent license grant is provided through the project license or a contributor agreement (see IP ownership below), then users may have to pay The Intellectual Property:IP Ownership determines the rights the foundation wants to acquire of the software code. It may be none (IP:NIP), a relicensing right (IP:RRG), or the full copyright (IP:CA). Some foundations do not require to receive any rights but rely on the project license to regulate intellectual property issues around the project. An example is the KDE e.V. (foundation), however, this is the more uncommon choice. (KDE offers a transfer but does not require it.) Most foundations ask contributors to sign a contributor agreement before they make their first contribution, which either provides the foundation with a relicensing right or directly signs over the copyright to the foundation.

• A relicensing rights grant asks a contributor to provide the foundation with the right to relicense the contributed software code. This is helpful should the foundation decide to change its license at a later point of time. It also provides the foundation control over the whole code base, because the foundation becomes the single and only holder of a complete relicensing right while each contributor holds rights only to their typically small piece. • A copyright assignment asks a contributor to transfer all rights to the foundation, which then becomes the sole owner of the source code. This includes all the rights from the relicensing rights grant. In addition, it allows the foundation to act as the representative of the project, for example, in court. In particular, the Free Software Foundation requires a copyright assignment and declares its intent to enforce its intellectual property rights.

The Governance model category

The Governance:Board Membership of a foundation can be anything from democratic (GV:DB) on the one end through meritocratic (GV:MB) in between to autocratic (GV:AB) on the other end. Some foundations allow for elections of board members from the member base or even general public while others have a set board that answers only to itself. The Free Software Foundation and the Mozilla Foundation are examples of the latter, the Linux Foundation and the Apache Software Foundation are examples of the former.

The Governance:Project Membership can be anything from democratic (GV:DP) (elected by membership) through meritocratic (GV:MP) (earned status through continued project work) to autocratic (GV:AP) (appointed by board). This is particularly important for the project leadership. Most foundations, for example, the Apache Software Foundation and the Eclipse Foundation, support a meritocratic model in which project members earn their stripes before being elected into respective positions, but the other options also occur.

The Governance:Natural Member Career determines the career that a natural person, typically a developer, can have inside the foundation. The Apache Foundation provides the original model of this career [START_REF]How It Works[END_REF]. The career design varies between foundation, but one can repeatedly find these three components [START_REF] Riehle | A New Developer Career[END_REF]:

• The traditional open source career steps of increasing status are user, contributor, and committer (a.ka. maintainer) (GV:UDC). A user uses the software and helps others, a contributor makes contributions that have to pass review before they are accepted, and a committer reviews the work that contributors submit and can make contributions to the project that don't have to pass anyone else's review. • Foundations make the project management level explicit (GV:PMC) that is tied to the committer role in traditional open source projects: Developers can become members of a project management committee (PMC). The PMC determines a project's road-map in the overall scope of the foundation. Thus, it manages the project's direction. A PMC member can become the leader of one or more PMCs. • Finally, beyond project management, developers can become officers and board members of the foundation (GV:BRD), determining and contributing to its overall strategy and direction.

The Governance:Juristic Member Level determines the role that a juristic person can play within the foundation. Usually, the member level is closely aligned with the resources that a member provides, most notably financing (GV:FL) and development resources (GV:DL). The Eclipse foundation, for example, provides four types of corporate membership ("associate", "solution", "enterprise" and "strategic" members) while the TOPCASED foundation, whose software builds on the Eclipse platform, provides only one type of membership.

The Financing model category

The Financing: (of the) Foundation can be any or all of membership fees (F:MF), sponsorships (F:S), gifts and grants (F:GG), or revenues from a commercial subsidiary (F:FPS).

• Membership fees have the benefit of being predictable, while sponsorship may or may not happen. Sponsorship money may be tied to a particular project. Gifts and grants are also not predictable, however, for gifts and grants the foundation has to put in work and advertise or apply for it. These three are the most common forms of financing a foundation and most foundations rely on them.

• In addition, a foundation can finance itself through commercial subsidiaries.

For example the Mozilla Foundation, with its for-profit subsidiary the Mozilla Corporation, funds itself through the income derived from products and services it sells for its open source software. In 2009, most of the Mozilla Foundation's $101M income came from its search related activities (the Firefox search box etc.) [START_REF] Baker | The State of Mozilla: Sustainability[END_REF].

The foundation's income is usually spent on providing infrastructure services for the projects it is maintaining, for back office work, lawyers and legal work, and a (typically) small staff.

The Financing: (of) Projects may come directly from the foundation (F:PFF) or from the project participants (F:PMF), that is, the foundation members working on the project. For example, the Eclipse Foundation pays for (and maintains) all the infrastructure for its projects, while TOPCASED and GENIVI rely on their members to set-up and maintain the infrastructure on a per-project basis.

The Operations model category

The Operations:Infrastructure of a foundation's projects may be provided by the foundation itself (O:IFO) or by its members (O:IMO). This may be closely aligned with the financing of projects. The common choice is for the foundation to provide the infrastructure, as the Free Software Foundation, the Apache Software Foundation, the KDE e.V. and many others do. Sometimes, members perform these project services, as is the case with TOPCASED and GENIVI foundations.

The Operations:Back Office handles most of the back office work like maintaining a member database, collecting contributor agreements, and watching over proper processes. Much of this work may be performed by volunteers (O:BOV), but typically there are at least a few full or part-time employees of the foundation (O:BOE), paid for from the foundation's income.

Application of Model to Developer Foundations

Application overview

A full confirmatory validation of the model has yet to be done. To demonstrate at least the usefulness of the model, we apply it to the nine foundations we used in the theory generation process. Tables 3 and4 shows the result of this application.

Discussion of application

The model fits the foundations well and no necessary changes to the model became apparent. This is not surprising, given that the model had been derived from these foundations. As described in Section 2, we took a multiple-step process, first deriving an initial model for six selected foundations, and then extending it by incorporating into the model what we learned from four more foundations. In a similar vein, if we were to apply it to more foundations, we might find more extensions to the model. We expect these possible modifications to be small and incremental. ture" what we call "foundation model". Their research, like ours, was qualitative in nature and based on interviews and supplementary materials review. West and O'Mahoney's Production category matches our Development Model category, their Governance category matches ours, except that we determined a separate Financing category, and their Intellectual Property category matches ours as well, except that ours involves Patent Handling. We became aware of this work only after performing our own, so we view similarities as additional validation of our work. West and O'Mahoney missed several categories like the more fine-grain member levels and careers that we determined. In general, we are providing more details with our possible values for attributes and the constraints between them.

Xia et al. distinguish between output and process benefits that consortium members achieve [START_REF] Xia | Enhancing Value via Cooperation: Firms' Process Benefits From Participation in a Consortium[END_REF]. They take the view of a single company trying to gauge returns on participating in a consortium. Output benefits are derived from having a stake in the consortium's output. Process benefits take the form of social capital and learning that a company derives from participating. A survey shows these benefits and we expect the process benefits to apply to members of open source foundations as well.

Among the diversity of real consortia, open source foundations are closest to research and development (R&D) consortia. Aldrich et al. present a comparative study of R&D consortia in the U.S.A. and Japan [START_REF] Aldrich | Information Exchange and Governance Structures in U.S. and Japanese R&D Consortia: Institutional and Organizational Influences[END_REF]. They find that Japanese consortia all show similar structures and formalize long-standing inter-company relationships. In contrast, U.S.-based consortia show significant diversity in terms of organizational structure and processes and were more fluid than their Japanese counterparts. In contrast to these consortia, open source foundations tend to have an international perspective. Thus they tend to have little dependency on governmental support and despite necessary incorporation in a particular jurisdiction are more adjusted to international needs than their local and more traditional non-open-source counterparts.

Conclusions

This article presents a qualitative study of open source developer foundations. In a multiple-step process, it distills a model of the structure and governance of these foundations. The model takes the form of category, attribute, and possible-value triples that explain how to design such a foundation. To demonstrate the models usefulness, it is successfully applied to nine such foundations. The goal of this research is to provide to the leaders of community open source projects a guide for choosing an existing foundation or a blueprint for designing their own foundation.

Acknowledgments

We would like to thank the anonymous reviewers for their comments. We would also like to thank everyone who participated in the interviews. Finally, we would like to thank Wayne Beaton (Eclipse Foundation), Gervase Markham (Mozilla Founda-

•

  A model of community open source developer foundations that has been derived from a three-step qualitative study process • The comparison of nine open source foundations using this model and demonstrating its ability to capture the complexity of existing foundations The paper is structured as follows. Section 2 outlines our research process. Section 3 presents a model of community open source developer foundations. Section 4 applies the model to nine existing open source foundations and demonstrates its usefulness. Section 5 reviews related work and section 6 concludes the paper.

Table 2 :

 2 Model of Open Source Developer Foundations, Part 2royalties to the patent holder. This option is uncommon, because one of the reasons for creating a foundation is to avoid such legal uncertainty.• If a patent license grant is provided for-use, then the software can be used without paying royalties under the original open source license. A software developer who wants to sell software that embeds the open source code under a different license may have to pay the original patent holder royalties. • If a patent license grant is provided for use and embedding, a software developer can embed the open source code in a commercial product and sell the software under a commercial license without having to pay royalties to the patent holder.

Table 3 :

 3 Application of Model to 9 Foundations, Part 1West and O'Mahoney investigate corporate sponsorship of open source communities, some of which are organized as foundations[START_REF] West | The Role of Participation Architectures in Growing Sponsored Open Source Communities[END_REF]. They call "participation architec-

	5 Related Work

Table 4 :

 4 Application of Model to 9 Foundations, Part 2


Danila Piatov
email: danila.piatov@unibz.it

Andrea Janes
email: ajanes@unibz.it

Alberto Sillitti
email: asillitti@unibz.it

Giancarlo Succi Case

Using the Eclipse C/C++ Development Tooling as a Robust, Fully Functional, Actively Maintained, Open Source C++ Parser

Open Source parsers that support contemporary C/C++, can recover from errors, include a preprocessor, and that are actively maintained, are rare. This work describes how to use the parser contained in the Eclipse C/C++ Development Tooling (CDT) as a Java library. Such parser provides not only the abstract syntax tree of the parsed le but also the semantics, i.e., type information and bindings. The authors used the same approach to obtain Java and JavaScript parsers.

Programming language parsers are used by industry and research to create compilers or interpreters, statical code analysis tools, code metrics tools, source code editors with code completion, etc.

Parsing C/C++ is particularly tricky (e.g., a construct a * b can be a multiplication or a pointer denition depending on the type of a). Generic Open Source parser generators do not alleviate this task since the ambiguities cannot be resolved by a parser alone but require type information.

We searched for Open Source C++ parsers that include a preprocessor, perform semantic analysis (resolve type information and name bindings), are robust, and support contemporary C/C++ features. Of the found parsers, namely cpp-ripper, Elsa, GCC using the -fdump-translation-unit option, GCC_XML, Clang, and the Eclipse CDT parser only the latter 2 fullled the requirements.

We decided to opt for the Eclipse parser since the approach could also (and did) provide us with parsers for other languages like Java and JavaScript.

The actual parser is located in the le org.eclipse.cdt.core_X.jar, in the Eclipse installation folder, where X stands for version of the le. The jar itself is an Eclipse plugin, however, it is possible to use it as a Java library, without initializing the Eclipse platform.

The instruction org.eclipse.cdt.core.dom.ast.gnu.cpp.GPPLanguage. getDefault().getASTTranslationUnit(FileContent, IScannerInfo, IncludeFileContent-Provider, IIndex, int, IParserLogService) performs the actual parsing, returning an abstract syntax tree (AST). This work deals with an (apparently) simple problem: to nd a working C++ parser. Eclipse CDT contains such parser, but there is no ocial documentation about using it as a library outside of Eclipse. We hope that our poster can ll this gap and be of help.


Luis Corral
email: luis.corral@stud-inf.unibz.it

Andrea Janes

Tadas Remencius

Juri Strumpflohner

Jelena Vlasenko
email: jelena.vlasenko@unibz.it

A Novel Application of Open Source Technologies to Measure Agile Software Development Process

In the last 10 years Open Source products have been widely used in industry. New methodologies and best practices to develop Open Source software appeared. In this work, we present an application that runs on Android-based mobile phones and collects proximity data with other devices via Bluetooth. The application gives new insights into measuring proximity inside a team of software developers. Data collection process is automatic so that the team members are not distracted from their daily activities. The collected data represent time frames when developers work alone at their machines and when they do Pair Programming with their colleagues.

Introduction

In the last 10 years Open Source based products have been widely used in industry [START_REF] Gurbani | A case study of open source tools and practices in a commercial setting[END_REF], including platforms for mobile devices. For example, from the several operating systems for mobile phones (iOS, RIM OS, Windows Mobile, Android, etc), Open Source Android OS stands out as one of the leading platforms. Android is based on Linux, and ships with tools that provide significant support support for mobileoriented software development. Moreover, Android OS supports many technologies, e.g. 3G, WiFi, Bluetooth, and many others, making it a powerful platform. Taking advantage of such technologies and its Open Source nature, it opens a new space for mobile software development. In this work, our focus is to take advantage of these characteristics and exploring how Open Source platforms and tools can be leveraged for measuring software development process.

Starting in the early '90s there have been several proposals for metrics for software processes and products [START_REF] Abrahamsson | Effort prediction in iterative software development processes--incremental versus global prediction models[END_REF][START_REF] Coman | A case-study on using an automated in-process software engineering measurement and analysis system in an industrial environment[END_REF][START_REF] Fenton | New directions for software metrics[END_REF][START_REF] Succi | Package-oriented software engineering: a generic architecture[END_REF]. Since then, the way in which people develop software has changed dramatically. To determine how software is developed, there have been several studies that have been dedicated to automatic and non-invasive observation of behavior of software developers [START_REF] Coman | A case-study on using an automated in-process software engineering measurement and analysis system in an industrial environment[END_REF], in terms of code quality [START_REF] Moser | Does refactoring improve reusability? Reuse of Off-the-Shelf Components[END_REF], time to market, effort distribution [START_REF] Abrahamsson | Effort prediction in iterative software development processes--incremental versus global prediction models[END_REF], knowledge transfer, etc.

The purpose of our research is to take advantage of such experience and to propose a new set of tools and methodologies to collect and interpret software metrics coming from emerging software production environments [START_REF] Janes | Identification of defect-prone classes in telecommunication software systems using design metrics[END_REF], making use of technologies and possibilities that mobile resources offer. In this paper, we present DroidSense, a mobile application for Android based smartphones, that utilizes Bluetooth technology to measure proximity between team members. Using these data we can detect when developers work alone and when they do Pair Programming, working collaboratively on one task using a single machine.

Related Work

There have been several works aiming to compare existing mobile operating systems in terms of different quality characteristics. In [START_REF] Anvaari | Evaluating architectural openness in mobile software platforms[END_REF], authors evaluate architectural openness of iPhone, Windows Mobile, Android, and others. The results evidence that Android and Symbian are more open for modifications than other platforms, making them attractive to carry out research and experimentation.

In [START_REF] Sundstrom | Sketching in Software and Hardware Bluetooth as a Design Material[END_REF], authors explore Bluetooth potentials for designing interacting systems. Several benefits and weaknesses of this technology have been identified, for example, Bluetooth chips can be carried by a person or placed in a specific location. Device names can be easily changed to uniquely identify persons or groups. With this, from the obtained data it is always possible to detect what kind of device has been encountered. However, Bluetooth is limited by short-range radio technology, so that only nearby located devices can be detected. Several scans might be needed to identify all the participating devices. For product assessment, in [START_REF] Smith | BlueMonarch: A System for evaluating Bluetooth applications in the wild[END_REF] authors developed BlueMonarch, an application to evaluate Bluetooth-based applications.

In this study, we take advantage of such technologies and to apply them for software metrics collection. There is also a significant number of devices supporting Bluetooth communications: phones, headsets, hand-helds, laptops, etc. Some of such devices, like phones and headsets, very often are carried by people wherever they go, thus, the presence of such devices can provide a detailed map of the physical activities that developers do during their work, meetings, etc. Tools using Bluetooth to determine proximity exist, like ReduxComputing-Proximity [5], Where's Blue [START_REF] Engelsma | EncounterEngine: Integrating Bluetooth user proximity data into social applications[END_REF], and Proximity Data Gathering For Android Through Bluetooth [START_REF] Pullabhatla | Proximity data Gathering for Android through Bluetooth[END_REF]. However, they are primitive and not yet adopted to extract detailed software metrics.

A Novel Application of Open Source Technologies to Measure Agile Software Development Process 3

DroidSense

DroidSense is a system for the automated collection of proximity information between developers for software process analysis. DroidSense consists of a mobile Android application and a central server component responsible for receiving, storing, and analyzing the data. The collected data can then be viewed and analyzed through an according web interface providing different kinds of visualizations. The structure of the system is shown in Figure 1:

Fig. 1. High Level System Architecture
DroidSense Android client is the core component of the system, being responsible for the data collection. It has been designed to be easily extensible to allow the development of future Android activities that are able to attach to its functionality. The end-user mainly interacts with the Android client that collects and uploads the data to the server. The main user interface presented to the user when he starts the application is the list showing all of the discovered Bluetooth devices.

By selecting an entry of the device list, the according device detail view opens. In addition to the device's detail information, it presents the collected proximity raw data in descending order, showing the most recent value on top of the list. Each entry shows the calculated value on top, followed by the raw value that has been returned from the Bluetooth adapter as well as the time stamp of the discovery.

DroidSense server, on the other hand, is responsible of storing and analyzing the collected values by all of the DroidSense Android clients. It has been implemented by using a conjunction of Open Source-only application frameworks, on top of J2EE and Spring. Spring supports Hibernate, which has been used to perform the objectrelational mapping to the underlying MySQL database. Open source technologies JDOM and Castor prepare the XML received from DroidSense services into Java objects that can be understood by JDBC to communicate with the database instance. For the web front-end, the Spring Web MVC framework has been used with JSP and jQuery.

4

DroidSense in Action

Case Study

To gain experience on the collection of data using our tool, as well as to prove their practical usability for the purpose of software process measurement, it was conducted an experiment of the use of DroidSense by a professional team. An initial implementation of the prototype took place on a team of 10 programmers, members of a software development team in a University Research Center which uses Agile practices such as Extreme Programming, Pair Programing, and Test-Driven Development. All participants joined the experiment in a voluntary basis.

The experiment covered a period of 3 months. Through the whole phase, more than 240,000 proximity values have been transmitted by the 10 participants. The samples were analyzed with the purpose of reconstructing the whole -or at least significant parts-of the software development process, based on human interaction. For privacy reasons, all personal names have been obfuscated.

Interpretation of Data Samples

An example on how data are interpreted is depicted in Figure 2, which shows a visualization of the raw data collected on a regular working day, from the viewpoint of developer UE at the University, our experimental setup. The y-axis shows the RSSI indicator, where lower values indicate shorter distances. The x-axis shows the time of the day in hours.

Fig. 2. Raw Values Collected at the University Research Center

The visualization contains data of the devices:

• PE: UE's personal laptop, used at work (triangles)

• MM: DroidSense-equipped Android phone of a member of UE's team (points) • MS: Android phone with DroidSense, member of UE's team (squares) Figure 3 shows an interpretation of the data acquired by DroidSense, saying that MM was near to PE during the whole period of the scan, while MS dropped in for a small amount of time at the beginning and the end of the scan (as seen in Figure 2). A pair programming session between user UE and MM can be inferred: On the other hand, another pair programming session took place in front of the workstation of UE itself, while the pair programming session shown previously was in front of the teammate's computer. The output is not presented as a list of detailed session detections, but rather the aggregated information of all of them. This helps on giving an overview of the activities performed through the day. It can be seen that the raw data is correctly interpreted, showing the user MS only appear for a small amount of 5 minutes during the scan period, while there is a longer pair programming session with MM.

Project's team managers at the Research Center reported a clearer identification of the execution of pair programming sessions, recognizing how devices group in front of a particular workstation for a given amount of time. DroidSense was useful to understand the interaction among developers: the distance between users and devices can be appraised, allowing to observe how such distance shifts when one user approaches a colleague, leaving his own workstation. This visualization was reported by the team managers as suitable to conduct further analysis on the importance of people's physical distribution in the way a team collaborates.

Conclusions

Measurement has become a major factor of importance in software development.

Project deadlines, limited budget and high customer expectations require the continuous search for optimizing existing processes.

In this work we presented a new approach in collecting data about Agile software development process by leveraging proximity measurements gathered using the Bluetooth technology through DroidSense, a system for Android OS which implements a software solution to characterize developer's interaction using data gathered from their own mobile devices. Thanks to an experiment with several developers conducting an Agile software development project, we present the practical use of DroidSense and the resulting process analysis. Using DroidSense shows that the collected data provides a valuable insight in the stakeholder's interactions within the process by automatically detecting a developer's involvement in computer work or pair programming sessions.

Using a widely spread technology such as Bluetooth, an Open Source operating platform like Android, and a wide range of Open Source frameworks and tools allows a team to slim down the development investment without losing the functionality required by architecture, design and implementation demands. Moreover, there is no costly setup required but installing a mobile app, and engineers do not have to undergo a major training phase or adapt their working habits.

Fig. 3 .

 3 Fig. 3. Calculated Sessions at the University Research Center