@conference {1223,
	title = {Success and Abandonment in Open Source Commons: Selected Findings from an Empirical Study of Sourceforge.net Projects},
	booktitle = {Second International Workshop on Building Sustainable Open Source Communities (OSCOMM 2010)},
	year = {2010},
	note = {"we utilize data collected from August through October 2006 on 107,747 OSS projects hosted on the open source hosting site Sourceforge.net (SF henceforth). We combined SF project data gathered by the FLOSSmole project (Howison et al., 2006) with other SF data we {\textquotedblleft}crawled{\textquotedblright} ourselves"},
	month = {05/2010},
	abstract = {Some open source software collaborations are sustained over long periods of time and across several versions of a software product, while others become abandoned even before the first version of the product has been developed. In this study, we identify factors that might be responsible for one or the other of these collaborative trajectories. We examine 107,747 open source software projects hosted on Sourceforge.net in August 2006 using data available through the FLOSSmole Project. We employ Classification and Regression Tree modeling and Random Forests statistical approaches to begin to establish an understanding of how various project attributes, especially physical and community ones, contribute to project success or abandonment. We find that factors associated with success and abandonment differ for projects in the early stage of development (pre-first release) compared to projects that have had a first release, and that product utility, project vision, leadership, and group-size are associated with success in open source collaborations. We also find that successful open source projects exist across all types of software and not simply in areas associated with the open source {\textquotedblleft}movement.{\textquotedblright} Other evidence suggests that Sourceforge.net may play an important role in {\textquotedblleft}intellectual match-making.{\textquotedblright}},
	keywords = {abandonment, flossmole, metadata, project failure, project success, sourceforge, time},
	attachments = {https://flosshub.org/sites/flosshub.org/files/osscomm003.pdf},
	author = {Schweik, C. M. and English, R. and Paienjton, Q. and Haire, S.}
}
@conference {1217,
	title = {Trends That Affect Temporal Analysis Using SourceForge Data},
	booktitle = {5th Workshop on Public Data about Software Development (WoPDaSD 2010)},
	year = {2010},
	note = {"In this paper we examine some of the limitations of artifact data by specifically addressing the applicability of SourceForge data to the study of project evolution."

"For our analysis we examine 9,997 Production/Stable or Maintenance phase projects stored in CVS on SourceForge and extracted in October of 2006 [5]"},
	abstract = {SourceForge is a valuable source of software artifact data for researchers who study project evolution and developer behavior. However, the data exhibit patterns that may bias temporal analyses. Most notable are cliff walls in project source code repository timelines, which indicate large commits that are out of character for the given project. These cliff walls often hide significant periods of development and developer collaboration{\textemdash}a threat to studies that rely on SourceForge repository data. We demonstrate how to identify these cliff walls, discuss reasons for their appearance, and propose preliminary measures for mitigating their effects in evolution-oriented studies.},
	keywords = {cliff walls, committers, cvs, evolution, growth, source code, sourceforge, time, time series},
	attachments = {https://flosshub.org/sites/flosshub.org/files/wopdasd001.pdf},
	author = {MacLean, Alexander C. and Pratt, Landon J. and Krein, Jonathan L. and Knutson, Charles D.}
}
@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 {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 {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}
}
