@proceedings {1715,
	title = {"Should we move to Stack Overflow?" Measuring the utility of social media for developer support},
	year = {2015},
	month = {05/2015},
	pages = {10pp},
	publisher = {IEEE},
	abstract = {Stack Overflow is an enormously popular question-and-answer web site intended for software developers to help each other with programming issues. Some software projects aimed at developers (for example, application programming interfaces, application engines, cloud services, development frameworks, and the like) are closing their self-supported developer discussion forums and mailing lists and instead directing developers to use special-purpose tags on Stack Overflow. The goals of this paper are to document the main reasons given for moving developer support to Stack Overflow, and then to collect and analyze data from a group of software projects that have done this, in order to show whether the expected quality of support was actually achieved. The analysis shows that for all four software projects in this study, two of the desired quality indicators, developer participation and response time, did show improvements on Stack Overflow as compared to mailing lists and forums. However, we also found several projects that moved back from Stack Overflow, despite achieving these desired improvements. The results of this study are applicable to a wide variety of software projects that provide developer support using social media.},
	keywords = {developer support, forums, mailing list, metrics, quality, social media, Stack Overflow, technical support},
	attachments = {https://flosshub.org/sites/flosshub.org/files/SEIP2015stackv2.pdf},
	author = {Squire, Megan}
}
@proceedings {1271,
	title = {Towards a Unified Definition of Open Source Quality},
	year = {2011},
	note = {"In order to answer the research question, how is quality defined in the FLOSS literature, we performed a literature review."

"we searched Google Scholar for journal articles and conference papers containing the terms {\textquotedblleft}open source{\textquotedblright} and {\textquotedblleft}quality{\textquotedblright}"

"This process left us with 24 papers, to which we then added 16 from the quality and defect-fixing categories in [34] that met the above stated criteria.
This left us with 40 papers that defined quality and performed some form of empirical validation of that definition."

"there is little consensus in the FLOSS literature when it comes to defining quality."

defect resolution versus modularity: "Defect resolution rates (amount of defects resolved, speed of resolution) are the best way to measure a community{\textquoteright}s commitment to quality, because they recognize that FLOSS is not a static product, but ever evolving. These rates should be calculated per release, and not cumulatively, because the cycle of FLOSS evolution is the release. Researchers should be careful to only include defects and not new feature requests, duplicates, or poorly reported bugs into their calculations.
Modularity is being touted as the main driver of FLOSS quality success, but it needs to be further defined and studied in order to understand how it works."},
	month = {10/2011},
	pages = {17-33},
	publisher = {Springer},
	abstract = {Software quality needs to be specified and evaluated in order to determine the success of a development project, but this is a challenge with Free/Libre Open Source Software (FLOSS) because of its permanently emergent state. This has not deterred the growth of the assumption that FLOSS is higher quality than traditionally developed software, despite of mixed research results. With this literature review, we found the reason for these mixed results is that that quality is being defined, measured, and evaluated differently. We report the most popular definitions, such as software structure measures, process measures, such as defect fixing, and maturity assessment models. The way researchers have built their samples has also contributed to the mixed results with different project properties being considered and ignored. Because FLOSS projects are evolving, their quality is too, and it must be measured using metrics that take into account its community{\textquoteright}s commitment to quality rather than just its software structure. Challenges exist in defining what constitutes a defect or bug, and the role of modularity in affecting FLOSS quality.},
	keywords = {literature review, measurement, open source, quality, Software},
	author = {Ruiz, Claudia and Robinson, William}
}
@article {10.1109/HICSS.2009.687,
	title = {Easier Said than Done: An Empirical Investigation of Software Design and Quality in Open Source Software Development},
	journal = {2009 42nd Hawaii International Conference on System Sciences (HICSS 2009)},
	year = {2009},
	note = {"projects that do not exhibit obvious corporate or organizational sponsorship or involvement, projects with at least one software release in a relatively mature development stage (Beta or Production/Stable), projects exhibiting a minimum level of project activity, and products written only using Java."
"The frame includes approximately 180 projects from which a random sample of 46 was drawn"
"For each project, we sample each major software release (e.g. 1.x, 2.x) as our unit of analysis for a total of 203 releases."
"We calculate the degree of modularity for each major software release sampled using the source code contained in each release"
"To measure intrinsic software quality, we calculate the number of static bugs and software complexity based on objective evaluations of the source code included in the software release using two static source code analysis tools"
"To assess customer satisfaction, we use three measures of software quality previously identified in OSS research as a proxy for software quality and OSS project success [3]: number of bugs reported, percentage of bugs closed, and time to close bugs."},
	pages = {1-10},
	publisher = {IEEE Computer Society},
	address = {Los Alamitos, CA, USA},
	abstract = {We empirically examine the relationship between software design modularity and software quality in open source software (OSS) development projects. Conventional wisdom suggests that degree of software modularity affects software quality. An analysis of 203 software releases in 46 OSS projects hosted on SourceForge.net lends support for a more complex relationship between software modularity and software quality than conventional wisdom suggests. We find that software modularity is associated with reduced software complexity, an increased number of static software bugs, and a mixed relationship with the percentage of bugs closed. We do not find empirical evidence supporting any relationship between modularity and other measures of customer satisfaction. In addition to empirically testing the relationship between modularity and quality, we introduce new measures of software modularity and software quality. Implications are developed for the theory of modularity and the practice of software development.},
	keywords = {modularity, quality, source code, sourceforge},
	isbn = {978-0-7695-3450-3},
	doi = {http://doi.ieeecomputersociety.org/10.1109/HICSS.2009.687},
	attachments = {https://flosshub.org/sites/flosshub.org/files/09-14-05.pdf},
	author = {Conley, Caryn A. and Lee Sproull}
}
@conference {844,
	title = {A Jury of Your Peers: Quality, Experience and Ownership in Wikipedia},
	booktitle = {The International Symposium on Wiki{\textquoteright}s and Open Collaboration},
	year = {2009},
	month = {10/2009},
	address = {Orlando, FL},
	keywords = {experience,, ownership,, peer, peer,, quality, review,, wikipedia,, wikiwork,},
	author = {Halfaker, A. and Kittur, N. and Kraut, R. and Riedl, J.}
}
@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 {Capiluppi200989,
	title = {Quality Factors and Coding Standards - a Comparison Between Open Source Forges},
	journal = {Electronic Notes in Theoretical Computer Science},
	volume = {233},
	year = {2009},
	note = {Proceedings of the International Workshop on Software Quality and Maintainability (SQM 2008)},
	pages = {89 - 103},
	abstract = {Enforcing adherence to standards in software development in order to produce high quality software artefacts has long been recognised as best practice in traditional software engineering. In a distributed heterogeneous development environment such those found within the Open Source paradigm, coding standards are informally shared and adhered to by communities of loosely coupled developers. Following these standards could potentially lead to higher quality software. This paper reports on the empirical analysis of two major forges where OSS projects are hosted. The first one, the KDE forge, provides a set of guidelines and coding standards in the form of a coding style that developers may conform to when producing the code source artefacts. The second studied forge, SourceForge, imposes no formal coding standards on developers. A sample of projects from these two forges has been analysed to detect whether the SourceForge sample, where no coding standards are reinforced, has a lower quality than the sample from KDE. Results from this analysis form a complex picture; visually, all the selected metrics show a clear divide between the two forges, but from the statistical standpoint, clear distinctions cannot be drawn amongst these quality related measures in the two forge samples.},
	keywords = {artefacts, artifacts, coding standards, coding style, complexity, forge, forges, kde, metrics, quality, source code, sourceforge},
	issn = {1571-0661},
	doi = {DOI: 10.1016/j.entcs.2009.02.063},
	url = {http://www.sciencedirect.com/science/article/B75H1-4VXDKRV-7/2/abcc2be2c4c3998e4bc9b53473ca2d81},
	author = {Capiluppi, Andrea and Boldyreff, Cornelia and Karl Beecher and Paul J. Adams}
}
@article {10.1109/HICSS.2009.1014,
	title = {Using Software Archaeology to Measure Knowledge Loss in Software Projects Due to Developer Turnover},
	journal = {2009 42nd Hawaii International Conference on System Sciences (HICSS 2009)},
	year = {2009},
	pages = {1-10},
	publisher = {IEEE Computer Society},
	address = {Los Alamitos, CA, USA},
	abstract = {Developer turnover can result in a major problem when developing software. When senior developers abandon a software project, they leave a knowledge gap that has to be managed. In addition, new (junior) developers require some time in order to achieve the desired level of productivity. In this paper, we present a methodology to measure the effect of knowledge loss due to developer turnover in software projects. For a given software project, we measure the quantity of code that has been authored by developers that do not belong to the current development team, which we define as orphaned code. Besides, we study how orphaned code is managed by the project. Our methodology is based on the concept of software archaeology, a derivation of software evolution. As case studies we have selected four FLOSS (free, libre, open source software) projects, from purely driven by volunteers to company-supported. The application of our methodology to these case studies will give insight into the turnover that these projects suffer and how they have managed it and shows that this methodology is worth being augmented in future research.},
	keywords = {attrition, case study, developers, evince, evolution, gimp, growth, knowledge collaboration, lines of code, nautilus, quality, sloc, turnover},
	isbn = {978-0-7695-3450-3},
	doi = {http://doi.ieeecomputersociety.org/10.1109/HICSS.2009.1014},
	attachments = {https://flosshub.org/sites/flosshub.org/files/07-07-08.pdf},
	author = {Izquierdo-Cortazar, Daniel and Gregorio Robles and Ortega, Felipe and Jesus M. Gonzalez-Barahona}
}
@article {1100,
	title = {An Empirical Study on the Relationship Between Software Design Quality, Development Effort and Governance in Open Source Projects},
	journal = {IEEE Transactions on Software Engineering},
	volume = {34},
	year = {2008},
	note = {"empirical data from a sample of 75 major OS projects"
no PDF to confirm [ms]},
	month = {11/2008},
	pages = {765 - 782},
	abstract = {The relationship among software design quality, development effort, and governance practices is a traditional research problem. However, the extent to which consolidated results on this relationship remain valid for open source (OS) projects is an open research problem. An emerging body of literature contrasts the view of open source as an alternative to proprietary software and explains that there exists a continuum between closed and open source projects. This paper hypothesizes that as projects approach the OS end of the continuum, governance becomes less formal. In turn a less formal governance is hypothesized to require a higher-quality code as a means to facilitate coordination among developers by making the structure of code explicit and facilitate quality by removing the pressure of deadlines from contributors. However, a less formal governance is also hypothesized to increase development effort due to a more cumbersome coordination overhead. The verification of research hypotheses is based on empirical data from a sample of 75 major OS projects. Empirical evidence supports our hypotheses and suggests that software quality, mainly measured as coupling and inheritance, does not increase development effort, but represents an important managerial variable to implement the more open governance approach that characterizes OS projects which, in turn, increases development effort.},
	keywords = {effort estimation, governance, quality, source code},
	issn = {0098-5589},
	doi = {10.1109/TSE.2008.68},
	author = {Capra, E. and Francalanci, C. and Merlo, F.}
}
@conference {681,
	title = {Call for Quality: Open Source Software Quality Observation},
	booktitle = {OSS2006: Open Source Systems (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing},
	year = {2006},
	pages = {57 - 62},
	publisher = {Springer},
	organization = {Springer},
	abstract = {This paper describes how a Software Quality Observatory works to evaluate and quantify the quality of an Open Source project. Such a quality measurement can be used by organizations intending to deploy an Open Source solution to pick one of the available projects for use. We offer a case description of how the Software Quality Observatory will be applied to the KDE project to document and evaluate its quality practices for outsiders.
},
	keywords = {kde, quality},
	doi = {http://dx.doi.org/10.1007/0-387-34226-5_6},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Call\%20for\%20Quality.pdf},
	author = {de Groot, Adriaan and K{\"u}gler, Sebastian and Adams, Paul and Gousios, Giorgos}
}
@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 {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 {1162,
	title = {Is Open Source Software Development Faster, Better, and Cheaper than Software Engineering?},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	abstract = {In this paper, I draw attention to the question of determining how open source software development may represent a significant alternative to modern software engineering techniques for developing large-scale software systems. OSSD often entails shorter time frames, producing higher quality systems, and incurring lower costs than may be realized through developing systems according SE techniques. Understanding why and how this may arise is the focus of this paper.},
	keywords = {argouml, quality, tigris},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Scacchi_0.pdf},
	author = {Walt Scacchi}
}
