@proceedings {1916,
	title = {Advancing Open Science with Version Control and Blockchains},
	year = {2017},
	month = {05/2017},
	pages = {13-14},
	abstract = {The scientific community is facing a crisis of reproducibility:
confidence in scientific results is damaged by
concerns regarding the integrity of experimental data and the
analyses applied to that data. Experimental integrity can be
compromised inadvertently when researchers overlook some
important component of their experimental procedure, or intentionally
by researchers or malicious third-parties who are
biased towards ensuring a specific outcome of an experiment.
The scientific community has pushed for {\textquotedblleft}open science{\textquotedblright} to add
transparency to the experimental process, asking researchers to
publicly register their data sets and experimental procedures.
We argue that the software engineering community can leverage
its expertise in tracking traceability and provenance of source
code and its related artifacts to simplify data management for
scientists. Moreover, by leveraging smart contract and blockchain
technologies, we believe that it is possible for such a system to
guarantee end-to-end integrity of scientific data and results while
supporting collaborative research.},
	keywords = {blockchain, replication, reproducible},
	author = {Jonathan Bell and Thomas D. LaToza and Foteini Baldmitsi and Angelos Stavrou}
}
@proceedings {1913,
	title = {An Empirical Analysis of Build Failures in the Continuous Integration Workflows of Java-Based Open-Source Software},
	year = {2017},
	note = {"empirical study of CI build
failures in 14 Java-based OSS projects. We extract and analyze
data from publicly available GitHub repositories and Travis-CI
build logs"},
	month = {05/2017},
	pages = {345-355},
	abstract = {{\textemdash}Continuous Integration (CI) has become a common
practice in both industrial and open-source software development.
While CI has evidently improved aspects of the software
development process, errors during CI builds pose a threat to
development efficiency. As an increasing amount of time goes
into fixing such errors, failing builds can significantly impair the
development process and become very costly. We perform an indepth
analysis of build failures in CI environments. Our approach
links repository commits to data of corresponding CI builds.
Using data from 14 open-source Java projects, we first identify
14 common error categories. Besides test failures, which are by
far the most common error category (up to >80\% per project),
we also identify noisy build data, e.g., induced by transient Git
interaction errors, or general infrastructure flakiness. Second,
we analyze which factors impact the build results, taking into
account general process and specific CI metrics. Our results
indicate that process metrics have a significant impact on the
build outcome in 8 of the 14 projects on average, but the strongest
influencing factor across all projects is overall stability in the
recent build history. For 10 projects, more than 50\% (up to 80\%)
of all failed builds follow a previous build failure. Moreover, the
fail ratio of the last k=10 builds has a significant impact on build
results for all projects in our dataset.},
	keywords = {build errors, continuous integration, correlation analysis, msr},
	author = {Thomas Rausch and Waldemar Hummer and Philipp Leitner and Stefan Schulte}
}
@inbook {1741,
	title = {First Results About Motivation and Impact of License Changes in Open Source Projects},
	booktitle = {Open Source Systems: Adoption and Impact},
	series = {IFIP Advances in Information and Communication Technology},
	volume = {451},
	year = {2015},
	pages = {137-145},
	publisher = {Springer International Publishing},
	organization = {Springer International Publishing},
	abstract = {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.
},
	keywords = {Business model, Contributor agreement, intellectual property, license, open source},
	isbn = {978-3-319-17836-3},
	doi = {10.1007/978-3-319-17837-0_13},
	url = {http://dx.doi.org/10.1007/978-3-319-17837-0_13},
	author = {Viseur, Robert and Gregorio Robles},
	editor = {Damiani, Ernesto and Frati, Fulvio and Dirk Riehle and Wasserman, Anthony I.}
}
@booklet {1781,
	title = {Lessons Learned from Applying Social Network Analysis on an Industrial Free/Libre/Open Source Software Ecosystem},
	year = {2015},
	abstract = {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.},
	keywords = {business models, cloud computing, homophily, open source, Open-Coopetition, openstack, social network analysis, Software ecosystems},
	url = {http://arxiv.org/abs/1507.04587},
	author = {Teixeira, Jose and Gregorio Robles and Jesus M. Gonzalez-Barahona}
}
@inbook {1736,
	title = {A Systematic Approach for Evaluating BPM Systems: Case Studies on Open Source and Proprietary Tools},
	booktitle = {Open Source Systems: Adoption and Impact},
	series = {IFIP Advances in Information and Communication Technology},
	volume = {451},
	year = {2015},
	pages = {81-90},
	publisher = {Springer International Publishing},
	organization = {Springer International Publishing},
	abstract = {Business Process Management Systems (BPMS) provide support for modeling, developing, deploying, executing and evaluating business processes in an organization. Selecting a BPMS is not a trivial task, not only due to the many existing alternatives, both in the open source and proprietary realms, but also because it requires a thorough evaluation of its capabilities, contextualizing them in the organizational environment in which they will be used. In this paper we present a methodology to guide the systematic evaluation of BPMS that takes into account the specific needs of each organization. It provides a list of key characteristics of BPMS which are ranked by the organization and evaluated using test cases and quantitative criteria. We also present case studies of open source and proprietary BPMS evaluations following our proposal.
},
	keywords = {Business Process Management Systems (BPMS), Evaluation methodology, Open source and proprietary BPMS, Systematic approach},
	isbn = {978-3-319-17836-3},
	doi = {10.1007/978-3-319-17837-0_8},
	url = {http://dx.doi.org/10.1007/978-3-319-17837-0_8},
	author = {Delgado, Andrea and Calegari, Daniel and Milanese, Pablo and Falcon, Renatta and Garc{\'\i}a, Esteban},
	editor = {Damiani, Ernesto and Frati, Fulvio and Dirk Riehle and Wasserman, Anthony I.}
}
@inbook {1619,
	title = {The Census of the Brazilian Open-Source Community},
	booktitle = {Open Source Software: Mobile Open Source Technologies},
	series = {IFIP Advances in Information and Communication Technology},
	volume = {427},
	year = {2014},
	pages = {202-211},
	publisher = {Springer Berlin Heidelberg},
	organization = {Springer Berlin Heidelberg},
	abstract = {

During a long time, software engineering research has been trying to better understand open-source communities and uncover two fundamental questions: (i) who are the contributors and (i) why they contribute. Most of these researches focus on well-known OSS projects, but little is known about the OSS movement in emerging countries. In this paper, we attempt to fill this gap by presenting a picture of the Brazilian open-source contributor. To achieve this goal, we examined activities from more than 12,400 programmers on Github, during the period of a year. Subsequently, we correlate our findings with a survey that was answered by more than 1,000 active contributors. Our results show that exists an OSS trend in Brazil: most part of the contributors are active, performing around 30 contributions per year, and they contribute to OSS basically by altruism.
},
	keywords = {Brazilian OSS Community, github, OSS},
	isbn = {978-3-642-55127-7},
	doi = {10.1007/978-3-642-55128-4_30},
	url = {http://dx.doi.org/10.1007/978-3-642-55128-4_30},
	author = {Pinto, Gustavo and Kamei, Fernando},
	editor = {Corral, Luis and Sillitti, Alberto and Succi, Giancarlo and Vlasenko, Jelena and Wasserman, AnthonyI.}
}
@conference {Romo:2014:FGD:2641580.2641592,
	title = {Filling the Gaps of Development Logs and Bug Issue Data},
	booktitle = {Proceedings of The International Symposium on Open Collaboration},
	series = {OpenSym {\textquoteright}14},
	year = {2014},
	pages = {8:1{\textendash}8:4},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {It has been suggested that the data from bug repositories is not always in sync or complete compared to the logs detailing the actions of developers on source code.

In this paper, we trace two sources of information relative to software bugs: the change logs of the actions of developers and the issues reported as bugs. The aim is to identify and quantify the discrepancies between the two sources in recording and storing the developer logs relative to bugs.

Focussing on the databases produced by two mining software repository tools, CVSAnalY and Bicho, we use part of the SZZ algorithm to identify bugs and to compare how the "defects-fixing changes" are recorded in the two databases. We use a working example to show how to do so.

The results indicate that there is a significant amount of information, not in sync when tracing bugs in the two databases. We, therefore, propose an automatic approach to re-align the two databases, so that the collected information is mirrored and in sync.},
	keywords = {Bug traceability, bug-fixing commits},
	isbn = {978-1-4503-3016-9},
	doi = {10.1145/2641580.2641592},
	url = {http://doi.acm.org/10.1145/2641580.2641592},
	author = {Romo, Bilyaminu Auwal and Capiluppi, Andrea and Hall, Tracy}
}
@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}
}
@proceedings {1512,
	title = {Discovering, Reporting, and Fixing Performance Bugs},
	year = {2013},
	month = {05/2013},
	abstract = {Software performance is critical for how users perceive the quality of software products. Performance bugs---programming errors that cause significant performance degradation---lead to poor user experience and low system throughput. Designing effective techniques to address performance bugs requires a deep understanding of how performance bugs are discovered, reported, and fixed. In this paper, we study how performance bugs are discovered, reported to developers, and fixed by developers, and compare the results with those for non-performance bugs. We study performance and non-performance bugs from three popular code bases: Eclipse JDT, Eclipse SWT, and Mozilla. First, we find little evidence that fixing performance bugs has a higher chance to introduce new functional bugs than fixing non-performance bugs, which implies that developers may not need to be overconcerned about fixing performance bugs. Second, although fixing performance bugs is about as error-prone as fixing nonperformance bugs, fixing performance bugs is more difficult than fixing non-performance bugs, indicating that developers need better tool support for fixing performance bugs and testing performance bug patches. Third, unlike many non-performance bugs, a large percentage of performance bugs are discovered through code reasoning, not through users observing the negative effects of the bugs (e.g., performance degradation) or through profiling. The result suggests that techniques to help developers reason about performance, better test oracles, and better profiling techniques are needed for discovering performance bugs.},
	keywords = {bugs, eclipse, mozilla, performance bugs},
	author = {Adrian Nistor and Tian Jiang and Tan, Lin}
}
@conference {zmzkh-icsm-2013,
	title = {How does Context affect the Distribution of Software Maintainability Metrics?},
	booktitle = {Proceedings of the 29th IEEE International Conference on Software Maintainability},
	series = {ICSM {\textquoteright}13},
	year = {2013},
	note = {"FLOSSMole [25] is another data source, from
where we download descriptions (i.e., application domain)
of SourceForge software systems. Furthermore, we download
latest application domain information4
and monthly download
data5 of studied software systems directly from SourceForge."},
	abstract = {Software metrics have many uses, e.g., defect prediction, effort estimation, and benchmarking an organization against peers and industry standards. In all these cases, metrics may depend on the context, such as the programming language. Here we aim to investigate if the distributions of commonly used metrics do, in fact, vary with six context factors: application domain, programming language, age, lifespan, the number of changes, and the number of downloads. For this preliminary study we select 320 nontrivial software systems from SourceForge. These software systems are randomly sampled from nine popular application domains of SourceForge. We calculate 39 metrics commonly used to assess software maintainability for each software system and use Kruskal Wallis test and Mann-Whitney U test to determine if there are significant differences among the distributions with respect to each of the six context factors. We use Cliff{\textquoteright}s delta to measure the magnitude of the differences and find that all six context factors affect the distribution of 20 metrics and the programming language factor affects 35 metrics. We also briefly discuss how each context factor may affect the distribution of metric values.We expect our results to help software benchmarking and other software engineering methods that rely on these commonly used metrics to be tailored to a particular context.},
	keywords = {benchmark, context, contextual factor, flossmole, large scale, metrics, mining software repositories, sampling, software maintainability, sourceforge, static metrics},
	attachments = {https://flosshub.org/sites/flosshub.org/files/icsm2013_contextstudy.pdf},
	author = {Zhang, Feng and Audris Mockus and Ying Zou and Foutse Khomh and Hassan, Ahmed E.}
}
@proceedings {1501,
	title = {The Impact of Tangled Code Changes},
	year = {2013},
	month = {05/2013},
	abstract = {When interacting with version control systems, developers often commit unrelated or loosely related code changes
in a single transaction. When analyzing the version history, such
tangled changes will make all changes to all modules appear
related, possibly compromising the resulting analyses through
noise and bias. In an investigation of five open-source JAVA
projects, we found up to 15\% of all bug fixes to consist of multiple
tangled changes. Using a multi-predictor approach to untangle
changes, we show that on average at least 16.6\% of all source
files are incorrectly associated with bug reports. We recommend
better change organization to limit the impact of tangled changes.},
	keywords = {bias, data quality, history, java, mining software repositories, noise, tangled code changes, version control},
	url = {http://www.kim-herzig.de/wp-content/uploads/2013/03/msr2013-untangling.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr2013-untangling.pdf},
	author = {Kim Herzig and Zeller, Andreas}
}
@proceedings {1521,
	title = {It{\textquoteright}s Not a Bug, It{\textquoteright}s a Feature: How Misclassification Impacts Bug Prediction},
	year = {2013},
	month = {05/2013},
	pages = {392-401},
	abstract = {In a manual examination of more than 7,000 issue reports from the bug databases of five open-source projects, we found 33.8\% of all bug reports to be misclassified{\textemdash}that is, rather than referring to a code fix, they resulted in a new feature, an update to documentation, or an internal refactoring. This misclassification introduces bias in bug prediction models, confusing bugs and features: On average, 39\% of files marked as defective actually never had a bug. We discuss the impact of this misclassification on earlier studies and recommend manual data validation for future studies.},
	keywords = {bias, bug reports, data quality, mining software repositories, noise},
	author = {Kim Herzig and Sascha Just and Zeller, Andreas}
}
@proceedings {1497,
	title = {Why So Complicated? Simple Term Filtering and Weighting for Location-Based Bug Report Assignment Recommendation},
	year = {2013},
	month = {05-2013},
	pages = {2-11},
	abstract = {Large software development projects receive many
bug reports and each of these reports needs to be triaged. An
important step in the triage process is the assignment of the
report to a developer. Most previous eorts towards improving
bug report assignment have focused on using an activity-based
approach. We address some of the limitations of activity-based
approaches by proposing a two-phased location-based approach
where bug report assignment recommendations are based on the
predicted location of the bug. The proposed approach utilizes
a noun extraction process on several information sources to
determine bug location information and a simple term weighting
scheme to provide a bug report assignment recommendation.
We found that by using a location-based approach, we achieved
an accuracy of 89.41\% and 59.76\% when recommending five
developers for the Eclipse and Mozilla projects, respectively.},
	keywords = {bug, bug report assignment, eclipse, File Activity Histories, Mining Software Artifacts, mozilla, Named Entity Recognition, POS Filtering},
	url = {http://www.cwu.edu/~janvik/papers/msr2013.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr2013.pdf}
}
@article {1399,
	title = {The evolution of Java build systems},
	journal = {Empirical Software Engineering},
	volume = {17},
	year = {2012},
	month = {8/2012},
	pages = {578 - 608},
	abstract = {Build systems are responsible for transforming static source code artifacts into executable software. While build systems play such a crucial role in software development and maintenance, they have been largely ignored by software evolution researchers. However, a firm understanding of build system aging processes is needed in order to allow project managers to allocate personnel and resources to build system maintenance tasks effectively, and reduce the build maintenance overhead on regular development activities. In this paper, we study the evolution of build systems based on two popular Java build languages (i.e., ANT and Maven) from two perspectives: (1) a static perspective, where we examine the complexity of build system specifications using software metrics adopted from the source code domain; and (2) a dynamic perspective, where the complexity and coverage of representative build runs are measured. Case studies of the build systems of six open source build projects with a combined history of 172 releases show that build system and source code size are highly correlated, with source code restructurings often requiring build system restructurings. Furthermore, we find that Java build systems evolve dynamically in terms of duration and recursive depth of the directory hierarchy. },
	keywords = {ant, build, maven, scm, source code analysis},
	issn = {1573-7616},
	doi = {10.1007/s10664-011-9169-5},
	author = {McIntosh, Shane and Adams, Bram and Hassan, Ahmed E.}
}
@proceedings {1451,
	title = {Exploring the Role of Outside Organizations in Free / Open Source Software Projects},
	volume = {378},
	year = {2012},
	month = {09/2012},
	pages = {201-215},
	publisher = {IFIP AICT},
	abstract = {Free/Open Source Software (FOSS) projects have a reputation for being grass-roots efforts driven by individual contributors volunteering their time and effort. While this may be true for a majority of smaller projects, it is not always the case for large projects. As projects grow in size, importance and complexity, many come to depend on corporations, universities, NGO{\textquoteright}s and governments, for support and contributions, either financially or through seconded staff. As outside organizations get involved in projects, how does this affect their governance, transparency and direction? To study this question we gathered bug reports and commit logs for GCC and the Linux Kernel. We found that outside organizations contribute a majority of code but rarely participate in bug triaging. Therefore their code does not necessarily address the needs of others and may distort governance and direction. We conclude that projects should examine their dependence on outside organizations},
	keywords = {bug reports, commit, Community sustainability, Contributor affiliation, gcc, governance, linux kernel, Participation metrics},
	url = {http://research.engr.oregonstate.edu/hci/sites/research.engr.oregonstate.edu.hci/files/papers/forrest2012exploring.pdf},
	author = {Forrest, Darren and Jensen, Carlos and Mohan, Nitin and Davidson, Jennifer}
}
@proceedings {1444,
	title = {Gender Differences in Early Free and Open Source Software Joining Process},
	volume = {378},
	year = {2012},
	note = {"We examined subscriber logs and data for six FOSS projects..."
"We examined the differences between posters and non-posters to determine the attrition rate..."
"Using data from the US Census, we matched names to lists of the most common female and male names. We identified 666 users using this process."},
	month = {09/2012},
	pages = {78-93},
	publisher = {IFIP AICT, Springer},
	address = {Eighth International Conference on Open Source Systems (OSS 2012)},
	abstract = {With the growth of free and open source software (FOSS) and the adoption of FOSS solutions in business and everyday life, it is important that projects serve their growingly diverse user base. The sustainability of FOSS projects relies on a constant influx of new contributors. Several large demo- graphic surveys found that FOSS communities are very homogenous, dominated by young men, similar to the bias existing in the rest of the IT workforce. Building on previous research, we examine mailing list subscriptions and posting statistics of female FOSS participants. New participants often experience their first interaction on a FOSS project{\textquoteright}s mailing list. We explored six FOSS projects {\textendash} Buildroot, Busybox, Jaws, Parrot, uClibc, and Yum. We found a declining rate of female participation from the 8.27\% of subscribers, to 6.63\% of posters, and finally the often reported code contributor rate of 1.5\%. We found a disproportionate attrition rate among women along every step of the FOSS joining process.},
	keywords = {buildroot, busybox, diversity, email, jaws, joining process, mailing lists, parrot, uClibc, Yum},
	author = {Kuechler, Victor and Gilbertson, Claire and Jensen, Carlos}
}
@article {1397,
	title = {How do open source communities blog?},
	journal = {Empirical Software Engineering},
	year = {2012},
	abstract = {We report on an exploratory study, which aims at understanding how software communities use blogs compared to conventional development infrastructures. We analyzed the behavior of 1,100 bloggers in four large open source communities, distinguishing between committing bloggers and other community members. We observed that these communities intensively use blogs with one new entry every 8 h. A blog entry includes 14 times more words than a commit message. When analyzing the content of the blogs, we found that committers and others bloggers write about similar topics. Most popular topics in committers{\textquoteright} blogs represent high-level concepts such as features and domain concepts, while source code related topics are discussed in 15\% of their posts. Other community members frequently write about community events and conferences as well as configuration and deployment topics. We found that the blogging peak period is usually after the software is released. Moreover, committers are more likely to blog after corrective engineering than after forward engineering and re-engineering activities. Our findings call for a hypothesis-driven research to (a) further understand the role of social media in dissolving the collaboration boundaries between developers and other stakeholders and (b) integrate social media into development processes and tools. },
	keywords = {blog, blogs},
	issn = {1573-7616},
	doi = {10.1007/s10664-012-9211-2},
	author = {Pagano, Dennis and Maalej, Walid}
}
@proceedings {1467,
	title = {A Linguistic Analysis on How Contributors Solve Software Problems in a Distributed Context},
	volume = {378},
	year = {2012},
	note = {"... a sample of 4109 bug reports was extracted from Bugzilla bug report repository"
"The analysis of our sample allows identifying the roles of participants in this activity according to their hierarchical statutes in the community. "
"we look statistically at words that people use in Bugzilla to discern differences in the discourse and representation between participants (core and periphery)"},
	month = {09/2012},
	pages = {322-330},
	publisher = {IFIP AICT,  Springer},
	abstract = {There is a little understanding of distributed solving activities in Open Source communities. This study aimed to provide some insights in this way. It was applied to the context of Bugzilla, the bug tracking system of Mozilla community. This study investigated the organizational aspects of this meditated, complex and highly distributed context through a linguistic analysis method. The main finding of this research shows that the organization of distributed problem-solving activities in Bugzilla isn{\textquoteright}t based only on the hierarchical distribution of the work between core and periphery participants but on their implication in the interactions. This implication varies according to the status of each one participant in the community. That is why we distinguish their roles, as well as, the established modes to manage such activity.},
	keywords = {bug report, bugzilla, linguistic, text mining},
	author = {Masmoudi, H{\'e}la and Boughzala, Imed}
}
@mastersthesis {1438,
	title = {Software Libre y abierto: comunidades y redes de producción digital de bienes comunes},
	year = {2012},
	pages = {269 pages},
	school = {Universidad Nacional Autónoma de México},
	address = {Ciudad de México, México},
	abstract = {This thesis is about a collective form of production that have expanded and strengthen in the global high technology market. It is about FLOSS production. 

The study takes on account that technnologies are not neutral, they emerge as strategies and mechanisms of politics and economic interests. 

Although, FLOSS production is inserted in the capitalist context, the collective work of the communities and networks that produce it is based on ideas about freedom and solidarity.

The types of rules and organization of labour inside of this communities have develop a kind of product that it is well categorized as part of the new commons.

The conclusions at the end of this work pretend to offer a clear approach to the FLOSS production networks dynamics inside the virtual infrastructure. Specifically, it offers an approach of the interaction and forms of cooperation, as well of the individual and collective schemas that motivates the cooperation action of the individuals.},
	keywords = {bienes comunes, commons, comunidades virtuales, FLOSS, flossmole, hackers, redes virtuales, repositories, repositorios, Software libre y abierto, virtual communities, virtual networks},
	url = {http://132.248.9.195/ptd2012/agosto/406008604/Index.html},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Tesis.pdf},
	author = {Tania E. Turner Sen}
}
@article {1396,
	title = {Studying the impact of social interactions on software quality},
	journal = {Empirical Software Engineering},
	year = {2012},
	note = {bug databases},
	abstract = {Correcting software defects accounts for a significant amount of resources in a software project. To make best use of testing efforts, researchers have studied statistical models to predict in which parts of a software system future defects are likely to occur. By studying the mathematical relations between predictor variables used in these models, researchers can form an increased understanding of the important connections between development activities and software quality. Predictor variables used in past top-performing models are largely based on source code-oriented metrics, such as lines of code or number of changes. However, source code is the end product of numerous interlaced and collaborative activities carried out by developers. Traces of such activities can be found in the various repositories used to manage development efforts. In this paper, we develop statistical models to study the impact of social interactions in a software project on software quality. These models use predictor variables based on social information mined from the issue tracking and version control repositories of two large open-source software projects. The results of our case studies demonstrate the impact of metrics from four different dimensions of social interaction on post-release defects. Our findings show that statistical models based on social information have a similar degree of explanatory power as traditional models. Furthermore, our results demonstrate that social information does not substitute, but rather augments traditional source code-based metrics used in defect prediction models.},
	keywords = {bug tracker, eclipse, Firefox, Human Factors, measurement, metrics, software evolution, Software quality assurance},
	issn = {1573-7616},
	doi = {10.1007/s10664-012-9205-0},
	author = {Bettenburg, Nicolas and Hassan, Ahmed E.}
}
@article {1324,
	title = {Are Developers Fixing Their Own Bugs?},
	journal = {International Journal of Open Source Software and Processes},
	volume = {3},
	year = {2011},
	note = {"The analysis is focused at the level of lines of code and it uses the information stored in the source code management system"},
	pages = {23 - 42},
	abstract = {The process of fixing software bugs plays a key role in the maintenance activities of a software project. Ideally, code ownership and responsibility should be enforced among developers working on the same artifacts, so that those introducing buggy code could also contribute to its fix. However, especially in FLOSS projects, this mechanism is not clearly understood: in particular, it is not known whether those contributors fixing a bug are the same introducing and seeding it in the first place. This paper analyzes the comm-central FLOSS project, which hosts part of the Thunderbird, SeaMonkey, Lightning extensions and Sunbird projects from the Mozilla community. The analysis is focused at the level of lines of code and it uses the information stored in the source code management system. The results of this study show that in 80\% of the cases, the bug-fixing activity involves source code modified by at most two developers. It also emerges that the developers fixing the bug are only responsible for 3.5\% of the previous modifications to the lines affected; this implies that the other developers making changes to those lines could have made that fix. In most of the cases the bug fixing process in comm-central is not carried out by the same developers than those who seeded the buggy code.},
	keywords = {bug fixing, developers, loc, scm},
	issn = {1942-3934},
	doi = {10.4018/jossp.2011040102},
	author = {Izquierdo-Cortazar, Daniel and Capiluppi, Andrea and Jesus M. Gonzalez-Barahona}
}
@conference {1304,
	title = {Entering the circle of trust},
	booktitle = {Proceeding of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {"we started by analyzing 219 projects"
},
	month = {05/2011},
	pages = {133-142},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {The success of an open-source project depends to a large degree on the proactive and constructive participation by the developer community. An important role that developers play in a project is that of a code committer. However, code-commit privilege is typically restricted to the core group of a project. In this paper, we study the phenomenon of the induction of external developers as code committers. The trustworthiness of an external developer is one of the key factors that determines the granting of commit privileges. Therefore, we formulate different hypotheses to explain how the trust is established in practice. To investigate our hypotheses, we developed an automated approach based on mining code repositories and bug-tracking systems. We implemented the approach and performed an empirical study, using the Eclipse projects, to test the hypotheses. Our results indicate that, most frequently, developers establish trust and credibility in a project by contributing to the project in a non-committer role. Moreover, the employing organization of a developer is another factor--although a less significant one--that influences trust.},
	keywords = {bug tracking, bug tracking system, commits, committers, core, developers, eclipse, trust},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985462},
	author = {Mani, Senthil and Sinha, Saurabh and Sinha, Vibha Singhal}
}
@proceedings {1283,
	title = {Framing the Conundrum of Total Cost of Ownership of Open Source Software},
	year = {2011},
	month = {10/2011},
	pages = {208-219},
	publisher = {Springer},
	abstract = {This paper reflects the results of phase I of our study on the total cost of ownership (TCO) of open source software adoption. Not only have we found TCO to be an intriguing issue but it is contentious, baffling and each company approaches it in a distinctive manner (and sometimes not at all). In effect it is a conundrum that needs unpacking before it can be explained and understood. Our paper discusses the components of TCO as total cost of ownership and total cost of acquisition (and besides). Using this broad dichotomy and its various components we then analyze our data to make sense of procurement decisions in relation to open source software in the public sector and private companies.},
	keywords = {benefits, exit costs, open source software, software adoption, Survey, tco, total cost of ownership},
	author = {Maha Shaikh and Cornford, Tony}
}
@conference {1307,
	title = {How do developers blog?},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {publishing frequency, post structure, word usage, publication patterns, content},
	month = {05/2011},
	pages = {123-132},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {We report on an exploratory study, which aims at understanding how software developers use social media compared to conventional development infrastructures. We analyzed the blogging and the committing behavior of 1,100 developers in four large open source communities. We observed that these communities intensively use blogs with one new entry about every 8 hours. A blog entry includes 14 times more words than a commit message. When analyzing the content of the blogs, we found that most popular topics represent high-level concepts such as functional requirements and domain concepts. Source code related topics are covered in less than 15\% of the posts. Our results also show that developers are more likely to blog after corrective engineering and management activities than after forward engineering and re-engineering activities. Our findings call for a hypothesis-driven research to further understand the role of social media in software engineering and integrate it into development processes and tools.},
	keywords = {blog, communication, developer, eclipse, gnome, LDA, postgres, python},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985461},
	author = {Maalej, Walid and Pagano, Dennis}
}
@article {1398,
	title = {The search for a research method for studying OSS process innovation},
	journal = {Empirical Software Engineering},
	volume = {16},
	year = {2011},
	month = {8/2011},
	pages = {514 - 537},
	abstract = {Medium-sized, open-participation Open Source Software (OSS) projects do not usually perform explicit software process improvement on any routine basis. It would be useful to understand how to get such a project to accept a process improvement proposal and hence to perform process innovation. We want to determine an effective and feasible qualitative research method for studying the above question. We present (narratively) a case study of how we worked towards and eventually found such a research method. The case involves four attempts at collecting suitable data about innovation episodes (direct participation (twice), polling developers for episodes, manually finding episodes in mailing list archives) and the adaptation of the Grounded Theory data analysis methodology. Direct participation allows gathering rather rich data, but does not allow for observing a sufficiently large number of innovation episodes. Polling developers for episodes did not prove to be useful. Using mailing list archives to find data to be analyzed is both feasible and effective. We also describe how the data thus found can be analyzed based on the Grounded Theory Method with suitable adjustments. By-and-large, our findings ought to apply to studying various phenomena in OSS development processes that are similarly heavyweight and infrequent. However, specific details may block this possibility and we cannot predict which details that might be. The amount of effort involved in direct participation approaches to qualitative research can easily be underestimated. Also, survey approaches are not well-suited for many process issues in OSS, because too few developers are sufficiently process-conscious. An approach based on passive observation is a viable alternative in the OSS context due to the availability of large amounts of fairly complete archival data. },
	keywords = {argouml, Bochs, bugzilla, Flyspray, FreeDOS, gEDA, grounded theory, Grub, Innovation introduction, KVM, mailing list, Methodology, MonetDB, open source, Request Tracket, Rox, U-Boot, Xfce},
	issn = {1573-7616},
	doi = {10.1007/s10664-011-9160-1},
	author = {Prechelt, Lutz and Oezbek, Christopher}
}
@conference {1308,
	title = {Social interactions around cross-system bug fixings},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {"We rely on information stored in versioning database and mailing lists of both systems and develop methods to reconstruct and integrate different historical database"},
	month = {05/2011},
	pages = {143-152},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {Cross-system bug fixing propagation is frequent among systems having similar characteristics, using a common framework, or, in general, systems with cloned source code fragments. While previous studies showed that clones tend to be properly maintained within a single system, very little is known about cross-system bug management.

This paper describes an approach to mine explicitly documented cross-system bug fixings, and to relate their occurrences to social characteristics of contributors discussing through the project mailing lists--e.g., degree, betweenness, and brokerage--as well as to the contributors{\textquoteright} activity on source code.

The paper reports results of an empirical study carried out on FreeBSD and OpenBSD kernels. The study shows that the phenomenon of cross-system bug fixing between these two projects occurs often, despite the limited overlap of contributors. The study also shows that cross-system bug fixings mainly involve contributors with the highest degree, betweenness and brokerage level, as well as contributors that change the source code more than others.},
	keywords = {bug fixing, bug tracking system, committers, email, email archives, freebsd, mailing list, openbsd},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985463},
	author = {Cerulo, Luigi and Cimitile, Marta and Di Penta, Massimiliano and Canfora, Gerardo}
}
@conference {1310,
	title = {System compatibility analysis of Eclipse and Netbeans based on bug data},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	month = {05/2011},
	pages = {230-233},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {Waikiki, Honolulu, HI, USANew York, New York, USA},
	abstract = {Eclipse and Netbeans are two top of the line Integrated Development Environments (IDEs) for Java development. Both of them provide support for a wide variety of development tasks and have a large user base. This paper provides an analysis and comparison for the compatibility and stability of Eclipse and Netbeans on the three most commonly used operating systems, Windows, Linux and Mac OS. Both IDEs are programmed in Java and use a Bugzilla issue tracker to track reported bugs and feature requests. We looked into the Bugzilla repository databases of these two IDEs, which contains the bug records and histories of these two IDEs. We used some basic data mining techniques to analyze some historical statistics of the bug data. Based on the analysis, we try to answer certain stability-comparison oriented questions in the paper, so that users can have a better idea which of these two IDEs is designed better to work on different platforms.

},
	keywords = {bug tracking system, bugzilla, eclipse, ms challenge, netbeans, version history},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985479},
	author = {Baik, Eilwoo and Devanbu, Premkar and Wang, Xinlei (Oscar)}
}
@proceedings {1293,
	title = {Virtual Health Information Infrastructures: A Scalable Regional Model},
	year = {2011},
	month = {10/2011},
	pages = {316-319},
	publisher = {Springer},
	abstract = {Integrating research, education and evidence-based medical practice requires complex infrastructures and network linkages among these critical activities. This research examines communities of practice and open source software tools in development of scalable virtual infrastructures for the regional Virtual Health Library of the Latin American and Caribbean Health Sciences System (Bireme) and embedded national cases. Virtual infrastructures refer to an environment characterized by overlapping distribution networks accessible through Internet portals and websites designed to facilitate integrated use of available resources. Case analysis shows engagement of interdisciplinary communities of practice for scalable virtual infrastructure design. This research program considers theory and methods for study of transferability of the Latin American model to large health care systems in other cultures.},
	keywords = {Bireme, Communities Of Practice, culture, open source systems, virtual infrastructures},
	author = {Seror, Ann}
}
@conference {1311,
	title = {What topics do Firefox and Chrome contributors discuss?},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	month = {05/2011},
	pages = {234-237},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {Firefox and Chrome are two very popular open source Web browsers, implemented in C/C++. This paper analyzes what topics were discussed in Firefox and Chrome bug reports over time. To this aim, we indexed the text contained in bug reports submitted each semester of the project history, and identified topics using Latent Dirichlet Allocation (LDA). Then, we investigated to what extent Firefox and Chrome developers/contributors discussed similar topics, either in different periods, or over the same period. Results indicate a non-negligible overlap of topics, mainly on issues related to page layouting, user interaction, and multimedia contents.},
	keywords = {bug reports, chrome, Firefox, LDA, msr challenge},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985480},
	author = {Zagarese, Quirino and Distante, Damiano and Di Penta, Massimiliano and Bernardi, Mario Luca and Sementa, Carmine}
}
@conference {957,
	title = {Assessment of issue handling efficiency},
	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 = {94 - 97},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {We mined the issue database of GNOME to assess how issues are handled. How many issues are submitted and resolved? Does the backlog grow or decrease? How fast are issues resolved? Does issue resolution speed increase or decrease over time? In which subproject are issues handled most efficiently? To answer such questions, we apply several visualization and quantification instruments to the raw issue data. In particular, we aggregate issues into four risk categories, based on their resolution time. These categories are the basis both for visualizing and ranking, which are used in concert for issue database exploration.},
	keywords = {bug reports, bug tracking, classification, gnome, msr challenge, visualization},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463292},
	attachments = {https://flosshub.org/sites/flosshub.org/files/94bluijtenMSR2010.pdf},
	author = {Luijten, Bart and Visser, Joost and Zaidman, Andy}
}
@conference {954,
	title = {Clones: What is that smell?},
	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 = {72 - 81},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Clones are generally considered bad programming practice in software engineering folklore. They are identified as a bad smell and a major contributor to project maintenance difficulties. Clones inherently cause code bloat, thus increasing project size and maintenance costs. In this work, we try to validate the conventional wisdom empirically to see whether cloning makes code more defect prone. This paper analyses relationship between cloning and defect proneness. We find that, first, the great majority of bugs are not significantly associated with clones. Second, we find that clones may be less defect prone than non-cloned code. Finally, we find little evidence that clones with more copies are actually more error prone. Our findings do not support the claim that clones are really a "bad smell". Perhaps we can clone, and breathe easy, at the same time.},
	keywords = {apache, bug fix revisions, bugs, clone, evolution, gimp, nautilus, scm, source code},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463343},
	attachments = {https://flosshub.org/sites/flosshub.org/files/72rahman2010cws.pdf},
	author = {Rahman, Foyzur and Christian Bird and Devanbu, Premkumar}
}
@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 {961,
	title = {Do stack traces help developers fix bugs?},
	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 = {118 - 121},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {A widely shared belief in the software engineering community is that stack traces are much sought after by developers to support them in debugging. But limited empirical evidence is available to confirm the value of stack traces to developers. In this paper, we seek to provide such evidence by conducting an empirical study on the usage of stack traces by developers from the ECLIPSE project. Our results provide strong evidence to this effect and also throws light on some of the patterns in bug fixing using stack traces. We expect the findings of our study to further emphasize the importance of adding stack traces to bug reports and that in the future, software vendors will provide more support in their products to help general users make such information available when filing bug reports.},
	keywords = {bug fixing, bug report, debugging, eclipse, stack trace},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463280},
	attachments = {https://flosshub.org/sites/flosshub.org/files/118-10-msr.pdf},
	author = {Schroter, Adrian and Schr{\"o}ter, Adrian and Bettenburg, Nicolas and Premraj, Rahul}
}
@conference {951,
	title = {The evolution of ANT build systems},
	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 = {42 - 51},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Build systems are responsible for transforming static source code artifacts into executable software. While build systems play such a crucial role in software development and maintenance, they have been largely ignored by software evolution researchers. With a firm understanding of build system aging processes, project managers could allocate personnel and resources to build system maintenance tasks more effectively, reducing the build maintenance overhead on regular development activities. In this paper, we study the evolution of ANT build systems from two perspectives: (1) a static perspective, where we examine the build system specifications using software metrics adopted from the source code domain; and (2) a dynamic perspective where representative sample build runs are conducted and their output logs are analyzed. Case studies of four open source ANT build systems with a combined history of 152 releases show that not only do ANT build systems evolve, but also that they need to react in an agile manner to changes in the source code.},
	keywords = {ant, argouml, build, eclipse, jboss, maintenance, metrics, source code, tomcat},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463341},
	attachments = {https://flosshub.org/sites/flosshub.org/files/42msr2010_mcintosh.pdf},
	author = {McIntosh, Shane and Adams, Bram and Hassan, Ahmed E.}
}
@conference {950,
	title = {An extensive comparison of bug prediction approaches},
	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 = {31 - 41},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Reliably predicting software defects is one of software engineering{\textquoteright}s holy grails. Researchers have devised and implemented a plethora of bug prediction approaches varying in terms of accuracy, complexity and the input data they require. However, the absence of an established benchmark makes it hard, if not impossible, to compare approaches. We present a benchmark for defect prediction, in the form of a publicly available data set consisting of several software systems, and provide an extensive comparison of the explanative and predictive power of well-known bug prediction approaches, together with novel approaches we devised. Based on the results, we discuss the performance and stability of the approaches with respect to our benchmark and deduce a number of insights on bug prediction models.},
	keywords = {apache, bug reports, eclipse, famix, lucene, mylyn, prediction, scm},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463279},
	attachments = {https://flosshub.org/sites/flosshub.org/files/31dambrosLanzaRobbes31.pdf},
	author = {D{\textquoteright}Ambros, Marco and Lanza, Michele and Robbes, Romain}
}
@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 {bird2010lee,
	title = {{Linkster: Enabling Efficient Manual Mining}},
	booktitle = {Demonstration Track, Proceedings of the 17th SIGSOFT Symposium on Foundations of Software Engineering},
	year = {2010},
	note = {"LINKSTER efficiently displays, integrates, and allows inspection and annotation of information from three main sources of data: source code repositories, developer mailing lists archives, and bug tracking databases. LINKSTER requires access to a source code repository for file content and a database which contains the raw mined repository, mailing list, and bug tracking information. All notes and annotations made by the user are also recorded in the database."},
	publisher = {ACM},
	organization = {ACM},
	abstract = {While many uses of mined software engineering data are automatic in nature, some techniques and studies either require, or can be improved, by manual methods. Unfortunately, manually inspecting, analyzing, and annotating mined data can be difficult and tedious, especially when information from multiple sources must be integrated. Oddly, while there are numerous tools and frameworks for automatically mining and analyzing data, there is a dearth of tools which facilitate manual methods. To fill this void, we have developed LINKSTER, a tool which integrates data from bug databases, source code repositories, and mailing list archives to allow manual inspection and annotation. LINKSTER has already been used successfully by an OSS project lead to obtain data for one empirical study.},
	keywords = {artifacts, bug, bug tracking, data mining, email, mailing lists, open source, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bird2010lee.pdf},
	author = {Christian Bird and Adrian Bachman and Rahman, Foyzur and Bernstein, Abraham}
}
@conference {1218,
	title = {A Longitudinal Study on Collaboration Networks and Decision to Participate in a FLOSS Community},
	booktitle = {5th Workshop on Public Data about Software Development (WoPDaSD 2010)},
	year = {2010},
	note = {"we chose as a case of study Epiphany, which is the default web browser of the GNOME graphical desktop environment"

"We collected all relevant data by parsing all the bug reports in GNOME Bugzilla repository relative to Epiphany. The data collection and storing was done using Bicho (v. 0.4 rev. 7198), a software part of the FLOSSMetric project [14]."},
	abstract = {In this paper we conjecture that individual decisions of FLOSS (Free/Libre Open Source Software) developers to take on a task are influenced by network relations generated by collaboration among project members. In order to explore our conjecture we collected data on a FLOSS project team consisting of 227 developers committed since 2002 to the development of a web browser. We reconstructed 2-mode co- collaboration networks (software developer by bug) in which a tie represents an action taken by a developer in order to solve a specific bug. Co-collaboration networks were collected at five points in time during a six-month development cycle of the software. We report and discuss results of longitudinal actor-based modeling that we specify to test for the influence of local network structures on developer{\textquoteright}s decision to take action on a specific bug. The study controls for bug-specific and developer-specific characteristics that may also affect developers{\textquoteright} decisions exogenously. We also control for priority and severity levels assigned by the team to bugs in an attempt to manage voluntary contribution.},
	keywords = {bicho, bug fixing, bug reports, bugzilla, COLLABORATION, developers, epiphany, flossmetrics, gnome, social network analysis},
	attachments = {https://flosshub.org/sites/flosshub.org/files/wopdasd002.pdf},
	author = {Guido Conaldi and Tonellato, Marco}
}
@conference {Oezbek:2010:OCS:1833272.1833274,
	title = {The onion has cancer: some social network analysis visualizations of open source project communication},
	booktitle = {Proceedings of the 3rd International Workshop on Emerging Trends in Free/Libre/Open Source Software Research and Development (FLOSS {\textquoteright}10)},
	series = {FLOSS {\textquoteright}10},
	year = {2010},
	note = {paper d/l from www.inf.fu-berlin.de/~oezbek/pub/OezThiPre10-SNA.pdf

"We study the introduction of process innovations in Open Source projects [33] by manually extracting innovation episodes from arch- ives of mailing-lists and analyzing these episodes qualitatively by the Grounded Theory Method [38]."

"we took all messages from the mailing-list archives in 2007 of the projects we were studying, turned each participant into a node (unifying multi- ple e-mail addresses where needed [6]), and computed relationship strength between A and B as the number of e-mails that are a reply of B to a message from A or vice versa, according to the in-reply-to header of the e-mail."

Our data set covers 11 of the 13 projects (from 7 different do- mains, selected from mailing-list archive Gmane to build a diverse set of projects) for which we analyzed innovation episodes. They include three workflow applications (Bugzilla, Flyspray, Request Tracker), two desktop environments (Rox, Xfce), two design tools (ArgoUML, a UML CASE tool; gEDA, a set of electronic design automation tools), one bootloader (Grub), one hardware emulator (Bochs), one operating system (FreeDOS), and one database man- agement system (MonetDB).},
	pages = {5{\textendash}10},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Background: People contribute to OSS projects in wildly different degrees, from reporting a single defect once and never coming back to spending many hours each workday on the project over several years - or anything in between. It is a common conception that these degrees of participation sort the participants into a number of similar groups which are layered like the peels of an onion: The onion model. Objective: We check whether this model of gradually different degrees of participation is valid with respect to the participation in OSS project mailing-list traffic. Methods: We perform social network analysis based on replies to mailing-list messages and use visualization to check the nature of three different groups of participants. Results: There appears to be a discontinuity with respect to core members: The degree to which very active core members (as opposed to less active co-developers) react to e-mails of senders from the project{\textquoteright}s periphery is significantly higher than would be expected from their level of activity in general. Limitations: The effect might be an artifact of the assumption that each mailing-list message can be treated the same. Conclusions: We conclude that core member status may be qualitatively (rather than just quantitatively) different and the transition of individual mailing-list participants towards ever higher participation is qualitatively discontinuous.},
	keywords = {argouml, Bochs, bugzilla, communication structure, Flyspray, gEDA, Grub, MonetDB, open source process, request tracker, Rox, social network analysis, Xfce},
	isbn = {978-1-60558-978-7},
	doi = {10.1145/1833272.1833274},
	url = {http://doi.acm.org/10.1145/1833272.1833274},
	attachments = {https://flosshub.org/sites/flosshub.org/files/OezThiPre10-SNA.pdf},
	author = {Oezbek, Christopher and Prechelt, Lutz and Thiel, Florian}
}
@book {1249,
	title = {Open Source Software Developer and Project Networks},
	series = {IFIP Advances in Information and Communication TechnologyOpen Source Software: New Horizons},
	volume = {319},
	year = {2010},
	note = {no information on data gathering procedures},
	pages = {407 - 412},
	publisher = {Springer Berlin Heidelberg},
	organization = {Springer Berlin Heidelberg},
	address = {Berlin, Heidelberg},
	abstract = {This paper outlines complex network concepts and how social networks are built from Open Source Software (OSS) data. We present an initial study of the social networks of three different OSS forges, BerliOS Developer, GNU Savannah, and SourceForge. Much research has been done on snapshot or conflated views of these networks, especially SourceForge, due to the size of the SourceForge community. The degree distribution, connectedness, centrality, and scale-free nature of SourceForge has been presented for the network at particular points in time. However, very little research has been done on how the network grows, how connections were made, especially during its infancy, and how these metrics evolve over time. },
	keywords = {berlios, savannah, sourceforge},
	isbn = {978-3-642-13244-5},
	issn = {1861-2288},
	doi = {10.1007/978-3-642-13244-5_39},
	author = {Madey, G. and van Antwerp, M.},
	editor = {{\r A}gerfalk, P{\"a}r and Boldyreff, Cornelia and Gonz{\'a}lez-Barahona, Jes{\'u}s M. and Madey, Gregory R. and Noll, John}
}
@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 {949,
	title = {Predicting the severity of a reported bug},
	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 = {1 - 10},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {The severity of a reported bug is a critical factor in deciding how soon it needs to be fixed. Unfortunately, while clear guidelines exist on how to assign the severity of a bug, it remains an inherent manual process left to the person reporting the bug. In this paper we investigate whether we can accurately predict the severity of a reported bug by analyzing its textual description using text mining algorithms. Based on three cases drawn from the open-source community (Mozilla, Eclipse and GNOME), we conclude that given a training set of sufficient size (approximately 500 reports per severity), it is possible to predict the severity with a reasonable accuracy (both precision and recall vary between 0.65-0.75 with Mozilla and Eclipse; 0.70-0.85 in the case of GNOME).},
	keywords = {bug reports, eclipse, gnome, mozilla, severity, text mining},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463284},
	attachments = {https://flosshub.org/sites/flosshub.org/files/1lamkanfiDemeyer1.pdf},
	author = {Lamkanfi, Ahmed and Demeyer, Serge and Giger, Emanuel and Goethals, Bart}
}
@conference {Rastkar:2010:SSA:1806799.1806872,
	title = {Summarizing software artifacts: a case study of bug reports},
	booktitle = {Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1},
	series = {ICSE {\textquoteright}10},
	year = {2010},
	pages = {505{\textendash}514},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Many software artifacts are created, maintained and evolved as part of a software development project. As software developers work on a project, they interact with existing project artifacts, performing such activities as reading previously filed bug reports in search of duplicate reports. These activities often require a developer to peruse a substantial amount of text. In this paper, we investigate whether it is possible to summarize software artifacts automatically and effectively so that developers could consult smaller summaries instead of entire artifacts. To provide focus to our investigation, we consider the generation of summaries for bug reports. We found that existing conversation-based generators can produce better results than random generators and that a generator trained specifically on bug reports can perform statistically better than existing conversation-based generators. We demonstrate that humans also find these generated summaries reasonable indicating that summaries might be used effectively for many tasks.},
	keywords = {bug reports, eclipse, gnome, human-centric software engineering, kde, machine learning, mozilla},
	isbn = {978-1-60558-719-6},
	doi = {10.1145/1806799.1806872},
	url = {http://doi.acm.org/10.1145/1806799.1806872},
	author = {Rastkar, Sarah and Murphy, Gail C. and Murray, Gabriel}
}
@book {1250,
	title = {Warehousing and Studying Open Source Versioning Metadata},
	series = {IFIP Advances in Information and Communication Technology Open Source Software: New Horizons (OSS 2010)},
	volume = {319},
	year = {2010},
	pages = {413 - 418},
	publisher = {Springer Berlin Heidelberg},
	organization = {Springer Berlin Heidelberg},
	address = {Berlin, Heidelberg},
	abstract = {In this paper, we describe the downloading and warehousing of Open Source Software (OSS) versioning metadata from SourceForge, BerliOS Developer, and GNU Savannah. This data enables and supports research in areas such as software engineering, open source phenomena, social network analysis, data mining, and project management. This newly-formed database containing Concurrent Versions System (CVS) and Subversion (SVN) metadata offers new research opportunities for large-scale OSS development analysis. The CVS and SVN data is juxtaposed with the SourceForge.net Research Data Archive [5] for the purpose of performing more powerful and interesting queries. We also present an initial statistical analysis of some of the most active projects. },
	keywords = {berlios, cvs, savannah, scm, sourceforge, srda, subversion, svn},
	isbn = {978-3-642-13244-5},
	issn = {1861-2288},
	doi = {10.1007/978-3-642-13244-5_40},
	author = {van Antwerp, M. and Madey, G.},
	editor = {{\r A}gerfalk, P{\"a}r and Boldyreff, Cornelia and Gonz{\'a}lez-Barahona, Jes{\'u}s M. and Madey, Gregory R. and Noll, John}
}
@article {1239,
	title = {Weaving a Semantic Web Across OSS Repositories},
	journal = {International Journal of Open Source Software and Processes},
	volume = {2},
	year = {2010},
	month = {32/2010},
	pages = {29 - 40},
	abstract = {Several public repositories and archives of {\textquotedblleft}facts{\textquotedblright} about libre software projects, maintained either by open source communities or by research communities, have been flourishing over the Web in recent years. These have enabled new analysis and support for new quality assurance tasks. This paper presents some complementary existing tools, projects and models proposed both by OSS actors or research initiatives that are likely to lead to useful future developments in terms of study of the FLOSS phenomenon, and also to the very practitioners in the FLOSS development projects. A goal of the research conducted within the HELIOS project is to address bugs traceability issues. In this regard, the authors investigate the potential of using Semantic Web technologies in navigating between many different bugtracker systems scattered all over the open source ecosystem. By using Semantic Web techniques, it is possible to interconnect the databases containing data about open-source software projects development, which enables OSS partakers to identify resources, annotate them, and further interlink those using dedicated properties and collectively designing a distributed semantic graph.},
	keywords = {archive, bug, bugtracker, database, debian, forge, interoperability, ontology, OSLC-CM, RDF, repository of repositories, semantic, semantic Web},
	issn = {1942-3934},
	doi = {10.4018/jossp.2010040103},
	attachments = {https://flosshub.org/sites/flosshub.org/files/wopdasd2009-olivier-berger.pdf},
	author = {Olivier Berger and Valentin Vlasceanu and Christian Bac and Quang Vu Dang and Lauriere, St{\'e}phane}
}
@article {10.1109/TSE.2010.63,
	title = {What Makes a Good Bug Report?},
	journal = {IEEE Transactions on Software Engineering},
	volume = {36},
	year = {2010},
	note = {"o find out which matter most, we asked 872 devel-
opers from the APACHE, ECLIPSE, and MOZILLA projects to:
1. Complete a survey on important information in bug reports and the problems they faced with them. We received a total of 156 responses to our survey (Section 2 and 3).
2. Rate the quality of bug reports from very poor to very good on a five-point Likert scale [22]. We received a total of 1,186 votes for 289 randomly selected bug reports (Section 4).
In addition, we asked 1,354 reporters1 from the same projects to complete a similar survey, out of which 310 responded. "},
	pages = {618-643},
	publisher = {IEEE Computer Society},
	address = {Los Alamitos, CA, USA},
	abstract = {In software development, bug reports provide crucial information to developers. However, these reports widely differ in their quality. We conducted a survey among developers and users of APACHE, ECLIPSE, and MOZILLA to find out what makes a good bug report.
The analysis of the 466 responses revealed an information mis- match between what developers need and what users supply. Most developers consider steps to reproduce, stack traces, and test cases as helpful, which are at the same time most difficult to provide for users. Such insight is helpful to design new bug tracking tools that guide users at collecting and providing more helpful information.
Our CUEZILLA prototype is such a tool and measures the quality of new bug reports; it also recommends which elements should be added to improve the quality. We trained CUEZILLA on a sample of 289 bug reports, rated by developers as part of the survey. In our experiments, CUEZILLA was able to predict the quality of 31{\textendash}48\% of bug reports accurately.},
	keywords = {bug report, Survey},
	issn = {0098-5589},
	doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.2010.63},
	url = {http://dl.acm.org/citation.cfm?id=1453146},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bettenburg-fse-2008.pdf},
	author = {Zimmermann, Thomas and Premraj, Rahul and Bettenburg, Nicolas and Sascha Just and Schroter, Adrian and Weiss, Cathrin}
}
@conference {953,
	title = {When process data quality affects the number of bugs: Correlations in software engineering datasets},
	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 = {62 - 71},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Software engineering process information extracted from version control systems and bug tracking databases are widely used in empirical software engineering. In prior work, we showed that these data are plagued by quality deficiencies, which vary in its characteristics across projects. In addition, we showed that those deficiencies in the form of bias do impact the results of studies in empirical software engineering. While these findings affect software engineering researchers the impact on practitioners has not yet been substantiated. In this paper we, therefore, explore (i) if the process data quality and characteristics have an influence on the bug fixing process and (ii) if the process quality as measured by the process data has an influence on the product (i.e., software) quality. Specifically, we analyze six Open Source as well as two Closed Source projects and show that process data quality and characteristics have an impact on the bug fixing process: the high rate of empty commit messages in Eclipse, for example, correlates with the bug report quality. We also show that the product quality - measured by number of bugs reported - is affected by process data quality measures. These findings have the potential to prompt practitioners to increase the quality of their software process and its associated data quality.},
	keywords = {apache, bug reports, eclipse, gnome, log files, mozilla, netbeans, openoffice.org, version control},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463286},
	attachments = {https://flosshub.org/sites/flosshub.org/files/62bachmann-msr10.pdf},
	author = {Bachmann, Adrian and Bernstein, Abraham}
}
@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 {937,
	title = {Assigning bug reports using a vocabulary-based expertise model of developers},
	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 = {131 - 140},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {For popular software systems, the number of daily submitted bug reports is high. Triaging these incoming reports is a time consuming task. Part of the bug triage is the assignment of a report to a developer with the appropriate expertise. In this paper, we present an approach to automatically suggest developers who have the appropriate expertise for handling a bug report. We model developer expertise using the vocabulary found in their source code contributions and compare this vocabulary to the vocabulary of bug reports. We evaluate our approach by comparing the suggested experts to the persons who eventually worked on the bug. Using eight years of Eclipse development as a case study, we achieve 33.6\% top-1 precision and 71.0\% top-10 recall.},
	keywords = {bug reports, bugzilla, develect, developers, eclipse, expertise, scm},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069491},
	attachments = {https://flosshub.org/sites/flosshub.org/files/131AssigningBugReports.pdf},
	author = {Matter, Dominique and Kuhn, Adrian and Nierstrasz, Oscar}
}
@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}
}
@article {10.1109/HICSS.2009.713,
	title = {Evaluating Longitudinal Success of Open Source Software Projects: A Social Network Perspective},
	journal = {2009 42nd Hawaii International Conference on System Sciences (HICSS 2009)},
	year = {2009},
	note = {"We collect data of various OSS projects over an extended period of 13 months and utilize cross-sectional time-series panel data analysis methods..."
"we observe and analyze the developers{\textquoteright} interactions through bug, patch, support request, and feature request (BPSF) tracking systems hosted on SourceForge.net"
"Three criteria are adopted to select useful projects: projects are selected from top 7000 ranked projects; projects have at least three developers; and there are enough interactions to ensure that each sociomatrix is equal to or larger than 3{\texttimes}3 matrix..."},
	pages = {1-10},
	publisher = {IEEE Computer Society},
	address = {Los Alamitos, CA, USA},
	abstract = {To date, numerous open source projects are hosted on many online repositories. While some of these projects are active and thriving, some projects are either languishing or showing no development activities at all. This phenomenon thus begs the important question of what are the influential factors that affect the success of open source projects. In a quest to deepen our understanding of the evolution of open source projects, this research aims to analyze the success of open source projects by using the theoretical lens of social network analysis. Based on extensive analyses of data collected from online repositories, we study the impact of the communication patterns of software development teams on the demand and supply outcomes of these projects, while accounting for project-specific characteristics. Using panel data analysis of data over 13 months, we find significant impacts of communication patterns on project outcomes over the long term.},
	keywords = {bug tracking system, communication, project success, social network analysis, sourceforge},
	isbn = {978-0-7695-3450-3},
	doi = {http://doi.ieeecomputersociety.org/10.1109/HICSS.2009.713},
	attachments = {https://flosshub.org/sites/flosshub.org/files/09-02-12.pdf},
	author = {Jing Wu and Khim Yong Goh}
}
@conference {931,
	title = {Evaluating process quality in GNOME based on change request data},
	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 = {95 - 98},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {The lifecycle of defects reports and enhancement requests collected in the Bugzilla database of the GNOME project provides valuable information on the evolution of the change request process and for the assessment of process quality in the GNOME sub projects. We present a quality model for the analysis of quality characteristics that is based on evaluating metrics on the Bugzilla database, and illustrate it with a comparative evaluation for 25 of the largest products within GNOME.},
	keywords = {bugzilla, bugzillametrics.org, change analysis, change history, gnome, msr challenge, qmetric},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069485},
	attachments = {https://flosshub.org/sites/flosshub.org/files/95ProcessQualityInGNOME.pdf},
	author = {Schackmann, Holger and Lichter, Horst}
}
@conference {944,
	title = {Learning from defect removals},
	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 = {179 - 182},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {Recent research has tried to identify changes in source code repositories that fix bugs by linking these changes to reports in issue tracking systems. These changes have been traced back to the point in time when they were previously modified as a way of identifying bug introducing changes. But we observe that not all changes linked to bug tracking systems are fixing bugs; some are enhancing the code. Furthermore, not all fixes are applied at the point in the code where the bug was originally introduced. We flesh out these observations with a manual review of several software projects, and use this opportunity to see how many defects are in the scope of static analysis tools.},
	keywords = {bug fixing, bugzilla, change management, cherry, cvs, eclipse, groovy, launching, source code, svn, text editor},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069500},
	attachments = {https://flosshub.org/sites/flosshub.org/files/179LearnFromDefects-MSR09.pdf},
	author = {Ayewah, Nathaniel and Pugh, William}
}
@conference {942,
	title = {On mining data across software repositories},
	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 = {171 - 174},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {Software repositories provide abundance of valuable information about open source projects. With the increase in the size of the data maintained by the repositories, automated extraction of such data from individual repositories, as well as of linked information across repositories, has become a necessity. In this paper we describe a framework that uses web scraping to automatically mine repositories and link information across repositories. We discuss two implementations of the framework. In the first implementation, we automatically identify and collect security problem reports from project repositories that deploy the Bugzilla bug tracker using related vulnerability information from the National Vulnerability Database. In the second, we collect security problem reports for projects that deploy the Launchpad bug tracker along with related vulnerability information from the National Vulnerability Database. We have evaluated our tool on various releases of Fedora, Ubuntu, Suse, RedHat, and Firefox projects. The percentage of security bugs identified using our tool is consistent with that reported by other researchers.},
	keywords = {bug reports, bugzilla, Fedora, Firefox, htmlscraper, integration, launchpad, national vulnerability database, RedHat, Suse, tracker, Ubuntu},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069498},
	attachments = {https://flosshub.org/sites/flosshub.org/files/171MiningAcrossmsr09.pdf},
	author = {Anbalagan, Prasanth and Vouk, Mladen}
}
@conference {935,
	title = {Mining search topics from a code search engine usage log},
	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 = {111 - 120},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {We present a topic modeling analysis of a year long usage log of Koders, one of the major commercial code search engines. This analysis contributes to the understanding of what users of code search engines are looking for. Observations on the prevalence of these topics among the users, and on how search and download activities vary across topics, leads to the conclusion that users who find code search engines usable are those who already know to a high level of specificity what to look for. This paper presents a general categorization of these topics that provides insights on the different ways code search engine users express their queries. The findings support the conclusion that existing code search engines provide only a subset of the various information needs of the users when compared to the categories of queries they look at.},
	keywords = {analysis, black duck, koders, log, logfile, search, source code},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069489},
	author = {Bajracharya, Sushil and Lopes, Cristina}
}
@conference {932,
	title = {Mining the coherence of GNOME bug reports with statistical topic models},
	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 = {99 - 102},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {We adapt latent Dirichlet allocation to the problem of mining bug reports in order to define a new information-theoretic measure of coherence. We then apply our technique to a snapshot of the GNOME Bugzilla database consisting of 431,863 bug reports for multiple software projects. In addition to providing an unsupervised means for modeling report content, our results indicate substantial promise in applying statistical text mining algorithms for estimating bug report quality. Complete results are available from our supplementary materials Web site at http://sourcerer.ics.uci.edu/msr2009/gnome_coherence.html.},
	keywords = {bug reports, bugzilla, gnome, msr challenge, quality, sourcerer},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069486},
	author = {Linstead, Erik and Baldi, Pierre}
}
@article {1236,
	title = {Tools for the Study of the Usual Data Sources found in Libre Software Projects},
	journal = {International Journal of Open Source Software and Processes},
	volume = {1},
	year = {2009},
	month = {31/2009},
	pages = {24 - 45},
	abstract = {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.},
	keywords = {bug tracking systems, data sources, mailing lists, scm, tools},
	issn = {1942-3934},
	doi = {10.4018/jossp.2009010102},
	attachments = {https://flosshub.org/sites/flosshub.org/files/robles.pdf},
	author = {Gregorio Robles and Gonz{\'a}lez-Barahona, Jes{\'u}s M. and Izquierdo-Cortazar, Daniel and Herraiz, Israel}
}
@conference {926,
	title = {Tracking concept drift of software projects using defect prediction quality},
	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 = {51 - 60},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {Defect prediction is an important task in the mining of software repositories, but the quality of predictions varies strongly within and across software projects. In this paper we investigate the reasons why the prediction quality is so fluctuating due to the altering nature of the bug (or defect) fixing process. Therefore, we adopt the notion of a concept drift, which denotes that the defect prediction model has become unsuitable as set of influencing features has changed - usually due to a change in the underlying bug generation process (i.e., the concept). We explore four open source projects (Eclipse, OpenOffice, Netbeans and Mozilla) and construct file-level and project-level features for each of them from their respective CVS and Bugzilla repositories. We then use this data to build defect prediction models and visualize the prediction quality along the time axis. These visualizations allow us to identify concept drifts and - as a consequence - phases of stability and instability expressed in the level of defect prediction quality. Further, we identify those project features, which are influencing the defect prediction quality using both a tree induction-algorithm and a linear regression model. Our experiments uncover that software systems are subject to considerable concept drifts in their evolution history. Specifically, we observe that the change in number of authors editing a file and the number of defects fixed by them contribute to a project{\textquoteright}s concept drift and therefore influence the defect prediction quality. Our findings suggest that project managers using defect prediction models for decision making should be aware of the actual phase of stability or instability due to a potential concept drift.},
	keywords = {bugzilla, cvs, defect prediction, eclipse, mozilla, netbeans, openoffice},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069480},
	attachments = {https://flosshub.org/sites/flosshub.org/files/51MSR2009_0111_Ekanayake_Jayalath.pdf},
	author = {Ekanayake, Jayalath and Tappolet, Jonas and Gall, Harald C. and Bernstein, Abraham}
}
@article {Au20099,
	title = {Virtual organizational learning in open source software development projects},
	journal = {Information \& Management},
	volume = {46},
	number = {1},
	year = {2009},
	pages = {9 - 15},
	abstract = {We studied virtual organizational learning in open source software (OSS) development projects. Specifically, our research focused on learning effects of OSS projects and the factors that affect the learning process. The number and percentage of resolved bugs and bug resolution time of 118 SourceForge.net OSS projects were used to measure the learning effects. Projects were characterized by project type, number and experience of developers, number of bugs, and bug resolution time. Our results provided evidence of virtual organizational learning in OSS development projects and support for several factors as determinants of performance. Team size was a significant predictor, with mid-sized project teams functioning best. Teams of three to seven developers exhibited the highest efficiency over time and teams of eight to 15 produced the lowest mean time for bug resolution. Increasing the percentage of bugs assigned to specific developers or boosting developer participation in other OSS projects also improved performance. Furthermore, project type introduced variability in project team performance.},
	keywords = {bug fixing, bugs, learning, Project performance, sourceforge, team size, teams, virtual organization},
	issn = {0378-7206},
	doi = {DOI: 10.1016/j.im.2008.09.004},
	url = {http://www.sciencedirect.com/science/article/B6VD0-4V1D7NT-1/2/a3bbf7652c674f753398160b8f05f6e9},
	author = {Yoris A. Au and Darrell Carpenter and Xiaogang Chen and Jan G. Clark}
}
@conference {933,
	title = {Visualizing Gnome with the Small Project Observatory},
	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 = {103 - 106},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {We analyzed the gnome family of systems with the small project observatory, our online ecosystem visualization platform. We begin by briefly introducing the model of SPO. We then observe and discuss several phases in the activity of the gnome ecosystem. We follow and look at how the contributors are distributed between writing source code and doing other activities such as internationalization. We end with a visual overview of the activity of more than 900 contributors in the 10 years of existence of gnome.},
	keywords = {bugzilla, contributions, gnome, msr challenge, spo, visualization},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069487},
	attachments = {https://flosshub.org/sites/flosshub.org/files/103Lung2009a.pdf},
	author = {Lungu, Mircea and Malnati, Jacopo and Lanza, Michele}
}
@conference {1205,
	title = {Weaving~a~Semantic~Web~across~OSS~repositories: a~spotlight~on~bts-link,~UDD,~SWIM},
	booktitle = {4th Workshop on Public Data about Software Development (WoPDaSD 2009)},
	year = {2009},
	note = {position paper; non-experimental},
	abstract = {Several  public  repositories  and  archives  of  facts  about  libre software  projects,  developed either  by open  source  communities  or by research communities,  have been flourishing over  the Web in  the  recent  years.  These  enable  new analysis  and  support  new quality assurance tasks. 

By  using  Semantic  Web  techniques,  the  databases  containing data  about  open-source  software projects development can  be interconnected,  hence  letting  OSS  partakers  identify  resources, annotate  them  and  further  interlink  them  using  dedicated properties,  collectively  designing  a  distributed  semantic  graph. Such  links  expressed  with  standard  Semantic  techniques  are paving  the  way  to  new  applications  (including  ones  meant  for {\textquotedblleft}end-users{\textquotedblright}).  For  instance  this  may have  an  impact  on  the  way research efforts  are  conducted  (less  fragmented),  and  could  also be  used  by  development  communities  to  improve  Quality Assurance tasks. 

A goal  of the  research  conducted  within  the  HELIOS project, is to  address  bugtracker  synchronization  issues.  For that, the potential of using Semantic  Web  technologies  in  navigating between many different  bugtracker  systems scattered all  over the open source ecosystem is being investigated. 

This  position  paper  presents  some  existing  tools,  projects  and models  proposed  by  OSS  actors  that  are  complementary  to research  initiatives,  and  that  are  likely to  lead  to  useful  future  developments:  UDD (Ultimate  Debian  Database)  and  bts-link, developed by the  Debian community,  and  SWIM (Semantic Web enabled Issue Manager) developed by Mandriva. 

The  HELIOS team welcomes  comments  on the  future  paths  that  can  be  considered  in  using  the  Semantic  Web  approach  for improving these projects. },
	keywords = {bts-link, bug tracker, bugzilla, debian, ecosystem, helios, mandriva, semantic Web, swim, udd},
	attachments = {https://flosshub.org/sites/flosshub.org/files/HELIOS-WOPDASD-improved-Olivier.pdf},
	author = {Olivier Berger and Valentin Vlasceanu and Christian Bac and Lauri{\`e}re, St{\'e}phane}
}
@conference {939,
	title = {On what basis to recommend: Changesets or interactions?},
	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 = {155 - 158},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Vancouver, BC, Canada},
	abstract = {Different flavours of recommendation systems have been proposed to help software developers perform software evolution tasks. A number of these recommendation systems are based on changesets. When changeset information is used, recommendations are based on only the end result of the activity undertaken to complete a task. In this paper, we report on an investigation that compared how recommendations based on changesets compare to recommendations based on interactions collected as a programmer performed the task that resulted in a changeset. To provide a common basis for the comparison, our investigation considered how bug reports considered similar based on changeset information compare to bug reports considered similar based on interaction information. We found that there is no direct relationship between the bug reports found similar with the different methods, suggesting that each comparison methods captures a different aspect of the problem.},
	keywords = {bug reports, changeset, eclipse, mylyn},
	isbn = {978-1-4244-3493-0},
	doi = {10.1109/MSR.2009.5069494},
	author = {Rastkar, Sarah and Murphy, Gail C.}
}
@conference {Wang:2008:ADD:1368088.1368151,
	title = {An approach to detecting duplicate bug reports using natural language and execution information},
	booktitle = {Proceedings of the 30th international conference on Software engineering},
	series = {ICSE {\textquoteright}08},
	year = {2008},
	pages = {461{\textendash}470},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {An open source project typically maintains an open bug repository so that bug reports from all over the world can be gathered. When a new bug report is submitted to the repository, a person, called a triager, examines whether it is a duplicate of an existing bug report. If it is, the triager marks it as DUPLICATE and the bug report is removed from consideration for further work. In the literature, there are approaches exploiting only natural language information to detect duplicate bug reports. In this paper we present a new approach that further involves execution information. In our approach, when a new bug report arrives, its natural language information and execution information are compared with those of the existing bug reports. Then, a small number of existing bug reports are suggested to the triager as the most similar bug reports to the new bug report. Finally, the triager examines the suggested bug reports to determine whether the new bug report duplicates an existing bug report. We calibrated our approach on a subset of the Eclipse bug repository and evaluated our approach on a subset of the Firefox bug repository. The experimental results show that our approach can detect 67\%-93\% of duplicate bug reports in the Firefox bug repository, compared to 43\%-72\% using natural language information alone.},
	keywords = {bug report, duplicate bug report, execution information, information retrieval, natural language},
	isbn = {978-1-60558-079-1},
	doi = {10.1145/1368088.1368151},
	url = {http://doi.acm.org/10.1145/1368088.1368151},
	author = {Wang, Xiaoyin and Zhang, Lu and Xie, Tao and Anvik, John and Sun, Jiasu}
}
@article {Crowston:2008,
	title = {Bug Fixing Practices within Free/Libre Open Source Software Development Teams},
	journal = {Journal of Database Management},
	volume = {19},
	number = {2},
	year = {2008},
	note = {"Projects to be studied were selected from those hosted on SourceForge, (http://sourceforge.net/)"
"we chose projects for which data we need for our analysis are publicly available, meaning a large number of bug reports"
"we chose teams with more than 8 developers"
"Only 140 projects of SourceForge met the first two requirements in 2002 when we drew our sample"
kicq, gaim, phpmyadmin, dynapi
"First, we obtained data indica- tive of the effectiveness of each project, such as its level of activity, number of downloads and development status"
"we elected to use objective data about the bug- fixing process. Hence, the main source of data about the bug-fixing process was obtained from the archives of the bug tracking system, which is the tool used to support the bug-fixing process"},
	pages = {1{\textendash}30},
	abstract = {Free/libre open source software (FLOSS, e.g., Linux or Apache) is primarily developed by distributed teams. Developers contribute from around the world and coordinate their activity almost exclusively by means of email and bulletin boards, yet some how profit from the advantages and evade the challenges of distributed software development. In this article we investigate the structure and the coordination practices adopted by development teams during the bug-fixing process, which is considered one of main areas of FLOSS project success. In particular, based on a codification of the messages recorded in the bug tracking system of four projects, we identify the accomplished tasks, the adopted coordination mechanisms, and the role undertaken by both the FLOSS development team and the FLOSS community. We conclude with suggestions for further research.},
	keywords = {activity, bug tracker, bug tracking system, coordination, downloads, dynapi, effectiveness, FLOSS, gaim, kicq, phpmyadmin, project success, size, status},
	issn = {1063-8016},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CrowstonScozziJDBM2008.pdf},
	author = {Kevin Crowston and Barbara Scozzi}
}
@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 {SGKL09,
	title = {Evaluating the Quality of Open Source Software},
	booktitle = {Electronic Notes in Theoretical Computer Science},
	volume = {233},
	year = {2008},
	note = {"the software source code and the associated data stored in the version control system, the bug tracking databases, the mailing lists, and the wikis allow us to evaluate quality in a transparent way"
"The data collection system collects the raw data from open source projects"
Mailing lists are measured in: Number of unique subscribers, Number of messages in user/support list per month, Number of messages in developers list per month, Average thread depth},
	month = {03/2009},
	pages = {5{\textendash}28},
	publisher = {The Reengineering Forum},
	organization = {The Reengineering Forum},
	abstract = {Traditionally, research on quality attributes was either kept under wraps within the organization that performed it, or carried out by outsiders using narrow, black-box techniques. The emergence of open source software has changed this picture allowing us to evaluate both software products and the processes that yield them. Thus, the software source code and the associated data stored in the version control system, the bug tracking databases, the mailing lists, and the wikis allow us to evaluate quality in a transparent way. Even better, the large number of (often competing) open source projects makes it possible to contrast the quality of comparable systems serving the same domain. Furthermore, by combining historical source code snapshots with significant events, such as bug discoveries and fixes, we can further dig into the causes and effects of problems. Here we present motivating examples, tools, and techniques that can be used to evaluate the quality of open source (and by extension also proprietary) software. },
	keywords = {bug tracking system, email, email archives, mailing list, metrics, open source, process quality attributes, product quality attributes, source code, SQO-OSS, wiki},
	doi = {10.1016/j.entcs.2009.02.058},
	url = {http://www.dmst.aueb.gr/dds/pubs/conf/2008-SQM-SQOOSS/html/SGKL09.html},
	attachments = {https://flosshub.org/sites/flosshub.org/files/entcs-sqooss.pdf},
	author = {Diomidis Spinellis and Gousios, Georgios and Vassilios Karakoidas and Panagiotis Louridas and Paul J. Adams and Samoladas, Ioannis and Ioannis Stamelos}
}
@conference {972,
	title = {Extracting structural information from bug reports},
	booktitle = {Proceedings of the 2008 international workshop on Mining software repositories  - MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {27-30},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {In software engineering experiments, the description of bug reports is typically treated as natural language text, although it often contains stack traces, source code, and patches. Neglecting such structural elements is a loss of valuable information; structure usually leads to a better performance of machine learning approaches. In this paper, we present a tool called infoZilla that detects structural elements from bug reports with near perfect accuracy and allows us to extract them. We anticipate that infoZilla can be used to leverage data from bug reports at a different granularity level that can facilitate interesting research in the future.},
	keywords = {bug reports, eclipse, enumerations, infozilla, natural language, patches, source code, stack trace},
	isbn = {9781605580241},
	doi = {10.1145/1370750.1370757},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p27-bettenburg.pdf},
	author = {Premraj, Rahul and Zimmermann, Thomas and Kim, Sunghun and Bettenburg, Nicolas}
}
@conference {Parnin:2008:ICD:1370750.1370765,
	title = {Improving change descriptions with change contexts},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {51{\textendash}60},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Software archives are one of the best sources available to researchers for understanding the software development process. However, much detective work is still necessary in order to unravel the software development story. During this process, researchers must isolate changes and follow their trails over time. In support of this analysis, several research tools have provided different representations for connecting the many changes extracted from software archives. Most of these tools are based on textual analysis of source code and use line-based differencing between software versions. This approach limits the ability to process changes structurally resulting in less concise and comparable items. Adoption of structure-based approaches have been hampered by complex implementations and overly verbose change descriptions. We present a technique for expressing changes that is fine-grained but preserves some structural aspects. The structural information itself may not have changed, but instead provides a context for interpreting the change. This in turn, enables more relevant and concise descriptions in terms of software types and programming activities. We apply our technique to common challenges that researchers face, and then we discuss and compare our results with other techniques.},
	keywords = {bytecode analysis, cecil, change management, change pairs, semantic diff, zedgraph},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370765},
	url = {http://doi.acm.org/10.1145/1370750.1370765},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p51-parnin.pdf},
	author = {Parnin, Chris and G{\"o}rg, Carsten}
}
@conference {Zhang:2008:ISG:1370750.1370785,
	title = {An initial study of the growth of eclipse defects},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	pages = {141{\textendash}144},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {We analyze the Eclipse defect data from June 2004 to November 2007, and find that the growth of the number of defects can be well modeled by polynomial functions. Furthermore, we can predict the number of future Eclipse defects based on the nature of defect growth.},
	keywords = {bug reports, defect growth model, defect prediction, eclipse, msr challenge, polynomial regression},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370785},
	url = {http://doi.acm.org/10.1145/1370750.1370785},
	author = {Zhang, Hongyu}
}
@conference {973,
	title = {On the relation of refactorings and software defect prediction},
	booktitle = {Proceedings of the 2008 international workshop on Mining software repositories  - MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {35-38},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {This paper analyzes the influence of evolution activities such as refactoring on software defects. In a case study of five open source projects we used attributes of software evolution to predict defects in time periods of six months. We use versioning and issue tracking systems to extract 110 data mining features, which are separated into refactoring and non-refactoring related features. These features are used as input into classification algorithms that create prediction models for software defects. We found out that refactoring related features as well as non-refactoring related features lead to high quality prediction models. Additionally, we discovered that refactorings and defects have an inverse correlation: The number of software defects decreases, if the number of refactorings increased in the preceding time period. As a result, refactoring should be a significant part of both bug fixes and other evolutionary changes to reduce software defects.},
	keywords = {argouml, bug fixing, bug reports, defects, evolution, jboss, liferay, prediction, refactoring, spring, weka, xdoclet},
	isbn = {9781605580241},
	doi = {10.1145/1370750.1370759},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p35-ratzinger.pdf},
	author = {Sigmund, Thomas and Gall, Harald C. and Ratzinger, Jacek}
}
@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 {Sudakrishnan:2008:UBF:1370750.1370761,
	title = {Understanding bug fix patterns in verilog},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	pages = {39{\textendash}42},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Today, many electronic systems are developed using a hardware description language, a kind of software that can be converted into integrated circuits or programmable logic devices. Like traditional software projects, hardware projects have bugs, and significant developer time is spent fixing them. A useful first step toward reducing bugs in hardware is developing an understanding of the frequency of different types of errors. Once the most common types are known, it is then possible to focus attention on eliminating them. As most hardware projects use software configuration management repositories, these can be mined for the textual bug fix changes. In this project, we analyze the bug fix history of four hardware projects written in Verilog and manually define 25 bug fix patterns. The frequency of each bug type is then computed for all projects. We find that 29 -- 55\% of the bug fix pattern instances in Verilog involve assignment statements, while 18 -- 25\% are related to if statements.},
	keywords = {bug fixing, error classification, hdl, verilog, VHDL},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370761},
	url = {http://doi.acm.org/10.1145/1370750.1370761},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p39-sudakrishnan.pdf},
	author = {Sudakrishnan, Sangeetha and Madhavan, Janaki and Whitehead,Jr., E. James and Renau, Jose}
}
@article {Barcellini:2008:UDM:1379919.1380288,
	title = {User and developer mediation in an Open Source Software community: Boundary spanning through cross participation in online discussions},
	journal = {Int. J. Hum.-Comput. Stud.},
	volume = {66},
	number = {7},
	year = {2008},
	pages = {558{\textendash}570},
	publisher = {Academic Press, Inc.},
	address = {Duluth, MN, USA},
	abstract = {The aim of this research is to analyse how design and use are mediated in Open Source Software (OSS) design. Focusing on the Python community, our study examines a {\textquoteright}{\textquoteright}pushed-by-users{\textquoteright}{\textquoteright} design proposal through the discussions occurring in two mailing-lists: one, user-oriented and the other, developer-oriented. To characterize the links between users and developers, we investigate the activities and references (knowledge sharing) performed by the contributors to these two mailing-lists. We found that the participation of users remains local to their community. However, several key participants act as boundary spanners between the user and the developer communities. This emerging role is characterized by cross-participation in parallel same-topic discussions in both mailing-lists, cohesion between cross-participants, the occupation of a central position in the social network linking users and developers, as well as active, distinctive and adapted contributions. The user championing the proposal acts as a key boundary spanner coordinating the process and using explicit linking strategies. We argue that OSS design may be considered as a form of {\textquoteright}{\textquoteright}role emerging design{\textquoteright}{\textquoteright}, i.e. design organized and pushed through emerging roles and through a balance between these roles. The OSS communities seem to provide a suitable socio-technical environment to enable such role emergence. },
	keywords = {Boundary spanners, Cross-participants, Distributed design, Open Source Software Community, Role emerging design},
	issn = {1071-5819},
	doi = {10.1016/j.ijhcs.2007.10.008},
	url = {http://dx.doi.org/10.1016/j.ijhcs.2007.10.008},
	author = {Barcellini, Flore and D{\'e}tienne, Fran{\c c}oise and Burkhardt, Jean-Marie}
}
@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}
}
@article {springerlink:10.1007/s10588-006-9006-3,
	title = {Correlating temporal communication patterns of the Eclipse open source community with performance and creativity},
	journal = {Computational \&amp; Mathematical Organization Theory},
	volume = {13},
	year = {2007},
	note = {"Social network data was collected from the Eclipse component development groups{\textquoteright} online mailing lists by using the online process tool (Gloor and Zhao, 2004). Data on bugs and enhancements for each group was collected from the Eclipse bugzilla database (Eclipse bugzilla, 2004). The social network data was analyzed with the TeCFlow tool (Gloor and Zhao, 2004)."
"The study is based on data from the three main projects of the Eclipse open source development community, namely {\textquotedblleft}eclipse{\textquotedblright}, {\textquotedblleft}tools{\textquotedblright} and {\textquotedblleft}technology{\textquotedblright}. We have chosen thirty-three different component development groups for analysis."
"The online process tool (online process tool, 2004) was utilized to collect communication data from their mailing list archives. The online process tool runs a robot that searches for URLs in the projects{\textquoteright} mailing list archives to compile a list of the possible URL links. It then extracts communication data as tuples in the form of {\textquotedblleft}sender, receiver, communication type, timestamp, communication contents{\textquotedblright} and stores it in the database. Further, bugs and enhancement data were collected from the Eclipse bugzilla database."},
	pages = {17-27},
	publisher = {Springer Netherlands},
	abstract = {This paper studies the temporal communication patterns of online communities of developers and users of the open source Eclipse Java development environment. It measures the productivity of each community and seeks to identify correlations that exist between group communication characteristics and productivity attributes. The study uses the TeCFlow (Temporal Communication Flow) visualizer to create movie maps of the knowledge flow by analyzing the publicly accessible Eclipse developer mailing lists as an approximation of the social networks of developers and users. Thirty-three different Eclipse communities discussing development and use of components of Eclipse such as the Java Development Tools, the different platform components, the C/C++ Development Tools and the AspectJ extension have been analyzed over a period of six months. The temporal evolution of social network variables such as betweenness centrality, density, contribution index, and degree have been computed and plotted. Productivity of each development group is measured in terms of two indices, namely performance and creativity. Performance of a group is defined as the ratio of new bugs submitted compared with bugs fixed within the same period of time. Creativity is calculated as a function of new features proposed and implemented. Preliminary results indicate that there is a correlation between attributes of social networks such as density and betweenness centrality and group productivity measures in an open source development community. We also find a positive correlation between changes over time in betweenness centrality and creativity, and a negative correlation between changes in betweenness centrality and performance.},
	keywords = {bug fixing, bugs, bugzilla, communication, creativity, developers, eclipse, email, email archives, feature requests, mailing lists, performance, productivity},
	issn = {1381-298X},
	url = {http://dx.doi.org/10.1007/s10588-006-9006-3},
	attachments = {https://flosshub.org/sites/flosshub.org/files/16.pdf},
	author = {Kidane, Yared and Gloor, Peter}
}
@conference {992,
	title = {Determining Implementation Expertise from Bug Reports},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {2 - 2},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {As developers work on a software product they accumulate expertise, including expertise about the code base of the software product. We call this type of expertise "implementation expertise". Knowing the set of developers who have implementation expertise for a software product has many important uses. This paper presents an empirical evaluation of two approaches to determining implementation expertise from the data in source and bug repositories. The expertise sets created by the approaches are compared to those provided by experts and evaluated using the measures of precision and recall. We found that both approaches are good at finding all of the appropriate developers, although they vary in how many false positives are returned.},
	keywords = {bug reports, developers, eclipse, expertise, repository, scm, source code},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.7},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300002.pdf},
	author = {Anvik, John and Murphy, Gail C.}
}
@conference {991,
	title = {How Long Will It Take to Fix This Bug?},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {1},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Predicting the time and effort for a software problem has long been a difficult task. We present an approach that automatically predicts the fixing effort, i.e., the person-hours spent on fixing an issue. Our technique leverages existing issue tracking systems: given a new issue report, we use the Lucene framework to search for similar, earlier reports and use their average time as a prediction. Our approach thus allows for early effort estimation, helping in assigning issues and scheduling stable releases. We evaluated our approach using effort data from the JBoss project. Given a sufficient number of issues reports, our automatic predictions are close to the actual effort; for issues that are bugs, we are off by only one hour, beating naive predictions by a factor of four.},
	keywords = {bug fixing, bug reports, effort estimation, jboss, lucene, prediction, time},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.13},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300001.pdf},
	author = {Weiss, Cathrin and Premraj, Rahul and Zimmermann, Thomas and Zeller, Andreas}
}
@conference {1018,
	title = {Local and Global Recency Weighting Approach to Bug Prediction},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {33 - 33},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Finding and fixing software bugs is a challenging maintenance task, and a significant amount of effort is invested by software development companies on this issue. In this paper, we use the Eclipse project{\textquoteright}s recorded software bug history to predict occurrence of future bugs. The history contains information on when bugs have been reported and subsequently fixed.},
	keywords = {bug fixing, bug reports, eclipse, maintenance, prediction},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.17},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300033.pdf},
	author = {Joshi, Hemant and Zhang, Chuanlei and Ramaswamy, S. and Bayrak, Coskun}
}
@article {125,
	title = {Membership herding and network stability in the open source community: The Ising perspective},
	journal = {Management Science},
	volume = {53},
	number = {7},
	year = {2007},
	month = {Jul},
	pages = {1086-1101},
	abstract = {The aim of this paper is twofold: (1) to conceptually understand membership dynamics in the open source software (OSS) community, and (2) to explore how different network characteristics (i.e., network size and connectivity) influence the stability of an OSS network. Through the lens of Ising theory, which is widely accepted in physics, we investigate basic patterns of interaction and present fresh conceptual insight into dynamic and reciprocal relations among OSS community members. We also perform computer simulations based on empirical data collected from two actual OSS communities. Key findings include: (1) membership herding is highly present when external influences (e.g., the availability of other OSS projects) are weak, but decreases significantly when external influences increase, (2) propensity for membership herding is most likely to be seen in a large network with random connectivity, and (3) for large networks, when external influences are weak, random connectivity will result in higher network strength than scale-free connectivity (as external influences increase, however, the reverse phenomenon is observed). In addition, scale-free connectivity appears to be less volatile than random connectivity in response to an increase in the strength of external influences. We conclude with several implications that may be of significance to OSS stakeholders in particular, and to a broader range of online communities in general.},
	keywords = {BEHAVIOR, DYNAMICS, ECONOMICS, INNOVATION, INVESTMENT, Ising theory, membership herding, MODEL, MOTIVATION, network connectivity, network stability, open source, PHASE-TRANSITION, UNCERTAINTY},
	isbn = {0025-1909},
	author = {Oh, Wonseok and Jeon, Sangyong}
}
@conference {1014,
	title = {Predicting Eclipse Bug Lifetimes},
	booktitle = {Fourth International Workshop on Mining Software RepositoriesFourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {29 - 29},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {In non-trivial software development projects planning and allocation of resources is an important and difficult task. Estimation of work time to fix a bug is commonly used to support this process. This research explores the viability of using data mining tools to predict the time to fix a bug given only the basic information known at the beginning of a bug{\textquoteright}s lifetime. To address this question, a historical portion of the Eclipse Bugzilla database is used for modeling and predicting bug lifetimes. A bug history transformation process is described and several data mining models are built and tested. Interesting behaviours derived from the models are documented. The models can correctly predict up to 34.9\% of the bugs into a discretized log scaled lifetime class.},
	keywords = {bug fixing, bugzilla, classification, eclipse, effort estimation, mining challenge, msr challenge, prediction, weka},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.25},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300029.pdf},
	author = {Panjer, Lucas D.}
}
@conference {1012,
	title = {Prioritizing Warning Categories by Analyzing Software History},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {27 - 27},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Automatic bug finding tools tend to have high false positive rates: most warnings do not indicate real bugs. Usually bug finding tools prioritize each warning category. For example, the priority of "overflow" is 1 and the priority of "jumbled incremental" is 3, but the tools{\textquoteright} prioritization is not very effective.

In this paper, we prioritize warning categories by analyzing the software change history. The underlying intuition is that if warnings from a category are resolved quickly by developers, the warnings in the category are important. Experiments with three bug finding tools (FindBugs, JLint, and PMD) and two open source projects (Columba and jEdit) indicate that different warning categories have very different lifetimes. Based on that observation, we propose a preliminary algorithm for warning category prioritizing.},
	keywords = {bug fixing, change history, columba, findbugs, jedit, jlint, kenyon, pmd, warning},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.26},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300027.pdf},
	author = {Kim, Sunghun and Ernst, Michael D.}
}
@conference {994,
	title = {Recommending Emergent Teams},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {5 - 5},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {To build successful complex software systems, developers must collaborate with each other to solve issues. To facilitate this collaboration, specialized tools, such as chat and screen sharing, are being integrated into development environments. Currently, these tools require a developer to maintain a list of other developers with whom they may wish to communicate and to determine who within this list has expertise for a specific situation. For large, dynamic projects, like several successful open-source projects, these requirements place an unreasonable burden on the developer. In this paper, we show how the structure of a team emerges from how developers change software artifacts. We introduce the Emergent Expertise Locator (EEL) that uses emergent team information to propose experts to a developer within their development environment as the developer works. We found that EEL produces, on average, results with higher precision and higher recall than an existing heuristic for expertise recommendation.},
	keywords = {bugzilla, developers, eclipse, evolution, expertise, Firefox, teams},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.27},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300005.pdf},
	author = {Minto, Shawn and Murphy, Gail C.}
}
@conference {1004,
	title = {Release Pattern Discovery via Partitioning: Methodology and Case Study},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {19 - 19},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {The development of Open Source systems produces a variety of software artifacts such as source code, version control records, bug reports, and email discussions. Since the development is distributed across different tool environments and developer practices, any analysis of project behavior must be inferred from whatever common artifacts happen to be available. In this paper, we propose an approach to characterizing a project{\textquoteright}s behavior around the time of major and minor releases; we do this by partitioning the observed activities, such as artifact check-ins, around the dates of major and minor releases, and then look for recognizable patterns. We validate this approach by means of a case study on the MySQL database system; in this case study, we found patterns which suggested MySQL was behaving consistently within itself. These patterns included testing and documenting that took place more before a release than after and that the rate of source code changes dipped around release time.},
	keywords = {bitkeeper, bt2csv, cvs, evolution, mysql, releases, revision history, scm, softchange, version control},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.28},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300019.pdf},
	author = {Hindle, Abram and Godfrey, Michael W. and Holt, Richard C.}
}
@article {119,
	title = {Social network structures in open source software development teams},
	journal = {Journal of Database Management},
	volume = {18},
	number = {2},
	year = {2007},
	note = {"Three projects were selected from SourceForge.net in terms of their similarities as well as their differences. Monthly data were extracted from the bug tracking systems in order to achieve a longitudinal view of the interaction pattern of each project. Social network analysis was used to generate the indices of social structure."

no pdf},
	month = {Apr-Jun},
	pages = {25-40},
	abstract = {Drawing on social network theories and previous studies, this research examines the dynamics of social network structures in open source software (OSS) teams. Three projects were selected from SourceForge.net in terms of their similarities as well as their differences. Monthly data were extracted from the bug tracking systems in order to achieve a longitudinal view of the interaction pattern of each project. Social network analysis was used to generate the indices of social structure. The finding suggests that the interaction pattern of OSS projects evolves from a single hub at the beginning to a corel periphery model as the projects move forward.},
	keywords = {bug tracking, bugs, COMMUNITY, INNOVATION, longitudinal study, MODEL, open source, social, social network analysis, social networks, sourceforge, structure},
	isbn = {1063-8016},
	author = {Long, Y. and Siau, K.}
}
@conference {993,
	title = {Spam Filter Based Approach for Finding Fault-Prone Software Modules},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {4 - 4},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Because of the increase of needs for spam e-mail detection, the spam filtering technique has been improved as a convenient and effective technique for text mining. We propose a novel approach to detect fault-prone modules in a way that the source code modules are considered as text files and are applied to the spam filter directly. In order to show the applicability of our approach, we conducted experimental applications using source code repositories of Java based open source developments. The result of experiments shows that our approach can classify more than 75\% of software modules correctly.},
	keywords = {argouml, bug reports, classification, eclipse, java, modules, scm, spam, text mining},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.29},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300004.pdf},
	author = {Mizuno, Osamu and Ikami, Shiro and Nakaichi, Shuya and Kikuno, Tohru}
}
@conference {1226,
	title = {Understanding the KDE Social Structure through Mining of Email Archive},
	booktitle = {2nd Workshop on Public Data about Software Development (WoPDaSD 2007)},
	year = {2007},
	note = {"Our data source is constituted by e-mails sent to KDE mailing-lists and archived by MARC"

"Two problems quickly arise: neither the e-mails addresses nor the names can be considered unique. Consequently, we used an in-depth search algorithm to put together {\textquotedblleft}name-email{\textquotedblright} couples corresponding to a same contributor. Indeed, the algorithm suggests possible merges."

"There is a specific mailing list in our data set, kde-commit, which gathers automatic notifications from the revision control system (RCS)....We measure {\textquotedblleft}commit{\textquotedblright} by the number of messages sent to the {\textquotedblleft}kde-commit{\textquotedblright} mailing list. However, we did not count {\textquotedblleft}silent{\textquotedblright} commits, nor usual messages sent to this mailing list."

"We measured activities done in BTS in two ways: {\textquotedblleft}bug opener{\textquotedblright} and {\textquotedblleft}non bug opener{\textquotedblright}.	First, we counted the number of modifications done by the contributor who opened the concerned bug report. "
},
	abstract = {In order to achieve a better understanding of FLOSS social structure, we need a definition of social position. From a theoretical perspective, we propose to think the participation as a trajectory. Empirically, we use optimal matching to build a typology of participation trajectories based on KDE email archives. We show how these trajectories structure the community as a whole by combining these results with a social network analysis.},
	keywords = {bug tracking system, bugzilla, commit, email, email archive, kde, mailing list, participation, revision control, social network analysis},
	attachments = {https://flosshub.org/sites/flosshub.org/files/wopdasd_studer_et_all_full.pdf},
	author = {Studer, Matthias and M{\"u}ller, Beno{\^\i}t and Ritschard, Gilbert}
}
@article {1215,
	title = {Using FLOSSmole Data in Determining Business Readiness Ratings},
	journal = {2nd Workshop on Public Data about Software Development (WopDaSD 2007)},
	year = {2007},
	month = {2007},
	abstract = {This paper is a preliminary report on using FLOSSmole data retrieved from open source repositories (forges) to calculate Business Readiness Rating scores.  },
	keywords = {brr, business readiness rating, flossmole},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Using\%20FLOSSmole\%20Data\%20in\%20Determining\%20Business\%20Readiness\%20Ratings.pdf},
	author = {Wasserman, Anthony and Ashutosh Das}
}
@conference {1213,
	title = {Working with Open Source Development Data: Considerations triggered by a study of bug scenarios},
	booktitle = {2nd Workshop on Public Data about Software Development (WoPDaSD 2007)},
	year = {2007},
	month = {2007},
	abstract = {The retrieval and preparation of public data on software development calls for more than just technical skills. In 
addition, care and judgement are needed to avoid disproportionate costs to the providers of data or unnecessary embarrassment to the participants tracked in the data. Taking the extraction of bug scenarios as a use case, we illustrate these concerns and discuss how they could be translated into social requirements that would help to make retrieval and preparation a sustainable exercise. In particular, we call for more efforts to establish institutional repositories of public data on software development and, besides, we suggest that reviewers could play a role in making sure that empirical research is performed in a way that does not bring the long-term relationship between software developers and researchers in jeopardy. },
	keywords = {bug reports, bug scenarios, Data Collection},
	attachments = {https://flosshub.org/sites/flosshub.org/files/denBesten-wopdasd.pdf},
	author = {den Besten, Matthijs and Masmoudi, H{\'e}la and Jean-Michel Dalle}
}
@conference {WeiBgerber:2006:RLE:1137983.1138011,
	title = {Are refactorings less error-prone than other changes?},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {112{\textendash}118},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Refactorings are program transformations which should preserve the program behavior. Consequently, we expect that during phases when there are mostly refactorings in the change history of a system, only few new bugs are introduced. For our case study we analyzed the version histories of several open source systems and reconstructed the refactorings performed. Furthermore, we obtained bug reports from various sources depending on the system. Based on this data we identify phases when the above hypothesis holds and those when it doesn{\textquoteright}t.},
	keywords = {argouml, bug reports, bugs, change history, jedit, junit, re-engineering, refactoring, reverse engineering, software evolution, version control},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138011},
	url = {http://doi.acm.org/10.1145/1137983.1138011},
	attachments = {https://flosshub.org/sites/flosshub.org/files/112AreRefactorings.pdf},
	author = {Wei{\ss}gerber, Peter and Diehl, Stephan}
}
@article {90,
	title = {Core and periphery in Free/Libre and Open Source software team communications},
	journal = {Proceedings of the 39th Annual Hawaii International Conference on System Sciences-Volume 06},
	year = {2006},
	abstract = {The concept of the core group of developers is important and often discussed in empirical studies of FLOSS projects. This paper examines the question, "how does one empirically distinguish the core?" Being able to identify the core members of a FLOSS development project is important because many of the processes necessary for successful projects likely involve core members differently than peripheral members, so analyses that mix the two groups will likely yield invalid results. 

We compare 3 analysis approaches to identify the core: the named list of developers, a Bradford{\textquoteright}s law analysis that takes as the core the most frequent contributors and a social network analysis of the interaction pattern that identifies the core in a core-and-periphery structure. We apply these measures to the interactions around bug fixing for 116 SourceForge projects. The 3 techniques identify different individuals as core members; examination of which individuals are identified leads to suggestions for refining the measures. All 3 measures though suggest that the core of FLOSS projects is a small fraction of the total number of contributors.},
	keywords = {bug fixing, contributions, contributors, core, developers, social network analysis, sourceforge, team},
	author = {Kevin Crowston and Kangning Wei and Li, Qing and Howison, James}
}
@article {Crowston:2006a,
	title = {Hierarchy and centralization in Free and Open Source Software team communications},
	journal = {Knowledge, Technology \& Policy},
	volume = {18},
	number = {4},
	year = {2006},
	pages = {65{\textendash}85},
	abstract = {Free/Libre Open Source Software (FLOSS) development teams provide an interesting and convenient setting for studying distributed work. We begin by answering perhaps the most basic question: what is the social structure of these teams? Based on a social network analysis of interactions represented in 62,110 bug reports from 122 large and active projects, we find that some OSS teams are highly centralized, but contrary to expectation, others are not. Projects are mostly quite hierarchical on four measures of hierarchy, consistent with past research but contrary to the popular image of these projects. Furthermore, we find that the level of centralization is negatively correlated with project size, suggesting that larger projects become more modular. The paper makes a further methodological contribution by identifying appropriate analysis approaches for interaction data. We conclude by sketching directions for future research.},
	keywords = {apache, bug fixing, bug tracking, FLOSS, project success, savannah, social network analysis, sourceforge, team size, teams},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CrowstonHierarchyAndCentralization.pdf},
	author = {Kevin Crowston and Howison, James}
}
@conference {Kim:2006:LDT:1137983.1138027,
	title = {How long did it take to fix bugs?},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {173{\textendash}174},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {The number of bugs (or fixes) is a common factor used to measure the quality of software and assist bug related analysis. For example, if software files have many bugs, they may be unstable. In comparison, the bug-fix time--the time to fix a bug after the bug was introduced--is neglected. We believe that the bug-fix time is an important factor for bug related analysis, such as measuring software quality. For example, if bugs in a file take a relatively long time to be fixed, the file may have some structural problems that make it difficult to make changes. In this report, we compute the bug-fix time of files in ArgoUML and PostgreSQL by identifying when bugs are introduced and when the bugs are fixed. This report includes bug-fix time statistics such as average bug-fix time, and distributions of bug-fix time. We also list the top 20 bug-fix time files of two projects.},
	keywords = {argouml, bug fixing, bugs, mining challenge, msr challenge, postgresql, quality, time},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138027},
	url = {http://doi.acm.org/10.1145/1137983.1138027},
	attachments = {https://flosshub.org/sites/flosshub.org/files/173HowLong.pdf},
	author = {Kim, Sunghun and Whitehead,Jr., E. James}
}
@article {flosswp113,
	title = {The Impact of Ideology on Effectiveness in Open Source Software Development Teams},
	journal = {MIS Quarterly},
	volume = {30},
	number = {2},
	year = {2006},
	note = {"...we collected data related to OSS projects hosted on Sourceforge (www.sourceforge.net)."
"Data was collected using two surveys and from the Sourceforge website."
},
	month = {2006},
	pages = {291-314},
	abstract = {The emerging work on understanding open source software has argued for the importance of understanding what leads to effectiveness in OSS development teams and has pointed to the importance of ideology. This paper develops a framework of the OSS ideology (including specific norms, beliefs, and values) and a theoretical model to show how adherence to components of the ideology impact effectiveness in OSS teams. The model is based on the idea that ideology provides clan control, which is important in OSS development settings because OSS teams generally lack formal behavioral and outcome controls. The paper hypothesizes both direct effects of ideology on OSS team effectiveness and indirect effects via influences on affective trust, cognitive trust, and communication quality. Hypotheses are tested using survey and objective data on OSS projects. Four effectiveness measures are used to capture unique aspects of effectiveness in OSS including both the extent to which a team attracts input from the community and the team{\textquoteright}s success in accomplishing project outcomes. Results support the main thesis that OSS team members{\textquoteright} adherence to the tenets of the OSS community ideology enhances OSS team effectiveness. The study uncovers several differences in the importance of OSS norms, beliefs, and values to different kinds of OSS team effectiveness and discusses implications for theory and practice.},
	keywords = {bug fixing, bug reports, bug tracking, communication, COMMUNITY, effectiveness, feature requests, ideology, metadata, sourceforge, Survey, team effort, team size, trust},
	attachments = {https://flosshub.org/sites/flosshub.org/files/stewartgosain2.pdf},
	author = {Stewart, K. and Gosain, S.}
}
@article {Crowston:2006,
	title = {Information systems success in Free and Open Source Software development: Theory and measures},
	journal = {Software Process{\textendash}Improvement and Practice},
	volume = {11},
	number = {2},
	year = {2006},
	note = {"we continue our examination of success measures using data from Sourceforge..."
"e chose the number of developers (assessed from the records of the project and from bug fixing logs), bug-fixing time, and popularity (assessed from the number of downloads and viewings of project Web pages, and inclusion in distributions). These measures were chosen because they span the reconsidered FLOSS development process discussed above, including inputs (number of developers), process (speed of bug fixing) and output (popularity)."},
	pages = {123{\textendash}148},
	abstract = {Information systems success is one of the most widely used dependent variables in information systems (IS) research, but research on Free/Libre and Open Source software (FLOSS) often fails to appropriately conceptualize this important concept. In this paper, we reconsider what success means within a FLOSS context. We first review existing models of IS success and success variables used in FLOSS research and assess them for their usefulness, practicality and fit to the FLOSS context. Then, drawing on a theoretical model of group effectiveness in the FLOSS development process, as well as an online discussion group with developers, we present additional concepts that are central to an appropriate understanding of success for FLOSS. In order to examine the practicality and validity of this conceptual scheme, the second half of our paper presents an empirical study that demonstrates its operationalization of the chosen measures and assesses their internal validity. We use data from SourceForge to measure the project{\textquoteright}s effectiveness in team building, the speed of the project at responding to bug reports and the project{\textquoteright}s popularity. We conclude by discussing the implications of this study for our proposed extension of IS success in the context of FLOSS development and highlight future directions for research.},
	keywords = {bug fixing, developers, downloads, FLOSS, flossmole, page views, popularity, project success, size, sourceforge, success, team size},
	doi = {10.1002/spip.259},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CrowstonHowisonAnnabi2006.pdf},
	author = {Kevin Crowston and Howison, James and Hala Annabi}
}
@conference {Askari:2006:ITE:1137983.1138013,
	title = {Information theoretic evaluation of change prediction models for large-scale software},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {126{\textendash}132},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {In this paper, we analyze the data extracted from several open source software repositories. We observe that the change data follows a Zipf distribution. Based on the extracted data, we then develop three probabilistic models to predict which files will have changes or bugs. The first model is Maximum Likelihood Estimation (MLE), which simply counts the number of events, i.e., changes or bugs, that happen to each file and normalizes the counts to compute a probability distribution. The second model is Reflexive Exponential Decay (RED) in which we postulate that the predictive rate of modification in a file is incremented by any modification to that file and decays exponentially. The third model is called RED-Co-Change. With each modification to a given file, the RED-Co-Change model not only increments its predictive rate, but also increments the rate for other files that are related to the given file through previous co-changes. We then present an information-theoretic approach to evaluate the performance of different prediction models. In this approach, the closeness of model distribution to the actual unknown probability distribution of the system is measured using cross entropy. We evaluate our prediction models empirically using the proposed information-theoretic approach for six large open source systems. Based on this evaluation, we observe that of our three prediction models, the RED-Co-Change model predicts the distribution that is closest to the actual distribution for all the studied systems.},
	keywords = {bugs, change analysis, cvs, evaluation approach, file, freebsd, information theory, kde, koffice, log files, netbsd, openbsd, postgresql, prediction, prediction models, scm, source code},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138013},
	url = {http://doi.acm.org/10.1145/1137983.1138013},
	attachments = {https://flosshub.org/sites/flosshub.org/files/126InformationTheoretic.pdf},
	author = {Askari, Mina and Holt, Ric}
}
@conference {Kim:2006:MPE:1137983.1137995,
	title = {Micro pattern evolution},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {40{\textendash}46},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {When analyzing the evolution history of a software project, we wish to develop results that generalize across projects. One approach is to analyze design patterns, permitting characteristics of the evolution to be associated with patterns, instead of source code. Traditional design patterns are generally not amenable to reliable automatic extraction from source code, yet automation is crucial for scalable evolution analysis. Instead, we analyze {\textquotedblleft}micro pattern{\textquotedblright} evolution; patterns whose abstraction level is closer to source code, and designed to be automatically extractable from Java source code or bytecode. We perform micro-pattern evolution analysis on three open source projects, ArgoUML, Columba, and jEdit to identify micro pattern frequencies, common kinds of pattern evolution, and bug-prone patterns. In all analyzed projects, we found that the micro patterns of Java classes do not change often. Common bug- prone pattern evolution kinds are {\textquoteleft}Pool {\textrightarrow} Pool{\textquoteright}, {\textquoteleft}Implementor {\textrightarrow} NONE{\textquoteright}, and {\textquoteleft}Sampler {\textrightarrow} Sampler{\textquoteright}. Among all pattern evolution	kinds,{\textquoteleft}Box{\textquoteright},{\textquoteleft}CompoundBox{\textquoteright},	{\textquoteleft}Pool{\textquoteright}, {\textquoteleft}CommonState{\textquoteright}, and {\textquoteleft}Outline{\textquoteright} micro patterns have high bug rates, but they have low frequencies and a small number of changes. The pattern evolution kinds that are bug-prone are somewhat similar across projects. The bug-prone pattern evolution kinds of two different periods of the same project are almost identical.},
	keywords = {argouml, bugs, columba, design patterns, evolution, extraction, java, jedit, source code},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1137995},
	url = {http://doi.acm.org/10.1145/1137983.1137995},
	attachments = {https://flosshub.org/sites/flosshub.org/files/40MicroPattern.pdf},
	author = {Kim, Sunghun and Pan, Kai and Whitehead,Jr., E. James}
}
@conference {WeiBgerber:2006:MRA:1137983.1138028,
	title = {Mining refactorings in ARGOUML},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	note = {"To see if refactorings in ARGOUML have an effect on the occurrence of new bugs and on communication between the developers, we relate the refactorings to bug reports in ISSUEZILLA respectively to mails on the developer mailing list. "},
	pages = {175{\textendash}176},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {In this paper we combine the results of our refactoring reconstruc- tion technique with bug, mail and release information to perform process and bug analyses of the ARGOUML CVS archive.},
	keywords = {argouml, bug tracking, bugs, cvs, email, evolution, mining challenge, msr challenge, re-engineering, refactoring, release history},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138028},
	url = {http://doi.acm.org/10.1145/1137983.1138028},
	attachments = {https://flosshub.org/sites/flosshub.org/files/175MiningRefactorings.pdf},
	author = {Wei{\ss}gerber, Peter and Diehl, Stephan and G{\"o}rg, Carsten}
}
@conference {708,
	title = {Social dynamics of free and open source team communications},
	booktitle = {OSS2006: Open Source Systems (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing },
	volume = {203/2006},
	year = {2006},
	month = {06/2006},
	pages = {319 - 330},
	publisher = {Springer},
	organization = {Springer},
	abstract = {This paper furthers inquiry into the social structure of free and open source software (FLOSS) teams by undertaking social network analysis across time. Contrary to expectations, we confirmed earlier findings of a wide distribution of centralizations even when examining the networks over time. The paper also provides empirical evidence that while change at the center of FLOSS projects is relatively uncommon, participation across the project communities is highly skewed, with many participants appearing for only one period. Surprisingly, large project teams are not more likely to undergo change at their centers.
},
	keywords = {bug fixing, bug reports, bug tracker, bug tracking, bugs, communications, Dynamic social networks, FLOSS teams, Human Factors, social network analysis, software development, sourceforge},
	issn = {978-0-387-34225-2},
	doi = {http://dx.doi.org/10.1007/0-387-34226-5_32},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Social\%20dynamics\%20of\%20free\%20and\%20open\%20source\%20team.pdf},
	author = {Howison, James and Inoue, Keisuke and Kevin Crowston}
}
@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 {Canfora:2006:BRK:1137983.1138032,
	title = {Where is bug resolution knowledge stored?},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {183{\textendash}184},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {ArgoUML uses both CVS and Bugzilla to keep track of bug-fixing activities since 1998. A common practice is to reference source code changes resolving a bug stored in Bugzilla by inserting the id number of the bug in the CVS commit notes. This relationship reveals useful to predict code entities impacted by a new bug report.In this paper we analyze ArgoUML software repositories with a tool, we have implemented, showing what are Bugzilla fields that better predict such impact relationship, that is where knowledge about bug resolution is stored.},
	keywords = {argouml, bugs, bugzilla, cvs, impact analysis, mining challenge, mining software repositories, msr challenge, source code},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138032},
	url = {http://doi.acm.org/10.1145/1137983.1138032},
	attachments = {https://flosshub.org/sites/flosshub.org/files/183WhereIsBug.pdf},
	author = {Canfora, Gerardo and Cerulo, Luigi}
}
@conference {Anvik:2006:FTB:1134285.1134336,
	title = {Who should fix this bug?},
	booktitle = {Proceedings of the 28th international conference on Software engineering},
	series = {ICSE {\textquoteright}06},
	year = {2006},
	pages = {361{\textendash}370},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Open source development projects typically support an open bug repository to which both developers and users can report bugs. The reports that appear in this repository must be triaged to determine if the report is one which requires attention and if it is, which developer will be assigned the responsibility of resolving the report. Large open source developments are burdened by the rate at which new bug reports appear in the bug repository. In this paper, we present a semi-automated approach intended to ease one part of this process, the assignment of reports to a developer. Our approach applies a machine learning algorithm to the open bug repository to learn the kinds of reports each developer resolves. When a new report arrives, the classifier produced by the machine learning technique suggests a small number of developers suitable to resolve the report. With this approach, we have reached precision levels of 57\% and 64\% on the Eclipse and Firefox development projects respectively. We have also applied our approach to the gcc open source development with less positive results. We describe the conditions under which the approach is applicable and also report on the lessons we learned about applying machine learning to repositories used in open source development.},
	keywords = {bug fixing, bug report, bug report assignment, bug triage, eclipse, Firefox, gcc, issue tracking, machine learning, problem tracking},
	isbn = {1-59593-375-1},
	doi = {10.1145/1134285.1134336},
	url = {http://doi.acm.org/10.1145/1134285.1134336},
	author = {Anvik, John and Hiew, Lyndon and Murphy, Gail C.}
}
@conference {779,
	title = {Carrot2 Clustering Framework},
	booktitle = {OSS2005: Open Source Systems },
	year = {2005},
	pages = {298-299},
	abstract = {Carrot2 is an Open Source framework for research experiments with querying various textual data sources, processing and presentation of the results. Its main goal is to promote component reuse in order to reduce the effort involved in the development of Information Retrieval software. So far, the most successful and popular application of Carrot2 has been organizing results of Internet searches into easy to browse thematic groups called clusters. In this area, the project successfully competes with commercial counterparts like Vivisimo or iBoogie.},
	keywords = {BSD license, cluster, clustering framework, open source, research, result},
	url = {http://pascal.case.unibz.it/handle/2038/788},
	author = {Weiss, Dawid and Osi{\textasciiacute}nski, Stanis{\l}aw}
}
@conference {Robles:2005:DIM:1083142.1083162,
	title = {Developer identification methods for integrated data from various sources},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {106-110},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {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.},
	keywords = {anonymization, bug tracker, developers, email, email address, gnome, identity, mailing list, privacy, source code, version control},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083162},
	url = {http://doi.acm.org/10.1145/1082983.1083162},
	attachments = {https://flosshub.org/sites/flosshub.org/files/106DeveloperIdentification.pdf},
	author = {Gregorio Robles and Jesus M. Gonzalez-Barahona}
}
@article {102,
	title = {Empirical validation of object-oriented metrics on open source software for fault prediction},
	journal = {IEEE Transactions on Software Engineering},
	volume = {31},
	number = {10},
	year = {2005},
	note = {"This paper describes how we calculated the object-oriented metrics given by Chidamber and Kemerer to illustrate how fault-proneness detection of the source code of the open source Web and e-mail suite called Mozilla can be carried out. We checked the values obtained against the number of bugs found in its bug database - called Bugzilla - using regression and machine learning methods to validate the usefulness of these metrics for fault-proneness prediction. We also compared the metrics of several versions of Mozilla to see how the predicted fault-proneness of the software system changed during its development cycle."
metrics, 
wmc weighted methods per class, 
dit depth of inheritance, 
rfc response for a class,
noc number of children,
cbo coupling between object classes,
cohesion,
lines of code, loc, sloc
chidamber and kemerer metrics},
	pages = {897-910},
	abstract = {Open source software systems are becoming increasingly important these days. Many companies are investing in open source projects and lots of them are also using such software in their own work. But, because open source software is often developed with a different management style than the industrial ones, the quality and reliability of the code needs to be studied. Hence, the characteristics of the source code of these projects need to be measured to obtain more information about it. This paper describes how we calculated the object-oriented metrics given by Chidamber and Kemerer to illustrate how fault-proneness detection of the source code of the open source Web and e-mail suite called Mozilla can be carried out. We checked the values obtained against the number of bugs found in its bug database - called Bugzilla - using regression and machine learning methods to validate the usefulness of these metrics for fault-proneness prediction. We also compared the metrics of several versions of Mozilla to see how the predicted fault-proneness of the software system changed during its development cycle.},
	keywords = {bugs, bugzilla, cbo, defects, dit, fault-prone modules, faults, lcom, lcomn, loc, metrics, mozilla, noc, object-oriented, rfc, source code, wmc},
	url = {http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.8372\&rep=rep1\&type=pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Gyimothy.pdf},
	author = {Gyimothy, T. and Ferenc, R. and Siket, I.}
}
@conference {Gorg:2005:EDR:1083142.1083148,
	title = {Error detection by refactoring reconstruction},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {29-33},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {In many cases it is not sufficient to perform a refactoring only at one location of a software project. For example, refactorings may have to be performed consistently to several classes in the inheritance hierarchy, e.g. subclasses or implementing classes, to preserve equal behavior.In this paper we show how to detect incomplete refactorings - which can cause long standing bugs because some of them do not cause compiler errors - by analyzing software archives. To this end we reconstruct the class inheritance hierarchies, as well as refactorings on the level of methods. Then, we relate these refactorings to the corresponding hierarchy in order to find missing refactorings and thus, errors and inconsistencies that have been introduced in a software project at some point of the history.Finally. we demonstrate our approach by case studies on two open source projects.},
	keywords = {bugs, class, inheritance, jedit, refactoring, tomcat},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083148},
	url = {http://doi.acm.org/10.1145/1082983.1083148},
	attachments = {https://flosshub.org/sites/flosshub.org/files/29ErrorDetection.pdf},
	author = {G{\"o}rg, Carsten and Wei{\ss}gerber, Peter}
}
@article {DBLP:journals/tse/Dinh-TrongB05,
	title = {The FreeBSD Project: A Replication Case Study of Open Source Development},
	journal = {IEEE Trans. Software Eng.},
	volume = {31},
	number = {6},
	year = {2005},
	note = {" we obtained the necessary data from the [FreeBsd] CVS repository, the bug report database, and the e-mail archive. The CVS repository contains all of the code and related documentation that is committed to the project from 1993 until the present. The bug report database contains information describing all reported problems, as well as the status (such as fixed, under test, or open) of each problem. Each bug report is called a PR and assigned a reference number. The e-mail archive contains every e-mail message exchanged between the developers since 1994."

d/l: research.cs.queensu.ca/~ahmed/home/teaching/.../F06/.../free-bsd.pdf},
	pages = {481-494},
	abstract = {Case studies can help to validate claims that open source software development produces higher quality software at lower cost than traditional commercial development. One problem inherent in case studies is external validity{\textemdash}we do not know whether or not results from one case study apply to another development project. We gain or lose confidence in case study results when similar case studies are conducted on other projects. This case study of the FreeBSD project, a long-lived open source project, provides further understanding of open source development. The paper details a method for mining repositories and querying project participants to retrieve key process information. The FreeBSD development process is fairly well-defined with proscribed methods for determining developer responsibilities, dealing with enhancements and defects, and managing releases. Compared to the Apache project, FreeBSD uses 1) a smaller set of core developers{\textemdash}developers who control the code base{\textemdash}that implement a smaller percentage of the system, 2) a larger set of top developers to implement 80 percent of the system, and 3) a more well-defined testing process. FreeBSD and Apache have a similar ratio of core developers to people involved in adapting and debugging the system and people who report problems. Both systems have similar defect densities and the developers are also users in both systems.},
	keywords = {apache, bug reports, contributors, core, cvs, defect density, developers, email, email archive, freebsd, mailing list, scm, source code, users},
	doi = {10.1109/TSE.2005.73},
	attachments = {https://flosshub.org/sites/flosshub.org/files/DinhTrungBieman.pdf},
	author = {Trung T. Dinh-Trong and James M. Bieman}
}
@conference {Fischer:2005:MED:1083142.1083145,
	title = {Mining evolution data of a product family},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {12-16},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Diversification of software assets through changing requirements impose a constant challenge on the developers and maintainers of large software systems. Recent research has addressed the mining for data in software repositories of single products ranging from fine- to coarse grained analyses. But so far, little attention has been payed to mining data about the evolution of product families. In this work, we study the evolution and commonalities of three variants of the BSD (Berkeley Software Distribution), a large open source operating system. The research questions we tackle are concerned with how to generate high level views of the system discovering and indicating evolutionary highlights. To process the large amount of data, we extended our previously developed approach for storing release history information to support the analysis of product families. In a case study we apply our approach on data from three different code repositories representing about 8.5GB of data and 10 years of active development.},
	keywords = {bsd, change analysis, change history, cvs, evolution, freebsd, netbsd, openbsd, release history, source code, text mining},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083145},
	url = {http://doi.acm.org/10.1145/1082983.1083145},
	attachments = {https://flosshub.org/sites/flosshub.org/files/12MiningEvolution.pdf},
	author = {Fischer, Michael and Oberleitner, Johann and Ratzinger, Jacek and Gall, Harald}
}
@conference {Huang:2005:MVH:1083142.1083158,
	title = {Mining version histories to verify the learning process of Legitimate Peripheral Participants},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {84-88},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Since code revisions reflect the extent of human involvement in the software development process, revision histories reveal the interactions and interfaces between developers and modules.We therefore divide developers and modules into groups according to the revision histories of the open source software repository, for example, sourceforge.net. To describe the interactions in the open source development process, we use a representative model, Legitimate Peripheral Participation (LPP) [6], to divide developers into groups such as core and peripheral teams, based on the evolutionary process of learning behavior.With the conventional module relationship, we divide modules into kernel and non-kernel types (such as UI). In the past, groups of developers and modules have been partitioned naturally with informal criteria. In this work, however, we propose a developer-module relationship model to analyze the grouping structures between developers and modules. Our results show some process cases of relative importance on the constructed graph of project development. The graph reveals certain subtle relationships in the interactions between core and non-core team developers, and the interfaces between kernel and non-kernel modules.},
	keywords = {awstats, bzflag, cvs, filezilla, gallery, Legitimate Peripheral Participants (LPP), moodle, open boundary, open source software development process, phpmyadmin, social networks, sourceforge},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083158},
	url = {http://doi.acm.org/10.1145/1082983.1083158},
	attachments = {https://flosshub.org/sites/flosshub.org/files/84MiningVersion.pdf},
	author = {Huang, Shih-Kun and Liu, Kang-min}
}
@conference {803,
	title = {Open Source firms: from community to business},
	booktitle = {OSS2005: Open Source Systems },
	year = {2005},
	pages = {362-363},
	abstract = {A large body of literature is now addressing the Open Source (OS) phenomenon. Economic scholars have deeply investigated the incentives of people working within OS community projects; the software production models in absence of explicit hierarchical structures; the successful dissemination of OS programs in environments dominated by proprietary standards; the peculiarities in the management of intellectual property within the OS framework. Theoretical contributions have coupled with the collection of extensive empirical evidence mainly through surveys taken on individual developers. Nowadays a new trend is shaping the OS movement: more and more firms are entering the market by offering software solutions based on the new paradigm (Open Source firms).},
	keywords = {business, COMMUNITY, firms, Open Source firms},
	url = {http://pascal.case.unibz.it/handle/2038/1265},
	author = {Andrea Bonaccorsi and Cristina Rossi}
}
@conference {Neamtiu:2005:USC:1083142.1083143,
	title = {Understanding source code evolution using abstract syntax tree matching},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {2-6},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Mining software repositories at the source code level can provide a greater understanding of how software evolves. We present a tool for quickly comparing the source code of different versions of a C program. The approach is based on partial abstract syntax tree matching, and can track simple changes to global variables, types and functions. These changes can characterize aspects of software evolution useful for answering higher level questions. In particular, we consider how they could be used to inform the design of a dynamic software updating system. We report results based on measurements of various versions of popular open source programs, including BIND, OpenSSH, Apache, Vsftpd and the Linux kernel.},
	keywords = {abstract syntax trees, apache, bind, evolution, linux, openssh, software evolution, source code, source code analysis, vsftpd},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083143},
	url = {http://doi.acm.org/10.1145/1082983.1083143},
	attachments = {https://flosshub.org/sites/flosshub.org/files/2Understanding.pdf},
	author = {Neamtiu, Iulian and Foster, Jeffrey S. and Hicks, Michael}
}
@conference {Sliwerski:2005:CIF:1083142.1083147,
	title = {When do changes induce fixes?},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {24-28},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {As a software system evolves, programmers make changes that sometimes cause problems. We analyze CVS archives for fix-inducing changes{\textemdash}changes that lead to problems, indicated by fixes. We show how to automatically locate fix-inducing changes by linking a version archive (such as CVS) to a bug database (such as BUGZILLA). In a first investigation of the MOZILLA and ECLIPSE history, it turns out that fix-inducing changes show distinct patterns with respect to their size and the day of week they were applied.},
	keywords = {bugzilla, change analysis, cvs, eclipse, evolution, mozilla},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083147},
	url = {http://doi.acm.org/10.1145/1082983.1083147},
	attachments = {https://flosshub.org/sites/flosshub.org/files/24WhenDoChanges.pdf},
	author = {Sliwerski, J and Zimmermann, Thomas and Zeller, Andreas}
}
@conference {1052,
	title = {Bug driven bug finders},
	booktitle = {Proceedings of the 2004 international workshop on Mining software repositories  - MSR {\textquoteright}04},
	volume = {2004},
	year = {2004},
	pages = {70 - 74},
	publisher = {IEE},
	organization = {IEE},
	address = {Edinburgh, Scotland, UK},
	abstract = {We describe a method of creating tools to find bugs in software that is driven by the analysis of previously fixed bugs. We present a study of bug databases and software repositories that characterize commonly occurring types of bugs.	Based on the types of bugs that were commonly reported and fixed in the code, we determine what types of bug finding tools should be developed. We have implemented one static checker, a return value usage checker. Novel features of this checker include the use of information from the software repository to try to improve its false positive rate by identifying patterns that have resulted in previous bug fixes.},
	keywords = {apache, bug tracking, bugs},
	doi = {10.1049/ic:20040479},
	attachments = {https://flosshub.org/sites/flosshub.org/files/70BugDrivenBug.pdf},
	author = {Williams, C.C. and Hollingsworth, J.K.}
}
@conference {Crowston:2004,
	title = {Coordination practices for bug fixing within FLOSS development teams},
	booktitle = {1st International Workshop on Computer Supported Activity Coordination, 6th International Conference on Enterprise Information Systems},
	year = {2004},
	note = {"First, we chose projects for which data we need for our analysis are publicly available (not all projects allow public access to the bug tracking system). Second, we chose teams with more than 8 members...we tried to select more and less suc- cessful development teams. To this aim we used the definitions of success proposed by [9], who suggest that a project is successful if it is active, the resulting software is downloaded and used and the code matures"

"Kicq, Gaim and PhPmyAdmin were chosen" - effective
DynAPI was chosen as an example of a less effective project" 

"We collected data indicative of the success of each project, such as its level of activity, number of downloads and development status. We then collected data from the archives of the bug tracking system, the tool used to support the bug fixing process"},
	address = {Porto, Portugal},
	abstract = {Free/Libre Open Source Software (FLOSS) is primarily developed by distributed teams. Developers contribute from around the world and coordinate their activity almost exclusively by means of email and bulletin boards. FLOSS development teams some how profit from the advantages and evade the challenges of distributed software development. Despite the relevance of the FLOSS both for research and practice, few studies have investigated the work practices adopted by these development teams. In this paper we investigate the structure and the coordination practices adopted by development teams during the bug-fixing process, which is considered one of main areas of FLOSS project success. In particular, based on a codification of the messages recorded in the bug tracking system of four projects, we identify the accomplished tasks, the adopted coordination mechanisms, and the role undertaken by both the FLOSS development team and the FLOSS community. We conclude with suggestions for further research.},
	keywords = {activity, bug fixing, bug reports, bug tracker, coordination, downloads, dynapi, FLOSS, gaim, kicq, phpmyadmin, status},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CrowstonScozzi04coordination.pdf},
	author = {Kevin Crowston and Barbara Scozzi}
}
@conference {Germ04b,
	title = {Mining CVS repositories, the softChange experience},
	booktitle = {Proc. Int{\textquoteright}l Workshop on Mining Software Repositories ({MSR})},
	year = {2004},
	note = {"Mailing lists. Mailing lists are an important source of information about the evolution of the project. We currently correlate MRs [modification requests] to mail messages by using the author and the date attributes of both the MR and the message."},
	pages = {17{\textendash}21},
	abstract = {CVS logs are a rich source of software trails (information left behind by the contributors to the development process, usually in the forms of logs). This paper describes how softChange extracts these trails, and enhances them. This paper also addresses some challenges that CVS fact extraction poses to researchers.},
	keywords = {bugzilla, cvs, email archives, log files, logs, softchange},
	attachments = {https://flosshub.org/sites/flosshub.org/files/17MiningCVS.pdf},
	author = {German, Daniel}
}
@article {1077,
	title = {Profiling an Open Source Project Ecology and Its Programmers},
	journal = {Electronic Markets},
	volume = {14},
	year = {2004},
	month = {6/2004},
	pages = {77 - 88},
	abstract = {While many successful and well-known open source projects produce output of high quality, a general assessment of this development paradigm is still missing. In this paper, an online community of both small and large, successful and failed projects and their programmers is analysed mainly using the version-control data of each project, also according to their productivity and estimation of expended effort. As the results show, there are indeed significant differences between this cooperative development model and the commercial organization of work in the areas explored. Both open source software projects in their size and their programmers{\textquoteright} effort differ significantly, and the evolution of projects{\textquoteright} size over time seems in part to contradict the laws of software evolution proposed for commercial systems. Both the inequality of effort distribution between programmers and an increasing number of developers in a project do not lead to a decrease in productivity, opposing Brooks{\textquoteright}s Law. Effort estimation based on the COCOMO model for commercial organizations shows a large amount of effort expended for the projects, while a more general Norden-Rayleigh modeling shows a distinctly smaller expenditure. This proposes that either a highly efficient development is achieved by this self-organizing cooperative and highly decentralized form of work, or that the participation of users besides programming tasks is enormous and constitutes an economic factor of large proportions. },
	keywords = {affiliation network, brooks law, cocomo, effort estimation, evolution, productivity, project success, scm, size, time, version control},
	issn = {1422-8890},
	doi = {10.1080/10196780410001675031},
	author = {Koch, Stefan}
}
@article {1113,
	title = {Release criteria for the Linux kernel},
	journal = {First Monday},
	volume = {9},
	number = {4},
	year = {2004},
	note = {"The first was to examine the change logs [10, 11, 12] that are submitted with the public release of a version of the kernel on www.kernel.org [1]. Observations were made on the release nomenclature used in both the 2.4.x series and the 2.5.x (which later became the 2.6.x series). The number of patches incorporated into each release and the elapsed time between releases was recorded. The second approach was to review the Linux kernel mailing list [2] for any evidence of criteria for performing a particular release including any metrics used, tests carried out or bug databases referenced."},
	month = {2004},
	abstract = {Before software is released to its users, software developers will ensure that the software has met specified functional and technical requirements and that it is as free from bugs as possible. Users should be able to have a high degree of confidence that the software will perform as specified and without fault. With open source development practices such as those employed on the Linux kernel project, there are no detailed specifications and little formal testing processes. The questions, then, are what criteria, if any, are used in determining the suitability for release of a particular version of this software, and do users have any degree of confidence in the quality of that release of software? These questions were examined in this study using information from the Linux Kernel Mailing List (LKML), the primary forum for discussion of development issues of the Linux kernel, and change logs submitted with version releases of the Linux kernel. It was determined that very little planning is employed in determining the release of a particular version of the software and that a version of the software is essentially a collection of source patches released at regular intervals with some stabilisation of the code base before each release. Very little attempt is made to verify that the code is bug free, and consequently, the code released is of a largely unknown level of quality. End users are left to decide for themselves the suitability and robustness of a particular version of the software.},
	keywords = {bugs, change log, linux, linux kernel, log files, mailing list, patches, quality, release history},
	url = {http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1136/1056},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Glance.pdf},
	author = {Glance, D.G.}
}
@conference {flosswp180,
	title = {Towards a Portfolio of FLOSS project Success Measures},
	booktitle = {Workshop on Open Source Software Engineering, International Conference on Software Engineering},
	year = {2004},
	month = {May},
	abstract = {Project success is one of the most widely used dependent variables in information systems research. However, conventional measures of project success are difficult to apply to Free/Libre Open Source Software projects. In this paper, we present an analysis of four measures of success applied to SourceForge projects: number of members of the extended development community, project activity, bug fixing time and number of downloads. We argue that these four measures provide different insights into the collaboration and control mechanisms of the projects.},
	keywords = {bug fixing, developers, downloads, project success, sourceforge, team, team size},
	attachments = {https://flosshub.org/sites/flosshub.org/files/crowston04towards.pdf},
	author = {Kevin Crowston and Hala Annabi and Howison, James and Chengetai Masango}
}
@conference {German03automatingthe,
	title = {Automating the measurement of open source projects},
	booktitle = {Proceedings of the 3rd Workshop on Open Source Software Engineering},
	year = {2003},
	note = {"We have chosen to use Evolution to illustrate some of the capabilities of SoftChange. We focus on the data provided by CVS logs and the CVS commit mailing list. Our data includes changes to the CVS repository from April 1998 to January 2003."},
	pages = {63{\textendash}67},
	abstract = {The proliferation of open source projects raises a number of vital economic, social, and software engineering questions that are subject of intense research. Based on experience analyzing numerous open source and commercial projects we propose a set of tools to support extraction and validation of software project data. Such tools would streamline empirical investigation of open source projects and make it possible to test existing and new theories about the nature of open source projects. Our soft- ware includes tools to extract and summarize information from mailing lists, CVS logs, ChangeLog files, and defect tracking databases. More importantly, it cross-links records from various data sources and identifies all contributors for a software change. We illustrate some of the capabilities by analyzing data from Ximian Evolution project.},
	keywords = {bug reports, bug tracking, changelog, cvs, defects, evolution, log files, logs, mailing list, scm, softchange, source code, ximian, ximian evolution},
	attachments = {https://flosshub.org/sites/flosshub.org/files/germanMockus2003.pdf},
	author = {German, Daniel and Audris Mockus}
}
@article {Reinke2003707,
	title = {The availability of source code in relation to timely response to security vulnerabilities},
	journal = {Computers \& Security},
	volume = {22},
	number = {8},
	year = {2003},
	note = {"This paper considers the effects of proprietary software versus non-proprietary software in determining the speed with which a security fix is made available"
"The sources considered are the BugTraq mailing list (available at SecurityFocus.com), the CERT Coordination Center (www.cert.org), and Incidents.org (from the SANS Institute)"
Note that these lists are generic topical discussion lists and not the mailing lists OF a particular open source project.},
	pages = {707 - 724},
	abstract = {Once a vulnerability has been found in an application or service that runs on a computer connected to the Internet, fixing that exploit in a timely fashion is of the utmost importance. There are two parts to fixing vulnerability: a party acting on behalf of the application{\textquoteright}s vendor gives instructions to fix it or makes a patch available that can be downloaded; then someone using that information fixes the computer or application in question. This paper considers the effects of proprietary software versus non-proprietary software in determining the speed with which a security fix is made available, since this can minimize the amount of time that the computer system remains vulnerable.},
	keywords = {bugtraq, cert, email, email archives, mailing list, security, vulnerability},
	issn = {0167-4048},
	doi = {DOI: 10.1016/S0167-4048(03)00011-7},
	url = {http://www.sciencedirect.com/science/article/B6V8G-4B9CV31-C/2/a218fccfaef185af5c122f118b252703},
	author = {John Reinke and Hossein Saiedian}
}
@conference {DBLP:conf/ecis/TsiavosH03,
	title = {Beyond good and evil: why open source development for peer-to-peer networks does not necessarily equal to an open society is as imbalanced as copyright law and definitely is not going to make you a better person},
	booktitle = {European Conference on Information Systems (ECIS 2003)},
	year = {2003},
	note = {"In a first stage we collected data related to the development of the Gnutella protocol. The sources included: web sites that were used for hosting forums and file repositories related to the development of the protocol that could be either archived or still operational; messages posted on discussion groups, forums and newsgroups; the design documents of the Gnutella protocol.
In a second stage we gathered material related to the Limewire application. The sources included: operational and archived web sites having been used for the development of the application; applications such as Concurrent Version Systems (CVS) or Bug reporting tools (such as Issuezila), design and implementation documentation and relevant press reports.
The data gathered covered a time span from early 2000 to late November 2002."
"Other sources informed our research and also acted, at times of uncertainty, as forms of triangulation and verification (Lee 1991). These sources include websites such as Slashdot.org and WiredNews; IRC-mediated communications and private messages exchanged between the various developers."},
	month = {2003},
	abstract = {This paper interrogates the claims that open source development is an ideal form of regulatory development. We begin by presenting the literature that offers a framework of modalities of regulation where code, along with laws, markets, and norms shape and influence individual action. Within this framework, it is argued that for an Open Society we need Open Code.	We present the processes through which the Gnutella protocol and the Limewire application are developed by deconstructing the mechanisms of participation and contribution of the individual developers. The techniques of monitoring, modularization and filtering that we identify appear to be inconsistent with open society promises. Instead we suggest a different framing, that of creating nests of interests, whose creators can find refuge from inhabitants of other nests. From that perspective, we suggest that we should stop referring to the war between Copyright and peer-to-peer networks as the battle between good and evil.},
	keywords = {bug reports, cvs, design documents, discussion, discussion forums, documentation, forums, gnutella, issuezilla, limewire, web site},
	attachments = {https://flosshub.org/sites/flosshub.org/files/tsiavosHosein.pdf},
	author = {Prodromos Tsiavos and Ian Hosein}
}
@conference {1109,
	title = {Distributed Collective Practices and F/OSS Problem Management: Perspective and Methods},
	booktitle = {Conference on Cooperation, Innovation \& Technology (CITE 2003)},
	year = {2003},
	note = {"We have begun studying in detail the general issues raised above using a large collection of research data from the Mozilla project"
"Our Bugzilla snapshot contains over 128,000 problem reports, of which about 88,000 have been resolved"},
	abstract = {This paper presents the state of our research on Distributed Collective Practices (DCPs) in Free/Open-Source Software (F/OSS) projects, focusing on sensemaking and resolution of software problems. We are exploring the hypothesis that variations in the content and in the articulation of these socio-technical processes have an impact on the outcome of the activity of F/OSS collectives, and more specifically on problem resolution. Our preliminary techniques for combining qualitative data analysis with automated process extraction result in a scalable analysis method called Computational Amplification (CA). We are applying CA to 128,000 problem reports from the Mozilla F/OSS project. The paper illustrates how CA is used to create multidimensional process models and shows types of conclusions we can reach.},
	keywords = {Automated process extraction, bug fixing, bug reports, bugzilla, Collective knowledge management, Information extraction from natural language texts, mozilla, Software problem management},
	author = {Gasser, Les and Gabriel Ripoche}
}
@article {1116,
	title = {Organizational learning in open-source software projects: an analysis of debugging data},
	journal = {IEEE Transactions on Engineering Management},
	volume = {50},
	year = {2003},
	month = {11/2003},
	pages = {485 - 493},
	abstract = {This paper studies organizational learning effects in open-source programming projects. Working with data from the Apache and Mozilla projects, the study focuses on three aspects of open-source development. The first is the use of the open-source approach as a hedge against system complexity. The second is the adaptive learning mechanisms realized by the debugging process. The last is the learning curve effects of project-specific experience on bug cycle times. The results indicate that while open-source development is subject to positive learning effects, these effects are not universal, with some projects deriving more benefit than others.},
	keywords = {apache, bugs, complexity, mozilla},
	issn = {0018-9391},
	doi = {10.1109/TEM.2003.820136},
	author = {Huntley, C.L.}
}
@conference {1160,
	title = {Adopting OSS Methods by Adopting OSS Tools},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	abstract = {The open source movement has created and used a set of software engineering tools with features that fit the characteristics of open source development processes. To a large extent, the open source culture and methodology are conveyed to new developers via the toolset itself, and through the demonstrated usage of these tools on existing projects. The rapid and wide adoption of open source tools stands in stark contrast to the difficulties encountered in adopting traditional CASE tools. This paper explores the characteristics that make these tools adoptable and how adopting them may influence software development processes.},
	keywords = {ant, argouml, bugzilla, cactus, cvs, developers, eclipse, emacs, email, faq, junit, mailing lists, make, netbeans, package management, rpm, scarab, subversion, teams, tools, torque, WORK},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Robbins.pdf},
	author = {Robbins, Jason E.}
}
@conference {1153,
	title = {Characterizing the OSS process},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	note = {"We have considered two well-known Open Source portals (FreshMeat [1] and SourceForge [2] )."
"Using pseudo-random sampling we have selected a sample of 400 projects (mostly from FreshMeat). Each project is described by several variables (programming language, type of license, size of source code, type of documentation available and others). By indirect means (analysis of the Changelog file, or CVS) it is also possible to compute the number of people working on the project, and the number of external contributors. From FreshMeat we get both a vitality index, that considers the number of releases per time period, and a popularity index, which is a first measure of the interest of users to the project (project URL hits, mixed with subscriptions to it)."},
	abstract = {The Open Source model of software development has gained the attention of both the business, the practitioners{\textquoteright} and the research communities. The Open Source process has been described by the seminal paper by Eric Raymond [4] and [5]. However, sound empirical studies are still very limited [3], [6].
Our goal is to investigate the OS process by empirical means, to analyze, characterize it, and possibly model it with quantitative models. It should be noted that the Open Source process provides open process and product data, and therefore is a rare opportunity for empirical research.
Our initial research focus is on the characterization of the process, starting from the evolution of OS projects. In traditional projects, a significant number of releases in a short time is usually considered an instability factor [7] and [8], while in the OSS community, it is an evidence of vitality, shows the commitment of the authors and the power of attraction of other programmers [9]. Is it possible to characterize the vitality of projects? And, can vitality be traced to some other characteristics of a project?},
	keywords = {bugs, change log, classification, cvs, downloads, freshmeat, metadata, patches, popularity, project success, release history, sourceforge, vitality},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CapiluppiLagoMorisio.pdf},
	author = {Capiluppi, Andrea and Patricia Lago and Maurizio Morisio}
}
@article {1251,
	title = {The Economics of Open Source Software: A Survey of the Early Literature},
	journal = {Review of Network Economics},
	volume = {1},
	number = {1},
	year = {2002},
	month = {03/2002},
	abstract = {This paper reviews the recent literature on the economics of open source software. Two different sets of issues are addressed. The first looks at the incentives of programmers to participate in open source projects. The second considers the business models used by profit-making firms in the open source industry, and the effects on existing closed source firms. Some possible future research directions are also given.},
	keywords = {business, commercial software, incentives, MOTIVATION},
	attachments = {https://flosshub.org/sites/flosshub.org/files/schiff.pdf},
	author = {Schiff, A.}
}
@article {1095,
	title = {High Quality and Open Source Software Practices},
	journal = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	note = {"We examined the publicly visible portions of these projects from November 2001 through March 2002, ...The SLOC counts for the predominate languages are shown},
	month = {2002},
	abstract = {Surveys suggest that, according to various metrics, the quality and dependability of today{\textquoteright}s open source software is roughly on par with commercial and government developed software. What are the prospects for advancing to much higher levels of quality in open source software? More specifically, what attributes must be possessed by quality-related interventions for them to be feasibly adoptable in open source practice? In order to identify some of these attributes, we conducted a preliminary survey of the quality practices of a number of successful open source projects. We focus, in particular, on attributes related to adoptability by the open source practitioner community.},
	keywords = {apache, bug report, bug tracker, bug tracking system, feature requests, gcc, gnome, kde, lines of code, linux, loc, mozilla, netbeans, perl, position paper, python, sloc, source code, Survey, tomcat, xfree86},
	attachments = {https://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf},
	author = {T. Halloran and W. Scherlis}
}
@article {121,
	title = {Two case studies of open source software development: Apache and Mozilla},
	journal = {ACM Transactions on Software Engineering and Methodology},
	volume = {11},
	number = {3},
	year = {2002},
	note = {apache data sources:
email, cvs, bug database 
regarding email: "We wrote Perl scripts to extract date, sender identity, message subject, and the message body that was further processed to obtain details on code changes and problem reports (see below). Manual inspection was used to resolve such things as multiple email addresses in cases where all automated techniques failed."
(but the rest of the paper does not address this data source at all)

mozilla data sources
bugzilla, cvs

},
	pages = {309-346},
	abstract = {According to its proponents, open source style software development has the capacity to compete successfully, and perhaps in many cases displace, traditional commercial development methods. In order to begin investigating such claims, we examine data from two major open source projects, the Apache web server and the Mozilla browser. By using email archives of source code change history and problem reports we quantify aspects of developer participation, core team size, code ownership, productivity, defect density, and problem resolution intervals for these OSS projects. We develop several hypotheses by comparing the Apache project with several commercial projects. We then test and refine several of these hypotheses, based on an analysis of Mozilla data. We conclude with thoughts about the prospects for high- performance commercial/ open source process hybrids.},
	keywords = {apache, bug fixing, bug reports, bugzilla, change history, core, defect density, email, email archives, mailing list, mozilla, ownership, participation, productivity, scm, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/mockusFieldingHerbsleb2002.pdf},
	author = {Audris Mockus and Roy Fielding and Herbsleb, J. D.}
}
@conference {Godfrey:2001:GES:602461.602482,
	title = {Growth, evolution, and structural change in open source software},
	booktitle = {Proceedings of the 4th International Workshop on Principles of Software Evolution (IWPSE 2001)},
	series = {IWPSE {\textquoteright}01},
	year = {2001},
	note = {"We measured [linux] system size in uncommented LOC"
"We also examined the growth of several other open source systems, including the VIM text editor, Eric Raymond{\textquoteright}s fetchmail utility, and the GCC compiler suite. "},
	pages = {103{\textendash}106},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Our recent work has addressed how and why software systems evolve over time, with a particular emphasis on software architecture and open source software systems [2, 3, 6]. In this position paper, we present a short summary of two recent projects. First, we have performed a case study on the evolution of the Linux kernel [3], as well as some other open source software (OSS) systems. We have found that several OSS systems appear not to obey some of "Lehman{\textquoteright}s laws" of software evolution [5, 7], and that Linux in particular is continuing to grow at a geometric rate. Currently, we are working on a detailed study of the evolution of one of the subsystems of the Linux kernel: the SCSI drivers subsystem. We have found that cloning, which is usually considered to be an indicator of lazy development and poor process, is quite common and is even considered to be a useful practice. Second, we are developing a tool called Beagle to aid software maintainers in understanding how large systems have changed over time. Beagle integrates data from various static analysis and metrics tools and provides a query engine as well as navigable visualizations. Of particular note, Beagle aims to provide help in modelling long term evolution of systems that have undergone architectural and structural change.},
	keywords = {agile methods, beagle, cloning, evolution, fetchmail, gcc, growth, kernel, lehman{\textquoteright}s laws, lines of code, linux, linux kernel, loc, open source software, software architecture, software evolution, source code, structural change, supporting environments, vim},
	isbn = {1-58113-508-4},
	doi = {http://doi.acm.org/10.1145/602461.602482},
	url = {http://doi.acm.org/10.1145/602461.602482},
	attachments = {https://flosshub.org/sites/flosshub.org/files/tu2001.pdf},
	author = {Michael Godfrey and Tu, Qiang}
}
@article {flosswp26,
	title = {A Case Study of Open Source Software Development: The Apache Server},
	journal = {Proceedings of the International Conference on Software Engineering (ICSE 2000)},
	year = {2000},
	note = {We used the following archival sources of data:
Developer email list (EMAIL).
Concurrent Version Control archive (CVS).
Problem reporting database (BUGDB).},
	month = {June},
	abstract = {According to its proponents, open source style software development has the capacity to compete successfully, and perhaps in many cases displace, traditional commercial development methods. We examine the development process of a major open source application, the Apache web server. By using email archives of source code change history and problem reports we quantify aspects of developer participation, core team size, code ownership, productivity, defect density, and problem resolution interval for this OSS project. This analysis reveals a unique process, which performs well on important measures.},
	keywords = {apache, bug fix revisions, bugs, core, cvs, defect density, developers, email archives, participation, productivity, revision control, revision history, roles, scm, source code, team size},
	attachments = {https://flosshub.org/sites/flosshub.org/files/mockusapache.pdf},
	author = {Audris Mockus and Roy Fielding and Herbsleb, James}
}
