@proceedings {1875,
	title = {Considering the use of walled gardens for FLOSS project communication},
	year = {2017},
	month = {05/2017},
	abstract = {At its core, free, libre, and open source software (FLOSS) is defined by its adherence to a set of licenses that give various freedoms to the users of the software, for example the ability to use the software, to read or modify its source code, and to distribute the software to others. In addition, many FLOSS projects and developers also champion other values related to "freedom" and "openness", such as transparency, for example in communication and decision-making, or community-orientedness, for example in broadening access, collaboration, and participation. This paper explores how one increasingly common software development practice - communicating inside non-archived, third-party "walled gardens" - puts these FLOSS values into conflict. If communities choose to use non-archived walled gardens for communication, they may be prioritizing one type of openness (broad participation) over another (transparency). We use 18 FLOSS projects as a sample to describe how walled gardens are currently being used for intra-project communication, as well as to determine whether or not these projects provide archives of these communications. Findings will be useful to the FLOSS community as a whole as it seeks to under- stand the evolution and impact of its communication choices.},
	keywords = {apache, chat, communication, email, free software, irc, mailing list, open source, Slack, Stack Overflow, teams, Wordpress},
	doi = {10.1007/978-3-319-57735-7_1},
	url = {https://link.springer.com/content/pdf/10.1007\%2F978-3-319-57735-7_1.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/preprint_0.pdf},
	author = {Squire, Megan}
}
@conference {ValdiviaGarcia:2014:CPB:2597073.2597099,
	title = {Characterizing and Predicting Blocking Bugs in Open Source Projects},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {72{\textendash}81},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {As software becomes increasingly important, its quality becomes an increasingly important issue. Therefore, prior work focused on software quality and proposed many prediction models to identify the location of software bugs, to estimate their fixing-time, etc. However, one special type of severe bugs is blocking bugs. Blocking bugs are software bugs that prevent other bugs from being fixed. These blocking bugs may increase maintenance costs, reduce overall quality and delay the release of the software systems.

In this paper, we study blocking-bugs in six open source projects and propose a model to predict them. Our goal is to help developers identify these blocking bugs early on. We collect the bug reports from the bug tracking systems of the projects, then we obtain 14 different factors related to, for example, the textual description of the bug, the location the bug is found in and the people involved with the bug. Based on these factors we build decision trees for each project to predict whether a bug will be a blocking bug or not. Then, we analyze these decision trees in order to determine which factors best indicate these blocking bugs. Our results show that our prediction models achieve F-measures of 15-42\%, which is a two- to four-fold improvement over the baseline random predictors. We also find that the most important factors in determining blocking bugs are the comment text, comment size, the number of developers in the CC list of the bug report and the reporter{\textquoteright}s experience. Our analysis shows that our models reduce the median time to identify a blocking bug by 3-18 days.},
	keywords = {Code Metrics, Post-release Defects, Process Metrics},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597099},
	url = {http://doi.acm.org/10.1145/2597073.2597099},
	attachments = {https://flosshub.org/sites/flosshub.org/files/garcia.pdf},
	author = {Valdivia Garcia, Harold and Shihab, Emad}
}
@conference {Krutz:2014:CCO:2597073.2597127,
	title = {A Code Clone Oracle},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {388{\textendash}391},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Code clones are functionally equivalent code segments. Detecting code clones is important for determining bugs, fixes and software reuse. Code clone detection is also essential for developing fast and precise code search algorithms. How- ever, the challenge of such research is to evaluate that the clones detected are indeed functionally equivalent, consider- ing the majority of clones are not textual or even syntactically identical. The goal of this work is to generate a set of method level code clones with a high confidence to help to evaluate future code clone detection and code search tools to evaluate their techniques. We selected three open source programs, Apache, Python and PostgreSQL, and randomly sampled a total of 1536 function pairs. To confirm whether or not these function pairs indicate a clone and what types of clones they belong to, we recruited three experts who have experience in code clone research and four students who have experience in programming for manual inspection. For confidence of the data, the experts consulted multiple code clone detection tools to make the consensus. To assist manual inspection, we built a tool to automatically load function pairs of interest and record the manual inspection results. We found that none of the 66 pairs are textual identical type- 1 clones, and 9 pairs are type-4 clones. Our data is available at: http://phd.gccis.rit.edu/weile/data/cloneoracle/.
},
	keywords = {clone, Clone Oracle, Code Clone Detection, msr data showcase, software engineering},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597127},
	url = {http://doi.acm.org/10.1145/2597073.2597127},
	attachments = {https://flosshub.org/sites/flosshub.org/files/clone_oracle.pdf},
	author = {Krutz, Daniel E. and Le, Wei}
}
@conference {Aggarwal:2014:CPD:2597073.2597120,
	title = {Co-evolution of Project Documentation and Popularity Within Github},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {360{\textendash}363},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Github is a very popular collaborative software-development platform that provides typical source-code management and issue tracking features augmented by strong social-networking features such as following developers and watching projects. These features help "spread the word" about individuals and projects, building the reputation of the former and increasing the popularity of the latter. In this paper, we investigate the relation between project popularity and regular, consistent documentation updates. We found strong indicators that consistently popular projects exhibited consistent documentation effort and that this effort tended to attract more documentation collaborators. We also found that frameworks required more documentation effort than libraries to achieve similar adoption success, especially in the initial phase.
},
	keywords = {Cross Correlation, Documentation Change, mining challenge, msr challenge, popularity},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597120},
	url = {http://doi.acm.org/10.1145/2597073.2597120},
	author = {Aggarwal, Karan and Hindle, Abram and Stroulia, Eleni}
}
@conference {Tymchuk:2014:COP:2597073.2597093,
	title = {Collaboration in Open-source Projects: Myth or Reality?},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {304{\textendash}307},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {One of the fundamental principles of open-source projects is that they foster collaboration among developers, disregarding their geographical location or personal background. When it comes to software repositories collaboration is a rather ephemeral phenomenon which lacks a clear definition, and it must therefore be mined and modeled. This throws up the question whether what is mined actually maps to reality.

In this paper we investigate collaboration by modeling it using a number of diverse approaches that we then compare to a ground truth obtained by surveying a substantial set of developers of the Pharo open-source community. Our findings indicate that the notion of collaboration must be revisited, as it is undermined by a number of factors that are often tackled in imprecise ways or not taken into account at all.},
	keywords = {COLLABORATION, Software ecosystems},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597093},
	url = {http://doi.acm.org/10.1145/2597073.2597093},
	author = {Tymchuk, Yuriy and Mocci, Andrea and Lanza, Michele}
}
@article {9400325220140301,
	title = {COLLABORATION THROUGH OPEN SUPERPOSITION: A THEORY OF THE OPEN SOURCE WAY.},
	journal = {MIS Quarterly},
	volume = {38},
	number = {1},
	year = {2014},
	pages = {29 - A9},
	abstract = {This paper develops and illustrates the theory of collaboration through open superposition: the process of depositing motivationally independent layers of work on top of each other over time. The theory is developed in a study of community-based free and open source software (FLOSS) development, through a research arc of discovery (participant observation), replication (two archival case studies), and theorization. The theory explains two key findings: (1) the overwhelming majority of work is accomplished with only a single programmer working on any one task, and (2) tasks that appear too large for any one individual are more likely to be deferred until they are easier rather than being undertaken through structured team work. Moreover, the theory explains how working through open superposition can lead to the discovery of a work breakdown that results in complex, functionally interdependent, work being accomplished without crippling search costs. We identify a set of socio-technical},
	keywords = {COLLABORATION, COMPUTER programmers, COMPUTER programming, COMPUTER software, coordination, FREEWARE (Computer software), INFORMATION storage \& retrieval systems, open source software, research, socio-technical system},
	issn = {02767783},
	author = {Howison, James and Kevin Crowston}
}
@proceedings {1289,
	title = {Cliff Walls: An Analysis of Monolithic Commits Using Latent Dirichlet Allocation},
	year = {2011},
	note = {"Our data set consists of the version control logs of almost 10,000 projects from SourceForge, acquired in late 2006"},
	month = {10/2011},
	pages = {282-298},
	publisher = {Springer},
	abstract = {Artifact-based research provides a mechanism whereby researchers may study the creation of software yet avoid many of the difficulties of direct observation and experimentation. However, there are still many challenges that can affect the quality of artifact-based studies, especially those studies examining software evolution. Large commits, which we refer to as {\textquotedblleft}Cliff Walls,{\textquotedblright} are one significant threat to studies of software evolution because they do not appear to represent incremental development. We used Latent Dirichlet Allocation to extract topics from over 2 million commit log messages, taken from 10,000 SourceForge projects. The topics generated through this method were then analyzed to determine the causes of over 9,000 of the largest commits. We found that branch merges, code imports, and auto-generated documentation were significant causes of large commits. We also found that corrective maintenance tasks, such as bug fixes, did not play a significant role in the creation of large commits.},
	keywords = {artifacts, commit, cvs, LDA, lines of code, log files, scm, sloc, sourceforge, version control},
	author = {Pratt, Landon J. and MacLean, Alexander C. and Knutson, Charles D. and Ringger, Eric K.}
}
@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 {958,
	title = {Cloning and copying between GNOME projects},
	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 = {98 - 101},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {This paper presents an approach to automatically distinguish the copied clone from the original in a pair of clones. It matches the line-by-line version information of a clone to the pair{\textquoteright}s other clone. A case study on the GNOME Desktop Suite revealed a complex flow of reused code between the different subprojects. In particular, it showed that the majority of larger clones (with a minimal size of 28 lines or higher) exist between the subprojects and more than 60\% of the clone pairs can be automatically separated into original and copy.},
	keywords = {clone, gnome, msr challenge, source code},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463290},
	attachments = {https://flosshub.org/sites/flosshub.org/files/98Coning.pdf},
	author = {Krinke, Jens and Gold, Nicolas and Jia, Yue and Binkley, David}
}
@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 {1264,
	title = {The Commit Size Distribution of Open Source Software},
	booktitle = {2009 42nd Hawaii International Conference on System Sciences (HICSS 2009)},
	year = {2009},
	note = {"We use the database of the open source analytics firm Ohloh Inc."
"This article is based on a March 2008 database snapshot, which contains 9,363 completely crawled and analyzed projects covering a time frame from January 1990 to February 2008."
"The Ohloh database provides the complete configuration management history of each crawled project (to the extent available on the web). Thus, every single commit action of all the projects over their entire history is available."
"We measure the size of commits in this paper in source lines of code (SLoC) using Ohloh{\textquoteright}s own open source diff too"},
	pages = {1 - 8},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Waikoloa, Hawaii, USA},
	abstract = {With the growing economic importance of open source, we need to improve our understanding of how open source software development processes work. The analysis of code contributions to open source projects is an important part of such research. In this paper we analyze the size of code contributions to more than 9,000 open source projects. We review the total distribution and distinguish three categories of code contributions using a size-based heuristic: single focused commits, aggregate team contributions, and repository refactorings. We find that both the overall distribution and the individual categories follow a power law. We also suggest that distinguishing these commit categories by size will benefit future analyses.},
	keywords = {commits, configuration management, history, lines of code, sloc, source code},
	isbn = {978-0-7695-3450-3},
	doi = {10.1109/HICSS.2009.421},
	attachments = {https://flosshub.org/sites/flosshub.org/files/07-07-07.pdf},
	author = {Arafat, O. and Dirk Riehle}
}
@article {1391,
	title = {Challenges and strategies in the use of Open Source Software by Independent Software Vendors},
	journal = {Information and Software Technology},
	volume = {50},
	year = {2008},
	month = {8/2008},
	pages = {991 - 1002},
	abstract = {Open Source Software (OSS) has already been adopted by a large number of organizations. An important {\textendash} but sometimes neglected {\textendash} group of OSS users are Independent Software Vendors (ISVs). ISVs often develop their applications on top of OSS platform software. Frequently, this requires making several extensions and modifications to these OSS components. We identify a number of challenges that ISVs face in handling these extensions and modifications. Next, we describe several strategies ISVs can follow in maintaining these modifications. Finally, we suggest an opportunity for a closer collaboration between OSS projects and ISVs which could be mutually beneficial.},
	keywords = {Contributing, Independent Software Vendor},
	issn = {09505849},
	doi = {10.1016/j.infsof.2007.09.001},
	author = {Ven, Kris and Mannaert, Herwig}
}
@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 {996,
	title = {Correlating Social Interactions to Release History during Software Evolution},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {7 - 7},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {In this paper, we propose a method to reason about the nature of software changes by mining and correlating discussion archives. We employ an information retrieval approach to find correlation between source code change history and history of social interactions surrounding these changes. We apply our correlation method on two software systems, LSEdit and Apache Ant. The results of these exploratory case studies demonstrate the evidence of similarity between the content of free-form text emails among developers and the actual modifications in the code. We identify a set of correlation patterns between discussion and changed code vocabularies and discover that some releases referred to as minor should instead fall under the major category. These patterns can be used to give estimations about the type of a change and time needed to implement it.},
	keywords = {ant, apache, change management, developers, discussion, effort estimation, lsedit, mailing lists, scm, source code},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.4},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300007.pdf},
	author = {Baysal, Olga and Malton, Andrew J.}
}
@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 {Gurbani:2006:CSC:1134285.1134352,
	title = {A case study of a corporate open source development model},
	booktitle = {Proceedings of the 28th international conference on Software engineering},
	series = {ICSE {\textquoteright}06},
	year = {2006},
	pages = {472{\textendash}481},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Open source practices and tools have proven to be highly effective for overcoming the many problems of geographically distributed software development. We know relatively little, however, about the range of settings in which they work. In particular, can corporations use the open source development model effectively for software projects inside the corporate domain? Or are these tools and practices incompatible with development environments, management practices, and market-driven schedule and feature decisions typical of a commercial software house? We present a case study of open source software development methodology adopted by a significant commercial software project in the telecommunications domain. We extract a number of lessons learned from the experience, and identify open research questions.},
	keywords = {architecture, case study, open source, session initiation protocol, software development, vkg},
	isbn = {1-59593-375-1},
	doi = {10.1145/1134285.1134352},
	url = {http://doi.acm.org/10.1145/1134285.1134352},
	author = {Gurbani, Vijay K. and Garvert, Anita and Herbsleb, James D.}
}
@conference {Beyer:2006:CVA:1137983.1138023,
	title = {Co-change visualization applied to PostgreSQL and ArgoUML: (MSR challenge report)},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {165{\textendash}166},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Co-change visualization is a method to recover the subsystem structure of a software system from the version history, based on common changes and visual clustering. This paper presents the results of applying the tool CCVisu which implements co-change visualization, to the two open-source software systems PostgreSQL and ArgoUML The input of the method is the co-change graph, which can be easily extracted by CCVisu from a Cvs version repository. The output is a graph layout that places software artifacts that were often commonly changed at close positions, and artifacts that were rarely co-changed at distant positions. This property of the layout is due to the clustering property of the underlying energy model,which evaluates the quality of a produced layout. The layout can be displayed on the screen, or saved to a file in SVG or VRML format.},
	keywords = {argouml, ccvisu, cvs, force-directed graph layout, graph, mining challenge, msr challenge, postgresql, software clustering, software structure analysis, software visualization, version control, visualization},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138023},
	url = {http://doi.acm.org/10.1145/1137983.1138023},
	attachments = {https://flosshub.org/sites/flosshub.org/files/165Co-Change.pdf},
	author = {Beyer, Dirk}
}
@conference {682,
	title = {Collaborative Maintenance in Large Open-Source Projects},
	booktitle = {OSS2006: Open Source Systems (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing},
	year = {2006},
	pages = {233 - 244},
	publisher = {Springer},
	organization = {Springer},
	abstract = {The paper investigates collaborative work among maintainers of open source software by analyzing the logs of a set of 10 large projects. We inquire whether teamwork can be influenced by several characteristics of code. Preliminary results suggest that collaboration among maintainers in most large open-source projects seems to be positively influenced by file vintage and by Halstead volume of files, and negatively by McCabe complexity and size measured in SLOCs. These results could be consistent with an increased attractivity of files created early in the history of a project, and with maintainers being less attracted by more verbose code and by more complex code, although in this last case it might also reflect the fact that more complex files would be de facto more exclusive in terms of maintenance.
},
	keywords = {apache, COLLABORATION, complexity, cvs, gaim, gcc, ghostscript, halstead, lines of code, loc, mccabe, mozilla, netbsd, openssh, postgresql, python, sloc},
	doi = {http://dx.doi.org/10.1007/0-387-34226-5_23},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Collaborative\%20Maintenance.pdf},
	author = {den Besten, Matthijs and Jean-Michel Dalle and Galia, Fabrice}
}
@conference {683,
	title = {Communication Networks in an Open Source Software Project},
	booktitle = {OSS2006: Open Source Systems (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing },
	volume = {203/2006},
	year = {2006},
	month = {2006///},
	pages = {297 - 306},
	publisher = {Springer},
	organization = {Springer},
	abstract = {This study explores the nature of the social network and the patterns of communication that exist in an open source software development project, the Apache HTTP (WEB) server project. Our analysis of archival data on email communications between developers in the Apache HTTP server project suggests an interesting pattern of communication. We find that the core developers self-organize into three sub-groups that communicate intensely in completing the project. Our analysis also reveals that a few prominent developers who are centrally located in the network are driving communications within the project. We identify the implications of our findings and suggest areas for further research.
},
	keywords = {apache, core, developers, email, email archive, mailing list, participation, social network analysis},
	issn = {978-0-387-34225-2},
	doi = {http://dx.doi.org/10.1007/0-387-34226-5_30},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Communication\%20Networks\%20in\%20an\%20Open\%20Source.pdf},
	author = {Roberts, Jeffrey and Il-Horn Hann and Sandra Slaughter}
}
@conference {686,
	title = {Contributor Turnover in Libre Software Projects},
	booktitle = {OSS2006: Open Source Systems (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing},
	year = {2006},
	pages = {273 - 286},
	publisher = {Springer},
	organization = {Springer},
	abstract = {A common problem that management faces in software companies is the high instability of their staff. In libre (free, open source) software projects, the permanence of developers is also an open issue, with the potential of causing problems amplified by the self-organizing nature that most of them exhibit. Hence, human resources in libre software projects are even more difficult to manage: developers are in most cases not bound by a contract and, in addition, there is not a real management structure concerned about this problem. This raises some interesting questions with respect to the composition of development teams in libre software projects, and how they evolve over time. There are projects lead by their original founders (some sort of {\textquotedblleft}code gods{\textquotedblright}), while others are driven by several different developer groups over time (i.e. the project {\textquotedblleft}regenerates{\textquotedblright} itself). 
In this paper, we propose a quantitative methodology, based on the analysis of the activity in the source code management repositories, to study how these processes (developers leaving, developers joining) affect libre software projects. The basis of it is the analysis of the composition of the core group, the group of developers most active in a project, for several time lapses. We will apply this methodology to several large, well-known libre software projects, and show how it can be used to characterize them. In addition, we will discuss the lessons that can be learned, and the validity of our proposal.
},
	keywords = {apache, committers, core, cvs, cvsanaly, developers, evolution, freebsd, gimp, gnome, kde, mono, mozilla},
	doi = {http://dx.doi.org/10.1007/0-387-34226-5_28},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Contributor\%20Turnover\%20in\%20Libre\%20Software\%20Projects.pdf},
	author = {Gregorio Robles and Gonzalez-Barahona, Jesus}
}
@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}
}
@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 {795,
	title = {The challenges of creating open source education software: the Gild experience},
	booktitle = {OSS2005: Open Source Systems },
	year = {2005},
	pages = {338-340},
	keywords = {COMMUNITY, eclipse, learning environment, novice programmers, open source, programming environment},
	url = {http://pascal.case.unibz.it/handle/2038/1539},
	author = {Daniel M. German and Rigby, Peter and Cubranic, Davor and Storey, Margaret-Anne and Thomson, Suzanne}
}
@proceedings {89,
	title = {Coordination of Free/Libre Open Source Software development},
	year = {2005},
	note = {"The data used for the study were interactions on the main developer communication venue, either a developer mailing list or online forum"
sourceforge
},
	address = {Las Vegas, NV, USA},
	abstract = {The apparent success of free/libre open source software (FLOSS) development projects such as Linux, Apache, and many others has raised the question, what lessons from FLOSS development can be transferred to mainstream software development? In this paper, we use coordination theory to analyze coordination mechanisms in FLOSS development and compare our analysis with existing literature on coordination in proprietary software development. We examined developer interaction data from three active and successful FLOSS projects and used content analysis to identify the coordination mechanisms used by the participants. We found that there were similarities between the FLOSS groups and the reported practices of the proprietary project in the coordination mechanisms used to manage task-task dependencies. However, we found clear differences in the coordination mechanisms used to manage task-actor dependencies. While published descriptions of proprietary software development involved an elaborate system to locate the developer who owned the relevant piece of code, we found that {\textquotedblleft}self-assignment{\textquotedblright} was the most common mechanism across three FLOSS projects. This coordination mechanism is consistent with expectations for distributed and largely volunteer teams. We conclude by discussing whether these emergent practices can be usefully transferred to mainstream practice and indicating directions for future research.},
	keywords = {case study, compiere, coordination, egroupware, email, email archives, FLOSS, gaim, mailing list},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CrowstonWeiLiEseryelHowison.pdf},
	author = {Kevin Crowston and Kangning Wei and Li, Qing and Eseryel, U. Yeliz and Howison, James}
}
@proceedings {1191,
	title = {Collaboration, Leadership, Control, and Conflict Negotiation in the Netbeans.org Community},
	year = {2004},
	pages = {48-52},
	abstract = {Large open source software development communities are quickly learning that, to be successful, they must integrate efforts not only among the organizations investing developers within the community and unaffiliated volunteer contributors, but also negotiate relationships with external groups hoping to sway the social and technical direction of the community and its products. Leadership and control sharing across organizations and individuals in and between communities are common sources of conflict. Such conflict often leads to breakdowns in collaboration. This paper seeks to explore the negotiation of these conflicts, collaborative efforts, and leadership and control structures in the Netbeans.org community.},
	keywords = {conflict, leadership, netbeans},
	attachments = {https://flosshub.org/sites/flosshub.org/files/jensen_0.pdf},
	author = {Chris Jensen and Walt Scacchi}
}
@proceedings {1188,
	title = {Communication and Conflict Issues in Collaborative Software Research Projects},
	year = {2004},
	pages = {14-17},
	abstract = {The Open Source Component Artefact Repository (OSCAR) was developed under the auspices of the GENESIS project to store data produced during the software development process. Significant problems were encountered during the course of the project in both the development itself and management of the project. The reasons for and potential solutions to these problems are examined with the intention of developing a set of guidelines to enable participants in other collaborative projects to avoid these pitfalls.
We wish to make it clear that we attach no opprobrium to any of the participants in the GENESIS project as many of the issues we outline below have solutions only visible with hindsight. Instead, we seek to provide a fair-minded critique of our role and the mistakes we made in a fairly typical two-year EU research project, and to provide a set of recommendations for other similar projects, in order that they can (attempt to) avoid suffering similarly.},
	keywords = {artefact, cvs, genesis, oscar},
	attachments = {https://flosshub.org/sites/flosshub.org/files/boldyreff15-18.pdf},
	author = {Boldyreff, Cornelia and Nutter, David and Rank, Stephen}
}
@proceedings {1190,
	title = {Community structure of modules in the Apache project},
	year = {2004},
	pages = {44-48},
	abstract = {The relationships among modules in a software project of a certain size can give us much information about its internal organization and a way to control and monitor development activities and evolution of large libre software projects. In this paper, we show how information available in CVS repositories can be used to study the structure of the modules in a project when they are related by the people working in them, and how techniques taken from the social networks fields can be used to highlight the characteristics of that structure. As a case example, we also show some results of applying this methodology to the Apache project in several points in time. Among other facts, it is shown how the project evolves and is self-structuring, with developer communities of modules corresponding to semantically related families of modules.},
	keywords = {apache, cvs, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/gonzalezBarahona44-48.pdf},
	author = {Jesus M. Gonzalez-Barahona and Luis Lopez and Gregorio Robles}
}
@proceedings {1202,
	title = {Control Objectives in Open Source Projects},
	year = {2004},
	pages = {100-104},
	abstract = {Many studies on Open Source Software Development (OSSD) have been published in the past years. In these studies, OSSD has received positive comments and is proposed as a new way of developing software. We investigate how project management is used in Open Source Software (OSS) projects to exercise control of development activities. Project management in OSSD is worth studying, because research has shown that project management is a critical success factor in traditional software development. We use the COBIT framework to audit project management practices commonly found in OSS projects with the aim of determining which practices are currently missing or can be further improved upon. The framework identifies several potential threats to the long term continuity of OSS projects.},
	keywords = {cobit, project management},
	attachments = {https://flosshub.org/sites/flosshub.org/files/ven101-105.pdf},
	author = {Ven, Kris and Verelst, Jan}
}
@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}
}
@article {146,
	title = {Community, joining, and specialization in open source software innovation: a case study},
	journal = {Research Policy},
	volume = {32},
	number = {7},
	year = {2003},
	note = {first, telephone interviews
"Secondly, we collected the project{\textquoteright}s public email conversations stored in the projects{\textquoteright} 
mailing lists which is archived on Freenet{\textquoteright}s website"
"The third source of data included the history of changes to the software code available 
via the project{\textquoteright}s software repository within the CVS ({\textquoteleft}Concurrent Versioning System{\textquoteright}) source 
code management tool"
"Fourthly, in order obtain contextual understanding of the project we collected publicly 
available documents related to open source in general and to the project in particular. Among 
the most important sources were the Freenet project web pages (e.g. the Frequently Asked 
Questions (FAQ)7), Ian Clarke{\textquoteright}s master thesis (1999), newspaper interviews with the core 
developers, and a technical paper (Clarke, Sandberg, Wiley, \& Hong, 2000) describing the 
Freenet project written by some of the developers."},
	pages = {1217-1241},
	abstract = {This paper develops an inductive theory of the open source software innovation process by focussing on the creation of Freenet, a project aimed at developing a decentralized and anonymous peer-to-peer electronic file sharing network. We are particularly interested in the strategies and processes by which new people join the existing community of software developers, and how they initially contribute code. Analyzing data from multiple sources on the Freenet software development process, we generate the constructs of "joining script", We are grateful to helpful comments from two anonymous reviewers. We also thank Chris Argyris, John Seely Brown, Eric von Hippel, Stefan Haefliger, Petra Kugler, Heike Bruch, Simon Gchter, Simon Peck, and Hari Tsoukas for helpful comments and suggestions. Ben Ho and Craig Lebowitz provided technical assistance with data importation and parsing. We would like to thank Ian Clarke and the Freenet developers for their willingness to participate in our study and providing key insights into the open source development process. Karim R. Lakhani would like to acknowledge the generous support of The Boston Consulting Group and Canada{\textquoteright}s Social Science and Humanities Research Council doctoral fellowship. Georg von Krogh and Sebastian Spaeth acknowledge the generous support from the Research Foundation at the University of St. Gallen.},
	keywords = {cvs, email, email archives, freenet, INNOVATION, mailing lists, roles, source code},
	doi = {http://dx.doi.org/10.1016/S0048-7333(03)00050-7},
	attachments = {https://flosshub.org/sites/flosshub.org/files/krogh03.pdf},
	author = {Georg von Krogh and Spaeth, S. and Karim R Lakhani}
}
@article {flosswp40,
	title = {Cave or Community? An Empirical Examination of 100 Mature Open Source Projects},
	journal = {First Monday},
	volume = {7},
	number = {6},
	year = {2002},
	note = {The author conducts an empirical study of the top 100 mature projects on SourceForge.net to develop an understanding of the F/OSS community. The author sought empirical evidence that would help us understand which is more common- the cave (i.e., lone producer) or the community in F/OSS development. Some key findings include: first, most F/OSS programs are developed by individuals, rather than communities. Second, most OSS programs do not generate a lot of discussion. Third, products with more developers tend to be viewed and downloaded more often. Fourth, the number of developers associated with a project is unrelated to the age of the project.},
	month = {06/2002},
	abstract = {Starting with Eric Raymond{\textquoteright}s groundbreaking work, "The Cathedral and the Bazaar", open-source software (OSS) has commonly been regarded as work produced by a community of developers. Yet, given the nature of software programs, one also hears of developers with no lives that work very hard to achieve great product results. In this paper, I sought empirical evidence that would help us understand which is more common - the cave (i.e., lone producer) or the community. Based on a study of the top 100 mature products on Sourceforge, I find a few surprising things. First, most OSS programs are developed by individuals, rather than communities. The median number of developers in the 100 projects I looked at was 4 and the mode was 1 - numbers much lower than previous numbers reported for highly successful projects! Second, most OSS programs do not generate a lot of discussion. Third, products with more developers tend to be viewed and downloaded more often. Fourth, the number of developers associated with a project was positively correlated to the age of the project. Fifth, the larger the project, the smaller the percent of project administrators.},
	keywords = {age, contributors, developers, project success, registration, sourceforge},
	attachments = {https://flosshub.org/sites/flosshub.org/files/krishnamurthy.pdf},
	author = {Sandeep Krishnamurthy}
}
@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 {Stamelos02codequality,
	title = {Code quality analysis in open source software development},
	journal = {Information Systems Journal},
	volume = {12},
	year = {2002},
	note = {"For our case study, we have used Logiscope{\quotesinglbase} (Telelogic, 2000), a comprehensive set of tools able to perform, automatically, code measurement and comparison with user-defined programming standards"
"Using Logiscope, we examined a sample of 100 C programs found in the SUSE Linux 6.0 release."
metrics collected:
number of statements
cyclomatic complexity
maximum levels
number of paths
unconditional jumps
comment frequency
vocabulary frequency
program length
average size
number of inputs/outputs},
	pages = {43{\textendash}60},
	abstract = {Proponents of open source style software development claim that better software is produced using this model compared with the traditional closed model. However, there is little empirical evidence in support of these claims. In this paper, we present the results of a pilot case study aiming: (a) to understand the implications of structural quality; and (b) to figure out the benefits of structural quality analysis of the code delivered by open source style development. To this end, we have measured quality characteristics of 100 applications written for Linux, using a software measurement tool, and compared the results with the industrial standard that is proposed by the tool. Another target of this case study was to investigate the issue of modularity in open source as this characteristic is being considered crucial by the proponents of open source for this type of software development. We have empirically assessed the relationship between the size of the application components and the delivered quality measured through user satisfaction. We have determined that, up to a certain extent, the average component size of an application is negatively related to the user satisfaction for this application.},
	keywords = {C, Code quality characteristics, functions, linux, metrics, open source development, software measurement, structural code analysis, Suse, user satisfaction},
	author = {Ioannis Stamelos and Lefteris Angelis and Apostolos Oikonomou and Georgios L. Bleris}
}
@article {54,
	title = {Code, Culture and Cash: The Fading Altruism of Open Source Development},
	journal = {First Monday},
	volume = {6},
	number = {12},
	year = {2001},
	note = {"I collected information on the country of residence for key contributors to the two projects. In the case of Linux, I relied on information located in the CREDITS file of all major kernel releases (from version 1.0 to version 2.4.9) [22]. For Gnome, I gathered developer-contact information from the project{\textquoteright}s web-site. Where information on the home-country of developers was not explicitly available, I performed private research to ascertain said information, or - in the last-case scenario - trusted information in the provided e-mail address of developers to infer home-country from domain ownership [23]. In the case of Linux, to avoid bias that might be introduced over time as developers migrated internationally, developers are continually counted as residents of the countries they were associated with when their names first entered the CREDITS file"},
	abstract = {The nexus of open source development appears to have shifted to Europe over the last ten years. This paper explains why this trend undermines cultural arguments about "hacker ethics" and "post-scarcity" gift economies. It suggests that classical economic theory offers a more succinct explanation for the peculiar international distribution of open source development: hacking rises and falls inversely to its opportunity cost. This finding throws doubt on the Schumpeterian assumption that the efficiency of industrial systems can be measured without reference to the social institutions that bind them.},
	keywords = {credits, email address, european, geography, gnome, linux},
	url = {http://131.193.153.231/www/issues/issue6_12/lancashire/index.html},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Lancashire.pdf},
	author = {David Lancashire}
}
@conference {1136,
	title = {Configuration Management for Open Source Software},
	booktitle = {1st Workshop on Open Source Software Engineering at ICSE 2001},
	year = {2001},
	month = {05/2001},
	abstract = {Open Source Software (OSS) projects have a seemingly anarchistic way of organising projects and a set-up (many, distributed developers) that is usually considered difficult to handle within the field of configuration management. Still they manage to produce software that is of at least as high a quality as that produced by Conventional Software Development (CSD) projects.
We have investigated more closely what they actually do, and why they are so successful. The goal of the study was to describe their underlying configuration management process, thereby making it explicit, so it can be followed in case others (like commercial companies) want to start an OSS project or a project having similar characteristics. We also analysed to what extent their success is due to a good process, good tools or simply to outstanding people participating in OSS projects. Based on this, lessons could be learned from OSS and possible transferred to conventional ways of developing software. We interviewed key people from three OSS projects (KDE, Mozilla and Linux) to obtain data for our study.},
	keywords = {configuration management, interviews, project success},
	attachments = {https://flosshub.org/sites/flosshub.org/files/asklundbendix.pdf},
	author = {Asklund, U. and Bendix, L.}
}
@conference {1141,
	title = {Corporate Source: Applying Open Source Concepts to a Corporate Environment},
	booktitle = {1st Workshop on Open Source Software Engineering at ICSE 2001},
	year = {2001},
	keywords = {commercial software, hewlett packard, hp, organizational sponsorship},
	attachments = {https://flosshub.org/sites/flosshub.org/files/dinkelackergarg.pdf},
	author = {Dinkelacker, J. and Garg, P.K.}
}
@conference {1138,
	title = {Creating a Free, Dependable Software Engineering Environment for Building Java Applications},
	booktitle = {1st Workshop on Open Source Software Engineering at ICSE 2001},
	year = {2001},
	abstract = {As open source software engineering becomes more prevalent, employing sound software engineering practices and the tools used to implement these practices becomes more important. This paper examines the current status of free software engineering tools. For each set of tools, we determined the important attributes that would best assist a developer in each stage of the waterfall model. We rated each tool based on predetermined attributes. We used the creation of a graphical user interface based email client in Java to assist in evaluating each tool. Our findings show that there is still a need for free tools to extract UML diagrams, test graphical user interfaces, make configuring Emacs easier, and profile Java applications. In other areas there are free tools that provide satisfactory functionality such as Concurrent Versions System (CVS), GVim, JUnit, JRefactory, GNU Make, Jakarta Ant, Javadoc, and Doc++.},
	keywords = {applications, cvs, Doc++, GNU Make, GVim, Jakarta Ant, java, Javadoc, jrefactory, junit, tools},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bittman.pdf},
	author = {Bittman, M. and Roos, R. and Kapfhammer, G.M.}
}
@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}
}
@conference {Yamauchi:2000:CLM:358916.359004,
	title = {Collaboration with Lean Media: how open-source software succeeds},
	booktitle = {Proceedings of the 2000 ACM conference on Computer supported cooperative work (CSCW)},
	series = {CSCW {\textquoteright}00},
	year = {2000},
	pages = {329{\textendash}338},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Open-source software, usually created by volunteer programmers dispersed worldwide, now competes with that developed by software firms. This achievement is particularly impressive as open-source programmers rarely meet. They rely heavily on electronic media, which preclude the benefits of face-to-face contact that programmers enjoy within firms. In this paper, we describe findings that address this paradox based on observation, interviews and quantitative analyses of two open-source projects. The findings suggest that spontaneous work coordinated afterward is effective, rational organizational culture helps achieve agreement among members and communications media moderately support spontaneous work. These findings can imply a new model of dispersed collaboration.},
	keywords = {cooperative work, cvs, distributed work, electronic media, INNOVATION, open-source, software engineering},
	isbn = {1-58113-222-0},
	doi = {10.1145/358916.359004},
	url = {http://doi.acm.org/10.1145/358916.359004},
	author = {Yamauchi, Yutaka and Yokozawa, Makoto and Shinohara, Takeshi and Ishida, Toru}
}
