@proceedings {1512, title = {Discovering, Reporting, and Fixing Performance Bugs}, year = {2013}, month = {05/2013}, abstract = {Software performance is critical for how users perceive the quality of software products. Performance bugs---programming errors that cause significant performance degradation---lead to poor user experience and low system throughput. Designing effective techniques to address performance bugs requires a deep understanding of how performance bugs are discovered, reported, and fixed. In this paper, we study how performance bugs are discovered, reported to developers, and fixed by developers, and compare the results with those for non-performance bugs. We study performance and non-performance bugs from three popular code bases: Eclipse JDT, Eclipse SWT, and Mozilla. First, we find little evidence that fixing performance bugs has a higher chance to introduce new functional bugs than fixing non-performance bugs, which implies that developers may not need to be overconcerned about fixing performance bugs. Second, although fixing performance bugs is about as error-prone as fixing nonperformance bugs, fixing performance bugs is more difficult than fixing non-performance bugs, indicating that developers need better tool support for fixing performance bugs and testing performance bug patches. Third, unlike many non-performance bugs, a large percentage of performance bugs are discovered through code reasoning, not through users observing the negative effects of the bugs (e.g., performance degradation) or through profiling. The result suggests that techniques to help developers reason about performance, better test oracles, and better profiling techniques are needed for discovering performance bugs.}, keywords = {bugs, eclipse, mozilla, performance bugs}, author = {Adrian Nistor and Tian Jiang and Tan, Lin} } @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} } @article {Au20099, title = {Virtual organizational learning in open source software development projects}, journal = {Information \& Management}, volume = {46}, number = {1}, year = {2009}, pages = {9 - 15}, abstract = {We studied virtual organizational learning in open source software (OSS) development projects. Specifically, our research focused on learning effects of OSS projects and the factors that affect the learning process. The number and percentage of resolved bugs and bug resolution time of 118 SourceForge.net OSS projects were used to measure the learning effects. Projects were characterized by project type, number and experience of developers, number of bugs, and bug resolution time. Our results provided evidence of virtual organizational learning in OSS development projects and support for several factors as determinants of performance. Team size was a significant predictor, with mid-sized project teams functioning best. Teams of three to seven developers exhibited the highest efficiency over time and teams of eight to 15 produced the lowest mean time for bug resolution. Increasing the percentage of bugs assigned to specific developers or boosting developer participation in other OSS projects also improved performance. Furthermore, project type introduced variability in project team performance.}, keywords = {bug fixing, bugs, learning, Project performance, sourceforge, team size, teams, virtual organization}, issn = {0378-7206}, doi = {DOI: 10.1016/j.im.2008.09.004}, url = {http://www.sciencedirect.com/science/article/B6VD0-4V1D7NT-1/2/a3bbf7652c674f753398160b8f05f6e9}, author = {Yoris A. Au and Darrell Carpenter and Xiaogang Chen and Jan G. Clark} } @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 \& 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} } @article {119, title = {Social network structures in open source software development teams}, journal = {Journal of Database Management}, volume = {18}, number = {2}, year = {2007}, note = {"Three projects were selected from SourceForge.net in terms of their similarities as well as their differences. Monthly data were extracted from the bug tracking systems in order to achieve a longitudinal view of the interaction pattern of each project. Social network analysis was used to generate the indices of social structure." no pdf}, month = {Apr-Jun}, pages = {25-40}, abstract = {Drawing on social network theories and previous studies, this research examines the dynamics of social network structures in open source software (OSS) teams. Three projects were selected from SourceForge.net in terms of their similarities as well as their differences. Monthly data were extracted from the bug tracking systems in order to achieve a longitudinal view of the interaction pattern of each project. Social network analysis was used to generate the indices of social structure. The finding suggests that the interaction pattern of OSS projects evolves from a single hub at the beginning to a corel periphery model as the projects move forward.}, keywords = {bug tracking, bugs, COMMUNITY, INNOVATION, longitudinal study, MODEL, open source, social, social network analysis, social networks, sourceforge, structure}, isbn = {1063-8016}, author = {Long, Y. and Siau, K.} } @conference {WeiBgerber:2006:RLE:1137983.1138011, title = {Are refactorings less error-prone than other changes?}, booktitle = {Proceedings of the 2006 international workshop on Mining software repositories}, series = {MSR {\textquoteright}06}, year = {2006}, pages = {112{\textendash}118}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {Refactorings are program transformations which should preserve the program behavior. Consequently, we expect that during phases when there are mostly refactorings in the change history of a system, only few new bugs are introduced. For our case study we analyzed the version histories of several open source systems and reconstructed the refactorings performed. Furthermore, we obtained bug reports from various sources depending on the system. Based on this data we identify phases when the above hypothesis holds and those when it doesn{\textquoteright}t.}, keywords = {argouml, bug reports, bugs, change history, jedit, junit, re-engineering, refactoring, reverse engineering, software evolution, version control}, isbn = {1-59593-397-2}, doi = {http://doi.acm.org/10.1145/1137983.1138011}, url = {http://doi.acm.org/10.1145/1137983.1138011}, attachments = {https://flosshub.org/sites/flosshub.org/files/112AreRefactorings.pdf}, author = {Wei{\ss}gerber, Peter and Diehl, Stephan} } @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} } @conference {Askari:2006:ITE:1137983.1138013, title = {Information theoretic evaluation of change prediction models for large-scale software}, booktitle = {Proceedings of the 2006 international workshop on Mining software repositories}, series = {MSR {\textquoteright}06}, year = {2006}, pages = {126{\textendash}132}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {In this paper, we analyze the data extracted from several open source software repositories. We observe that the change data follows a Zipf distribution. Based on the extracted data, we then develop three probabilistic models to predict which files will have changes or bugs. The first model is Maximum Likelihood Estimation (MLE), which simply counts the number of events, i.e., changes or bugs, that happen to each file and normalizes the counts to compute a probability distribution. The second model is Reflexive Exponential Decay (RED) in which we postulate that the predictive rate of modification in a file is incremented by any modification to that file and decays exponentially. The third model is called RED-Co-Change. With each modification to a given file, the RED-Co-Change model not only increments its predictive rate, but also increments the rate for other files that are related to the given file through previous co-changes. We then present an information-theoretic approach to evaluate the performance of different prediction models. In this approach, the closeness of model distribution to the actual unknown probability distribution of the system is measured using cross entropy. We evaluate our prediction models empirically using the proposed information-theoretic approach for six large open source systems. Based on this evaluation, we observe that of our three prediction models, the RED-Co-Change model predicts the distribution that is closest to the actual distribution for all the studied systems.}, keywords = {bugs, change analysis, cvs, evaluation approach, file, freebsd, information theory, kde, koffice, log files, netbsd, openbsd, postgresql, prediction, prediction models, scm, source code}, isbn = {1-59593-397-2}, doi = {http://doi.acm.org/10.1145/1137983.1138013}, url = {http://doi.acm.org/10.1145/1137983.1138013}, attachments = {https://flosshub.org/sites/flosshub.org/files/126InformationTheoretic.pdf}, author = {Askari, Mina and Holt, Ric} } @conference {Kim:2006:MPE:1137983.1137995, title = {Micro pattern evolution}, booktitle = {Proceedings of the 2006 international workshop on Mining software repositories}, series = {MSR {\textquoteright}06}, year = {2006}, pages = {40{\textendash}46}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {When analyzing the evolution history of a software project, we wish to develop results that generalize across projects. One approach is to analyze design patterns, permitting characteristics of the evolution to be associated with patterns, instead of source code. Traditional design patterns are generally not amenable to reliable automatic extraction from source code, yet automation is crucial for scalable evolution analysis. Instead, we analyze {\textquotedblleft}micro pattern{\textquotedblright} evolution; patterns whose abstraction level is closer to source code, and designed to be automatically extractable from Java source code or bytecode. We perform micro-pattern evolution analysis on three open source projects, ArgoUML, Columba, and jEdit to identify micro pattern frequencies, common kinds of pattern evolution, and bug-prone patterns. In all analyzed projects, we found that the micro patterns of Java classes do not change often. Common bug- prone pattern evolution kinds are {\textquoteleft}Pool {\textrightarrow} Pool{\textquoteright}, {\textquoteleft}Implementor {\textrightarrow} NONE{\textquoteright}, and {\textquoteleft}Sampler {\textrightarrow} Sampler{\textquoteright}. Among all pattern evolution kinds,{\textquoteleft}Box{\textquoteright},{\textquoteleft}CompoundBox{\textquoteright}, {\textquoteleft}Pool{\textquoteright}, {\textquoteleft}CommonState{\textquoteright}, and {\textquoteleft}Outline{\textquoteright} micro patterns have high bug rates, but they have low frequencies and a small number of changes. The pattern evolution kinds that are bug-prone are somewhat similar across projects. The bug-prone pattern evolution kinds of two different periods of the same project are almost identical.}, keywords = {argouml, bugs, columba, design patterns, evolution, extraction, java, jedit, source code}, isbn = {1-59593-397-2}, doi = {http://doi.acm.org/10.1145/1137983.1137995}, url = {http://doi.acm.org/10.1145/1137983.1137995}, attachments = {https://flosshub.org/sites/flosshub.org/files/40MicroPattern.pdf}, author = {Kim, Sunghun and Pan, Kai and Whitehead,Jr., E. James} } @conference {WeiBgerber:2006:MRA:1137983.1138028, title = {Mining refactorings in ARGOUML}, booktitle = {Proceedings of the 2006 international workshop on Mining software repositories}, series = {MSR {\textquoteright}06}, year = {2006}, note = {"To see if refactorings in ARGOUML have an effect on the occurrence of new bugs and on communication between the developers, we relate the refactorings to bug reports in ISSUEZILLA respectively to mails on the developer mailing list. "}, pages = {175{\textendash}176}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {In this paper we combine the results of our refactoring reconstruc- tion technique with bug, mail and release information to perform process and bug analyses of the ARGOUML CVS archive.}, keywords = {argouml, bug tracking, bugs, cvs, email, evolution, mining challenge, msr challenge, re-engineering, refactoring, release history}, isbn = {1-59593-397-2}, doi = {http://doi.acm.org/10.1145/1137983.1138028}, url = {http://doi.acm.org/10.1145/1137983.1138028}, attachments = {https://flosshub.org/sites/flosshub.org/files/175MiningRefactorings.pdf}, author = {Wei{\ss}gerber, Peter and Diehl, Stephan and G{\"o}rg, Carsten} } @conference {708, title = {Social dynamics of free and open source team communications}, booktitle = {OSS2006: Open Source Systems (IFIP 2.13)}, series = {IFIP International Federation for Information Processing }, volume = {203/2006}, year = {2006}, month = {06/2006}, pages = {319 - 330}, publisher = {Springer}, organization = {Springer}, abstract = {This paper furthers inquiry into the social structure of free and open source software (FLOSS) teams by undertaking social network analysis across time. Contrary to expectations, we confirmed earlier findings of a wide distribution of centralizations even when examining the networks over time. The paper also provides empirical evidence that while change at the center of FLOSS projects is relatively uncommon, participation across the project communities is highly skewed, with many participants appearing for only one period. Surprisingly, large project teams are not more likely to undergo change at their centers. }, keywords = {bug fixing, bug reports, bug tracker, bug tracking, bugs, communications, Dynamic social networks, FLOSS teams, Human Factors, social network analysis, software development, sourceforge}, issn = {978-0-387-34225-2}, doi = {http://dx.doi.org/10.1007/0-387-34226-5_32}, attachments = {https://flosshub.org/sites/flosshub.org/files/Social\%20dynamics\%20of\%20free\%20and\%20open\%20source\%20team.pdf}, author = {Howison, James and Inoue, Keisuke and Kevin Crowston} } @conference {Canfora:2006:BRK:1137983.1138032, title = {Where is bug resolution knowledge stored?}, booktitle = {Proceedings of the 2006 international workshop on Mining software repositories}, series = {MSR {\textquoteright}06}, year = {2006}, pages = {183{\textendash}184}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {ArgoUML uses both CVS and Bugzilla to keep track of bug-fixing activities since 1998. A common practice is to reference source code changes resolving a bug stored in Bugzilla by inserting the id number of the bug in the CVS commit notes. This relationship reveals useful to predict code entities impacted by a new bug report.In this paper we analyze ArgoUML software repositories with a tool, we have implemented, showing what are Bugzilla fields that better predict such impact relationship, that is where knowledge about bug resolution is stored.}, keywords = {argouml, bugs, bugzilla, cvs, impact analysis, mining challenge, mining software repositories, msr challenge, source code}, isbn = {1-59593-397-2}, doi = {http://doi.acm.org/10.1145/1137983.1138032}, url = {http://doi.acm.org/10.1145/1137983.1138032}, attachments = {https://flosshub.org/sites/flosshub.org/files/183WhereIsBug.pdf}, author = {Canfora, Gerardo and Cerulo, Luigi} } @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.} } @conference {Gorg:2005:EDR:1083142.1083148, title = {Error detection by refactoring reconstruction}, booktitle = {Proceedings of the 2005 international workshop on Mining software repositories}, series = {MSR {\textquoteright}05}, year = {2005}, pages = {29-33}, publisher = {ACM}, organization = {ACM}, address = {New York, NY, USA}, abstract = {In many cases it is not sufficient to perform a refactoring only at one location of a software project. For example, refactorings may have to be performed consistently to several classes in the inheritance hierarchy, e.g. subclasses or implementing classes, to preserve equal behavior.In this paper we show how to detect incomplete refactorings - which can cause long standing bugs because some of them do not cause compiler errors - by analyzing software archives. To this end we reconstruct the class inheritance hierarchies, as well as refactorings on the level of methods. Then, we relate these refactorings to the corresponding hierarchy in order to find missing refactorings and thus, errors and inconsistencies that have been introduced in a software project at some point of the history.Finally. we demonstrate our approach by case studies on two open source projects.}, keywords = {bugs, class, inheritance, jedit, refactoring, tomcat}, isbn = {1-59593-123-6}, doi = {http://doi.acm.org/10.1145/1082983.1083148}, url = {http://doi.acm.org/10.1145/1082983.1083148}, attachments = {https://flosshub.org/sites/flosshub.org/files/29ErrorDetection.pdf}, author = {G{\"o}rg, Carsten and Wei{\ss}gerber, Peter} } @conference {1052, title = {Bug driven bug finders}, booktitle = {Proceedings of the 2004 international workshop on Mining software repositories - MSR {\textquoteright}04}, volume = {2004}, year = {2004}, pages = {70 - 74}, publisher = {IEE}, organization = {IEE}, address = {Edinburgh, Scotland, UK}, abstract = {We describe a method of creating tools to find bugs in software that is driven by the analysis of previously fixed bugs. We present a study of bug databases and software repositories that characterize commonly occurring types of bugs. Based on the types of bugs that were commonly reported and fixed in the code, we determine what types of bug finding tools should be developed. We have implemented one static checker, a return value usage checker. Novel features of this checker include the use of information from the software repository to try to improve its false positive rate by identifying patterns that have resulted in previous bug fixes.}, keywords = {apache, bug tracking, bugs}, doi = {10.1049/ic:20040479}, attachments = {https://flosshub.org/sites/flosshub.org/files/70BugDrivenBug.pdf}, author = {Williams, C.C. and Hollingsworth, J.K.} } @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.} } @article {1116, title = {Organizational learning in open-source software projects: an analysis of debugging data}, journal = {IEEE Transactions on Engineering Management}, volume = {50}, year = {2003}, month = {11/2003}, pages = {485 - 493}, abstract = {This paper studies organizational learning effects in open-source programming projects. Working with data from the Apache and Mozilla projects, the study focuses on three aspects of open-source development. The first is the use of the open-source approach as a hedge against system complexity. The second is the adaptive learning mechanisms realized by the debugging process. The last is the learning curve effects of project-specific experience on bug cycle times. The results indicate that while open-source development is subject to positive learning effects, these effects are not universal, with some projects deriving more benefit than others.}, keywords = {apache, bugs, complexity, mozilla}, issn = {0018-9391}, doi = {10.1109/TEM.2003.820136}, author = {Huntley, C.L.} } @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 {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} }