%0 Journal Article %J Empirical Softw. Engg. %D 2004 %T Open-Source Change Logs %A Chen, Kai %A Schach, Stephen R. %A Yu, Liguo %A Offutt, Jeff %A Heller, Gillian Z. %K change log %K gcc %K GCC-g %K GNUJSP %K Jikes %K log files %K Open-source software %K source code %X A recent editorial in Empirical Software Engineering suggested that open-source software projects offer a great deal of data that can be used for experimentation. These data not only include source code, but also artifacts such as defect reports and update logs. A common type of update log that experimenters may wish to investigate is the ChangeLog, which lists changes and the reasons for which they were made. ChangeLog files are created to support the development of software rather than for the needs of researchers, so questions need to be asked about the limitations of using them to support research. This paper presents evidence that the ChangeLog files provided at three open-source web sites were incomplete. We examined at least three ChangeLog files for each of three different open-source software products, namely, GNUJSP, GCC-g++, and Jikes. We developed a method for counting changes that ensures that, as far as possible, each individual ChangeLog entry is treated as a single change. For each ChangeLog file, we compared the actual changes in the source code to the entries in the ChangeLog file and discovered significant omissions. For example, using our change-counting method, only 35 of the 93 changes in version 1.11 of Jikes appear in the ChangeLog file—that is, over 62% of the changes were not recorded there. The percentage of omissions we found ranged from 3.7 to 78.6%. These are significant omissions that should be taken into account when using ChangeLog files for research. Before using ChangeLog files as a basis for research into the development and maintenance of open-source software, experimenters should carefully check for omissions and inaccuracies. %B Empirical Softw. Engg. %I Kluwer Academic Publishers %C Hingham, MA, USA %V 9 %P 197–210 %8 September %U http://portal.acm.org/citation.cfm?id=990374.990391 %R 10.1023/B:EMSE.0000027779.70556.d0 %> https://flosshub.org/sites/flosshub.org/files/chen.pdf %0 Journal Article %J First Monday %D 2004 %T Release criteria for the Linux kernel %A Glance, D.G. %K bugs %K change log %K linux %K linux kernel %K log files %K mailing list %K patches %K quality %K release history %X 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. %B First Monday %V 9 %8 2004 %U http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1136/1056 %> https://flosshub.org/sites/flosshub.org/files/Glance.pdf %0 Conference Paper %B Proceedings of the 25th International Conference on Software Engineering %D 2003 %T Toward an understanding of the motivation Open Source Software developers %A Ye, Yunwen %A Kishida, Kouichi %K change log %K COMMUNITY %K contributions %K contributors %K developers %K email %K email archives %K evolution %K gimp %K log files %K mailing list %K roles %K source code %X An Open Source Software (OSS) project is unlikely to be successful unless there is an accompanied community that provides the platform for developers and users to collaborate. Members of such communities are volunteers whose motivation to participate and contribute is of essential importance to the success of OSS projects. In this paper, we aim to create an understanding of what motivates people to participate in OSS communities. We theorize that learning is one of the motivational forces. Our theory is grounded in the learning theory of Legitimate Peripheral Participation, and is supported by analyzing the social structure of OSS communities and the co-evolution between OSS systems and communities. We also discuss practical implications of our theory for creating and maintaining sustainable OSS communities as well as for software engineering research and education. %B Proceedings of the 25th International Conference on Software Engineering %S ICSE '03 %I IEEE Computer Society %C Washington, DC, USA %P 419–429 %@ 0-7695-1877-X %U http://portal.acm.org/citation.cfm?id=776816.776867 %> https://flosshub.org/sites/flosshub.org/files/YeKishida.pdf %0 Conference Paper %B Proceedings of the 2nd ICSE Workshop on Open Source %D 2002 %T Characterizing the OSS process %A Capiluppi, Andrea %A Patricia Lago %A Maurizio Morisio %K bugs %K change log %K classification %K cvs %K downloads %K freshmeat %K metadata %K patches %K popularity %K project success %K release history %K sourceforge %K vitality %X The Open Source model of software development has gained the attention of both the business, the practitioners’ 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? %B Proceedings of the 2nd ICSE Workshop on Open Source %> https://flosshub.org/sites/flosshub.org/files/CapiluppiLagoMorisio.pdf