@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}
}
@article {adams2016empirical,
	title = {An empirical study of integration activities in distributions of open source software},
	journal = {Empirical Software Engineering},
	volume = {21},
	number = {3},
	year = {2016},
	pages = {960{\textendash}1001},
	publisher = {Springer},
	abstract = {Reuse of software components, either closed or open source, is considered to be one of the most important best practices in software engineering, since it reduces development cost and improves software quality. However, since reused components are (by definition) generic, they need to be customized and integrated into a specific system before they can be useful. Since this integration is system-specific, the integration effort is non-negligible and increases maintenance costs, especially if more than one component needs to be integrated. This paper performs an empirical study of multi-component integration in the context of three successful open source distributions (Debian, Ubuntu and FreeBSD). Such distributions integrate thousands of open source components with an operating system kernel to deliver a coherent software product to millions of users worldwide. We empirically identified seven major integration activities performed by the maintainers of these distributions, documented how these activities are being performed by the maintainers, then evaluated and refined the identified activities with input from six maintainers of the three studied distributions. The documented activities provide a common vocabulary for component integration in open source distributions and outline a roadmap for future research on software integration.

},
	url = {http://mcis.soccerlab.polymtl.ca/publications/2016/integration_oss_distribution.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/integration_oss_distribution.pdf},
	author = {Adams, Bram and Kavanagh, Ryan and Hassan, Ahmed E. and Daniel M. German}
}
@inbook {Poo-Caama{\~n}o2016,
	title = {Herding Cats: A Case Study of Release Management in an Open Collaboration Ecosystem},
	booktitle = {Open Source Systems: Integrating Communities: 12th IFIP WG 2.13 International Conference, OSS 2016, Gothenburg, Sweden, May 30 - June 2, 2016, Proceedings},
	year = {2016},
	pages = {147{\textendash}162},
	publisher = {Springer International Publishing},
	organization = {Springer International Publishing},
	chapter = {Herding Cats: A Case Study of Release Management in an Open Collaboration Ecosystem},
	address = {Cham},
	abstract = {Release management in large-scale software development projects requires significant communication and coordination. It is particularly challenging in Free and Open Source Software (FOSS) ecosystems, in which hundreds of loosely connected developers and their projects need to be coordinated to release software to a schedule. To better understand this process and its challenges, we analyzed over two and half years of communication in the GNOME ecosystem and studied developers{\textquoteright} interactions. We cataloged communication channels, categorized high level communication and coordination activities in one of them, and triangulated our results by interviewing developers. We found that a release schedule, influence instead of direct control, and diversity are factors that impact positively the release process in the GNOME ecosystem. Our results can help organizations build better large-scale teams and show that research focused on individual projects might miss important parts of the picture.
},
	isbn = {978-3-319-39225-7},
	doi = {10.1007/978-3-319-39225-7_12},
	url = {http://dx.doi.org/10.1007/978-3-319-39225-7_12},
	author = {Poo-Caama{\~n}o, Germ{\'a}n and Singer, Leif and Knauss, Eric and Daniel M. German},
	editor = {Kevin Crowston and Hammouda, Imed and Lundell, Bj{\"o}rn and Gregorio Robles and Gamalielsson, Jonas and Juho Lindman}
}
@proceedings {1758,
	title = {A Dataset of the Activity of the git Super-repository of Linux in 2012},
	year = {2015},
	month = {05/2015},
	publisher = {IEEE},
	abstract = {This dataset documents the activity in the public
portion of the git Super-repository of the Linux kernel during
2012. In a distributed version control system, such as git, the
Super-repository is the collection of all the repositories (repos)
used for development. In such a Super-repository, some repos
will be accessible only by their owners (they are private, and
are located in places that are unreachable to other users) while
others are available to other members of the team. The latter
public repositories are used as avenues through which commits
flow from one developer to another. During the last six weeks of
2011, we proceeded to automatically discover the public portion
of the Super-repository of Linux. Then, in 2012, every 3 hrs,
each of these public repositories was queried to see what new
commits it had and what commits had disappeared from it
using a process we call continuous mining. This resulted in the
identification of 533,513 different commits across 451 different
public repositories and how they propagated through the Linux
Super-repository, including the repository of Linus Torvalds (i.e.,
the main repository of the Linux kernel). This information could
help us understand how kernel contributors use git, how they
collaborate and how commits are integrated into the Linux kernel
and into the repositories of organizations that distribute the
kernel.
This dataset is at http://turingmachine.org/2015/linuxGit},
	url = {http://turingmachine.org/2015/linuxGit/msr-data-git-linux.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr-data-git-linux.pdf},
	author = {Daniel M. German and Adams, Bram and Hassan, Ahmed E.}
}
@article {1796,
	title = {An in-depth study of the promises and perils of mining GitHub},
	journal = {Empirical Software Engineering},
	year = {2015},
	publisher = {Springer},
	abstract = {With over 10 million git repositories, GitHub is becoming one of the most important sources of software artifacts on the Internet. Researchers mine the information stored in GitHub{\textquoteright}s event logs to understand how its users employ the site to collaborate on software, but so far there have been no studies describing the quality and properties of the available GitHub data. We document the results of an empirical study aimed at understanding the characteristics of the repositories and users in GitHub; we see how users take advantage of GitHub{\textquoteright}s main features and how their activity is tracked on GitHub and related datasets to point out misalignment between the real and mined data. 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. For example, we show that the majority of the projects are personal and inactive, and that almost 40\% of all pull requests do not appear as merged even though they were. Also, approximately half of GitHub{\textquoteright}s registered users do not have public activity, while the activity of GitHub users in repositories is not always easy to pinpoint. We use our identified perils to see if they can pose validity threats; we review selected papers from the MSR 2014 Mining Challenge and see if there are potential impacts to consider. We provide a set of recommendations for software engineering researchers on how to approach the data in GitHub.},
	keywords = {github},
	issn = {1573-7616},
	doi = {10.1007/s10664-015-9393-5},
	url = {http://www.gousios.gr/pub/promises-perils-github-extended.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/promises-perils-github-extended.pdf},
	author = {Kalliamvakou, Eirini and Gousios, Georgios and Blincoe, Kelly and Singer, Leif and Daniel M. German and Damian, Daniela}
}
@proceedings {1776,
	title = {A Method to Detect License Inconsistencies in Large-Scale Open Source Projects},
	year = {2015},
	month = {05/2015},
	publisher = {IEEE},
	abstract = {The reuse of free and open source software (FOSS)
components is becoming more and more popular. They usually
contain one or more software licenses describing the requirements
and conditions which should be followed when been reused.
Licenses are usually written in the header of source code files as
program comments. Removing or modifying the license header
by re-distributors will result in the inconsistency of license with
its ancestor, and may potentially cause license infringement. But
to the best of our knowledge, no research has been devoted
to investigate such kind of license infringements nor license
inconsistencies. In this paper, we describe and categorize different
types of license inconsistencies and propose a feasible method to
detect them. Then we apply this method to Debian 7.5 and present
the license inconsistencies found in it. With a manual analysis, we
summarized various reasons behind these license inconsistencies,
some of which imply license infringement and require the attention
from the developers. This analysis also exposes the difficulty
to discover license infringements, highlighting the usefulness of
finding and maintaining source code provenance.},
	url = {http://sel.ist.osaka-u.ac.jp/lab-db/betuzuri/archive/992/992.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/992.pdf},
	author = {Yuhao Wu and Manabe, Yuki and Tetsuya Kanda and Daniel M. German and Inoue, Katsuro}
}
@proceedings {1788,
	title = {Software Patents: A Replication Study},
	year = {2015},
	month = {08/2015},
	abstract = {Previous research has documented the legal and economic aspects
of software patents. To study the evolution in the granting of software
patents we reproduced and extended part of the empirical
study on software patents conducted by Bessen and Hunt. The
original study established a criteria to identify software patents,
and provided a look at the evolution of patents granted until 2002.
We present a simple approach to retrieve patents from the full text
database provided by the United States Patent and Trademark Of-
fice (USPTO), which is freely accessible. We also present the evolution
of software patents since the original study, and which we
also present separated by major technological firms. Our research
shows a continuous increase in the number of software patents
granted higher, both in number of patents granted (in absolute numbers)
and in proportion of overall patents (in relative terms). The
relevance of studying the evolution of software patents relies in
the challenges to find prior-art, either for practitioners looking for
patenting as well as for examiners evaluating granting a new patent.},
	url = {http://www.opensym.org/os2015/proceedings-files/p104-poo-caamano.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p104-poo-caamano.pdf},
	author = {Poo-Caama{\~n}o, Germ{\'a}n and Daniel M. German}
}
@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}
}
@proceedings {1499,
	title = {Will My Patch Make It? And How Fast?: Case Study on the Linux Kernel},
	year = {2013},
	month = {05/2013},
	abstract = {The Linux kernel follows an extremely distributed reviewing and integration process supported by 130 developer mailing lists and a hierarchy of dozens of Git repositories for version control. Since not every patch can make it and of those that do, some patches require a lot more reviewing and integration effort than others, developers, reviewers and integrators need support for estimating which patches are worthwhile to spend effort on and which ones do not stand a chance. This paper cross- links and analyzes eight years of patch reviews from the kernel mailing lists and committed patches from the Git repository to understand which patches are accepted and how long it takes those patches to get to the end user. We found that 33\% of the patches makes it into a Linux release, and that most of them need 3 to 6 months for this. Furthermore, that patches developed by more experienced developers are more easily accepted and faster reviewed and integrated. Additionally, reviewing time is impacted by submission time, the number of affected subsystems by the patch and the number of requested reviewers.},
	author = {Yujuan Jiang and Adams, Bram and Daniel M. German}
}
@conference {1813,
	title = {Modification and developer metrics at the function level: Metrics for the study of the evolution of a software project},
	booktitle = {2012 3rd International Workshop on Emerging Trends in Software Metrics (WETSoM)},
	year = {2012},
	pages = {49 - 55},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Zurich, Switzerland},
	abstract = {Software evolution, and particularly its growth, has been mainly studied at the file (also sometimes referred as module) level. In this paper we propose to move from the physical towards a level that includes semantic information by using functions or methods for measuring the evolution of a software system. We point out that use of functions-based metrics has many advantages over the use of files or lines of code. We demonstrate our approach with an empirical study of two Free/Open Source projects: a community-driven project, Apache, and a company-led project, Novell Evolution. We discovered that most functions never change; when they do their number of modifications is correlated with their size, and that very few authors who modify each; finally we show that the departure of a developer from a software project slows the evolution of the functions that she authored.
},
	isbn = {978-1-4673-1763-4},
	doi = {10.1109/WETSoM.2012.6226993},
	author = {Gregorio Robles and Herraiz, Israel and Daniel M. German and Izquierdo-Cortazar, Daniel}
}
@conference {1314,
	title = {Apples vs. oranges?},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {"In this MSR challenge report, we compare the source code of two in- dustrial grade Integrated Development Environments (IDE): Netbeans, developed by Oracle Corporation, and Eclipse, developed by the Eclipse Foundation. In the same spirit as [1], our goal is not to identify how similar or different they are, but to identify differences that, if not taken into consideration, might result in biased, and potentially erroneous conclusions."},
	month = {05/2011},
	pages = {246-249},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {We attempt to compare the source code of two Java IDE systems: Netbeans and Eclipse. The result of this experiment shows that many factors, if ignored, could risk a bias in the results, and we posit various observations that should be taken into consideration to minimize such risk.

},
	keywords = {eclipse, netbeans, source code},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985483},
	author = {Davies, Julius and Daniel M. German}
}
@conference {Bougie:2011:TUT:1984701.1984707,
	title = {Towards understanding twitter use in software engineering: preliminary findings, ongoing challenges and future questions},
	booktitle = {Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering},
	series = {Web2SE {\textquoteright}11},
	year = {2011},
	note = {paper d/l from http://www.thechiselgroup.org/publications/content/towards-understanding-twitter-use-software-engineering-preliminary-findings-ong

"From this site, we selected the top 30 individuals for the topics Linux and Eclipse. We chose these two topics based on their potential to expose "tweeters" from a large operating system community as well as an IDE development community. We also decided to investigate a project for which all committers use Twitter. Through a colleague, we were informed that the MXUnit project lists the Twitter user names for all eight of its committers. The MXUnit project [5] is a small, open source ColdFusion test framework that is written as an Eclipse plug-in."},
	pages = {31{\textendash}36},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {There has been some research conducted around the motivation for the use of Twitter and the value brought by micro-blogging tools to individuals and business environments. This paper builds on our understanding of how the phenomenon affects the population which birthed the technology: Software Engineers. We find that the Software Engineering community extensively leverages Twitter{\textquoteright}s capabilities for conversation and information sharing and that use of the tool is notably different between distinct Software Engineering groups. Our work exposes topics for future research and outlines some of the challenges in exploring this type of data.},
	keywords = {eclipse, linux, mxunit, social media, software development, twitter, web 2.0},
	isbn = {978-1-4503-0595-2},
	doi = {10.1145/1984701.1984707},
	url = {http://doi.acm.org/10.1145/1984701.1984707},
	attachments = {https://flosshub.org/sites/flosshub.org/files/WEB2SE2011.pdf},
	author = {Bougie, Gargi and Starke, Jamie and Storey, Margaret-Anne and Daniel M. German}
}
@conference {Bougie:2011:TUT:1984701.1984707,
	title = {Towards understanding twitter use in software engineering: preliminary findings, ongoing challenges and future questions},
	booktitle = {Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering},
	series = {Web2SE {\textquoteright}11},
	year = {2011},
	note = {paper d/l from http://www.thechiselgroup.org/publications/content/towards-understanding-twitter-use-software-engineering-preliminary-findings-ong

"From this site, we selected the top 30 individuals for the topics Linux and Eclipse. We chose these two topics based on their potential to expose "tweeters" from a large operating system community as well as an IDE development community. We also decided to investigate a project for which all committers use Twitter. Through a colleague, we were informed that the MXUnit project lists the Twitter user names for all eight of its committers. The MXUnit project [5] is a small, open source ColdFusion test framework that is written as an Eclipse plug-in."},
	pages = {31{\textendash}36},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {There has been some research conducted around the motivation for the use of Twitter and the value brought by micro-blogging tools to individuals and business environments. This paper builds on our understanding of how the phenomenon affects the population which birthed the technology: Software Engineers. We find that the Software Engineering community extensively leverages Twitter{\textquoteright}s capabilities for conversation and information sharing and that use of the tool is notably different between distinct Software Engineering groups. Our work exposes topics for future research and outlines some of the challenges in exploring this type of data.},
	keywords = {eclipse, linux, mxunit, social media, software development, twitter, web 2.0},
	isbn = {978-1-4503-0595-2},
	doi = {10.1145/1984701.1984707},
	url = {http://doi.acm.org/10.1145/1984701.1984707},
	attachments = {https://flosshub.org/sites/flosshub.org/files/WEB2SE2011_0.pdf},
	author = {Bougie, Gargi and Starke, Jamie and Storey, Margaret-Anne and Daniel M. German}
}
@conference {948,
	title = {Beyond replication: An example of the potential benefits of replicability in the mining of software repositories community},
	booktitle = {1st Workshop on Replication in Empirical Software Engineering Research},
	year = {2010},
	month = {05/2010},
	keywords = {literature review, msr, replication},
	author = {Gregorio Robles 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 {955,
	title = {Perspectives on bugs in the Debian bug tracking system},
	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 = {86 - 89},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Bugs in Debian differ from regular software bugs. They are usually associated with packages, instead of software modules. They are caused and fixed by source package uploads instead of code commits. The majority are reported by individuals who appear in the bug database once, and only once. There also exists a small group of bug reporters with over 1,000 bug reports each to their name. We also explore our idea that a high bug-frequency for an individual package might be an indicator of popularity instead of poor quality.},
	keywords = {bug reports, debian, msr challenge, popularity},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463288},
	attachments = {https://flosshub.org/sites/flosshub.org/files/86bugs-debian.pdf},
	author = {Davies, Julius and Hanyu Zhang and Nussbaum, Lucas and Daniel M. German}
}
@conference {929,
	title = {Code siblings: Technical and legal implications of copying code between applications},
	booktitle = {2009 6th IEEE International Working Conference on Mining Software Repositories (MSR)2009 6th IEEE International Working Conference on Mining Software Repositories},
	year = {2009},
	pages = {81 - 90},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {Source code cloning does not happen within a single system only. It can also occur between one system and another. We use the term code sibling to refer to a code clone that evolves in a different system than the code from which it originates. Code siblings can only occur when the source code copyright owner allows it and when the conditions imposed by such license are not incompatible with the license of the destination system. In some situations copying of source code fragments are allowed - legally - in one direction, but not in the other. In this paper, we use clone detection, license mining and classification, and change history techniques to understand how code siblings - under different licenses - flow in one direction or the other between Linux and two BSD Unixes, FreeBSD and OpenBSD. Our results show that, in most cases, this migration appears to happen according to the terms of the license of the original code being copied, favoring always copying from less restrictive licenses towards more restrictive ones. We also discovered that sometimes code is inserted to the kernels from an outside source.},
	keywords = {bsd, fossology, freebsd, linux, openbsd, source code},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069483},
	attachments = {https://flosshub.org/sites/flosshub.org/files/81CodeSiblings.pdf},
	author = {Daniel M. German and Di Penta, Massimiliano and Gueheneuc, Yann-Gael 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 {Hindle:2008:LCT:1370750.1370773,
	title = {What do large commits tell us?: a taxonomical study of large commits},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {99{\textendash}108},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Research in the mining of software repositories has frequently ignored commits that include a large number of files (we call these large commits). The main goal of this paper is to understand the rationale behind large commits, and if there is anything we can learn from them. To address this goal we performed a case study that included the manual classification of large commits of nine open source projects. The contributions include a taxonomy of large commits, which are grouped according to their intention. We contrast large commits against small commits and show that large commits are more perfective while small commits are more corrective. These large commits provide us with a window on the development practices of maintenance teams.},
	keywords = {boost, bug fixing, egroupware, enlightenment, evolution, firebird, large commits, maintenance, mysql, postgresql, samba, software evolution, source control system, spring},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370773},
	url = {http://doi.acm.org/10.1145/1370750.1370773},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p99-hindle.pdf},
	author = {Hindle, Abram and Daniel M. German and Holt, Ric}
}
@conference {1009,
	title = {Using Software Distributions to Understand the Relationship among Free and Open Source Software Projects},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {24 - 24},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Success in the open source software world has been measured in terms of metrics such as number of downloads, number of commits, number of lines of code, number of participants, etc. These metrics tend to discriminate towards applications that are small and tend to evolve slowly. A problem is, however, how to identify applications in these latter categories that are important. Software distributions specify the dependencies needed to build and to run a given software application. We use this information to create a dependency graph of the applications contained in such a distribution. We explore the characteristics of this graph, and use it to define some metrics to quantify the dependencies (and dependents) of a given software application. We demonstrate that some applications that are invisible to the final user (such as libraries) are widely used by end-user applications. This graph can be used as a proxy to measure success of small, slowly evolving free and open source software.},
	keywords = {dependencies, evolution, fink, metrics},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.32},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300024.pdf},
	author = {Daniel M. German}
}
@article {flosswp347,
	title = {A preliminary examination of code review processes in open source projects},
	year = {2006},
	month = {January},
	abstract = {In this paper, we provide preliminary answers to the following questions regarding OSS peer review or inspection. What is the patch process and review process used by the projects? What types of review does a the project use? Why are patches rejected? What percentage of patches are rejected? Who performs the review? Are the top developers also the top reviewers? When are reviews performed? What is the frequency of review? How long do reviews take to perform? How does the patch size affect the review? How does merit-based trust among actors affect the review? Are more trusted individuals reviewed less often? How much feedback is provided in the review? What kinds of non-source code patches are reviewed? How does the kind of patch affect the review? What affect does reviewing have on other elements of the patch process? What is the relationship between reviewing and testing? The first two questions are answered in a qualitative manner for GCC, Linux, Mozilla, and Apache. The remaining questions are answered for the Apache project. The most striking similarities among projects is there use of a pre-commit review and requests for small, complete, independent patches. The Apache project also uses a post-commit review of trusted members. Reviews in the Apache project occur very frequently and usually have a review interval of hours. A small core group of reviewers conduct over 80\% of reviews for Apache; however, the number of and actual individuals fluctuates over the 9 years of data we examine.},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Rigby2006TR.pdf},
	author = {Peter C. Rigby and Daniel M. German}
}
@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 {Hindle:2005:SFM:1083142.1083161,
	title = {SCQL: a formal model and a query language for source control repositories},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {100-104},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Source Control Repositories are used in most software projects to store revisions to source code files. These repositories operate at the file level and support multiple users. A generalized formal model of source control repositories is described herein. The model is a graph in which the different entities stored in the repository become vertices and their relationships become edges. We then define SCQL, a first order, and temporal logic based query language for source control repositories. We demonstrate how SCQL can be used to specify some questions and then evaluate them using the source control repositories of five different large software projects.},
	keywords = {evolution, file, gnumeric, modperl, openssl, revision, samba, scm, source code},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083161},
	url = {http://doi.acm.org/10.1145/1082983.1083161},
	attachments = {https://flosshub.org/sites/flosshub.org/files/100scql.pdf},
	author = {Hindle, Abram and 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}
}
