Chris Jensen
email: cjensen@uci.edu

Walt Scacchi
email: wscacchi@uci.edu

License Update and Migration Processes in Open Source Software Projects

Keywords: Open source, license evolution, process, Apache, NetBeans

Open source software (OSS) has increasingly been the subject of research efforts. Central to this focus is the nature under which the software can be distributed, used, and modified and the causes and consequent effects on software development, usage, and distribution. At present, we have little understanding of, what happens when these licenses change, what motivates such changes, and how new licenses are created, updated, and deployed. Similarly, little attention has been paid to the agreements under which contributions are made to OSS projects and the impacts of changes to these agreements. We might also ask these same questions regarding the licenses governing how individuals and groups contribute to OSS projects. This paper focuses on addressing these questions with case studies of processes by which the Apache Software Foundation's creation and migration to Version 2.0 of the Apache Software License and the NetBeans project's migration to the Joint Licensing Agreement.

Introduction

Software process research has investigated many aspects of open source software (OSS) development in the last several years, including release processes, communication and collaboration, community joining, and project governance. The central point of Lawrence Lessig's book "Code" is that the hardware and software that make up cyberspace also regulate cyberspace. He argues that code both enables and protects certain freedoms, but also serves as to control cyberspace. Software licenses codify these freedoms and regulations by setting forth the terms and conditions for software use, modification, and distribution of a system and any changes made to it. For that reason, others have suggested that licenses serve as contracts for collaboration. In the case of non-OSS licenses, that contract may indicate no collaboration, but rather strict separation between users and developers. OSS licenses, by contrast range widely in permissiveness, some granting more rights to the original authors and some granting more rights to consumers of OSS software. While research has examined OSS licenses to great detail, we are only beginning to understand license evolution. Just as OSS code is not static, neither are the licenses under which it is distributed. Research into license evolution is just beginning. However, when licenses change, so too the contracts for collaboration change. This paper seeks to provide an incremental step to understanding how changes in software licensing impact software development processes.

Why does understanding license update and migration matter? Companies using OSS software need to know how changes affect their use, modification, and distribution of a software system. License compatibility in OSS has long been a topic of debate. Research is only beginning to provide tools for assistance in resolving software license compatibility [START_REF] Scacchi | The Role of Software Licenses in Open Architecture Ecosystems[END_REF]. OSS project participants need to understand why changes are being made, whether the changes align with their values and business models (e.g., enabling new avenues of license compatibility offering strategic benefit or opening up new channels of competition). As a project sponsor or host, you may be concerned about how to best protect both the software system and your user community, but also your business model. You typically want a license that will attract a large number of developers to your project [START_REF] Lindman | Choosing an Open Source Software License in Commercial Context: A Managerial Perspective, Software Engineering and Advanced Applications[END_REF] while at the same time allowing you to make a profit and stay in business.

While licenses such as the GNU General Public License (GPL), the Berkeley Software Distribution (BSD) license, and the Apache License are well known, we rarely consider another type of license agreement critical to understanding collaboration in OSS projects: individual contributor license agreements (CLAs) and organizational contributor license agreements (OCLAs), for contributos from organized entities. In non-OSS software development, the contract for collaboration is typically an employment contract, often stating that all intellectual property rights pertaining to source code written by an employee are property of the employer. This provides the employer with complete control of the rights granted of licensed software. In OSS development, you have a situation where multiple developers are contributing to a software system. Without copyright assignment or a CLAs, changing a software license requires the consent of every contributor to that system. We observed this situation in the case of the Linux kernel, which suggested that without a CLA, license evolution can become inhibited or prevented as the number of contributors, each with differing values and objectives, increases. To understand how changes in software licenses affect software development processes, we must also investigate changes in CLAs.

We address these issues with two case studies. The first examines the creation and deployment of the Apache Software License, Version 2.0. The second looks at an update to the contributor license agreement in the NetBeans project.

Background Work

Legal scholars, such as St. Laurent [START_REF] St | Understanding Open Source and Free Software Licensing[END_REF] and Larry Rosen [START_REF] Rosen | Open Source Licensing: Software Freedom and Intellectual Property Law[END_REF], former general counsel and secretary for the Open Source Initiative (OSI), have written extensively on license selection. They note that quite often, the choice of license is somewhat outside the control of a particular developer. This is certainly the case for code that is inherited or dependent on code that is either reciprocally licensed, or at the very least, requires a certain license for the sake of compatibility. However, outside such cases, both St. Laurent and Rosen advocate for the use of existing and well-tested, well-understood licenses as opposed to the practice of creating new licenses. Such license proliferation is seen as a source of confusion among users and is often unnecessary given the extensive set of licenses that already exist for a diverse set of purposes. Lerner and Tirole [START_REF] Lerner | The Scope of Open Source Licensing The Journal of Law[END_REF] observe specific determinant factors in license selection. Of the 40,000 Sourceforge projects studied, projects geared towards end-users tended towards more restrictive license terms, while projects directed towards software developers tended towards less restrictive licenses. Highly restrictive licenses were also found more common in consumer software (e.g., games) but less common for software on consumer-oriented platforms (e.g., Microsoft Windows) as compared to non-consumeroriented platforms. Meanwhile, Rosen specifically addresses the issue of relicensing, commenting that license changes made by fiat are likely to fracture the community. This case of relicensing is exactly the focus of our case studies here.

The drafting and release of the GNU General Public License, Version 3.0 was done in a public fashion, inviting many prominent members of the OSS community to participate in the process. In fact, we even see a sort of prescriptive process specification outlining, at a high level, how the new license was to be created. This license revision process is interesting from the perspective that the license in question is not used by one project or one foundation, but rather is an update of the most commonly used open source license in practice. As such the process of its update and impact of its revision on software development is both wide ranging and widely discussed.

Di Penta, et al. [START_REF] Di Penta | An exploratory study of the evolution of software licensing[END_REF], examined changes to license headers in source code files in several major open source projects. Their three primary research questions sought to understand how frequently licensing statements in source code files change, the extent of the changes, and how copyright years change in source code files. Their work shows that most of the changes observed to source code files are small, though even small changes could signify a migration to a different license. The authors also note that little research available speaks to license evolution, pointing to the need for greater understanding in this area.

Lindman, et al., [START_REF] Lindman | Choosing an Open Source Software License in Commercial Context: A Managerial Perspective, Software Engineering and Advanced Applications[END_REF] examine how companies perceive open source licenses and what major factors contribute to license choice in companies releasing open source software. The study reveals a tight connection between business model, patent potential, the motivation for community members to participate in development, control of project direction, company size, and network externalities (compatibility with other systems) and licensing choice.

Lindman, et al., provide a model of a software company, its developers, and users in the context of an OSS system developed and released from a corporate environment [START_REF] Lindman | Choosing an Open Source Software License in Commercial Context: A Managerial Perspective, Software Engineering and Advanced Applications[END_REF]. However, few systems are developed in complete isolation. Rather, they leverage existing libraries, components, and other systems developed by third parties. Moreover, as Goldman and Gabriel point out, open source is more than just source code in a public place released under an OSS license [START_REF] Goldman | Innovation Happens Elsewhere: How and Why a Company should Participate in Open Source[END_REF]; communities matter. Fig. 1 shows the production and consumption of open source software, highlighting the impact of software licenses and contributor license agreements.

Fig. 1. A model of software production and consumption with open source licensing

Going a step further, Oreizy [START_REF] Oreizy | Open Architecture Software: A Flexible Approach to Decentralized Software Evolution[END_REF] describes a canonical high-level software customization process for systems and components, highlighting intra-organizational software development processes and resource flow between a system application developer, an add-on developer, a system integrator, and an end user.

Similarly, we have examined such concepts in the context of software ecosystems [START_REF] Jensen | Process Modeling Across the Web Information Infrastructure[END_REF] in the context of process interaction. Software license change can precipitate integrative forms of process interaction in the case of dual and multi-licensing by enabling new opportunities for use of software systems upstream of a project to provide added functionality or support, as well as projects downstream vis a vis use as a library, plugin development, support tool development, and via customization and extension. In such cases, software source becomes a resource flowing between interacting projects. However, license change can also trigger interproject process conflict if new license terms render two systems incompatible. At that point, the resource flow between projects can be cut off, when downstream consumers of software source code no longer receive updates. A more common example with non-OSS is license expiration. License-based interproject process conflicts can also manifest as unmet dependencies in software builds or an inability to fix defects or add enhancements to software, resulting in process breakdown, and failing recover, project failure. OSS licenses, however, guarantee that even when conflict occurs, recovery is possible because the source is available and can be forked.

Methodology

The case studies in this report are part of an ongoing, multi-year research project discovering and modeling open source software processes. Our research methodology is ethnographically informed, applying a grounded theory to the analysis of artifacts found in OSS projects. The primary data sources in this study come from mailing list archives of the Apache and NetBeans projects.

Our primary data sources were mailing list messages. However, we also found supplementary documentation on each project's websites that served to inform our study. These supplementary documents were often, though not always referenced by the messages in the mailing list. Cases regarding the NetBeans project all took place between April and June of 2003, involving over 300 email messages, whereas the Apache cases were spread over several discrete time periods and consisted of more than 350 messages.

Case selection happened in two ways. For NetBeans, the cases arose during our study of requirements and release processes, having stood out as prominent issues facing the community during the time period studied. Although we observed additional incidents appropriate for discussion, the three cases selected fit together nicely as a cohesive story. This approach was also used in the study of the Apache project. However, due to a lower incident frequency, we expanded our study over a longer time period to find incidents that proved substantial. As a testament to the nature of project interaction, issues raised in mailing list discussions proved to be short-lived, either because they were resolved quickly or because the conversation simply ceased.

It is possible to suggest this is the normal behavior pattern for both projects. A few issues proved outliers, having more focused discussions, and these were selected for further study. We also observed a tendency for discussions to play out in a series of short-lived discussions sessions. A topic would be raised, receiving little or no attention. Then, at a later time, it would be raised again. The JCA discussion in NetBeans and Subversion migration discussion in the Apache project demonstrated such conversational resurgence. We observed, in general, that discussion topics carry certain conversational momentum. Topics with a high degree of momentum tended to have lengthier discussion periods or frequent discussion sessions until fully resolved or abandoned while topics with a low degree of momentum were addressed quickly or simply died off. The causes and factors affecting changes in momentum were not investigated as they laid too far afield from the focus of this study. We do note that although consensus by attrition has been cited in other communities (e.g., [10 and 11]), we did not observe it in effect in any of the cases studied, but rather that the primary participants in discussions remained active in their respective projects for several months following the reported incidents. The creation of the Apache License, version 2.0 was directed to us by a colleague familiar with the project. Data for the Apache licensing case was gathered from email messages sent to a mailing list established for the purpose of discussing the proposed changes.

Considering the difficulties we experienced with building our own search engine to support process discovery, we still faced the challenge of keeping track of process data once we found it as we were building our models. Up until this point, our approach to providing process traceability was simply to include links to project artifacts in our models. However, this strategy did not help us build the models, themselves. We returned the search problem back to the projects, themselves using their own search engines to locate process data, looking for more lightweight support for discovery.

Our current strategy for providing computer support for process discovery returns to using each project's own search engine to locate process information. We have operationalized the reference model as an OWL ontology with the Protégé ontology editor [START_REF][END_REF], using only the OWL class and individual constructs to store process concepts and their associated search queries respectively. Secondly, we built a Firefox plugin, Ontology [13], to display the reference model ontology in the Firefox web browser. Next, we enlisted the Zotero citation database Firefox plugin [14] to store process evidence elicited from project data, integrating the two plugins such that each datum added to the citation database from a project artifact is automatically tagged with the selected reference model entities.

The use of a citation database as a research data repository may seem unintuitive. Zotero, however, has proven well suited for our needs. Like many Firefox plugins, Zotero can create records simply from highlighted sections of a web document, though the creation of arbitrary entries (not gleaned from document text selections) is also possible. It can also save a snapshot of the entire document for later review, which is useful given the high frequency of changes of some web documents-changes that evidence steps in a software processes. The tag, note, and date fields for each entry are useful for recording reference model associations and memos about the en-try for use in constructing process steps and ascertaining their order. A screenshot of Zotero with Ontology appears in Fig. 2.

The plugin integration greatly facilitates the coding of process evidence and provides traceability from raw research data to analyzed process models. As the tool set is browser-based, it is not limited to analysis of a particular data set, whether local or remote. Moreover, the tool set does not limit users to a single ontology or Zotero database, thereby allowing users to construct research models using multiple ontologies describing other (e.g. non-OSS process) phenomenon and reuse the tool set for analysis of additional data sets. Thus, it may be easily appropriated for grounded theory research in other fields of study.

The elicitation of process evidence is still search driven. Rather than use one highly customized search engine for all examined data repositories, the search task has been shifted back to the organizations of study. This decision has several implications in comparison with the previous approach, both positive and negative. Using an organization's own search engine limits our ability to extract document-type specific metadata, however among the organizations we have studied, their search tools provide greater coverage of document and artifact types than Lucene handled at that time. Furthermore, this approach does not suffer the data set limitations imposed by web crawler exclusion rules. The ability to query the data set in a scripted fashion has been lost, yet some scientists would see this as a gain. The use of computer-assisted qualitative data analysis software (CAQDAS) historically has put into question the validity of both the research method and results [15,16].

Fig. 2. Data capture in Firefox with Zotero and Ontology

This tool was still quite unfinished as we began governance process discovery and modeling. As we added functionality, we had to return to some of our data sources and recapture it. Although we have high hope to use the integrated timeline feature to assist in process activity composition and sequencing, the time and date support within Zotero's native date format was insufficiently precise. With provisions only for year, month, and day, there is no ability to capture action sequences that happen on the same day. After adding support for greater date and time, we found having to enter the date and time for every piece of data we captured rather tedious. Eventually we have had to prioritize completion of discovery and modeling ahead of computersupport for process discovery, and we had to disable the time and date entry. Unable to utilize Zotero to our intended effect in discovery and modeling, our efforts with Zotero remain in progress, pending usability improvements.  Requiring a patent license on contributions that necessarily infringe the contributor's own patents  Moving the full text of the license and specific conditions outside the source code  Roy further indicated a desire to have a license compatible with other OSS licenses, notably the GPL. As you can see from Fig. 3, most of the discussion took place in mid November of 2003. In fact, given that the ApacheCon conference that ran from 16-19 November, we can see a high message density in the days leading up to ApacheCon, with a steady rate continuing on for a few days afterward. Beyond this, the frequency becomes sparse. An update to the proposed license was announced on 24 December 2003, after some internal review, a part of the process that is not publicly visible. This update prompted a brief discussion. A second active time period is observable in January 2004, when Fielding announces a final update (20 January 2004) and that the final version of the license has been approved by the board [18 and 19] (21 January 2004).

The primary discussion point of the creation and migration to the 2.0 version of the Apache License centered around a patent clause in the proposed license. According to Brian Behlendorf, who was serving on the ASF board of directors at the time, the ASF's patent-related goals were to "prevent a company from sneaking code into the codebase covered by their own patent and then seeking royalties from either the ASF or end-users" [20]. The clause in question read:

Reciprocity. If You institute patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to You under this License shall terminate as of the date such litigation is filed. In addition, if You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work itself (excluding combinations of the Work with other software or hardware) infringes Your patent(s), then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. [21]

Consequences of this clause sparked discussion in a few areas, mainly surrounding the first sentence of the clause regarding license termination. Legal representatives from industry stated objections to losing usage rights for patent litigation regarding any software, even software unrelated to that covered by the license [22], proposing alternative wordings to achieve the stated license goals but restricting the trigger to litigation pertaining to patents covered by the ASF licensed code [23]. Uncertainty regarding the roles of people in the license revision process [24] and proposed changes [25] created additional confusion regarding the patent reciprocity stance.

Eben Moglen, General Counsel for the Free Software Foundation (FSF), adds that the first sentence of the license clause carries great risk for unintended and serious consequences, and is an inappropriate vehicle for protecting free software against patent litigation [26]. As such, the FSF has deemed the clause causes the license to be incompatible with version 2 of the GPL, failing one of the goals of the proposed Apache License.

Brian Carlson reports that the Debian community's consensus is that the proposed license does not meet the criteria for Free Software Licenses under the Debian Free Software Guidelines [27]. Consequently, code licensed as such would sandboxed into the non-free archive, and therefore, not automatically built for Debian distributions, nor receive quality assurance attention. Again, the license termination aspect of the reciprocity clause is cited as the critical sticking point [28], with several members of the Debian community arguing that free software licenses should only restrict modification and distribution, but not usage of free software.

The patent reciprocity clause was not entirely rejected. There was support for extending it to provide mutual defense against patent litigation attacks against all open source software [29]. The idea was quickly nixed on the grounds that it could lead to users being attacked and unable to defend themselves if someone were to maliciously violate a user's patent on an unrelated piece of software and create an open source version. In such a scenario, the user would have to choose between using Apache licensed software and losing all their patents [30].

On 18 November, Fielding indicates that there have been "several iterations on the patent sentences, mostly to deal with derivative work" [24], mentioning he will probably include the suggested changes in the patent language recommended by one of the legal representatives from industry. Fielding notes that he has been in contact with representatives from other organizations, among them Apple, Sun, the OSI, Mozilla, and a few independent attorneys, although the details of these portions of the process remain hidden.

The next milestone in the process occurs on 24 December, when Fielding mentions that a second draft, version 1.23, has been prepared after internal review due to extensive changes [31], and has been posted to the proposed licenses website [32] and the mailing list. The new proposed license [33] incorporates many of the proposed changes, including the removal of the contested first sentence of the patent reciprocity clause, leaving the generally agreed upon patent termination condition:

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

The 1.23 version of the license received little feedback on the license discussion mailing list. Aside from definition clarifications, there was an inquiry about GPL compatibility. Behlendorf commented that Moglen's suggestions had been incorporated to address the two issues with GPL compliance, but he had been contacted earlier in the week to take a look at the current draft [34]. As a result, Behlendorf (on 7 January 2004) offers that the issues presented have been addressed to his satisfaction and is willing to propose the license to the board at the January 2004 meeting [35]. However, before the board meeting, Fielding announces a version 1.24, featuring a change to the definition of "Contributor" [36] and a 1.25 version very shortly thereafter to address the way "Copyright" is represented due to various laws and the use of "(C)" to indicate copyright [37]. Finally, the Apache License, Version 2.0 was approved by the ASF board by a unanimous vote on 20 January 2004 [18] and announced to the mailing list by Fielding the following day [19]. Per the board meeting minutes:

WHEREAS, the foundation membership has expressed a strong desire for an update to the license under which Apache software is released, WHEREAS, proposed text for the new license has been reworked and refined for many, many months, based on feedback from the membership and other parties outside the ASF, NOW, THEREFORE, BE IT RESOLVED, that the proposed license found at http://www.apache.org/licenses/proposed/LICENSE-2.0.txt is officially named the Apache Software License 2.0. To grant a sufficient transition time, this license is to be used for all software releases from the Foundation after the date of March 1st, 2004.

The conversation continued on, briefly, to address two points. Firstly, a return to the GPL compatibility discussion. Don Armstrong requested verification as to whether Moglen/the FSF has identified the license as GPL compatible (Fielding's announcement claimed it was) [38]. Fielding responds, saying Moglen sent a private communication commenting on the license compatibility, and furthermore, that it was the belief of the ASF that "a derivative work consisting of both Apache Licensed code and GPL code can be distributed under the GPL," and, as such, there wasn't anything further to consider, as far as the ASF was concerned [39]. Incidentally, the FSF standing is that due to the patent issue, the Apache license 2.0 is GPL3 compatible but not GPL2 compatible [40]. Secondly, Vincent Massol requested information about moving his Apache sub-project to the ASL2 license and what file license headers should be used [41], to which Behlendorf responds [42]. A flow graph of the License creation and migration process appears in Fig. 4.

1. So the project can defend itself in court without the participation and approval of its contributors.

2. To give the project (and not the contributor) the right to make licensing decisions, such as relicensing, about the software

The NetBeans case is interesting because it is not simple copyright assignment, but rather affords both the contributor and the project (Sun Microsystems, specifically) equal and independent copyright to contributed source.

The Joint License Agreement (JLA) was introduced to the NetBeans project on 28 April 2003 by Evan Adams, a prominent project participant working for Sun Microsystems [43]. Adams states that the JLA was being introduced in response to observa- Under the proposed agreement, contributors (original authors) would retain all copyrights independently for project contributions and any previous contributions whose authors did not agree to the terms of the JCA would have to be removed from the source tree. The discussion spanned ninety messages from seventeen individuals over nearly two months, with a follow-up discussion consisting of forty six messages from fourteen individuals (eleven of whom participated in the earlier discussion) over a third month. The discussion, which began at the end of April 2003 continued through July (with a few sporadic messages extending out to September), long after the deadline for requiring JLA for project contributions.

The process for the license format change seems simple. The particulars of the proposed license received early focus in the discussion. As the discussion progressed, concern shifted away from details of the license agreement to the way in which the In the course of discussion, it was revealed that switching to the JLA was an idea proposed by the Sun legal counsel and the decision to adopt it was done internally, unilaterally, and irrevocably by Sun without the involvement of the project, at large. The adoption decision raised questions regarding the decision rights and transparency within the project. While recognizing that Sun-employed contributors were responsible for a majority of project effort, non-Sun contributors took the lack of transparency and consideration in the decision making process as disenfranchisement. In a follow-up discussion, project members further expressed fears that giving Sun full copyright of contributed code could lead to reclassification of volunteer-contributed code in objectionable ways. More significantly, they feared the change could impact copyright of projects built upon the NetBeans codebase, but not contributed back to NetBeans source repository.

In time, most of the "corner case" concerns about the license agreement were addressed. However, ultimately non-Sun employed contributors were still in the position of having to trust Sun to act in an acceptable manner with a grant of full copyright. Moreover, the discussion drew out larger concerns regarding Sun's role position of leadership and control of the project, and regarding transparency in decision making. A flow graph of the JCA introduction process appears in Fig. 5.

Discussion and Conclusions

The two cases presented are not directly comparable. The Apache study looks at the process of creating a new license, to be used by all projects under the domain of the Apache Software Foundation. The NetBeans study focuses on the adoption of a new license agreement for contributors to the NetBeans IDE and platform. Software source licenses govern the rights and responsibilities of software consumers to (among other things) use, modify, and distribute software. Contributor license agreements (CLAs), on the other hand, govern the rights and responsibilities to (among other things) use, modify, and distribute contributions of the organization to which the contributions are submitted, and those retained by the contributor. The new CLA stated that copyright of project contributions would be jointly owned by the originating contributors, as well as the project's benefactor, Sun Microsystems. Code contribution agreements may not be of interest to end users of software executables. However, the OSS movement is known for its tendency towards user-contributors; that is, users who contribute to the development of the software and developers who use their own software.

If we consider, specifically, the license changes in the Apache and NetBeans projects, both were introduced as inevitable changes by persons of authority in each project (founder Roy Fielding of Apache and Evan Adams of Sun Microsystems for NetBeans). The initiators of the discussion both presented the rationale for making the changes. For Apache, the move was motivated by a desire to increase compatibility with other licenses, reduce the number of questions about the Apache license, moving the text outside the source code, and require patent license on contributions where necessary. For NetBeans, the motivations were to protect the project from legal threats and provide Sun the ability to change the license in the future. In the Apache case, the motivations for making the changes went unquestioned. The discussion focused on what objectives to achieve with the change and how best to achieve them. The former had to do with a (minority) subset of participants who saw the license change as an opportunity to affect software development culture, altering the direction of the software ecosystem as a means of governance on a macro level. The latter had to do with making sure the verbiage of the license achieved the intended objectives of the license without unintended consequences (such as those whose nature was of the former). In the NetBeans case, the discussion focused on the differences between the licenses and their affect on non-sponsoring-organization participants (meso-level project governance) of the license. Given the context of the surrounded cases, the structural and procedural governance of the project was also questioned.

The area of the NetBeans license change that received the greatest push-back was granting the sponsoring organization the right to change the license unilaterally at any point in the future. This right was similarly granted to the ASF in the Apache contributor license agreement (CLA) [44], a point that was not lost on participants in the NetBeans license change discussions [45]. Why did this issue receive push-back in NetBeans and not Apache? West and O'Mahony [START_REF] West | Contrasting Community Building in Sponsored and Community Founded Open Source Projects[END_REF] suggest caution that, unlike community-initiated projects, sponsored OSS projects must achieve a balance between establishing pre-emptive governance design (as we saw here) and establishing boundaries between commercial and community ownership and control. The surrounding cases served to create an atmosphere of distrust within the project. The distrust led to fears that contributions from the sponsoring organization would become closed off from the community, perhaps saved for the organization's commercial version of the product, leaving the sponsoring organization as free-riders [47 and 48] profiting off of the efforts of others without giving back [START_REF] Hedhman | mailing list message dated[END_REF] or otherwise limit what project participants can do with project code.

Perhaps the most striking difference in the way the two license changes were introduced is that the Apache case invited project participants (as well as the software ecosystem and the public, at large) to be a part of the change, whereas the NetBeans case did not. Participants in the NetBeans project were left without a sense of transparency in the decision-making process in that the change was put on them without any warning before the decision was made. Moreover, they were left without representation in the decision-making process in that they did not participate in determining the outcome of a decision that had a large impact on them. This is not to say that the Apache case was entirely transparent. There are clear indications from the messages on the list that conversations were held off-list. Likewise, there were misconceptions over what roles participants played and participant affiliation. However, the process was not questioned, nor the result.

In conclusion, we have taken a first step to understanding how license change processes impact software development processes by discovering and modeling the update process for the Apache License and the update to the contributor license agreement in the NetBeans project. We observed how differences in the processes in introducing change intent influenced response to the changes. To put these cases into context, NetBeans underwent two license changes since the events described above, neither of which received significant push-back from the community. The first shifted the license to the CDDL. The second was a move to dual license NetBeans under the GPLv2. This second licensing shift was considered by Sun "at the request from the community" [START_REF]NBDiscuss mailing list message[END_REF]. Unlike the introduction of the JCA, the GPL shift was presented to the community by Sun for feedback (in August 2007) as an added option (rather than a complete relicensing) before the change was made. Thus, we can clearly see further change in the processes used to govern the community in a way that directly addressed the defects in the project's governance processes circa 2003. Shah [START_REF] Shah | Motivation, governance and the viability of hybrid forms in open source software development[END_REF] echoes these concerns, observing that code ownership by firms creates the possibility that non-firm-employed contributors will be denied future access to project code. In other projects, these threats can lead to forking of the source, as happened when the MySQL corporation was purchased by Sun Microsystems, which, in turn, has recently been acquired by Oracle.

4Fig. 3 .

 3 Fig. 3. Timeline of the Review and Approval of the Apache License, Version 2.0

Fig. 4 .

 4 Fig. 4. Process flow graph for Apache License Version 2.0 creation

Fig. 5 .

 5 Fig. 5. NetBeans JCA introduction process flow graph

Acknowledgements. The research described in this report is supported by grants from the Center for Edge Power at the Naval Postgraduate School, and the National Science Foundation, #0534771 and #0808783. No endorsement implied.

Editor Project, available online at http://protege.stanford.edu/ [last accessed 23 June, 2008] 13.The Firefox Ontology Plugin project available online at http://rotterdam.ics.uci.edu/development/padme/browser/ontology [last accessed 23 June, 2008] 14.The Zotero Project, available online at http://www.zotero.org/ [last accessed 23 June, 2008] 15.Bringer, J. D., Johnston, L. H., Brackenridge, C. H.: Using Computer-Assisted Qualitative Data Analysis Software to Develop a Grounded Theory Project Field Methods, 18(3): 245-266 (2006) 16.Kelle, U.: Theory Building in Qualitative Research and Computer Programs for the Management of Textual Data Sociological Research Online, 1997, 2(2) available online at http://www.socresonline.org.uk/socresonline/2/2/1.html [last accessed 23 June 2008] 17.Fielding, R.: Message dated Sat, 08 Nov 2003 02:39:09 GMT "Review of proposed Apache License, version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archive-license/200311.mbox/%3cBAAB287A-1194-11D8-842D-000393753936@apache.org%3e, last acccessed 14 August 2009 18.Board meeting minutes of The Apache Software Foundation, January 2004, available online at http://apache.org/foundation/records/minutes/2004/board_minutes_2004_01_21.txt , last accessed 13 August 2009 19.Fielding, R.: Mailing list message dated Sat, 24 Jan 2004 01:34:36 GMT "Apache License, Version 2.0 ," available online at http://mailarchives.apache.org/mod_mbox/archive-license/200401.mbox/%3C781EEF08-4E0D-11D8-915D-000393753936@apache.org%3E, last accessed 13 August 2009 20.Behlendorf, B.: Mailing list message dated Sat, 22 Nov 2003 07:31:40 GMT "RE: termination with unrelated trigger considered harmful," available online at http://mail-archives.apache.org/mod_mbox/archivelicense/200311.mbox/%3C20031121232552.X38821@fez.hyperreal.org%3E, last accessed 13 August, 2009 21.Carlson, B. M.: Mailing list message dated Sat, 8 Nov 2003 10:03:55 +0000 "Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]," availa-ble online at http://lists.debian.org/debian-legal/2003/11/msg00053.html, last accessed 12 August 2009 22.Peterson, S.K.: Mailing list message dated Fri, 14 Nov 2003 14:52:54 GMT "termination with unrelated trigger considered harmful," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3C6D64 63F31027B14FB3B1FB094F2C744704A11176@tayexc17.americas.cpqcorp.net% 3E, last accessed 13 August 2009 23.Machovec, J.: Mailing list message dated Fri, 14 Nov 2003 16:49:09 GMT "Re: termination with unrelated trigger considered harmful," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3C3FB5 0785.7010801@golux.com%3E, last accessed 13 August 2009 24.Fielding, R.: Mailing list message dated Tue, 18 Nov 2003 02:10:27 GMT "Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]," available online at http://mail-archives.apache.org/mod_mbox/archivelicense/200311.mbox/%3c60AEF3C1-196C-11D8-A8F4-000393753936@apache.org%3e, last accessed 13 August 2009 25.Engelfriet, A.: Mailing list message dated Mon, 17 Nov 2003 20:59:53 GMT "Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]," available online at http://mail-archives.apache.org/mod_mbox/archivelicense/200311.mbox/%3c20031117205953.GA95846@stack.nl%3e, last accessed 13 August 2009 26.Moglen, E.: Mailing list message dated Fri, 14 Nov 2003 21:28:32 GMT "FSF Comments on ASL 2.0 draft," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3c16309 .18688.540989.283163@new.law.columbia.edu%3e, last accessed 13 August 2009 27.Carlson, B. M.: Mailing list message dated Thu, 13 Nov 2003 05:39:49 GMT "DFSG-freeness of Apache Software Licenses," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3c20031 113053949.GD23250@stonewall%3e, last accessed 13 August 2009 28.Armstrong, D.: Mailing list message dated Fri, 14 Nov 2003 04:39:50 GMT "Re: DFSG-freeness of Apache Software Licenses," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3C2003 1114043950.GM2707@donarmstrong.com%3E, last accessed 13 August 2009 29.Johnson, P.: Mailing list message dated Wed, 12 Nov 2003 02:09:14 GMT "Mutual defence patent clause," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3C003d 01c3a8c1$f9b55170$c6ba400c@protocol.com%3E, last accessed 12 August 2009 30.Behlendorf, B.: Mailing list message dated Wed, 12 Nov 2003 21:09:32 GMT "Re: Mutual defence patent clause," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200311.mbox/%3C2003 1112130508.H497@fez.hyperreal.org%3E, last accessed 13 August 2009 31.Fielding, R.: Mailing list message dated 12/24/2003 04:16 AM "Re: Review of proposed Apache License, version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archive-license/200312.mbox/%3c464B4006-3604-11D8-9A9F-000393753936@apache.org%3e, last accessed 12 August 2009 32.Apache License Proposal Website, available online at http://www.apache.org/licenses/proposed/, last accessed 13 August 2009 33.Apache License, Version 1.23, available online at http://mailarchives.apache.org/mod_mbox/archive-license/200312.mbox, last accessed 13 August 2009 34.Behlendorf, B.: Mailing list message datedFri, 09 Jan 2004 22:42:52 GMT "Re: Review of proposed Apache License, version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200401.mbox/%3c20040109143803.G31301@fez.hyperreal.org%3e, last accessed 13 August 2009 35.Behlendorf, B.: Mailing list message dated Wed, 07 Jan 2004 22:16:36 GMT "Re: Review of proposed Apache License, version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200401.mbox/%3c20040107140658.A23429@fez.hyperreal.org%3e, last accessed 13 August 2009 36.Fielding, R.: Mailing list message dated Wed, 14 Jan 2004 20:25:50 GMT "Re: Review of proposed Apache License, version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archive-license/200401.mbox/%3cD81EA136-46CF-11D8-B08A-000393753936@apache.org%3e, last accessed 13 August 2009 37.Fielding, R.: Mailing list message dated Wed, 14 Jan 2004 20:54:26 GMT "Re: Review of proposed Apache License, version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archive-license/200401.mbox/%3cD6DB9454-46D3-11D8-B08A-000393753936@apache.org%3e, last accessed 13 August 2009 38.Armstrong, D.: Mailing list message dated Sat, 24 Jan 2004 02:13:50 GMT "Re: Apache License, Version 2.0," available online at http://mail archives.apache.org/mod_mbox/archivelicense/200401.mbox/%3C20040124021350. GG3060@archimedes.ucr.edu%3E, last accessed 13 August 2009 39.Fielding, R.: Mailing list message dated Sat, 24 Jan 2004 02:29:29 GMT "Re: Apache License, Version 2.0," available online at http://mailarchives.apache.org/mod_mbox/archive-license/200401.mbox/%3C23385101-4E15-11D8-915D-000393753936@apache.org%3E, last accessed 13 August 2009 40.Free Software Foundation Licenses webpage, available online at http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses, last accessed 14 August 2009 41.Massol, V.: Mailing list message dated Sun, 25 Jan 2004 16:01:19 GMT "How to use the 2.0 license?," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200401.mbox/%3C012f0 1c3e35c$78e229d0$2502a8c0@vma%3E, last accessed 13 August 2009 42.Behlendorf, B.: Mailing list message dated Sun, 25 Jan 2004 20:17:06 GMT "Re: How to use the 2.0 license?," available online at http://mailarchives.apache.org/mod_mbox/archivelicense/200401.mbox/%3C2004 0125121456.H396@fez.hyperreal.org%3E, last accessed 13 August 2009 43.Adams, E. NBDiscuss mailing list message: "Joint Copyright Assignment," available online at http://www.netbeans.org/servlets/ReadMsg?list=nbdiscuss&msgNo-=2228, last accessed 6 August, 2009 44.The Apache Software Foundation Individual Contributor License Agreement, Version 2.0 available online at http://www.apache.org/licenses/icla.txt, last accessed 20 October 2009.


Nguyen Duc

Daniela S Cruzes
email: dcruzes@idi.ntnu.no

Claudia Ayala
email: cayala@essi.upc.edu

Reidar Conradi
email: conradi@idi.ntnu.no

Impact of Stakeholder Type and Collaboration on Issue Resolution Time in OSS Projects

Initialized by a collective contribution of volunteer developers, Open source software (OSS) attracts an increasing involvement of commercial firms. Many OSS projects are composed of a mix group of firm-paid and volunteer developers, with different motivations, collaboration practices and working styles. As OSS development consists of collaborative works in nature, it is important to know whether these differences have an impact on collaboration between difference types of stakeholders, which lead to an influence in the project outcomes. In this paper, we empirically investigate the firm-paid participation in resolving OSS evolution issues, the stakeholder collaboration and its impact on OSS issue resolution time. The results suggest that though a firm-paid assigned developer resolves much more issues than a volunteer developer does, there is no difference in issue resolution time between them. Besides, the more important factor that influences the issue resolution time comes from the collaboration among stakeholders rather than from individual characteristics.

Introduction

Open source software (OSS) development is a highly distributed and collaborative activity. In OSS projects, stakeholders, who are people involve in software development project such as developers, project leader, tester and end-users, collaborate with each other in various ways to accomplish development tasks. Although OSS was born as a movement mainly based on contributions of volunteer stakeholders, an increasing number of firms are getting involved in OSS projects [START_REF] Herbsleb | Global Software Engineering: The Future of Socio-technical Coordination[END_REF] [START_REF] Rahman | Resource allocation and activity scheduling: bug fixing perspective[END_REF]. Lakhani et al. found that around 40% of programmers are paid by companies to contribute to OSS projects [START_REF] Lakhani | Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects[END_REF]. Hars and Ou obtained similar results in a survey on the developers of the Linux kernel [START_REF] Nguyen | Studying the impact of dependency network measures on software quality[END_REF]. Consequently, many open source projects contain both types of stakeholder (firm-paid and volunteer), which have different motivations, collaboration practices and working styles. For instance, firmpaid developers contribute to the OSS community as part of their jobs, which provide them a financial motivation. In addition, they often also work on proprietary software since it constitutes a part of the business model of their sponsor firm [START_REF] Anbalagan | On predicting the time taken to correct bug reports in open source projects[END_REF][9] [START_REF] Martinez-Romo | Using social network analysis techniques to study collaboration between a FLOSS community and a company[END_REF]. Therefore, they have to learn the community working style and adjust to the rhythms and the demands of OSS development [START_REF] Anbalagan | On predicting the time taken to correct bug reports in open source projects[END_REF]. In contrast, volunteer developers are usually motivated by social or technical reasons to demonstrate or improve their technical skills [START_REF] B O N A C C O R S I | B u s i n e s s f i r m s ' engagement in community projects. Empirical evidence and further developments of the research[END_REF] [START_REF] Martinez-Romo | Using social network analysis techniques to study collaboration between a FLOSS community and a company[END_REF].

Several studies have investigated the potential differences among firm-paid and volunteer developers in OSS projects [START_REF] Anbalagan | On predicting the time taken to correct bug reports in open source projects[END_REF][21] [START_REF] Lakhani | Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects[END_REF][29] [START_REF] Rahman | Resource allocation and activity scheduling: bug fixing perspective[END_REF]. However, these studies did not address whether these differences actually have an impact on the OSS project outcomes such as quality of the source code, productivity of developers, activeness of the community and time to accomplish a software evolution task.

A software evolution task (or software issue) is normally referred as a unit of work to accomplish an improvement in the system. Dealing with a software issue includes fixing defects, implementing new feature requests and enhancing current system features. With a large amount of issues that occur from time to time, resolving them in a cost-effective manner is essential to achieve a high user satisfaction with less working effort.

Besides the impact of some special characteristics of stakeholders (in the issue resolving process, they are usually reporters and assignees), the issue resolution time can be influenced by a collaborative working process between reporters and assignees. Pinzger et al. mention the Coordination theory in OSS, which state that the interaction among stakeholders can impact software quality (such as mean time between failure) and work performance (such as defect removal effectiveness and problem fixing time) [START_REF] Pinzger | Can developer-module networks predict failures?[END_REF]. In the issue resolving process, stakeholders often use electronic media such as mailing list, IRC and issue tracking system to discuss, comment and clarify about an assigned task [START_REF] Kagan | United we stand: Collaboration for child care and early education services[END_REF] [START_REF] Mattessich | Collaboration: What Makes it Work: A review of Research and Literature on Factors Influencing Successful Collaboration[END_REF]. The collaboration among stakeholders, such as discussion, instruction and clarification on an issue, is important to the completion of the issue-resolving task.

This study has three main objectives. First, we characterize the difference in the average amount of resolved issues and issue resolution time between a volunteer assignee and a firm-paid assignee. To best of our knowledge, there is no study that empirically investigates the influence of volunteers versus firm-paid developers on issue resolution time. Second, we investigate collaboration among stakeholders in OSS projects by using Social network metrics and analysis. Last, we explore the impact of the collaboration measures on issue resolution time. While there are several studies using Social network metrics investigating software quality (as described in Section 2.1), this is among the first attempts to apply these metrics on studying issue resolution time.

The rest of the paper is organized as follows. Section 2 presents a construction of stakeholder collaboration measure using Social network analysis (SNA). While Section 3 states our hypotheses, Section 4 describes our case study and data collection procedure. Section 5 provides the hypotheses testing results. Section 6 discusses the findings and Section 7 identifies the threats to validity. The paper ends with a conclusion and future works.

2 Stakeholder collaboration measure by social network analysis (SNA)

Impact of collaboration on software development

Table 1presents several studies exploring the impact of collaboration on software development outcomes. Bettenburg et al. studied the impact of social structure on software quality and find a statistical relation between a communication flow between developers and users and post-release defects [START_REF] B E T T E N B U R G | What makes a good bug report?[END_REF]. Abreu et al. investigated Eclipse sub-projects and found a significantly positive correlation between communication frequency between developers and number of injected defects in the software [START_REF] Abreu | How developer communication frequency relates to bug introducing changes[END_REF]. Bird et al. showed that a socio-technical network of software modules and developers is able to predict software failure proneness with greater accuracy than other prediction methods [START_REF] Bird | Putting It All Together: Using Socio-technical Networks to Predict Failures[END_REF]. Wolf et al. formed a developer-task network to explore the impact of developer communication on software build integration fail [START_REF] Wolf | Predicting build failures using social network analysis on developer communication[END_REF]. Pinzger et al. constructed a developer-module network to predict the software failures [START_REF] Pinzger | Can developer-module networks predict failures?[END_REF].

More relevant to our focus are studies about relationship between developer collaboration and defect fixing time. Feczak et al. empirically validated the Coordination theory in open source projects and found that collaboration among stakeholders, measured by social network metrics, has a positive influence on software defect fixing time [START_REF] Feczak | Measuring Coordination Gaps of Open Source Groups through Social Networks[END_REF]. Anbalagan et al. also found a significant correlation between number of participants in editing a defect report and median time taken to correct it [START_REF] Anbalagan | On predicting the time taken to correct bug reports in open source projects[END_REF]. Guo et al. used collaboration measures to predict which defect will get fixed in Windows 7 and concluded that the defects that have more people involved in defect report editing will be more likely to be fixed [START_REF] Guo | Characterizing and predicting which bugs get fixed: an empirical study of Microsoft Windows[END_REF]. While these studies show that developers collaboration, measured by a developer-artifact network metrics is useful for predicting software defects and fixing time, a similar approach can be applied to discover the impact of developers collaboration on issue resolution time.

Issue-Stakeholder network measures

Social network analysis (SNA) considers social relationships in term of network theories, which focus on social nodes, such as people, groups, organizations and measures relationships and information flows among them [START_REF] Freeman | The Development of Social Network Analysis[END_REF]. In this study, we construct an undirected graph to represent a network of issue-stakeholders. The graph employs two types of nodes: stakeholders and issues. Stakeholders include a reporter (who reports the issue), an assignee (who is assigned to resolve the issue) or a commenter (who comments or discuss about the issue). A link occurs only between a stakeholder and an issue, which represents for a stakeholder's action on the issue, such as an issue report, a report update, a comment on the issue and an issue assignment. Figure 1: Issue-stakeholder network in issue resolution To establish the issue-stakeholder network, we use a social network analysis tool, namely ORA 1 . The most common measure in SNA is centrality, which denotes the structural power position of a node in a given network. There are three centrality measures in SNA, namely Freeman Degree Centrality, Closeness and Betweeness. In the scope of this study, we investigate Freeman Centrality Degree since this metric is successfully applied in relevant studies [START_REF] Feczak | Measuring Coordination Gaps of Open Source Groups through Social Networks[END_REF][30] [START_REF] Wolf | Predicting build failures using social network analysis on developer communication[END_REF]. In our network, the Freeman Degree Centrality of an issue represents the number of unique stakeholders that involve in the issue. For each issue, the high value of a centrality degree shows a large number of stakeholders working on it (reporting, commenting or resolving it). The centrality degree of an issue is calculated as in Formula 1:

() () 1 di G di n (1)
with d(i) is the node degree of a issue, n is the total number of stakeholders and issues Similarly, the Freeman Degree Centrality of a stakeholder is the number of issues directly linked to the stakeholder. We also want to explore whether stakeholder centrality has an impact on issue resolution time. For each issue, we calculate the accumulative stakeholder centrality degree (Cs) as a sum of centrality degrees of all involved stakeholders, as in Formula 2:

() () () () Cs i Gdass i Gdrep i Gdcom i (2)
with Gdass(i), Gdrep(i) and Gdcom is the centrality degree of assignee, reporter and commenter correspondently. The meaning of Cs(i) is that the issue is important when they are resolved by many stakeholders and by important stakeholders, who involved in many other issues.

Research hypotheses

In our context, a firm-paid stakeholder is an assignee or a reporter who works for a commercial company that uses and contributes to the development of an OSS project.

We observe that many firm-paid assignees are also core contributors in developing the OSS product. While these core project members have significant contributions in developing the software [START_REF] Cro Wsto N | Co re and Perip he ry in Free/Libre and Open Source Software Team Communications[END_REF], it is interested to know whether they also significantly contribute to resolving issues in the software evolution phase. Therefore, our first hypothesis is that:

H1: The stakeholder's centrality degree of a firm-paid assignee is higher than those of volunteer assignee. (Null hypothesis: there is no difference in distribution of stakeholder centrality degrees between firm-paid and volunteer assignees).

Since firm-paid assignees also include the core members of the projects, they are supposed to have more knowledge and experience in developing the OSS product than peripheral members do [START_REF] Cro Wsto N | Co re and Perip he ry in Free/Libre and Open Source Software Team Communications[END_REF]. Therefore the resolution time should be different between the group of volunteer assignees and the group of firm-paid assignees. Our second hypothesis is that: H2: There is a difference in mean issue resolution time between a firm-paid assignee and a volunteer assignee. (Null hypothesis: there is no difference in mean issue resolution time between firm-paid and volunteer assignees).

An issue with many stakeholders involved might relate to many different software modules or different development tasks. Therefore, the complexity of such issues is higher and thus, it takes the assignee longer time to resolve. Our third hypothesis is that:

H3: The larger number of stakeholders involve in an issue is, the longer the issue resolution time is. (Null hypothesis: there is no correlation between the number of stakeholders involved in an issue and the issue resolution time).

A large number of comments and discussions on an issue may be caused by problems on the issue description (which leads to confusion or dissensus among stakeholders) or by the complexity of the resolving task and could lead to longer resolution time. Our last hypothesis is that: H4: The larger number of exchanged messages on an issue is, the longer the issue resolution time is. (Null hypothesis: there is no correlation between the number of message exchanged in an issue and the issue resolution time).

The case study

Projects Context and Selection

Three OSS projects were selected for our study, namely Qt, Qpid and Geronimo. The reasons for selecting these projects were: (1) these projects are active and ongoing for at least 4 years, which ensure the scale of the datasets; (2) there are similar issue tracking system used in these projects, which facilitate the data collection; (3) these projects are similar in business domain and technical level, thus reducing the variability of the results, and, (4) these projects are significantly influenced by firm-paid developers, which enable the investigation of the impact of different stakeholder types.

Qt is an Open Source cross-platform framework developed by Qt Development Framework (Nokia) based on the programming language C++. The framework offers common components such as networking, OpenGL, multimedia and a widget toolkit 2 . Qpid is an cross-platform Open Source enterprise messaging system developed around the open standard Advanced Message Queuing Protocol (AMQP). It is implemented in many programming languages, such as: C++, C#, Python, Ruby and Java 3 . The project originated from a joint venture mostly consisting of code by Red Hat, Iona and JP Morgan. Geronimo is a server runtime framework that pulls together the Open Source alternatives to create runtime instances that meet the needs of developers and system administrators and open-source, Apache-licensed 4 . The project originated from IBM developers.

Data collection and preprocessing

All software issues were collected from JIRA repositories 5 of the respective projects. The summary of datasets was described in Table 2, with the main, owner firm of each project, the time frame of the issues collected for analysis, the total number of issues, number of stakeholders (assigned developers and issue reporters, who collaborated with the project during this period), the total number of issues in the repository and the total number of issues that we used for our analysis. Issue resolution time was computed by using the created time field and the issue resolved time field. We excluded 3514 issues that are not possible to calculate the issue resolution time. We removed 2171 issues that have the state OPEN, DUPLICATE or INVALID. We also deleted 2838 issues that do not have reporter or assignee information (stated as unassigned or unknown), and issues with invalid stakeholder information (as described below). Twenty-two data points were also taken out by an outlier detection function implemented in the R6 package. At the end of the data preprocessing procedure, 16986 issues were selected for further analyses, which consumes 67% of total number of issues.

The classification of stakeholder type (firm-paid or volunteer) was manually executed by searching stakeholder name and professional information in the Internet. The first information source is the list of contributor and mailing list from the project repository. We found these stakeholders with explicit company information, either as project initiators or main contributors of the open projects. With stakeholders that company information was not given in the project site, we determined the affiliation by: (1) the stakeholder's profile from social networking site such as Facebook, LinkedIn and personal blogs, and (2) the stakeholder's email with a private company domain. The stakeholder company information were extracted by the time when the stakeholder worked in the OSS project. We assumed that the group of stakeholders (more than three) come from the same company participate in the OSS project as a company representative and are paid by the company. The stakeholders without any identified company information were classified as volunteers.

After collecting stakeholder information, we synchronized the stakeholder name and alias to avoid replicated data. Table 2 describes the total number of stakeholders that involve in the OSS projects in the time period that data are collected. Collaboration information was extracted from issue tracking systems and the mailing lists of OSS projects using a Perl script. For each issue, we collected comments, edits on the issue report and issue-related messages from the project mailing list.

Descriptive statistics

Table 3 presents the distribution of reported issues by stakeholder types in Qpid, Geronimo and Qt correspondingly. As our expectation, stakeholders from Redhat and JP Morgan in Qpid (53.6% of reported issues) and stakeholders from IBM in Geronimo (60.8% of reported issues) are the main contributors in reporting issues. However, the largest amount of reported issues in Qt comes from volunteer reporters (44.9% of reported issues). This observation can be explained by the large amount of end-users involved in the Qt project, who directly report their problem, in the issue project tracking system. Table 4 shows the distribution of resolved issues by different stakeholder types. Not surprisingly, most of the issues are resolved by developers from the main firms such as Redhat and JP Morgan (62.4% of resolved issues) in Qpid, IBM (71.6% of resolved issues) in Geronimo and Nokia (62% of resolved issues) in Qt.

Figure 4 presents box plot charts of issue centrality and issue-based messages in the three projects. In Figure 4a shows that most of issues are touched by one to three stakeholders, other than the reporter. In Figure 4b, the average number of issue-based messages is similar among three projects. We see that number of message exchanged around an issue in three projects is from none to four messages, slightly vary among projects.

H1: The stakeholder's centrality degree of a firm-paid assignee is higher than those of a volunteer assignee.

Due to the fact that stakeholder centrality degrees are not normally distributed as observed from histogram and descriptive statistics, we used Wilcoxon rank-sum test [START_REF] Devore | Probability and Statistics for Engineering and the Sciences[END_REF]. All the tests are performed using the statistic package R with alpha = 0.05. The null hypothesis H1, which stated that there is no difference in stakeholder centrality degree between firm-paid and volunteer assignee was investigated with a one-tail test. The results are shown in Table 5. In all cases, the median values of centrality degree in the firm-paid groups are significantly higher than those in the volunteer groups. In particular, the number of issues involved by a firm-paid stakeholder is at least two times higher than ones involved by volunteer stakeholder in all projects. The p-values in all tests allow us to reject the null hypotheses in all projects. We accept the alternative hypothesis that the centrality degree of firm-paid stakeholders is higher than one of volunteer stakeholders.

H2: There is a difference in mean issue resolution time between a firm-paid assignee and a volunteer assignee.

The distribution of issue resolution time between firm-paid assignee and volunteer assignee is shown in Figure 5. From the graph, we notice that the difference between these two groups in Qt and Qpid is very small. In Geronimo, there is a slightly higher difference in distribution of issue resolution time between firm-paid and volunteer assignee, but the high standard deviation could make this insignificant. To test whether there is a difference in issue resolution time between firm-paid and volunteer assignees, we also used the Wilcoxon rank-sum test.

The null hypothesis H2, which stated that there is no difference in issue resolution time between firm-paid and volunteer assignee was investigated with a two-tail test. The results are shown in Table 6. We observed that in three cases, the test with Geronimo data revealed a significant difference in resolution time between two groups while those with Qt and Qpid data did not. Therefore, the null hypothesis was rejected only in Geronimo dataset at significance level 95%. In Qpid and Qt, we accept the assumption of the null hypothesis.

H3: The larger number of stakeholders involve in an issue is, the longer the issue resolution time is, and H4: The larger number of exchanged message on an issue is, the longer the issue resolution time is

We performed a pair-wise correlation analysis among number of message, issue centrality degree, sum of stakeholder centrality and issue resolution time. The correlation matrixes for Qt, Qpid and Geronimo projects are shown in Table 7, Table 8 and Table 9 respectively. The mark "**" represents a significance level at 0.01. Referring to Hopskin interpretation of value of correlation coefficient, which classify the value of correlation coefficient as trivial (<0.1), minor (0.1 -0.3), moderate (0.3-0.5), large (0.5 -0.7), very large (0.7 -0.9) and almost perfect (0.9 -1.0) [START_REF] Hopkins | A scale of magnitudes for the effect statistics[END_REF], the correlation between number of task-based messages and issue resolution time is significant at minor level in Qt, Qpid while it is at moderate level in Geronimo. The correlation between issue centrality and its resolution time is at a minor level for Qt and at a moderate level for Qpid and Geronimo. Besides, the correlation coefficient between stakeholder accumulative centrality and resolution time is slightly higher than the one of issue centrality. All of these correlation coefficients are significant at level 0.01, which allow us reject the null hypotheses for H3, H4 and accept the alternative ones. It is noticed that among three variables, the accumulative stakeholder centrality degree has the largest correlation coefficient with issue resolution time in all projects.

Discussion of Results

Table 10 summarizes the testing results for each hypothesis. Concerning hypothesis H1, the statistical test results reject the null hypotheses in all cases, which show the centrality degree of an average firm-paid assignee are significantly higher than that of an average volunteer assignee. This finding infers the distribution of labor between firm-paid and volunteer assignees. It indicates that in the issue-resolving process, a firm-paid assignee involves in much more issues than a volunteer assignee does. On testing hypothesis H2, the issue resolution time significantly varies between firm-paid assignees and volunteer assignees in only one out of three investigated projects. Therefore, we can conclude that the stakeholder type is unlikely an influenced factor on issue resolution time. The data suggests that while volunteer and firm-paid assignees participate in OSS projects with different motivation and working approaches, these differences do not have an impact on their issue resolution time.

In the result for H3 and H4, the correlation tests reveal a positive correlation between collaboration measures, such as number of message, number of involved stakeholder and issue resolution time. It implies that the high collaboration level in an issue, e.g. high number of messages exchanged or high number of involved stakeholders indicates a longer resolution time. This may be due to the complexity of the task that relates other issues or software modules; or the poor quality of the issue description leads to demands of explanation and discussion. However, we are aware that the result of correlation analysis doesn't imply cause-effect relationship due to the effect of compounding factors. To validate the provided hypothesis, a further regression analysis is necessary. From the results, we also observe that there is significant positive correlation between issue centrality and number of messages exchanged. This observation was expected as the larger number of stakeholders involved in an issue (i.e. editing the reports or commenting on the issue) clearly leads to the increasing of number of comments or report edits. Therefore, these two variables should be checked for compounding factors if they are both used in regression models.

Threats to validity

First, a major threat of the study validity lies in the division of stakeholders as volunteer or firm-paid. Although a major amount of stakeholder's affiliation is identified, there are still some stakeholders with no company information. However this group of unidentified stakeholders is responsible for a very small portion of issues in general. Since the major portion of the issues comes from identified stakeholders, the comparison of resolution time between groups of stakeholders would not be significantly influenced. Second, a main concept investigated in this study is collaboration, which is measured by the number of comments, messages and number of issue-involved stakeholders. Although collaboration between stakeholders can be done via other channels, such as IRC, Skype and face-to-face discussion, issue tracking system and mailing list are the most common discussion means. The most relevant discussion about an issue should be found here. The other concern in the data collection process is the quality of the issue report since the data can be randomly filled in and the occurrence of duplicated reports. However, the quality of report is also an included factor in this study since it might influence the issue resolution time.

Third, another threat to validity comes from the generality of the research findings. As in many empirical studies of OSS projects, few case studies are definitely not significant enough to generalize what we found to the population of OSS projects. In this study, the cases were thoroughly selected to represent for an active, mediumsize and on-going OSS projects.

Last but not least, compounding factors is an unavoidable threat in a correlational study. The high correlation between number of messages, number of stakeholders and issue resolution time can be caused by a latent variable, not investigated in this study, such as complexity of the issue, or dependencies among issues. Therefore, this concern could be a subject for a future investigation.

Conclusion and future work

In this study, we investigated the impact of different stakeholder types and their collaboration on issue resolution time in three medium-size and ongoing OSS projects. The statistic test result provides some interesting findings for OSS practitioners as well as OSS researchers. First, we found that in firm-involved OSS projects, there is not only a large portion of firm-paid labor contributed to the projects, but also a higher workload on an average firm-paid assignee than on a average volunteer assignee. However, we did not find a difference in issue resolution time between volunteer and firm-paid assignees. The result contributes to the understanding of distribution of workload and resolving time between volunteer and firm-paid assignees. Second, we found a significant impact of stakeholder collaboration on issue resolution time. Particularly, the issue with fewer stakeholders is resolved faster than the one with more stakeholders. The issue with fewer comments is also resolved faster than the ones with more comments. For practitioners, these metrics can be integrated in the issue tracking system or defect repository to provide a recommendation for issue resolving process. Particularly, the collaboration information collected overtime will help developers being aware of which issue is going to take longer time to resolve. For researchers who want to integrate collaboration measures in software quality or productivity prediction models, they should consider of not only the usefulness of number of involved stakeholders, number of exchanged messages but also the compounding effect between them.

The paper contributes to fill in a gap in the literature gap by providing an empirical investigation of firm-paid stakeholders and their cooperation with others in OSS projects. The findings were supported by descriptive statistic and correlation analysis and further work should employ regression analysis to validate these findings. The study is also limited in using simple SNA metrics, such as the Freeman Centrality Degree. In future, we will explore more SNA metrics to investigate other aspects of stakeholder collaboration. Besides, the findings are based on only three projects, so the analysis should be replicated with more datasets to generalize conclusions on OSS community.

Figure

  Figure 4a, b: Descriptive of issue centrality and issue-based messages

Figure 5 :

 5 Figure 5: Issue resolution time (days) between volunteer and firm-paid stakeholder Table 6: Resolution time of volunteer vs. firm-paid assignees Projects Median resolution time by Firm-paid

Table 1 : Studies about collaboration Studies Dependent Variable Collaboration Variable Exploring Method Test Results

 1

	Bettenb	Number of	Participant reputation	Multiple linear	Increase a
	urg et	post-released	(number of contributed	regression	predictive power
	al.	defects	messages)	model	of prediction
	[6]				model 11.66%
	Abreu et	Number of	Number of messages in	Spearman's	R = 0.1 to 0.45
	al. [1]	code changes	mailing list	correlation	p < 0.001
			Number of messages		R = 0.06 to 0.16
			from high-centrality-		p < 0.05
			degree developers
	Bird et	Post-released	Developer-component	Release-cross	Recall: 0.705 to
	al. [7]	defect	network measures, e.g.:	Multiple	0.859.
		proneness	centrality degree	Logistic	Precision: 0.747
				regression	to 0.827
	Wolf et	Build failure	Developer-developer	Bayesian	Recall:0.62,
	al. [32]	likelihood	network measures, e.g.:	classifier	Precision: 0.75
			density, centrality,
			betweenness and
			structural holes
	Pinzger	Number of	Number of authors,	Spearman	R= 0.503 to
	et al. [30]	failure	number of commits, networks measures e.g.:	correlation Multiple linear	0.747, p<0.01 R 2 = 0.698 to
			Freeman centrality	regression	0.746
			degree and betweenness	model
	Andrew	Vulnerability	Betweenness measures,	Mann-	Higher values
	et al. [5]	of software	number of developers	Whitney-	for vulnerable
		files	and number of commits	Wilcoxon	file,
				(MWW) test	p<0.0001
	Feczak	Bug fixing	Stakeholder network	Spearman	R = 0.13 to 0.35
	et al.	time	measures, e.g: Freeman	correlation	p <0.05
	[14]		centrality degree
	Anbalag	Defect	Number of unique	Spearman	R = 0.22
	an et al.	resolution	participants	correlation	p < 0.0001
	[2]	time
	Guo et	Likelihood	Defect opener reputation,	Chi square test	p < 0.0001
	al. [16]	of fixed	number of defect report	Correlation test	Not reported
		defect	editors and assignees

  1 http://www.casos.cs.cmu.edu/projects/ora/

	Illustrated by Figure 1, the Freeman centrality degree of Stakeholder 2 is 5/11 and the
	degree of Stakeholder 3 is 1/11, which shows that Stakeholder 2 involves in more
	Issue 2 issues than Stakeholder 3 does. Issue 3's centrality degree is 3/11 and Issue 4's Issue 1 Stakeholder 3 Stakeholder 5 centrality degree is 1/11, which shows that Issue 3 is involved by more stakeholders
	r e s o lv e s than Issue 4 is. The accumulative stakeholder centrality degree of Issue 3 is 7/11. reports reports r e p o r t s r e p o r ts
			resolves
	Stakeholder 1	Stakeholder 2	Issue 3	Issue 4
	resolves	r e p o r t s	c o m m e n t s	c o m m e n t s
	Issue 6		Issue 5	Stakeholder 4

Table 2 :

 2 Issue collection from cases study

	Info.\ Projects	Qt	Qpid	Geronimo
	Main Firms	Qt (Nokia)	Red Hat, JP Morgan	IBM
	Time Frame	11/03-12/10	9/06-12/10	8/03-12/10
		(85 months)	(51 Months)	(87 Months)
	Number of Stakeholders	1568	126	405
	Number of issues	16818	3016	5697
	Number of selected issues	9921	2278	4787

Table 3 :

 3 Distribution of contribution in reporting issue

	Issues from	Qpid	Geronimo	Qt
	Individual	453 (19.9%)	1205 (25.0%)	4452 (44.9%)
	Other company	605 (26.5%)	683 (14.2%)	1124 (11.3%)
	Main Firms	1220 (53.6%)	2919 (60.8%)	4345 (43.8%)
	Total	2278 (100%)	4787 (100%)	9921 (100%)

Table 4 :

 4 Distribution of contribution in resolving issue

	Issues from	Qpid	Geronimo	Qt
	Individual	252 (11.1%)	401 (8.4%)	2463 (24.8%)
	Other company	604 (26.5%)	956 (20.0%)	1315 (13.2%)
	Main Firms	1422 (62.4%)	3420 (71.6%)	6143 (62.0%)
	Total	2278 (100%)	4787 (100%)	9921 (100%)

Table 5 :

 5 Resolution time by volunteer vs. firm-paid assignees

	Projects	Median centrality of Firm-paid	Median centrality of Volunteer	Significance level
	Geronimo	0.0169	0.0049	p=0.0014
	Qpid	0.0114	0.0057	p=0.0251
	Qt	0.0131	0.0024	p=0.0014

Table 7

 7

		-Pairwise correlation for Qt
		No of	Issue	Sum. Stak.	Resolution
		message	centrality	centrality	time
	Number of message	1	0.413**	0.460**	0.125**
	Issue centrality		1	0.213**	0.172**
	Sum. Stak. centrality			1	0.262**
	Resolution time				1
	Table 8: Pairwise correlation for Qpid
		No of	Issue	Sum. Stak.	Resolution
		message	centrality	centrality	time
	Number of message	1	0.569**	0.423**	0.243**
	Issue centrality		1	0.199**	0.310**
	Sum. Stak. centrality			1	0.331**
	Resolution time				1

Table 9 :

 9 Pairwise correlation for Geronimo

		No of	Issue	Sum. Stak.	Resolution
		message	centrality	centrality	time
	Number of message	1	0.491**	0.382**	0.416**
	Issue centrality		1	0.251**	0.303**
	Sum. Stak. centrality			1	0.409**
	Resolution time				1

Table 10 :

 10 Results of Hypotheses testing

	Hypotheses	H1	H2	H3	H4
	Test	Mann	Mann	Spearman	Spearman
		Whitney U	Whitney U	correlation	correlation
	Geronimo	Accept	Accept	Accept	Accept
	Qt	Accept	Reject	Accept	Accept
	Qpid	Accept	Reject	Accept	Accept

Qt project -http://qt.nokia.com/

Qpid project -http://qpid.apache.org/

Geronimo project -http://geronimo.apache.org/

JIRA-bug, issue and project tracking system, http://www.atlassian.com/software/jira/

The R Project for Statistical Computing -http://www.r-project.org/

Acknowledgements

The authors would like to thank Tor Stålhane for his valuable comments and help with checking the statistical procedures.