@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}
}
@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}
}
@article {1079,
	title = {Are All Open Source Projects Created Equal? Understanding the Sustainability of Open Source Software Development Model},
	journal = {AMCIS 2005 Proceedings},
	number = {435},
	year = {2005},
	note = {uses first 300 most active projects on Sourceforge: {\textquoteright}Our data sample consists of 300 open source software development projects hosted in the Sourceforge.Net. They are the first 300 active projects ranked by Sourceforge.Net....Our dependent variable in the model to measure the success of the projects is the number of downloads. It is an essential variable to show how successful the project is. Generally, more number of downloads means a more successful project. Independent variables include: development status, project lifespan, number of developers, number of messages in the forums, number of mailing list, number of bug report, number of patch report, number of CVS report, number of file releases and also number of news release."},
	abstract = {A very intriguing question in Open Source software (OSS) development is: why there are only a few open source projects succeed, while the majority of projects never do. In this research, we examine the factors that may influence the performance of OSS projects. We particularly focus on the OSS{\textquoteright}s core developers{\textquoteright} role in the project{\textquoteright}s success. Extant research has yet to distinguish core developers and non-core developers from the community at large. The different roles of the core developers and non-core developers in OSS projects{\textquoteright} success still remain unclear. Our research contributes to the literature by separating the core developers from the development forces in general and empirically examining the core developers{\textquoteright} importance. Drawing the evidences from our extensive dataset of 300 open source projects, we demonstrated that core developers{\textquoteright} leadership and project advocation are crucial in determining the fate of the OSS projects. Our research could provide better understanding of OSS sustainability. It could also give practical advice to the OSS community on how to make the project successful.},
	keywords = {contributors, core, developers, downloads, metadata, project success, sourceforge},
	attachments = {https://flosshub.org/sites/flosshub.org/files/LongYuan.pdf},
	author = {Long, J. and Yuan, M.J.}
}
@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 {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 {Wynn03organizationalstructure,
	title = {Organizational Structure of Open Source Projects: A Life Cycle Approach},
	booktitle = {Proceedings of 7th Annual Conference of the Southern Association for Information Systems},
	year = {2003},
	note = {"The three graphs in Figure 2 below were taken from smoothed download counts for existing open source projects on Sourceforge.net"
"A random sample of 150 open source projects will be taken from data provided by Sourceforge.net. Each project will be evaluated to determine their current life cycle stage (where possible) using download counts. Next, the project admins, developers, and several identifiable users for each evaluated project will be contacted via email to request completing a brief questionnaire to measure the current focus of the project, formal structure, division of labor, leader role, coordination, level of commitment, user success, and developer success. "},
	abstract = {The structure of open source project communities is discussed in relation to the organizational life cycle. In lieu of sales figures, the download counts for each project are used to identify the life cycle stage of a random sample of open source projects. A research model is proposed that attempts to measure the fit between the life cycle stage and the specific organizational characteristics of these projects (focus, division of labor, role of the leader, level of commitment, and coordination/control) as an indicator of the success of a project as measured by the satisfaction and involvement of both developers and users.},
	keywords = {division of labor, downloads, growth, interview, leadership, life cycle, lifecycle, project success, roles, sourceforge, Survey},
	attachments = {https://flosshub.org/sites/flosshub.org/files/wynn2004.pdf},
	author = {Donald E. Wynn}
}
@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}
}
