@proceedings {1911,
	title = {Machine Learning-Based Detection of Open Source License Exceptions},
	year = {2017},
	note = {"We address these questions by first performing a large scale mining-based study... [W]e analyzed the  source code of 51,754 projects written in six different programming languages (Ruby, Javascript, Python, C, C++, and C$\#$) hosted on GitHub. },
	month = {05/2017},
	pages = {118-129},
	abstract = {From a legal perspective, software licenses govern the redistribution, reuse, and modification of software as both source and binary code. Free and Open Source Software (FOSS) licenses vary in the degree to which they are permissive or restrictive in allowing redistribution or modification under licenses different from the original one(s). In certain cases developers may modify the license by appending to it an exception to specifically allow reuse or modification under a particular condition. These exceptions are an important factor to consider for license compliance analysis since they modify the standard (and widely understood_ terms of the original license. In this work, we first perform a large-scale empirical study on the change history of over 51k FOSS systems aimed at quantitatively investigating the prevalence of known license exceptions and identifying new ones. Subsequently, we performed a study on the detection of license exceptions by relying on machine learning. We evaluated the license exception classification with four different supervised learners and sensitivity analysis. Finally we present a categorization of license exceptions and explain their implications.},
	keywords = {classifier, empirical studies, license, machine learning},
	doi = {10.1109/ICSE.2017.19},
	author = {Vendome, Christopher and Mario Linares-Vasquez and Bavota, Gabriele and Di Penta, Massimiliano and Daniel M. German and Poshyvanyk, Denys}
}
@conference {Kalliamvakou:2014:PPM:2597073.2597074,
	title = {The Promises and Perils of Mining GitHub},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {92{\textendash}101},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {With over 10 million git repositories, GitHub is becoming one of the most important source of software artifacts on the Internet. Researchers are starting to mine the information stored in GitHub{\textquoteright}s event logs, trying to understand how its users employ the site to collaborate on software. However, so far there have been no studies describing the quality and properties of the data available from GitHub. We document the results of an empirical study aimed at understanding the characteristics of the repositories in GitHub and how users take advantage of GitHub{\textquoteright}s main features---namely commits, pull requests, and issues. Our results indicate that, while GitHub is a rich source of data on software development, mining GitHub for research purposes should take various potential perils into consideration. We show, for example, that the majority of the projects are personal and inactive; that GitHub is also being used for free storage and as a Web hosting service; and that almost 40\% of all pull requests do not appear as merged, even though they were. We provide a set of recommendations for software engineering researchers on how to approach the data in GitHub.
},
	keywords = {bias, code reviews, git, github, mining software repositories},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597074},
	url = {http://doi.acm.org/10.1145/2597073.2597074},
	attachments = {https://flosshub.org/sites/flosshub.org/files/perils.pdf},
	author = {Kalliamvakou, Eirini and Gousios, Georgios and Blincoe, Kelly and Singer, Leif and Daniel M. German and Damian, Daniela}
}
@article {bettenburg2013management,
	title = {Management of community contributions},
	journal = {Empirical Software Engineering},
	year = {2013},
	pages = {1{\textendash}38},
	publisher = {Springer},
	abstract = {In recent years, many companies have realized that collaboration with a thriving user or developer community is a major factor in creating innovative technology driven by market demand. As a result, businesses have sought ways to stimulate contributions from developers outside their corporate walls, and integrate external developers into their development process. To support software companies in this process, this paper presents an empirical study on the contribution management processes of two major, successful, open source software ecosystems. We contrast a for-profit (ANDROID) system having a hybrid contribution style, with a not-for-profit (LINUX kernel) system having an open contribution style. To guide our comparisons, we base our analysis on a conceptual model of contribution management that we derived from a total of seven major open-source software systems. A quantitative comparison based on data mined from the ANDROID code review system and the LINUX kernel code review mailing lists shows that both projects have significantly different contribution management styles, suited to their respective market goals, but with individual advantages and disadvantages that are important for practitioners. Contribution management is a real-world problem that has received very little attention from the research community so far. Both studied systems (LINUX and ANDROID) employ different strategies and techniques for managing contributions, and both approaches are valuable examples for practitioners. Each approach has specific advantages and disadvantages that need to be carefully evaluated by practitioners when adopting a contribution management process in practice.},
	keywords = {android, contribution, linux, management},
	url = {http://link.springer.com/article/10.1007/s10664-013-9284-6},
	author = {Bettenburg, Nicolas and Hassan, Ahmed E. and Adams, Bram and Daniel M. German}
}
@conference {960,
	title = {A comparative exploration of FreeBSD bug lifetimes},
	booktitle = {2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)},
	year = {2010},
	pages = {106 - 109},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {In this paper, we explore the viability of mining the basic data provided in bug repositories to predict bug lifetimes. We follow the method of Lucas D. Panjer as described in his paper, Predicting Eclipse Bug Lifetimes. However, in place of Eclipse data, the FreeBSD bug repository is used. We compare the predictive accuracy of five different classification algorithms applied to the two data sets. In addition, we propose future work on whether there is a more informative way of classifying bugs than is considered by current bug tracking systems.},
	keywords = {bug reports, bug tracking, classification, eclipse, msr challenge, prediction},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463291},
	attachments = {https://flosshub.org/sites/flosshub.org/files/106ChallengeGargi.pdf},
	author = {Bougie, Gargi and Treude, Christoph and Daniel M. German and Storey, Margaret-Anne}
}
@conference {965,
	title = {Identifying licensing of jar archives using a code-search approach},
	booktitle = {2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)},
	year = {2010},
	pages = {151 - 160},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Free and open source software strongly promotes the reuse of source code. Some open source Java components/libraries are distributed as jar archives only containing the bytecode and some additional information. For whoever wanting to integrate this jar in her own project, it is important to determine the license(s) of the code from which the jar archive was produced, as this affects the way that such component can be used. This paper proposes an automatic approach to determine the license of jar archives, combining the use of a code-search engine with the automatic classification of licenses contained in textual flies enclosed in the jar. Results of an empirical study performed on 37 jars - from 17 different systems - indicate that this approach is able to successfully infer the jar licenses in over 95\% of the cases, but that in many cases the license in textual flies may differ from the one of the classes contained in the jar.},
	keywords = {apache, bytecode, classification, eclipse, google code, jar, java, licenses, source code},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463282},
	attachments = {https://flosshub.org/sites/flosshub.org/files/151msr2010.pdf},
	author = {Di Penta, Massimiliano and Daniel M. German and Antoniol, Giuliano}
}
@conference {Rigby:2008:OSS:1368088.1368162,
	title = {Open source software peer review practices: a case study of the apache server},
	booktitle = {Proceedings of the 30th International Conference on Software Engineering (ICSE 2008)},
	series = {ICSE {\textquoteright}08},
	year = {2008},
	note = {http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/testing/p541-rigby.pdf},
	pages = {541{\textendash}550},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Peer review is seen as an important quality assurance mechanism in both industrial development and the open source software (OSS) community. The techniques for performing inspections have been well studied in industry; in OSS development, peer reviews are less well understood. We examine the two peer review techniques used by the successful, mature Apache server project: review-then-commit and commit-then-review. Using archival records of email discussion and version control repositories, we construct a series of metrics that produces measures similar to those used in traditional inspection experiments. Specifically, we measure the frequency of review, the level of participation in reviews, the size of the artifact under review, the calendar time to perform a review, and the number of reviews that find defects. We provide a comparison of the two Apache review techniques as well as a comparison of Apache review to inspection in an industrial project. We conclude that Apache reviews can be described as (1) early, frequent reviews (2) of small, independent, complete contributions (3) conducted asynchronously by a potentially large, but actually small, group of self-selected experts (4) leading to an efficient and effective peer review technique.},
	keywords = {apache, cvs, email, inspection, mining software repositories (email), open source software, peer review, version control},
	isbn = {978-1-60558-079-1},
	doi = {10.1145/1368088.1368162},
	url = {http://doi.acm.org/10.1145/1368088.1368162},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p541-rigby.pdf},
	author = {Peter C. Rigby and Daniel M. German and Storey, Margaret-Anne}
}
@conference {Herraiz:2008:TSB:1370750.1370786,
	title = {Towards a simplification of the bug report form in eclipse},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	pages = {145{\textendash}148},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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.},
	keywords = {bug fixing, bug report, bug tracking system, classification, eclipse, msr challenge, severity},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370786},
	url = {http://doi.acm.org/10.1145/1370750.1370786},
	author = {Herraiz, Israel and Daniel M. German and Jesus M. Gonzalez-Barahona and Gregorio Robles}
}
@conference {German:2006:SCP:1137983.1138022,
	title = {A study of the contributors of PostgreSQL},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {163{\textendash}164},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {This report describes some characteristics of the development team of PostgreSQL that were uncovered by analyzing the history of its software artifacts as recorded by the project{\textquoteright}s CVS repository.},
	keywords = {contributions, contributors, cvs, developers, mining challenge, mining software repositories, msr challenge, patches, postgresql, revision history, roles, software evolution, source code, team},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138022},
	url = {http://doi.acm.org/10.1145/1137983.1138022},
	attachments = {https://flosshub.org/sites/flosshub.org/files/163AStudyOf.pdf},
	author = {Daniel M. German}
}
@conference {German:2006:UEA:1137983.1138020,
	title = {Using evolutionary annotations from change logs to enhance program comprehension},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {159{\textendash}162},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Evolutionary annotations are descriptions of how source code evolves over time. Typical source comments, given their static nature, are usually inadequate for describing how a program has evolved over time; instead, source code comments are typically a description of what a program currently does. We propose the use of evolutionary annotations as a way of describing the rationale behind changes applied to a given program (for example "These lines were added to ..."). Evolutionary annotations can assist a software developer in the understanding of how a given portion of source code works by showing him how the source has evolved into its current form.In this paper we describe a method to automatically create evolutionary annotations from change logs, defect tracking systems and mailing lists. We describe the design of a prototype for Eclipse that can filter and present these annotations alongside their corresponding source code and in workbench views. We use Apache as a test case to demonstrate the feasibility of this approach.},
	keywords = {annotations, apache, bug tracking, change history, eclipse, evolutionary, log files, mailing lists, mining software repositories, software evolution, version control},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138020},
	url = {http://doi.acm.org/10.1145/1137983.1138020},
	attachments = {https://flosshub.org/sites/flosshub.org/files/159UsingEvolutionary.pdf},
	author = {Daniel M. German and Peter C. Rigby and Storey, Margaret-Anne}
}
@conference {795,
	title = {The challenges of creating open source education software: the Gild experience},
	booktitle = {OSS2005: Open Source Systems },
	year = {2005},
	pages = {338-340},
	keywords = {COMMUNITY, eclipse, learning environment, novice programmers, open source, programming environment},
	url = {http://pascal.case.unibz.it/handle/2038/1539},
	author = {Daniel M. German and Rigby, Peter and Cubranic, Davor and Storey, Margaret-Anne and Thomson, Suzanne}
}
@conference {792,
	title = {Experiences teaching a graduate course in Open Source Software Engineering},
	booktitle = {OSS2005: Open Source Systems },
	year = {2005},
	pages = {326-328},
	abstract = {This paper describes the early experiences of a graduate course in open source software engineering at the Department of Computer Science at the University Victoria. It includes a description of the motivation for the course, its structure and evaluation methods. It concludes with a discussion of the lessons learned and its future.},
	keywords = {course, FOSS, MOTIVATION, open source, open source software engineering},
	url = {http://pascal.case.unibz.it/handle/2038/971},
	author = {Daniel M. German}
}
@conference {1156,
	title = {The evolution of the GNOME Project},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	abstract = {The GNOME Project is an attempt to create a GUI desktop for Unix systems. Originally started by a handful of volunteers in 1996, GNOME has become the desktop of choice for Solaris, HP-UX, and Red Hat Linux, and it is currently developed by a team of approximately five hundred people around the world. The importance of GNOME to the Unix world has attracted the attention of several software companies who are actively participating in its development. At the same time, some of its volunteer developers have created enterprises who expect to sell services and products around GNOME. This extended abstract describes, first, the development model of GNOME, then the influence that private companies had had on the project: on one hand they are contributing a large amount of resources to the project, accelerating its development, and increasing its reliability and documentation; and on the other hand, the GNOME Foundation has been created to maintain the goal of the project to provide a free (as in freedom) software desktop for Unix, and avoid that the commercial interests of these partners could jeopardize the interests of the community.},
	keywords = {commercial software, gnome, organizational sponsorship},
	attachments = {https://flosshub.org/sites/flosshub.org/files/German.pdf},
	author = {Daniel M. German}
}
