@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}
}
@conference {zmzkh-icsm-2013,
	title = {How does Context affect the Distribution of Software Maintainability Metrics?},
	booktitle = {Proceedings of the 29th IEEE International Conference on Software Maintainability},
	series = {ICSM {\textquoteright}13},
	year = {2013},
	note = {"FLOSSMole [25] is another data source, from
where we download descriptions (i.e., application domain)
of SourceForge software systems. Furthermore, we download
latest application domain information4
and monthly download
data5 of studied software systems directly from SourceForge."},
	abstract = {Software metrics have many uses, e.g., defect prediction, effort estimation, and benchmarking an organization against peers and industry standards. In all these cases, metrics may depend on the context, such as the programming language. Here we aim to investigate if the distributions of commonly used metrics do, in fact, vary with six context factors: application domain, programming language, age, lifespan, the number of changes, and the number of downloads. For this preliminary study we select 320 nontrivial software systems from SourceForge. These software systems are randomly sampled from nine popular application domains of SourceForge. We calculate 39 metrics commonly used to assess software maintainability for each software system and use Kruskal Wallis test and Mann-Whitney U test to determine if there are significant differences among the distributions with respect to each of the six context factors. We use Cliff{\textquoteright}s delta to measure the magnitude of the differences and find that all six context factors affect the distribution of 20 metrics and the programming language factor affects 35 metrics. We also briefly discuss how each context factor may affect the distribution of metric values.We expect our results to help software benchmarking and other software engineering methods that rely on these commonly used metrics to be tailored to a particular context.},
	keywords = {benchmark, context, contextual factor, flossmole, large scale, metrics, mining software repositories, sampling, software maintainability, sourceforge, static metrics},
	attachments = {https://flosshub.org/sites/flosshub.org/files/icsm2013_contextstudy.pdf},
	author = {Zhang, Feng and Audris Mockus and Ying Zou and Foutse Khomh and Hassan, Ahmed E.}
}
@conference {1317,
	title = {Describing the Software Forge Ecosystem},
	booktitle = {45th Hawai{\textquoteright}i International Conference on System Sciences},
	year = {2012},
	note = {http://flossmole.org/content/everything-you-ever-wanted-know-about-software-forges-code-forges-june-2011},
	month = {01/2012},
	pages = {3416-3425},
	abstract = {Code forges are online software systems that are designed to support teams doing software development work. There have been few if any attempts in the research literature to describe the web of people, projects, and tools that make up the free, libre, and open source (FLOSS) forge ecosystem. The main contributions of this paper are (1) to introduce a classification of FLOSS-oriented forges according to their characteristics; (2) to describe the forge-level and project-level data and artifacts currently available at each FLOSS forge; (3) to show various patterns already discovered in the FLOSS forge ecosystem, such as timelines of creation or arrangements by size or feature; (4) to make some recommendations to forge providers and data collectors about how to expose the structure and information in the forges; and (5) to describe the effort needed to extend our publicly- available information about the FLOSS forge ecosystem into the future.},
	keywords = {features, FLOSS, forge, hosting, metrics},
	attachments = {https://flosshub.org/sites/flosshub.org/files/SquireWilliamsHICSS2012.pdf},
	author = {Squire, Megan and Williams, David}
}
@article {1879,
	title = {Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It},
	year = {2012},
	month = {03/2012},
	institution = {The Linux Foundation},
	abstract = {The kernel which forms the core of the Linux system is the result of one of the largest cooperative software projects ever attempted. Regular 2-3 month releases deliver stable updates to Linux users, each with signi cant new features, added device support, and improved performance. The rate of change in the kernel is high and increasing, with between 8,000 and 12,000 patches going into each recent kernel release. These releases each contain the work of over 1,000 developers representing nearly 200 corporations.
Since 2005, over 7,800 individual developers from almost 800 different companies have contributed to the kernel. The Linux kernel, thus, has become a common resource developed on a massive scale by companies which are  erce competitors in other areas.
This is the fourth update of this document, which has been published roughly annually since 2008. It covers development through the 3.2 release, with an emphasis on the releases (2.6.36 to 3.2) made since the last update. It has been a busy period, with seven kernel releases created, many signi cant changes made, and continual growth of the kernel developer and user community.
},
	keywords = {corporate, corporations, developers, linux kernel, metrics},
	attachments = {https://flosshub.org/sites/flosshub.org/files/lf_kernel_development_2012.pdf},
	author = {Corbet, Jonathan and Greg Kroah-Hartman and Amanda McPherson}
}
@article {1396,
	title = {Studying the impact of social interactions on software quality},
	journal = {Empirical Software Engineering},
	year = {2012},
	note = {bug databases},
	abstract = {Correcting software defects accounts for a significant amount of resources in a software project. To make best use of testing efforts, researchers have studied statistical models to predict in which parts of a software system future defects are likely to occur. By studying the mathematical relations between predictor variables used in these models, researchers can form an increased understanding of the important connections between development activities and software quality. Predictor variables used in past top-performing models are largely based on source code-oriented metrics, such as lines of code or number of changes. However, source code is the end product of numerous interlaced and collaborative activities carried out by developers. Traces of such activities can be found in the various repositories used to manage development efforts. In this paper, we develop statistical models to study the impact of social interactions in a software project on software quality. These models use predictor variables based on social information mined from the issue tracking and version control repositories of two large open-source software projects. The results of our case studies demonstrate the impact of metrics from four different dimensions of social interaction on post-release defects. Our findings show that statistical models based on social information have a similar degree of explanatory power as traditional models. Furthermore, our results demonstrate that social information does not substitute, but rather augments traditional source code-based metrics used in defect prediction models.},
	keywords = {bug tracker, eclipse, Firefox, Human Factors, measurement, metrics, software evolution, Software quality assurance},
	issn = {1573-7616},
	doi = {10.1007/s10664-012-9205-0},
	author = {Bettenburg, Nicolas and Hassan, Ahmed E.}
}
@proceedings {1452,
	title = {Two Evolution Indicators for FOSS Projects},
	volume = {378},
	year = {2012},
	month = {09/2012},
	pages = {216-232},
	publisher = {IFIP AICT},
	abstract = {In this paper we introduce two project evolution indicators. One is showing an increase of downloads of the project and therefore a growing interest of users in the results of the project. The second indica- tor is predicting the future evolution of the project with the submission of new revisions to the concurrent versioning system. Both indicators can provide evidence of the sustainability of a software project. We used the General Linear Model method to statistically formulate the two linear equations that can be used to predict the two indicators. The predicting equations were build by using two stratified data samples one of 760 projects and the second of 880 projects extracted from the SourceForge repository. The six metrics included into the final version of the two models were extracted from a set of thirty project and product metrics as: the number of downloads, the number of developers, etc. We have validated the discriminant and the concurrent validity of the two models by using different statistical tests as the goodness-of-fit and we have used the two models to predict the indicators on two hold-out validation samples. The model predicting the increment of downloads was correct in 75 percent of the cases, the model predicting the submission of new revisions was correct in 93 percent of the cases.},
	keywords = {metrics, sourceforge},
	author = {Petrinja, Etiel and Succi, Giancarlo}
}
@conference {951,
	title = {The evolution of ANT build systems},
	booktitle = {2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)},
	year = {2010},
	pages = {42 - 51},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Build systems are responsible for transforming static source code artifacts into executable software. While build systems play such a crucial role in software development and maintenance, they have been largely ignored by software evolution researchers. With a firm understanding of build system aging processes, project managers could allocate personnel and resources to build system maintenance tasks more effectively, reducing the build maintenance overhead on regular development activities. In this paper, we study the evolution of ANT build systems from two perspectives: (1) a static perspective, where we examine the build system specifications using software metrics adopted from the source code domain; and (2) a dynamic perspective where representative sample build runs are conducted and their output logs are analyzed. Case studies of four open source ANT build systems with a combined history of 152 releases show that not only do ANT build systems evolve, but also that they need to react in an agile manner to changes in the source code.},
	keywords = {ant, argouml, build, eclipse, jboss, maintenance, metrics, source code, tomcat},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463341},
	attachments = {https://flosshub.org/sites/flosshub.org/files/42msr2010_mcintosh.pdf},
	author = {McIntosh, Shane and Adams, Bram and Hassan, Ahmed E.}
}
@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}
}
@conference {SGKL09,
	title = {Evaluating the Quality of Open Source Software},
	booktitle = {Electronic Notes in Theoretical Computer Science},
	volume = {233},
	year = {2008},
	note = {"the software source code and the associated data stored in the version control system, the bug tracking databases, the mailing lists, and the wikis allow us to evaluate quality in a transparent way"
"The data collection system collects the raw data from open source projects"
Mailing lists are measured in: Number of unique subscribers, Number of messages in user/support list per month, Number of messages in developers list per month, Average thread depth},
	month = {03/2009},
	pages = {5{\textendash}28},
	publisher = {The Reengineering Forum},
	organization = {The Reengineering Forum},
	abstract = {Traditionally, research on quality attributes was either kept under wraps within the organization that performed it, or carried out by outsiders using narrow, black-box techniques. The emergence of open source software has changed this picture allowing us to evaluate both software products and the processes that yield them. Thus, the software source code and the associated data stored in the version control system, the bug tracking databases, the mailing lists, and the wikis allow us to evaluate quality in a transparent way. Even better, the large number of (often competing) open source projects makes it possible to contrast the quality of comparable systems serving the same domain. Furthermore, by combining historical source code snapshots with significant events, such as bug discoveries and fixes, we can further dig into the causes and effects of problems. Here we present motivating examples, tools, and techniques that can be used to evaluate the quality of open source (and by extension also proprietary) software. },
	keywords = {bug tracking system, email, email archives, mailing list, metrics, open source, process quality attributes, product quality attributes, source code, SQO-OSS, wiki},
	doi = {10.1016/j.entcs.2009.02.058},
	url = {http://www.dmst.aueb.gr/dds/pubs/conf/2008-SQM-SQOOSS/html/SGKL09.html},
	attachments = {https://flosshub.org/sites/flosshub.org/files/entcs-sqooss.pdf},
	author = {Diomidis Spinellis and Gousios, Georgios and Vassilios Karakoidas and Panagiotis Louridas and Paul J. Adams and Samoladas, Ioannis and Ioannis Stamelos}
}
@conference {1007,
	title = {Analysis of the Linux Kernel Evolution Using Code Clone Coverage},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {22 - 22},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Most studies of the evolution of software systems are based on the comparison of simple software metrics. In this paper, we present our preliminary investigation of the evolution of the Linux kernel using code-clone analysis and the code-clone coverage metrics. We examined 136 versions of the stable Linux kernel using a distributed extension of the code clone detection tool CCFinder. The result is shown as a heat map.},
	keywords = {ccfinder, clone, cloning, kernel, linux, metrics, source code},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.1},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300022.pdf},
	author = {Livieri, Simone and Higo, Yoshiki and Matsushita, Makoto and Inoue, Katsuro}
}
@article {Wang:2007:MEO:1317471.1317479,
	title = {Measuring the evolution of open source software systems with their communities},
	journal = {SIGSOFT Softw. Eng. Notes},
	volume = {32},
	year = {2007},
	note = {"1. M1: The number of modules in software system at a series of specific moment.
2. CD: The number of developers (code contributors) at a series of specific moment.
3. MC: The correlation of M1 and CD."
"We get the information of Modules from the Launchpad[1] which is a distributed collaborative infrastructure for Ubuntu and other open source software development. Ubuntu mainly grows though a manner of adding new packages. So, we treat packages as the modules we mention before. In Ubuntu community, some members are in charge of auditing the packages and add them to Ubuntu, here developers are refers them."},
	month = {November},
	publisher = {ACM},
	address = {New York, NY, USA},
	abstract = {Open Source Software (OSS) has become the subject of much commercial and academic interest in last few years. As traditional software, OSS also evolves to fulfill the need of stakeholders. Therefore, providing quantitative metrics for OSS evolution has also become an urgent issue. However, most existing studies of software evolution have been performed on systems developed within a single company using traditional management techniques. These metrics models are inadequate to measure OSS evolution. In this paper, we describe a preliminary evolution metrics set for evaluating OSS. The most significant novelty of this model is that it takes specific properties of Open Source Community (OSC) into consideration. In another word, we measure the evolution of OSS and OSC together. We also provide a lightweight case study on Ubuntu project using this metrics set. We find out that the Open Source Community and its members also play essential role in OSS evolution. We expect this metrics model can bring better understandings and explanations of phenomena in open source development and evolution.},
	keywords = {evolution, launchpad, metrics, open source community, open source software, Ubuntu},
	issn = {0163-5948},
	doi = {http://doi.acm.org/10.1145/1317471.1317479},
	url = {http://doi.acm.org/10.1145/1317471.1317479},
	author = {Yi Wang and Defeng Guo and Shi, Huihui}
}
@conference {1214,
	title = {A Preliminary Analysis of Publicly Available FLOSS Measurements: Towards Discovering Maintainability Trends},
	booktitle = {2nd Workshop on Public Data about Software Development (WoPDaSD 2007)},
	year = {2007},
	note = {used SourceKibitzer data downloaded from FLOSSmole},
	month = {2007},
	abstract = {The spread of free/libre/open source software (FLOSS) and the openness of its development model offer researchers a valuable source of information regarding software data. The creation of large portals, which host a vast amount of FLOSS projects make it easy to create large datasets with valuable information regarding the FLOSS development process. In addition initiatives such as FLOSSMole provide researchers with a single point and continuing access to those data. Up to now the majority of datasets from FLOSSMole offered data regarding the development process and not the code itself. From February 2007 FLOSSMole offers data donated 
by SourceKibitzer, which contain source code metrics for FLOSS projects written in Java. In this paper we provide 
a premilinary analysis on those data using machine learning techniques, such as classification rules and decision trees. Using the first available data from February 2007, we tried to build rules that can be used in order to estimate the future values of metrics offered for March. Here we present some preliminary results that are encouraging and deserve to be further analyzed in future releases of SourceKibitzer datasets. },
	keywords = {decision tree, flossmole, java, machine learning, metrics, sourcekibitzer},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Samolades2007.pdf},
	author = {Samoladas, Ioannis and Bibi, Stamatia and Ioannis Stamelos and Sowe, Sulayman K. and Deligiannis, Ignatios}
}
@conference {1006,
	title = {Towards a Theoretical Model for Software Growth},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {21 - 21},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Software growth (and more broadly, software evolution) is usually considered in terms of size or complexity of source code. However in different studies, usually different metrics are used, which make it difficult to compare approaches and results. In addition, not all metrics are equally easy to calculate for a given source code, which leads to the question of which one is the easiest to calculate without losing too much information. To address both issues, in this paper present a comprehensive study, based on the analysis of about 700,000 C source code files, calculating several size and complexity metrics for all of them. For this sample, we have found double Pareto statistical distributions for all metrics considered, and a high correlation between any two of them. This would imply that any model addressing software growth should produce this Pareto distributions, and that analysis based on any of the considered metrics should show a similar pattern, provided the sample of files considered is large enough.},
	keywords = {C, complexity, evolution, freebsd, growth, halstead, lines of code, loc, mccabe, metrics, scm, size, sloc, sloccount, source code},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.31},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300021.pdf},
	author = {Herraiz, Israel and Jesus M. Gonzalez-Barahona and Gregorio Robles}
}
@conference {1009,
	title = {Using Software Distributions to Understand the Relationship among Free and Open Source Software Projects},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {24 - 24},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Success in the open source software world has been measured in terms of metrics such as number of downloads, number of commits, number of lines of code, number of participants, etc. These metrics tend to discriminate towards applications that are small and tend to evolve slowly. A problem is, however, how to identify applications in these latter categories that are important. Software distributions specify the dependencies needed to build and to run a given software application. We use this information to create a dependency graph of the applications contained in such a distribution. We explore the characteristics of this graph, and use it to define some metrics to quantify the dependencies (and dependents) of a given software application. We demonstrate that some applications that are invisible to the final user (such as libraries) are widely used by end-user applications. This graph can be used as a proxy to measure success of small, slowly evolving free and open source software.},
	keywords = {dependencies, evolution, fink, metrics},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.32},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300024.pdf},
	author = {Daniel M. German}
}
@conference {Herraiz:2006:CSN:1116163.1116405,
	title = {Comparison Between SLOCs and Number of Files As Size Metrics for Software Evolution Analysis},
	booktitle = {Proceedings of the Conference on Software Maintenance and Reengineering},
	series = {CSMR {\textquoteright}06},
	year = {2006},
	pages = {206{\textendash}213},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Washington, DC, USA},
	keywords = {empirical studies, libre software, metrics, software evolution},
	isbn = {0-7695-2536-9},
	url = {http://dl.acm.org/citation.cfm?id=1116163.1116405},
	author = {Herraiz, Israel and Gregorio Robles and Gonzalez-Barahon, Jes us M.}
}
@conference {Robles:2006:MLS:1137983.1137986,
	title = {Mining large software compilations over time: another perspective of software evolution},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {3{\textendash}9},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {With the success of libre (free, open source) software, a new type of software compilation has become increasingly common. Such compilations, often referred to as {\textquoteright}distributions{\textquoteright}, group hundreds, if not thousands, of software applications and libraries written by independent parties into an integrated system. Software compilations raise a number of questions that have not been targeted so far by software evolution, which usually focuses on the evolution of single applications. Undoubtedly, the challenges that software compilations face differ from those found in single software applications. Nevertheless, it can be assumed that both, the evolution of applications and that of software compilations, have similarities and dependencies.In this sense, we identify a dichotomy, common to that in economics, of software evolution in the small (micro-evolution) and in the large (macro-evolution). The goal of this paper is to study the evolution of a large software compilation, mining the publicly available repository of a well-known Linux distribution, Debian. We will therefore investigate changes related to hundreds of millions of lines of code over seven years. The aspects that will be covered in this paper are size (in terms of number of packages and of number of lines of code), use of programming languages, maintenance of packages and file sizes.},
	keywords = {debian, distributions, evolution, large software collections, lines of code, loc, metrics, mining software repositories, size, sloc, sloccount, software evolution, software integrators},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1137986},
	url = {http://doi.acm.org/10.1145/1137983.1137986},
	attachments = {https://flosshub.org/sites/flosshub.org/files/3miningLarge.pdf},
	author = {Gregorio Robles and Jesus M. Gonzalez-Barahona and Martin Michlmayr and Amor, Juan Jose}
}
@article {102,
	title = {Empirical validation of object-oriented metrics on open source software for fault prediction},
	journal = {IEEE Transactions on Software Engineering},
	volume = {31},
	number = {10},
	year = {2005},
	note = {"This paper describes how we calculated the object-oriented metrics given by Chidamber and Kemerer to illustrate how fault-proneness detection of the source code of the open source Web and e-mail suite called Mozilla can be carried out. We checked the values obtained against the number of bugs found in its bug database - called Bugzilla - using regression and machine learning methods to validate the usefulness of these metrics for fault-proneness prediction. We also compared the metrics of several versions of Mozilla to see how the predicted fault-proneness of the software system changed during its development cycle."
metrics, 
wmc weighted methods per class, 
dit depth of inheritance, 
rfc response for a class,
noc number of children,
cbo coupling between object classes,
cohesion,
lines of code, loc, sloc
chidamber and kemerer metrics},
	pages = {897-910},
	abstract = {Open source software systems are becoming increasingly important these days. Many companies are investing in open source projects and lots of them are also using such software in their own work. But, because open source software is often developed with a different management style than the industrial ones, the quality and reliability of the code needs to be studied. Hence, the characteristics of the source code of these projects need to be measured to obtain more information about it. This paper describes how we calculated the object-oriented metrics given by Chidamber and Kemerer to illustrate how fault-proneness detection of the source code of the open source Web and e-mail suite called Mozilla can be carried out. We checked the values obtained against the number of bugs found in its bug database - called Bugzilla - using regression and machine learning methods to validate the usefulness of these metrics for fault-proneness prediction. We also compared the metrics of several versions of Mozilla to see how the predicted fault-proneness of the software system changed during its development cycle.},
	keywords = {bugs, bugzilla, cbo, defects, dit, fault-prone modules, faults, lcom, lcomn, loc, metrics, mozilla, noc, object-oriented, rfc, source code, wmc},
	url = {http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.8372\&rep=rep1\&type=pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Gyimothy.pdf},
	author = {Gyimothy, T. and Ferenc, R. and Siket, I.}
}
@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}
}
@conference {1163,
	title = {On the Nonmaintainability of Open-Source Software},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	note = {"We downloaded 365 versions of Linux. For each version in turn, we examined the 17 kernel modules and counted the number of lines of code in each module. Then we counted the number of instances of common (global) coupling between each of the kernel modules and all the other modules in that version of Linux. We obtained two primary results."},
	keywords = {Common coupling, coupling, lines of code, linux, linux kernel, loc, metrics},
	attachments = {https://flosshub.org/sites/flosshub.org/files/SchachOffutt.pdf},
	author = {Schach, Stephen R. and Offutt, Jeff}
}
