@proceedings {1752,
	title = {Why Power Laws? An Explanation from Fine-Grained Code Changes},
	year = {2015},
	note = {"The data used in this section come from four open source Java projects. We used CVSANALY to collect data from their Git repositories."},
	abstract = {Throughout the years, empirical studies have found
power law distributions in various measures across many software
systems. However, surprisingly little is known about how
they are produced. What causes these power law distributions?
We offer an explanation from the perspective of fine-grained
code changes. A model based on preferential attachment and selforganized
criticality is proposed to simulate software evolution.
The experiment shows that the simulation is able to render power
law distributions out of fine-grained code changes, suggesting
preferential attachment and self-organized criticality are the
underlying mechanism causing the power law distributions in
software systems.},
	keywords = {Apache Maven, cvsanaly, eclipse, git, Google Guice, java, jedit, open source},
	url = {https://users.soe.ucsc.edu/~linzhp/msr2015.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr2015.pdf},
	author = {Zhongpeng Lin and Jim Whitehead}
}
@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}
}
@conference {839,
	title = {Amassing and indexing a large sample of version control systems: towards the census of public source code history},
	booktitle = {6th IEEE Working Conference on Mining Software Repositories},
	year = {2009},
	note = {Related work: "For example, FLOSSMole [8]
collects the list of projects and their metadata from SourceForge,
FreshMeat, Free Software Foundation (FSF), RubyForge,
and ObjectWeb. "

"The list of
home pages from open source directories such as FSF or
FLOSSMole could provide a focused set of web pages for
the search"

"To get the list of projects for SourceForge we used
FLOSSMole project [8] that collects the list of SourceForge
projects and their metadata. We use project ID, because it
was used to specify the VCS URL within the SourceForge
repository."},
	month = {May 16{\textendash}17},
	abstract = {The source code and its history represent the output and process of software development activities and are an in- valuable resource for study and improvement of software development practice. While individual projects and groups of projects have been extensively analyzed, some fundamental questions, such as the spread of innovation or genealogy of the source code, can be answered only by considering the entire universe of publicly available source code and its history. We describe methods we developed over the last six years to gather, index, and update an approximation of such a universal repository for publicly accessible version control systems and for the source code inside a large corporation. While challenging, the task is achievable with limited resources. The bottlenecks in network bandwidth, processing, and disk access can be dealt with using inherent parallelism of the tasks and suitable tradeoffs between the amount of storage and computations, but a completely automated discovery of public version control systems may require enticing participation of the sampled projects. Such universal repository would allow studies of global properties and origins of the source code that are not possible through other means.},
	keywords = {bazaar, cvs, flossmole, git, mercurial, source code, sourceforge, subversion, version control},
	attachments = {https://flosshub.org/sites/flosshub.org/files/11amassing.pdf},
	author = {Audris Mockus}
}
@conference {DBLP:conf/msr/BirdRBHGD09,
	title = {The promises and perils of mining git},
	booktitle = {Proceedings of the 6th International Working Conference on Mining Software Repositories, MSR 2009},
	year = {2009},
	pages = {1-10},
	abstract = {We are now witnessing the rapid growth of decentralized source code management (DSCM) systems, in which every developer has her own repository. DSCMs facilitate a style of collaboration in which work output can flow sideways (and privately) between collaborators, rather than always up and down (and publicly) via a central repository. Decentralization comes with both the promise of new data and the peril of its misinterpretation. We focus on git, a very popular DSCM used in high-profile projects. Decentralization, and other features of git, such as automatically recorded contributor attribution, lead to richer content histories, giving rise to new questions such as "How do contributions flow between developers to the official project repository?" However, there are pitfalls. Commits may be reordered, deleted, or edited as they move between repositories. The semantics of terms common to SCMs and DSCMs sometimes differ markedly, potentially creating confusion. For example, a commit is immediately visible to all developers in centralized SCMs, but not in DSCMs. Our goal is to help researchers interested in DSCMs avoid these and other perils when mining and analyzing git data.},
	keywords = {dscm, git, mining, scm, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/1promisePeril.pdf},
	author = {Christian Bird and Peter C. Rigby and Earl T. Barr and David J. Hamilton and Daniel M. Germ{\'a}n and Premkumar T. Devanbu}
}
@conference {1206,
	title = {Collecting data from distributed FOSS projects},
	booktitle = {3rd Workshop on Public Data about Software Development (WoPDaSD 2008)},
	year = {2008},
	note = {"We selected three projects from the initial set of projects: Linux 2.6, an operating system kernel, gimp, a graphics program, and Blender, a 3d content creation suite."
"To acquire data from each data source, we wrote special programs based on the earlier prototypes....The first program extracts information from mailing list archives....The second program obtains bug reports from bug tracking systems....The third program obtains source code from network-accessible version control systems and runs metric calculations on it."},
	month = {2009},
	pages = {8-13},
	abstract = {A key trait of Free and Open Source Software (foss) development is its distributed nature. Nevertheless, two project-level operations, the fork and the merge of program code, are among the least well understood events in the lifespan of a foss project. Some projects have explicitly adopted these operations as the primary means of concurrent development. In this study, we examine the effect of highly distributed software development, as found in the Linux kernel project, on collection and modelling of software development data. We find that distributed development calls for sophisticated temporal modelling techniques where several versions of the source code tree can exist at once. Attention must be turned towards the methods of quality assurance and peer review that projects employ to manage these parallel source trees. Our analysis indicates that two new metrics, fork rate and merge rate, could be useful for determining the role of distributed version control systems in foss projects. The study 
presents a preliminary data set consisting of version control and mailing list data. },
	keywords = {bitkeeper, bug tracking system, cvs, distributed, email archive, fork rate, git, life cycle, linux, linux kernel, mailing list, merge rate, subversion, svn, version control},
	attachments = {https://flosshub.org/sites/flosshub.org/files/fagerholm.pdf},
	author = {Fagerholm, Fabian and Taina, Juha}
}
@conference {1229,
	title = {Regurgitate: Using GIT For F/LOSS Data Collection},
	booktitle = {1st Workshop on Public Data about Software Development (WoPDaSD 2006)},
	year = {2006},
	abstract = {We have created a new tool, regurgitate, for importing CVS repositories into the GIT source code management system. Important features of GIT include great expressiveness in capturing relationships between revisions and across files as well as extremely high-speed processing. These features make GIT an ideal platform for gathering detailed longitudinal metrics for open source projects. The availability of regurgitate facilitates using GIT as an analysis tool for that majority of open source projects that keep their repositories in CVS. In particular, GIT is fast enough that it is practical to replay the entire development history of a project commit-at-a-time, collecting metrics at each step. We demonstrate this process for a simple metric and a collection of benchmark F/LOSS repositories.},
	keywords = {cvs, cvsanaly, git, history, promise, regurgitate, scm},
	attachments = {https://flosshub.org/sites/flosshub.org/files/massey.pdf},
	author = {Bart Massey and Keith Packard}
}
