%0 Book Section %B Open Source Systems: Adoption and Impact %D 2015 %T First Results About Motivation and Impact of License Changes in Open Source Projects %A Viseur, Robert %A Gregorio Robles %E Damiani, Ernesto %E Frati, Fulvio %E Dirk Riehle %E Wasserman, Anthony I. %K Business model %K Contributor agreement %K intellectual property %K license %K open source %X Free and open source software is characterized by the freedoms and criteria that are warranted by specific licenses. These licenses describe the rights and duties of the licensors and licensees. However, a licensing change may be necessary in the life of an open source project to meet legal developments or to allow the implementation of new business models. This paper examines the motivations and impacts of license changes in open source projects. After a state of the art on the subject, a set of case studies where projects changed their license is presented. Then a set of motivations to change licenses, the ways to legally make this change, the problems caused by this change and a set of benefits of the license change are discussed. %B Open Source Systems: Adoption and Impact %S IFIP Advances in Information and Communication Technology %I Springer International Publishing %V 451 %P 137-145 %@ 978-3-319-17836-3 %U http://dx.doi.org/10.1007/978-3-319-17837-0_13 %R 10.1007/978-3-319-17837-0_13 %0 Generic %D 2015 %T Lessons Learned from Applying Social Network Analysis on an Industrial Free/Libre/Open Source Software Ecosystem %A Teixeira, Jose %A Gregorio Robles %A Jesus M. Gonzalez-Barahona %K business models %K cloud computing %K homophily %K open source %K Open-Coopetition %K openstack %K social network analysis %K Software ecosystems %X Many software projects are no longer done in-house by a single organization. Instead, we are in a new age where software is developed by a networked community of individuals and organizations, which base their relations to each other on mutual interest. Paradoxically, recent research suggests that software development can actually be jointly-developed by rival firms. For instance, it is known that the mobile-device makers Apple and Samsung kept collaborating in open source projects while running expensive patent wars in the court. Taking a case study approach, we explore how rival firms collaborate in the open source arena by employing a multi-method approach that combines qualitative analysis of archival data (QA) with mining software repositories (MSR) and Social Network Analysis (SNA). While exploring collaborative processes within the OpenStack ecosystem, our research contributes to Software Engineering research by exploring the role of groups, sub-communities and business models within a high-networked open source ecosystem. Surprising results point out that competition for the same revenue model (i.e., operating conflicting business models) does not necessary affect collaboration within the ecosystem. Moreover, while detecting the different sub-communities of the OpenStack community, we found out that the expected social tendency of developers to work with developers from same firm (i.e., homophony) did not hold within the OpenStack ecosystem. Furthermore, while addressing a novel, complex and unexplored open source case, this research also contributes to the management literature in coopetition strategy and high-tech entrepreneurship with a rich description on how heterogeneous actors within a high-networked ecosystem (involving individuals, startups, established firms and public organizations) joint-develop a complex infrastructure for big-data in the open source arena. %U http://arxiv.org/abs/1507.04587 %0 Journal Article %J International Journal of Open Source Software and Processes %D 2009 %T Tools for the Study of the Usual Data Sources found in Libre Software Projects %A Gregorio Robles %A González-Barahona, Jesús M. %A Izquierdo-Cortazar, Daniel %A Herraiz, Israel %K bug tracking systems %K data sources %K mailing lists %K scm %K tools %X Due to the open nature of Free/Libre/Open Source software projects, researchers have gained access to a rich set of development-related information. Although this information is publicly available on the Internet, obtaining and analyzing it in a convenient way is not an easy task and many considerations have to be taken into account. In this paper we present the most important data sources that can be found in libre software projects and that are studied by the research community: source code, source code management systems, mailing lists and bug tracking systems. We will give advice for the problems that can be found when retrieving and preparing the data sources for a posterior analysis, as well as provide information about the tools that support these tasks. %B International Journal of Open Source Software and Processes %V 1 %P 24 - 45 %8 31/2009 %N 1 %R 10.4018/jossp.2009010102 %> https://flosshub.org/sites/flosshub.org/files/robles.pdf %0 Conference Paper %B Proceedings of the 2008 international working conference on Mining software repositories %D 2008 %T Towards a simplification of the bug report form in eclipse %A Herraiz, Israel %A Daniel M. German %A Jesus M. Gonzalez-Barahona %A Gregorio Robles %K bug fixing %K bug report %K bug tracking system %K classification %K eclipse %K msr challenge %K severity %X We believe that the bug report form of Eclipse contains too many fields, and that for some fields, there are too many options. In this MSR challenge report, we focus in the case of the severity field. That field contains seven different levels of severity. Some of them seem very similar, and it is hard to distinguish among them. Users assign severity, and developers give priority to the reports depending on their severity. However, if users can not distinguish well among the various severity options, they will probably assign different priorities to bugs that require the same priority. We study the mean time to close bugs reported in Eclipse, and how the severity assigned by users affects this time. The results shows that classifying by time to close, there are less clusters of bugs than levels of severity. We therefore conclude that there is a need to make a simpler bug report form. %B Proceedings of the 2008 international working conference on Mining software repositories %S MSR '08 %I ACM %C New York, NY, USA %P 145–148 %@ 978-1-60558-024-1 %U http://doi.acm.org/10.1145/1370750.1370786 %R http://doi.acm.org/10.1145/1370750.1370786 %0 Conference Paper %B Proceedings of the 2005 international workshop on Mining software repositories %D 2005 %T Developer identification methods for integrated data from various sources %A Gregorio Robles %A Jesus M. Gonzalez-Barahona %K anonymization %K bug tracker %K developers %K email %K email address %K gnome %K identity %K mailing list %K privacy %K source code %K version control %X Studying a software project by mining data from a single repository has been a very active research field in software engineering during the last years. However, few efforts have been devoted to perform studies by integrating data from various repositories, with different kinds of information, which would, for instance, track the different activities of developers. One of the main problems of these multi-repository studies is the different identities that developers use when they interact with different tools in different contexts. This makes them appear as different entities when data is mined from different repositories (and in some cases, even from a single one). In this paper we propose an approach, based on the application of heuristics, to identify the many identities of developers in such cases, and a data structure for allowing both the anonymized distribution of information, and the tracking of identities for verification purposes. The methodology will be presented in general, and applied to the GNOME project as a case example. Privacy issues and partial merging with new data sources will also be considered and discussed. %B Proceedings of the 2005 international workshop on Mining software repositories %S MSR '05 %I ACM %C New York, NY, USA %P 106-110 %@ 1-59593-123-6 %U http://doi.acm.org/10.1145/1082983.1083162 %R http://doi.acm.org/10.1145/1082983.1083162 %> https://flosshub.org/sites/flosshub.org/files/106DeveloperIdentification.pdf