text:
This action might not be possible to undo. Are you sure you want to continue?
Master's Thesis in Informatics TYPICAL DEVELOPMENT PROCESSES OF FREE A N D O P E N S O U R C E S O F T WA R E P R O J E C T S
daniel g . siegel
FA K U LT Ä T F Ü R I N F O R M AT I K Technische Universität München
Master's Thesis in Informatics TYPICAL DEVELOPMENT PROCESSES OF FREE A N D O P E N S O U R C E S O F T WA R E P R O J E C T S
author : supervisor : advisor : date :
daniel g . siegel univ.- prof . dr . peter hubwieser marcus bitzl may 15 th , 2012
I assure the single handed composition of this master's thesis only supported by declared resources. Munich, May 15th , 2012
Daniel G. Siegel
This includes very hierarchical structures with akin roles. Following this catalogue several Free and Open Source Software projects are analyzed in order to identify concertedly models and processes. vivid development communities and consequent support for open standards. Despite these facts. The results corroborate suggestions that especially large and mature Free and Open Source Software projects have established similar structures and processes. iv . there has been little research about the particular similarities or differences in the development processes and structures of Free and Open Source Software projects. To accomplish this. This thesis aims to provide an introduction into the development processes and project management strategies of Free and Open Source Software projects.ABSTRACT Free and Open Source Software is a research subject which has constantly been gaining importance for modern digital life over the past 20 years. a project analysis catalogue is established with which Free and Open Source Software can be analyzed systematically and satisfactorily for the goals of this thesis. The World Wide Web as we know it today would have been impossible without the free availability of source code. similar release cycles and analogical development processes which cannot be resembled with traditional or agile software engineering methods.
. . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . 5 development process analysis 5. . . . . . . . . . . . . v . . 4. . . . . . 5. . . . . . . .3. . . . . . . . . . . . . . . . . .2 Qualitative Content Analysis .3 Visualization of Project Data . . . . . . . . .3 Application in Computer Science . . . . . . . . . . . . . . . . . . . . .2.3 Time Based View . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 3 3 4 5 6 6 8 10 10 11 11 12 13 13 13 13 13 14 14 15 15 16 17 17 18 19 21 21 21 21 24 26 27 28 28 30 2 3 4 methodology 4. .1. . . . . . .2 Motivation . . . . . . . . . . . . .3 Project Age . 4. . . . . . . . . .1 Problem and Motivation . . . related work 3.3 Release Process .4. . . .3 Software Engineering 3. . . . . . . . . . .2 Final Selection . . . . . . . . . . .4. . . . . . . . . . 4. . 5. . 3. 2. .1 Project Structure . . . . . . . . . . . . . . 4. . . . . . . . .1 Grounded Theory . . . . . . . . . . . . . . . . . .1. . . 5.1. . . . . . . .4 Software Engineering Comparison Models . . .1. . .5 Community . . .1 Project Selection . . 5.5 Authors by Month . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . .2 Popularity . . . . . . . .3. . . . . . . . 3.4 Development . 4. .1. .2 Agile Software Engineering Models . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . 2. . .2 Community . . . . . . .1 Traditional Software Engineering Models 2.3 Release Process . . . . . .1 Drupal Project Analysis . . 5. . . . . .2 Outline of the Thesis . . . . .CONTENTS 1 introduction 1. . . . . . . . .1. . . . . .2 Plone Project Analysis . . .2 Commits by Year .1 History . . . . .4 Commits by Month . . . . . . . . . . 2. . . . . . . . . 4. . . . . .1 Commits by Author . .1 Category . . . .1. . . . .1. . . . . .2. . . . . . . . . . . . . .3. . . .4 Activity . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . 1. . . . . . . . 5.1 History . . . . . theoretical background 2. . . . . 2.2 Community . . . 4. . . . . . . . . . . . . .4 Case Studies . 4. . . . . . 5. . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . .2. . . . . . . . . . 5. . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . .5.6 5. 5. . . .8 Development . . . . . . . . .7 Development . . .8. . . 5. . . . . . . . . . . .4. 5. . . . . PHP Project Analysis . . . . . 5. . . . . . 5. . . . .4. . 5. . 5. . . .8. . . . . . . . . . . . . . . . .4 License . . .9 5. . . . . . 5. . . . . . . . . .2 Community . . 5.3 Release Process . . . . . . . . . .4 Development . . . . .4 History . . .4. .4 History . . . . . . . . . . . . .1 Project Category . . . 5. .4 Development . . . . . . . . .6. . . . 5. . . .4 Development . . . . . . 31 34 34 34 37 38 41 41 42 44 45 47 48 49 51 54 54 55 55 57 61 62 62 62 62 62 62 63 63 64 65 65 65 65 65 65 66 67 68 68 68 69 69 69 70 71 . .6. . . . . . . . . . .1 History . . . . . .8. . . 5. . . . . . 5.3 5. . . . . 5. .8. . . . . . . . .9. . . . .3.7. . . . . . . . . . . . . . . . . . . . . . . .contents vi 5. . . . . .7 Development . . . . . . .6 Release Process .2 Scope of Analysis . . . . . .6 Release Process . . . . . . .3 License . . . . . . . .7. . . . . . .1 Description of the Project . . .7. . . . . . . . . . . . . . . . .5. . . . .7. 5. . PostgreSQL Project Analysis . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . 5. . . . . . . . . . . . 5. . . .2 Community . . . . . . . . . . . . . .7 5.6. 5. . . . . . . . . . . . . . . . . .4 Development .2 Community . . . . . . . . . . . . . . . . . . . 5. . . . . . .6. . . . . .7. . . .5 History . . .9. . . . . . . . . .9.1 Project Category . . . . . . . . . . . . .2 Community . . . . . . .5 5. . . . . . MySQL/MariaDB Project Analysis . . . . .1 History . . . 5. . . . . . . . . . . . . . . . . . . . . .3 Release Process . . . .2. . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . 5. . . . . . . 5. . . . . . . . . . . . . . . . . . . . . Python Project Analysis . . .9. . . 5. . .3 Scope of Analysis . . . . . 5. . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . .4. . . . . . . Proposition for a Project Analysis Catalogue 5. . . . . 5. . . . . . . 5. . . . . . . . 5. . . . . . . . . . . . . . . 5. . . .5 Community . . . .3. . . . . . . .3 Release Process . . . 5. . . . . . . . . . . 5.8 5. . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . . . . GNOME Project Analysis . . . .1 History . .1 History . . .2 Project Category .7. . . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . .4 Development . . . . . . . .9. . . . . . . .9. . . . . . . .7 Release Process . . . .7. . . . . . . . . . . . .3 License . . . .3.9. . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . 5. . . . . . . . . 5. . . . . . . . . .5 Community . . . .2 Scope of Analysis . . . . . . . . . . . KDE Project Analysis . . . . .4 5. .6 Community . .3 Release Process . .7. . . 5. . . . . . 5. . . . . . . .
. . . . .3 License .10. . . . . .7 Development . . 6. . 6. . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . 6. . . . . . .2 Release Schedule . .2. . . . . . . . . . . . . . . . . . . . .1 Project Category 5. . . .3.10 Fedora Project Analysis 5. . . . . .3 Release Process . . . . . . . . .3 Feature Inclusion Process . . . . . . . . . .10. . . . . . . . . . . . . . . . . .1 Project Category 5. .2 Community . . . . . . . .11. . . . .4. . .11 Debian Project Analysis 5. . . .1 Versioning Scheme . . . . . . . .2. . . . . . . . 6. . . . . . . . . . . . . . . . . 6. . . 5. . . . . . . .1 Project Origin . . .11. . . . . . . . . . . . 6. . . . . . . . . .10. . . .3 License .4 History . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . .2 Community . . . . . . . . . . . . . 7 8 bibliography Appendix a comparison of project graphs b project resources 111 b. . . . . .4. . .5 Community . . . . . . . . . . . . . . . . 5. . . . . . . . 5. . . . . 6 . . . . . . . . . . . 72 72 72 72 72 73 74 74 75 75 75 75 76 76 77 77 79 79 80 80 81 82 82 84 85 85 86 89 89 90 90 93 93 93 95 95 97 100 105 106 comparison of development processes 6. . . . . . . . . . 6. . . . . . . . . . . . . .3 Release Process 7. . . . . . . 5. . . . . 7. . . . . . . . . . . .2 Scope of Analysis 5. conclusion . . . . . . 7. . . . . . . . . . . . . . . . . 5.10. . . . . .11. . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . .2 Communication . . . . . . . . .2 Development Workflow . . . . . . . . . . . . . . .1 Drupal . . . .5 Community . .11. . . . . . .1 Development Lead . . . . . . . . . . 5. . . . . . . . . . . . 6. . . .3 Conferences . . . . . .4. . . . . . . . . . . . 5. . . . . . . . . 111 b. . .7 Development . . . . . . . . . . . . . . . .4 Development . . . . . . . . . discussion 7. .10. . . . . . . . . . . . . .4 Roles . . . . . . . . . . . . . . . . .contents vii 5. . . . . . . . 5. . . . . . . . 5. . . . . . . . . .4 Development . . . . . . . . . . . . . . . . . . . . . .11. . . . . . .4 History . . . . . . . . . . .11. . . . .2 Plone . . . . . . . . . . . . . . . . . . .1 Project Origin . . . . 6. . . 6. . . . . . . . . . . . . . . . . . . . . . . . .2. . .2. .6 Release Process . . . . . . . . . . . . . . 111 . . . . . . . .5 Project Founders . . . . . . .1 Community Size . . . . . . . . . . . . . .6 Release Process . .3. . . . . . . . . . . . . . . . . . . . .10.10. . . 6. . . . . . . . . . . . . . . . . . . . . . . . .11.2 Scope of Analysis 5. . . . . . .
. . . . . . .contents viii b. . . . . PHP . . . . . . . . GNOME . . .8 b. . . . . . . . . . . . . . . .5 b. KDE . . . . . . . .3 b. . . . . . . . . . . . . . . MySQL/MariaDB Fedora . . . . . . . . . . . . . . . . . 112 113 114 115 115 116 117 118 . . . . . . . . . . . . PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 b. . . . .7 b. . . . . . . . . . . . . . . . . . . . Debian . . . . .9 b. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 b. . . . . . . . . . . . .10 Python . . . . . .
Spiral Model . . The Time Based View Graph . . . Major Releases of PHP . . . . . . . . . . . . . . . . .14 Figure 5.24 Figure 5. Python . .2 Figure 5. . . . . . .15 Figure 5. . . . . . . . . Plone . . . . . .23 Figure 5. . . . Status Paths of Plone Improvement Proposals . . . . . . Drupal . . Drupal . . . . . . . . . . . Authors by Month. . . . . . . PHP . . Major Releases of Drupal . . .8 Figure 5. . The Authors by Month Graph . . The Commits by Month Graph . . . . . . Drupal . . . . . . . . . .10 Figure 5. Plone . . Python . . . PHP . . . . . PHP . . . . . .18 Figure 5. . Drupal . .LIST OF FIGURES Figure 2. .17 Figure 5. . Plone . . . . . . . .3 Figure 2. . . .2 Figure 4. . Plone . . . . . . . . . . Drupal Release Process Phases . Commits by Month. .5 Figure 5. . . . . . . . . . . . . Time Based View on Commits. . . Commits by Year. . . . . . Extreme Programming Model . . . . . . . Time Based View on Commits. . Major Releases of Python . . . Scrum Model . . .12 Figure 5. . . . . Commits by Most Active Authors. . . . . . .3 Figure 4. . Inductive Qualitative Content Analysis Process Original Waterfall Model .19 Figure 5. . . . . . . . . . . . Commits by Year. . . . . . . Python .4 Figure 2. . . . . . . . . . PHP . . . . . The Commits by Year Graph . . . . Commits by Month. . Time Based View on Commits. . . . . . . . . . . . . . . . . . . Commits by Year. . . . . . . .1 Figure 2. . 3 4 6 7 8 8 16 17 17 18 19 22 24 24 25 25 26 27 29 30 30 31 32 32 33 35 36 36 37 37 38 39 40 42 43 43 44 44 45 46 47 ix . . .28 Figure 5. . . . . . . . .21 Figure 5.2 Figure 2. . . Status Paths of PHP Request for Comments . . . . . . . . Commits by Year. . . .3 Figure 5. .7 Figure 5. . . . . . . . . . . .30 Grounded Theory Process . . . . . . . Major Releases of Plone . Python . . . . . . . . .5 Figure 2. . . . . . . .20 Figure 5. . . . Commits by Month. Commits by Most Active Authors. . . . . . Excerpt from Python Enhancement Proposal 8 Authors by Month. . Drupal .1 Figure 4. Authors by Month. . . .22 Figure 5. . . . .25 Figure 5. .1 Figure 5. . Time Based View on Commits. . . . . . .27 Figure 5. . . Preliminary PHP Release Cycle . .29 Figure 5. . .16 Figure 5. . . . . Python . . . . . . . . . .6 Figure 5. The Commits by Author Graph . .6 Figure 4. . Commits by Month. . Authors by Month. . . . Commits by Most Active Authors. . .4 Figure 5. PHP .11 Figure 5. Plone . . Status Paths of Python Enhancement Proposals Commits by Most Active Authors. . . . .26 Figure 5. .4 Figure 4.9 Figure 5. . . . . . . .13 Figure 5.5 Figure 5. . . . . . .
.3 Figure 7. Authors by Month. .3 List of Analyzed Free and Open Source Software Projects . GNOME . . . . . KDE . . .2 Figure A. . Overview of Commits by Year Graphs . . . . .1 Figure 7. . . .38 Figure 5. . . . . . KDE . . GNOME . . Commits by Most Active Authors. . . . . . Previous and Planned Drupal Conferences . . Representation of Development Cycles . . .31 Figure 5. Versioning Schemes in the Analyzed Projects . . Used Licenses in the Analyzed Projects . . . . . . . . . . . . . . . . . . . . . . Overview of Commits by Author Graphs . . Project Founders and Origins . Major Releases of KDE . Authors by Month. . .Figure 5. . . . . . Representation of Feature Inclusion Processes Free and Open Source Software Project Development Structure . . . . .3 Table 6. Commits by Year.34 Figure 5. . . . . GNOME . . . . . . . . .36 Figure 5.1 Figure 6. 15 23 49 56 79 80 86 x . . . . . . . . . . . .41 Figure 5. . . . .5 Commits by Most Active Authors. . . . . . . Commits by Month. . 48 50 51 51 52 52 53 57 58 58 59 60 60 83 88 91 94 96 106 107 108 109 110 L I S T O F TA B L E S Table 4. Overview of Time Based View Graphs . . . . . . Overview of Authors by Month Graphs . . .37 Figure 5. . . .32 Figure 5. . GNOME . . . Life Cycle Model of Free and Open Source Software Projects . .35 Figure 5. . . . .2 Table 5. . . . . . . . Previous and Planned GNOME Conferences . . . . . . . . . . . . . Previous and Planned KDE Conferences . . GNOME 3. . .4 Release Schedule .2 Figure 6. . . . GNOME . .1 Table 6. . . .33 Figure 5. .3 Figure A.2 Table 6. . . KDE . . . . . Time Based View on Commits.1 Table 5. . .42 Figure 5. . . .2 Figure A. .39 Figure 5. . . . . . . . . . . . . Commits by Year. . .40 Figure 5. KDE . . . . . . Comparison of Development Related Roles . . . . . . Commits by Month. . .1 Figure A.1 Table 5. . Major Releases of GNOME . Overview of Commits by Month Graphs . . . Time Based View on Commits. . .4 Figure A. . . . . . . . KDE .43 Figure 6. . . .
ACRONYMS ABI API BDFL CDE CMF CMS DFSG FESCo FOSS GNU GNU GPL GNU LGPL GTK IRC KDE SC ORDBMS PEP PLIP QPL RFC SIG SQL UI UTC XP Application Binary Interface Application Programming Interface Benevolent Dictator For Life Common Desktop Environment Content Management Framework Content Management System Debian Free Software Guidelines Fedora Engineering Steering Committee Free and Open Source Software GNU's Not Unix GNU General Public License GNU Lesser General Public License GIMP Tool Kit Internet Relay Chat KDE Software Compilation Object-Relational Database Management System Python Enhancement Proposal Plone Improvement Proposal Q Public License Request for Comments Special Interest Group Structured Query Language User Interface Coordinated Universal Time Extreme Programming xi .
Concretely. which structures do they have and which workflows have they established. When comparing them at first glance they indeed look quite different.1 problem and motivation Without Free and Open Source Software (FOSS) the modern digital life would be different. 1 . running on most of the servers. the communities and the goals of each project. different development models have evolved. summarizing the findings and trying to establish a common ground. A matching example is the company Google which used the Linux operating system to build big data centers cost-effectively. Lowdown such as the costs. used tools or the project structure. the social structure inside a project. the free availability of the source code and the number of people who work on a single project are certainly positive aspects of FOSS projects. Red Hat or Facebook. On account of the different origins and backgrounds of the single projects. In addition they will be compared to traditional software engineering models in order to see whether they are similar or oppose differences. They allow to use them without big investments and risks to implement an idea quickly and effectively. To accomplish this. development and release cycles. However FOSS projects do not only have an important role in the modern software ecosystem.INTRODUCTION 1 1. there is also an active development community behind them which consists of volunteers but also companies. too diverse seem the different project leaders. This thesis aims to provide a primary step into this direction. which seem inimitable. Examples are the different communities. That is just one of the many reasons why FOSS has become quite popular especially in the last years. They also are key figures in the internet. Amazon. There exist however many studies about single aspects of projects. Unfortunately there are not too many scrutinies which aim for similarities or differences in the development processes of FOSS projects. but also on smartphones or other devices. this study tries to answer the following research question: How do FOSS projects work. development workflows or software engineering methods. such as the motivation of developers. the communication. FOSS projects empower Fortune 500 companies such as Google. several FOSS will be analyzed in order to identify concertedly models. The question here is now whether projects have common grounds or use so called best practices.
the development processes. This analysis will be the center piece on which further chapters build on. chapter 5 – development process analysis A deeper look is made at several FOSS projects. chapter 6 – comparison of development processes This chapter examines the previous made analysis and compares the findings by working through the established catalogue and analyses. This includes a general explanation of methods and the presentation of collected data. chapter 4 – methodology The used methodology and explanations of visualized project data will be provided in this chapter. chapter 8 – conclusion The thesis finally concludes with a summary and draws together the main findings of the study along with possible future directions.2 outline of the thesis 2 1. case studies and software engineering methods are presented with appropriate references. analyzed and compared with traditional software engineering methods. chapter 3 – related work An outline of related researches in the field of FOSS. related findings by other researchers and previously explained methods. Additionally traditional and agile software engineering methods will be discussed.2 outline of the thesis chapter 1 – introduction This chapter presents an overview of the thesis and introduces the reader to the problem and motivation of this analysis. chapter 7 – discussion The findings will be evaluated. several research methods and tools will be introduced in this chapter. .1. coming up with an analysis catalogue and applying that on further projects. chapter 2 – theoretical background In order to empower a scientific research for the project analysis.
a series of scientific research methodologies were used. The Grounded Theory approach is a systematic research methodology first published by Glaser and Strauss [GS67] in 1967. This chapter gives an introduction to these methods and tries to vindicate their usage. 2. It always starts with the collection of data on the researched subject. It first was applied in social sciences gathering data and discovering a theory after an analysis of the rallied data.1: Process of theory building using the Grounded Theory as research method according to Strauss and Corbin [Pan96].1 grounded theory Theoretical Sampling Data Collection Data Ordering Data Analysis Theory Development Theory Saturation Saturated Research Closure Figure 2.THEORETICAL BACKGROUND 2 In order to analyze and compare development workflows. Grounded Theory is mostly used in qualitative research and operates quite different from traditional research methods. Thereafter the collected items are marked with 3 Not Saturated .
2.2 qualitative content analysis 4 codes which later can be grouped into different categories. The second approach was described by Strauss and Corbin [SC90] in 1990. The most important difference seems to be the technique used to code the samples into categories. a Grounded Theory approach was reviewed as a good scientific research method to gather all the required data and use it as a base research method. Glaser favors a systematical and well defined approach for the coding process while Strauss prefers a more dynamic approach coding the elements as soon as they become visible. This has lead to different appendages. Both methods have their benefits and downsides. Due to the quite dynamic development approach and nescience about the different development processes.2 qualitative content analysis Research Question Determination of Category Definition and Levels of Abstraction Step by Step Formulation and Subsumption of Inductive Categories Revision of Categories Formative Check of Reliability Final Working through the Content Summative Check of Reliability Interpretation of Results Figure 2. They are the base of an emerging theory which can be established out of the gathered data and its analysis. .2: Step model of inductive category development in Qualitative Content Analysis according to Mayring [May00. However Glaser and Strauss have established different opinions on the Grounded Theory approach [Hea04]. 2. however in this analysis the Strauss and Corbin approach was chosen as a better fitting research method. May83]. which either favor the Glaser or the Strauss understanding on the application of the Grounded Theory.
The establishment of categories can be done either in an inductive or deductive way. Those categories can then be revised and checked if they are valid categories for the analysis. Similarly Meerbaum-Salant.3 application in computer science 5 Another quite useful research method is the Qualitative Content Analysis first published by Mayring [May83]. Hazzan et al. Armoni and Ben-Ari [MSABA10] explore different ways on how to learn computer science concepts with qualitative analysis methods. Following this analysis further. The following list stands for an array of examples from different areas of the computer science research field. As such they are especially useful in areas like software engineering.2. This is also known as feedback loops. However they also have their right of existence in computer science as they provide excellent research methods and tools to examine existing phenomena and domains besides others. Porter and . This defines what aspects will be taken into account during the analysis. The Grounded Theory is used by Perry. possible categories may appear. It also considers ways to carefully check and review the established categories. especially for comparing different development models. This leads to a framework one can use to provide an empirical. 2. Furthermore they can be split up or be set as subcategories of previously found categories. computer science education or computer science research methods.3 application in computer science Qualitative research methods such as the above have their origin in social sciences. For this analysis it makes sense to use an inductive category development. The main idea is to apply methods of Qualitative Content Analysis to the research question and transfer them to a step by step interpretation which can be used for quantitative content analysis [May00]. It is related to the previous mentioned Grounded Theory however differs from its theoretical approach. yet methodologically controlled analysis which follows a previously established content analysis canon. This step will be iterated through the research data until a final interpretation and analysis can be established. The centerpiece of this method is the finding and establishment of categories in which the analyzed data can be inserted. The described Qualitative Content Analysis approach supplements the Grounded Theory in a quite useful way. Armstrong [Arm06] uses qualitative research methods to discuss the usage of object oriented programming vocabulary in different papers and books. [Haz+06] for example discuss the use and plausibility of qualitative research methods in computer science education. since the research method begins with the research question and the ensuing determination of category definition.
in computer science.2.4 software engineering comparison models 6 Votta [PPV00] to outline the strengths and weaknesses of empirical research in software engineering. Requirements Analysis Design Implementation Verification Operations Figure 2. especially the Grounded Theory. . that qualitative analysis might not fit every research matter and is often better suited for meta or process analysis. The in the following described Waterfall and Spiral model will stand as an example and be used for the comparison later on.1 Traditional Software Engineering Models Many different traditional software engineering models exist in the software engineering research field. This collective research effort shows the growing interest in using qualitative research methods. For a later comparison the most renowned and appositely models will be presented in the following. It is also used by Sarker.4. 2.4 software engineering comparison models Research in software engineering has brought up many different software engineering models which are suitable for different types of environments. Lau and Sahay [SLS01] for building and developing a process model of collaboration in virtual teams. Kaplan and Maxwell [KM94] use qualitative research methods for evaluating computer information systems. Cunningham and Downie [BCD03] use the Grounded Theory to analyze music queries.3: The original Waterfall software engineering model with its implementation steps according to Royce [Roy70]. 2. However it shall be noted. Finally also Bainbridge.
Program Design. As the name suggest it is devised as a Spiral including steps such as risk management. Furthermore several modified Waterfall models exist. Coding. It then proceeds to risk management. Basili and Turner [BT75] wrote the first description of iterative enhancements inside a software engineering life cycle. Verify Next-Level Product Figure 2. Analysis. The Spiral model has also been described as an evolutionary or iterative development model. Determine Objectives. It therefore combines the systematic approach of the Waterfall model with an evolutionary development approach which allows to incrementally enhance the product.4 software engineering comparison models 7 The first formal description of the Waterfall model was published by Royce [Roy70] in 1970. Alternatives. It is interesting to note that Royce did not use the term Waterfall to describe his model. . Constraints Evaluate Alternatives. However it is still very popular and became widely known within the software engineering field. Resolve Risks Prototype 3 Prototype 2 Prototype 1 Concept Requirements Improvement Design Plan Next Phase Develop. planning or determination of objectives. The original sequential phases are from top to bottom System Requirements. Identify. which change the single sequences and domains. Boehm [Boe88] created the Spiral model as a response to the Waterfall model. A typical cycle of the Spiral always starts with the specification of goals and constraints of the upcoming cycle.4: The Spiral software engineering model with its typical four step approach according to Boehm [Boe88].2. The model follows a sequential process from top to bottom which is the reason of its name. In 1988. He described it as a model which is not appropriate for software engineering. Testing and Operations. Software Requirements. which tries to identify risks or to provide alternatives.
that existing teams can adapt to [Bec99]. Test Scenarios User Stories Requirements Architectural Spike New User Story Release Planning Uncertain Estimates Spike Confident Estimates Iteration Bugs Acceptance Tests Small Releases Figure 2. flat management. not until 1995 the Scrum development model was presented formally by Sutherland [Sut95] . 2. awareness of user requirement changes and frequent communication with the customer. Lastly the next cycle is planned. The Extreme Programming and Scrum development models stand as an example for this area.2 Agile Software Engineering Models Agile software engineering models base. It has to be noted. The main differences to existing models are frequent releases and generally short development cycles. on incremental and iterative development which are known to be quick and flexible to new requirements or changes [Bec99]. However. It also includes other paradigms such as unit tests. simplicity. Beck set his goal to improve existing software engineering models by improving the overall software quality of a product and the responsiveness of changes required by customers or other incorporated parties. but as a process. that Beck does not promote Extreme Programming as a finished concept.2. The Scrum software engineering model was first referred by DeGrace and Stahl [DS90] in 1990.6: The Scrum software engineering model shown as methodology according to Schwaber [Sch95]. in comparison to traditional software engineering models. Develop Wrap Planning & System Architecture Sprints Closure Adjust Review Figure 2. Extreme Programming (XP) is a software development model first published by Beck [BA99] in 1999.4.5: The Extreme Programming software engineering model according to Beck and Andres [BA99].4 software engineering comparison models 8 The defined goals are developed and tested as a next step.
These sprints are planned before they are executed and represent one development cycle in which parts of the project will be developed. The basic idea behind Scrum are so called sprints.2. They usually last between a week and one month. represent the customer and the development team. Another important part of the model is the backlog that keeps track of which features are to be done in which priority. These tools ensure the frugalness of new requirements by customers or other constraints. Like the Extreme Programming development model it is an incremental and iterative approach. . The Scrum development process usually contains three major roles which ensure the process model is followed.4 software engineering comparison models 9 and Schwaber [Sch95].
3. The Cathedral model which is planned and developed by a small group of architects and the Bazaar model in which the project gets developed in a more chaotic way by a number of developers with no real leader. [Oga+07] visualized the communication in several established FOSS projects and came to the conclusion that a small group of people were active in most of the discussion about development or future plans. many different findings exist in this domain. However the project age seemed to correlate with the 10 . Kim [Kim03] takes a more general approach and tries to describe the FOSS landscape as a whole. Ogawa et al. The research by Capiluppi and Michlmayr [CM07] draws on "The Cathedral and the Bazaar" and the authors suggest that the Cathedral and Bazaar model are not mutually exclusive. In a case study including 100 mature projects the finding was that most projects were indeed lead by small groups of people. The conclusion is that in most FOSS projects the development is actually led by a small group or single developers which dissents a Bazaar like model. The most relevant to this analysis will be presented in this chapter. the demographics of developers and the structure of FOSS projects. much more they offer the assertion that especially bigger FOSS projects go through both models starting with a Cathedral like development model and then when becoming larger adopting the Bazaar model.R E L AT E D W O R K 3 Although FOSS is a quite new research subject. Godfrey and Tu [GT00] on the other hand try to compare FOSS development processes with industrial and traditional management techniques. It is an essay. based on the author's observation which contrasts two software engineering models found in FOSS development. Also Krishnamurthy [Kri02] makes a strong case for a different development model. Additionally they claim that especially big FOSS projects have the ability to still grow at least linearly. Furthermore a Bazaar like discussion was often not happening at all.1 project structure Certainly one of the most relevant and most known studies of FOSS development processes is "The Cathedral and the Bazaar" by Raymond [Ray98]. Interesting however is the open approach on information sharing and easily accessible collaboration.
3 software engineering A descriptive analysis of FOSS development is offered by Roets. A similar study which is limited to the Debian project was conducted by Sadowski. They claim that most people do offer support because it returns direct learning benefits. They have come to the conclusion that there are similarities but also considerable distinctions. Minnaar and Wright [RMW07].2 motivation 11 number of developers. Finally however the research paper by Conway [Con68] contains an insight that the organization of a software system is similar to the group which designed and implemented the system. They consider external motivational factors as implausible and propose enjoyment-based intrinsic motivation as the main motivation for professionals but also for volunteers. connected structure to a flat non-connected structure. The findings were similar.3. They suggest however that both methods can learn from an- . Lakhani and Hippel [LH02] for example examined why people do provide free support to other developers or users. They suggest however that bigger projects tend to decentralize structures and projects do vary quite drastically in terms of communication structure. Lakhani and Wolf [LW03] implemented a web based survey analyzing the answers of over 600 developers and over 287 projects. A similar study. Yet they derive a software development cycle based on different established software engineering processes. Also Grazzini [Gra09] questioned why developers would work for free and came to the conclusion that a complex interaction between several technological. Based on a survey of over 2700 FOSS developers Ghosh [Gho05] assumes a classification of FOSS projects which range from a hierarchical. however analyzed from a psychological point of view. The authors claim that no single software development process exists. Sadowski-Rasters and Duysters [SSRD08]. Warsta and Abrahamsson [WA03] discuss whether agile methods and FOSS development methods are similar. 3. 3. Similar findings are proposed by Crowston and Howison [CH05] who had analyzed over 120 projects.2 motivation Many research papers exist about motivation of developers or contributers to FOSS projects. social and economic factors provide reasons for a developer's motivation. Lerner and Tirole [LT00] focus more on developers. Niedner and Herrmann [HNH03]. In addition the number of project leaders decreased relatively to the size. but limited to the Linux kernel was done by Hertel.
Almost all analyzed projects have established a flexible management model based on leadership. Similarly a case study of the GNOME project is provided by Koch and Schneider [KS02]. Another case study is provided by Magnusson [Mag10] who considered only the PHP project. A theoretical model of the structure of FOSS projects is offered by Crowston et al. [Cro+04] analyzed several FOSS projects and offered an analysis of several project success measures. Crowston et al. Fielding and Herbsleb [MFH02] analyze Apache and Mozilla and compare them with several commercial projects. A concrete analysis of software engineering processes in the GNOME project is offered by German [Ger03]. A similar finding is provided by Koch [Koc04] who names the biggest difference the co-location in agile methods. Dinh-Trong and Bieman [DTB04] provide a case study on the FreeBSD project with a final comparison with the Apache project.4 case studies 12 other. distributed work and the structure of distributed teams.3. . Mockus. 3.4 case studies In addition to the research studies. The proposed model focuses on software development. He comes to the conclusion that most FOSS projects follow an adaptive life cycle. which of course is not available in most FOSS projects. collaboration and accountability. [Cro+05]. Spinellis and Szyperski [SS04] make a strong case that FOSS affects traditional software development since many FOSS projects do actually share pieces of code or use other projects for their development. Taking a look on the evolution of software engineering processes Scacchi [Sca06] provides a study claiming that development processes evolve together with the community of a project and that their development processes have great influence on companies who were used to traditional software engineering processes. many case studies are relevant to this analysis and focus on several FOSS projects. Johnson [Joh01] provides a quite exhaustive process model of different FOSS projects. Furthermore the Plone project was analyzed in depth by Aspeli [Asp05].
1 project selection Since there is a huge number of FOSS projects to choose from. this chapter will give an explanation of the used methodology. the number of active developers. Examples are programming languages.2 Popularity In order to not choose small or not relatively unknown projects. Such a breakdown enables a direct comparison of projects with similar goals as well as with other. These criteria allow a good selection and furthermore they should give a reasonable sample within this analysis can produce valid results. Furthermore quite new projects often do not have such a structured development workflow and it is seldom known if they still will be developed in the near future. 4.1. 4.3 Project Age It seems that especially FOSS projects take some time to identify their development workflow and structure their project accordingly. which are only maintained and 13 .1. approximations of installations and citations in websites or magazines give a good quantitative representation. desktop interfaces and other.1 Category There is a vast number of FOSS projects available. As of course not all projects have the same goals in mind and provide similar software. research choices as well as the approach to the different projects. To achieve a good selection of such projects several criteria were established to ease the assortment. not related projects.1. As such a minimum project age was set to ten years. To exclude older projects. While it is very difficult to represent this factor with absolute numbers. it makes sense to differentiate the projects by their goals and the type of the resulting software. this study focuses on well established projects with a quite long history compared to others. 4. the popularity and usage of a project was taken into account.METHODOLOGY 4 Based on the scientific research methods explained in chapter 2. 4.
4 Activity The activity of a project is a very important measure to include only actively developed projects which still fall into the above mentioned time frame. the communication methods have to be openly accessible.4.5 Community The people behind a project are the driving force. As such a large number of commits also shows a high activity. releases Regular or a high number of releases are a sign of a high activity of FOSS projects. As such it makes sense to provide some criteria to choose projects with a considerable number of developers. directly lead and develop a project. its size and activity. As such a large number of developers is wanted for this analysis. 4. forums or chat systems.1. The activity of a project however is difficult to measure.1.1 project selection 14 do not follow a typical FOSS workflow the maximum project age was set to 25 years. conferences Meetings such as conferences. . hackfests or other are an indicator of an active and vital community. but one can look at certain numbers published by most of the projects which allow a good insight of how active the project is without rating it quantitatively. communication In order to be able to examine development workflows in a project. Furthermore a project should have a good level of communication over diverse methods such as mailing lists. however it is not always possible to get an accurate number. 4. They represent an important meeting point in most projects and as such are a good criteria for the activity of projects. A big number of course shows a high popularity and also a high activity within the project. As such this represents an important criteria for the selection. downloads Some projects publish the number of accesses to their code repositories or number of downloads of their releases. number of commits There is a correlation between the number of commits to a project's repository and its activity. developers The number of developers of a project is a direct indicator of the popularity of a project.
This choice was made to allow an easier comparison between the projects without any clutter they might bring in.2 final selection With the above explained criteria catalogue. 4.4. but also the code repositories of the projects. For FOSS projects all code repositories are publicly available and often range back to the beginning of the project. The reason for this is to underly the made conclusions and to check the analysis for validity. In some cases however data from the beginning is not available.3 visualization of project data For this analysis not only the publicly available project information was analyzed. A deliberate choice was made to only analyze the core parts of the projects.2 final selection 15 foundations Bigger FOSS projects mostly have a foundation as backer. ten FOSS projects were chosen and analyzed. Such programs almost always lead to a larger community which is able to host such events. ongoing projects A lot of bigger FOSS projects hold or join projects like Google's Summer of Code program in which students are invited to join the project for a few months. They usually appear after a few years of development or a growing size of the project. even if they are built with a modular approach or consist of several other parts. This leads to the following list of projects. be it because of the lack of versioning control systems at that time or . which makes sure that the project stays independent from companies or other. 4. project Debian Drupal Fedora GNOME KDE MySQL/MariaDB PHP Plone PostgreSQL Python origin 1993 2001 2002 1997 1996 1997 1994 1999 1986 1989 category Operating System Content Management System Operating System Desktop Environment Desktop Environment Database Management System Programming Language Content Management System Database Management System Programming Language Table 4.1: List of analyzed FOSS projects.
4. This could mean two things. This produced several graphs which will be explained below. The first six were then chosen and their monthly commit count was analyzed from the projects' inception (if available) until the end of the analysis. 4. the person is busy in other parts of the project. To smooth the curve and to allow an easier understanding of the graph each second month was left out and interpolated over the other points. The monthly number was then plotted and a curve was interpolated between these points. For the generation of this graph all related software repositories were analyzed in relation to each developer with the most commits. all software repositories were downloaded and prepared for automatic analysis. first a person could have left a project or. which made it harder to combine the given data. The above graph shows the six most active developers of a project with their over time commits per month. which is the case in the Python project.3 visualization of project data 16 migrations of version control systems.3. In this case for example the Python project leader Guido van Rossum diminished his activity from 2004 on in comparison to other developers. .1 Commits by Author 250 200 # Commits 150 100 50 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Guido van Rossum Benjamin Peterson Fred Drake Raymond Hettinger Georg Brandl Jack Jansen Figure 4. It quickly allows to see the involvement of certain people in the project and their activity on the development side of the project.1: A graph displaying the six most active developers with their monthly commit number with data from the Python project. With those two points in mind. In other cases the code was split into several different code repositories.
3 Time Based View Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour Figure 4.2: A graph displaying the number of commits per year with data from the KDE project. such as the commits by month or the authors by month graphs. It is interesting to note that this graph often matches up with other graphs in the same project.006 11.2 Commits by Year 26.4.154 29.579 26. 4. Most projects have a steadily increasing number over the years.219 Figure 4.000 10.000 # Commits 20.538 16.166 5.000 15. The above graph shows the number of total commits per year. In the above case this can be explained with the development of a new major KDE release.000 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 966 7.208 15. The graph was generated counting all commits per year from inception till the end of the analysis.3 visualization of project data 17 4.159 25.903 15. In some cases like the above there is a quite large leap.947 35.000 .000 15.089 15.000 2.3: A punchcard graph showing when commits usually occur with data from the GNOME project.3.660 29.3.578 30. This graph shows all commits from inception till the end of the analysis in form of a circle with the related day and time combina- 11.201 14.
4.3 visualization of project data
tion. A bigger circle represents more commits at the given day/time combinations. In the below example the most busy day was Monday between 4 pm and 12 pm. This can be easily explained with the fact that the GNOME project usually does new releases on Monday. Furthermore such a graph shows the developers usual working hours. This example also shows that many developers tend to have a main job in a company, as usual office hours match up with the day and time combinations. This is enforced by a quite low number of commits on Saturday and Sunday in comparison to workdays. The graph was generated counting the commits depending on their day and time. Of course local time was converted to Coordinated Universal Time (UTC) to guarantee comparable results. The circles were then drawn on the graph using different sizes and transparency depending on the number of commits on a single day and time combination. The size and transparency is a relative value ranging from the day and time combination with the least number of commits to the day and time combination with most commits. All other circles were then drawn using a value between this range. 4.3.4 Commits by Month
350 300 250 # Commits 200 150 100 50 0 2000 2002 2004 2006 Time 2008 2010 2012
Figure 4.4: A graph showing the number of commits per month with data from the Drupal project.
The above graph shows the commits per month correlation from inception till the end of this analysis. It is quite similar to the yearly overview mentioned before, however gives a better insight into the monthly development. An increase of commits always shows a cer-
4.3 visualization of project data
tain degree of interest of people for the project. It can of course mean that more people are willing to contribute to a certain project, but also that the existing developers are producing more code. This is especially interesting when comparing it with the following graph. In the above example there is a peak between 2008 and 2009 which can be explained with the upcoming Drupal 7 release development at that time. The graph was generated counting the commits from inception till the end of this analysis and plotting that number for each month. The blue line then was interpolated between those points. The red line on the other hand stands for the average value over a year and is useful to identify the project's direction. 4.3.5 Authors by Month
60 50 40 # Authors 30 20 10 0 1998 2000 2002 2004 2006 Time 2008 2010 2012
Figure 4.5: A graph showing the number of distinct authors per month with data from the PHP project.
The above graph shows the number of distinct authors per month from inception till the end of analysis. It gives a good impression on how many people were responsible for the amount of work done in a certain time period, which can be seen in the previous graphs. The above example shows a decrease of authors meaning either that developers left the project or that developers reduced their time working on the project. The graph was generated counting all distinct authors per month from inception till the end of analysis. As this is always in whole numbers, the graph was generated using a so called constant plot. The red
4.3 visualization of project data
line on the other hand is an average value over one year which is interpolated between those points. In case of authors with different email addresses or slightly different names in the single commits, they were combined if it was the same person.
over 250. This first part of this chapter makes heavy use of the Grounded Theory research method presented earlier. It is written in the PHP programming language and licensed under the GNU General Public License (GNU GPL). Quickly however a fully-fledged CMS emerged out of the initial version. The name originates from the dutch word druppel which translated means drop.2 Community The Drupal project has a large user and developer community around the world. Twice a year the community holds a conference under the name Drupal Conference or DrupalCon. Drupal is used for a wide range of capabilities such as blogs. About 1200 of those were additionally listed as developers. communities and is directed to be a widely spread CMS [Dru#5]. W3T#1]. whereas the number could be a bit higher [Buy11]. In the following though only Drupal Core will be analyzed. company and political websites.2 % [Bui.org in August 2011. 5.1. This is a good use case for Mayring's research method for Qualitative Content Analysis described in chapter 2.7 % of all websites worldwide and holds a market share of 6. Originally the software provided a black board like directory. However it can be extended through numerous modules. Especially in the last years it experienced a wide distribution and is used for at least 1. After a thorough analysis of each project. To alleviate the journey of the atten- 21 . Drupal is also known as Drupal Core inside the Community and contains the base functionality of the CMS. The second part of this chapter will then use the proposed catalogue to analyze further projects. 5.D E V E L O P M E N T P R O C E S S A N A LY S I S 5 In the following chapter the chosen FOSS projects will be analyzed in depth. According to own statements. 5. a project analysis catalogue will be proposed.1 History The first version of Drupal was released in 2001 by Dries Buytaert [Dru#4].1.000 users were registered on drupal.1 drupal project analysis Drupal is a Content Management System (CMS) and a Content Management Framework (CMF).
5.1 drupal project analysis
200 180 160 140 # Commits 120 100 80 60 40 20 0 2000 2002 2004 2006 Time 2008 2010 2012
Dries Buytaert G´ abor Hojtsy
Angie Byron Neil Drumm
Steven Wittens Kjartan Mannes
Figure 5.1: Monthly activity of the most active Drupal Core developers. It clearly shows the involvement of the founder Dries Buytaert. In recent years however the roles of Gábor Hojtsy and Angie Byron became more important.
dees the conference takes place alternatively in Europe and North America. The communication possibilities sprawl from forums on drupal. org, mailing lists and discussion groups on groups.drupal.org. Additionally a wide range of Internet Relay Chat (IRC) channels for different aspects of the Drupal project are being used. Next to the last-mentioned classification of users and developers, people can – provided that they are working on Drupal Core – be classified into one of the following categories [Dru#1]. core contributor All developers who bring in code or documentation for Drupal Core are known as core contributors. All modification proposals are checked by another core committer in a review process and are then either accepted or dropped. maintainer While maintainers often aren't involved in the decision making progress, they have the liability of small portions of Drupal Core. Most of them are particular core modules or technical domains such as JavaScript. The assignment happens over Dries Buytaert, whom interested developers can approach or will be invited to join.
5.1 drupal project analysis
venue Munich, Germany Denver, USA London, England Chicago, USA Kopenhagen, Denmark San Francisco, USA Paris, France Washington D.C., USA Szeged, Hungary Boston, USA Barcelona, Spain Sunnyvale, USA Brussels, Belgium Vancouver, Canada Amsterdam, Netherlands Portland, USA Antwerpen, Belgium
date August 2012 March 2012 August 2011 March 2011 August 2010 April 2010 September 2009 March 2009 August 2008 March 2008 September 2007 March 2007 September 2006 February 2006 October 2005 August 2005 February 2005
attendees N/A N/A 1751 3000 1200 3000 850 1400 500 850 450 ~300 150 ~150 ~100 100 ~50
Table 5.1: Previous and planned DrupalCon events [Wal11].
core committer Only few people have write access to the Drupal Core repository. They are known as core committer and look through code changes and propositions and decide about patch acceptances. At this juncture there is a distinction between permanent core committers and branch maintainers. permanent core committer Dries Buytaert is currently the only permanent core committer. branch maintainer Next to Dries Buytaert they are in charge of maintaining a particular Drupal version. • Gerhard Killesreiter for Drupal 4.7.x. • Neil Drumm for Drupal 5.x. • Gábor Hojtsy for Drupal 6.x. • Angie Byron for Drupal 7.x. founder and lead developer Dries Buytaert, the founder of the Drupal project, holds the role of the project leader and therefore decides the project's direction. Furthermore he is the main decision maker. Though in some cases he also gives away his decision control to a trusted person.
5.1 drupal project analysis
2,500 2,047 1,806
# Commits
0 2000 2002 2004 2006 Time 2008 2010 2012
Figure 5.2: Yearly overview of commits to Drupal Core. The peak in 2009 and 2010 is most likely related to the development of Drupal 7 which was released in early 2011.
5.1.3 Release Process For releases, Drupal uses a version naming with two numbers since Drupal 5. The numbers stand for major and minor versions [Dru#6]. New major releases are quite scarce and will get released every few years. They are planned for a long time in advance, often with incompatible changes. Before Drupal 5 a three numbers versioning scheme was used. While the time periods between single Drupal Core major releases are not bound, the time until a stable release is divided into single phases [Dru#3]. The length of a single phase is not fixated either, but is limited by a range of factors which will be explained in the following. code thaw After each major release a new branch will be created in the Drupal Core repository. In this phase all new features and modifications can be discussed and added. No restrictions apply.
1.0.0 3.0.0 4.1.0 4.3.0 4.5.0 5.0 6.0 7.0
4.4.0 4.2.0 4.6.0
Figure 5.3: Major releases of Drupal.
At this point in time. The first release candidate is published once there are no more known critical bugs. At the end of this phase. several alpha. release candidates and in the long run the stable version will be released. Code Thaw Code Slush Polish Code Freeze API Freeze Feature Freeze UI Freeze String Freeze Release Alpha Beta Release Candidate Final Release Figure 5. In this phase no new features except the chosen initiatives are allowed.5. polish phase In this phase Drupal Core will be polished and the last enhancements on performance.5: Drupal release process phases. beta. accessibility. At the end of the phase string freeze and user interface freeze will be put in place. code slush This phase was added to the Drupal 7 release cycle to restrict the time between major releases. release phase Lastly. documentation and other are brought in. Though changes will be accepted to fix errors or add missing functionality. . the API can only be changed when critical errors are found and have to be corrected.1 drupal project analysis Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour 25 Figure 5. Important features will be elaborated and handled with the help of so called initiatives. the Application Programming Interface (API) freeze will be declared.4: Time based view on commits of core contributors. There seems to be a tendency to evenings during the week and Sundays which could be interpreted with a more community driven project.
Initiatives can be created by any Drupal developer. Again. the development process features a number of core initiatives which will stand for a major area of Drupal [Dru#2].1 drupal project analysis 26 Additional release candidates are released if new critical bugs appear. the development was mostly driven through the issue queues. 350 300 250 # Commits 200 150 100 50 0 2000 2002 2004 2006 Time 2008 2010 2012 Commits Average Figure 5. Each initiative has one or two initiative owners who lead the development and coordinate the initiative while working closely with Dries Buytaert. the following initiatives will be followed: • Configuration Management • Web Services Context Core Initiative • Design 4 Drupal . The subsequent low is then related to the planning phase of Drupal 8.5. He also choses the initiative leaders and remains in close contact with them. 5. which is a bug tracking system on drupal. however Dries Buytaert choses which initiative will be followed for the next major release.4 Development The Drupal project changed its development workflow for the upcoming Drupal 8 release. For the Drupal 8 release. the peak in 2009 and 2010 seems to match the development of Drupal 7.6: Amount of commits per month of core contributors.1. otherwise the final release is published. Until then. Furthermore each initiative defines a small set of goals which should be reached by the time of the next major release. bugs and new features. While it is still used for communication.org.
The project is split into Plone Core and Collective. Plo#6. It is mostly written in Python and available for all major platforms. The project is known for its very good security track record. This analysis however will only focus on Plone Core as it is the heart of the project. . groupware and other.7: Amount of distinct authors of Drupal Core over time. Due to their policy. blogs. The project recently started adding author names to the commits. Nokia and others. Amnesty International. extensibility and flexibility. Plo#13]. Plone is one of the top 2 % of FOSS projects worldwide [Bla11].2 plone project analysis Plone is a CMS built on top of the Zope application server which provides the core functionality layer for the project [Asp05. only certain developers are allowed to commit to the repository.5.2 plone project analysis 27 • Drupal 8 Multi-Lingual Initiative • HTML5 • Mobile 6 5 4 # Authors 3 2 1 0 2000 2002 2004 2006 Time 2008 2010 2012 Authors Average Figure 5. Furthermore it is used by organizations and companies such as NASA. high usability. Plone is licensed under the GNU GPL and according to Ohloh. 5. It can be used for a wide range of websites such as internal websites.
Bla11. It is also highly recommended to attend a conference .0 was released which made Plone more configurable and enhanced the possibility of adding modules to the CMS. Plo#9. Alexander Limi and Alan Runyan started the Plone Project creating a usability layer on top of the application server and CMF Zope [Asp05. In 2004 Plone 2. there are also large forums and IRC channels available where one can give and find support. This is not limited to code. The first version was then released two years later in 2001 [Plo#12].1 History In 1999. Plo#2]. 5. usability and more [Plo#7.2 Community The Plone project consists of a large user and developer community. core developer This role is defined to have access to the Plone Core codebase. but can also be usability enhancements or other contributions.2 plone project analysis 28 5. Plo#8. infrastructure.2. To become a member of this role one must have established a track record of contributions to the Plone project. there is a much bigger community working on Plone Collective projects [Asp05. There are also lots of other mailing lists available for almost every aspect concerning the project. Since then the yearly Plone conference attracted a growing number of attendees every year and was held in Europe as well as in the United States. development. Plo#1]. The Plone community is very eager to organize so called sprints [Plo#11]. However. security. While there are about 300 people working on Plone Core. where each team is responsible for a specific part of the Plone project such as release management. the Plone foundation was established. Plo#6]. A sprint is a focused development session where developers meet in person and try to enhance a certain part of the Plone project. It normally lasts about three to five days in which one person leads the session and tracks the activities and the development. Most of the communication is done through the Plone mailing lists whereas the plone-developers mailing list is in place to discuss the development and future of Plone Core. The currently used and developed Plone 4 was released in 2010. Due to the large group of Plone developers. The next major Plone version was released in 2007 under the name Plone 3. Many sprints take place worldwide every year. The first Plone conference was held in New Orleans in 2003 [Plo#5]. At the same time.5.2. the project is split into several teams. which to this day has ownership rights over the Plone project and trademarks. It was quickly picked up by many people and a community around the Plone project began to emerge.
Hanno Schlichting and Martin Aspeli serve as gatekeepers for this role. Hanno Schlichting.5. Furthermore all significant changes must go through the framework team. Finally one has to request an account.8: Monthly activity of the most active Plone developers. By accepting or rejecting PLIPs they gather information from the community and finally recommend them to the release manager. Currently the team consists of 16 people. Wichert Akkerman. Currently this role has 375 members. The manager works closely with the framework team to ensure improvement and continuing development of Plone. The release manager gets named by the Plone foundation board and is a paid position [Plo04]. or sprint in order to become acquainted with the other developers. Holek. Stefan H. Eric Steele. The team consists of a small group of people and are chosen arbitrarily. release managers Each major Plone release is done by a release manager who is responsible for continuing releases in the specific series. They are however not responsible for adding new features or patching bugs.2 plone project analysis 29 250 200 # Commits 150 100 50 0 2002 2004 2006 Time 2008 2010 2012 Hanno Schlichting David Glick Martin Aspeli Wichert Akkerman Alexander Limi Eric Steele Figure 5. While the founder Alexander Limi was very active in the inception phase. they only drive the Plone Improvement Proposal (PLIP) process. Informally. Hanno Schlichting and Eric Steele seem to drive the project much more in present time. framework team This team is responsible for the decision of which code gets into a Plone release. Godefroid Chapelle. Alan Hoey. . They do this by recommending code for inclusion to the Plone release manager team. The current release managers are Alec Mitchell.
000 9.9: Yearly overview of commits to Plone. While they do not have any further rights.000 0 2002 2004 2006 Time 2008 2010 2012 1.038 4.784 . there will be a new Plone release. 5.5. overruling the community's proposal.000 3.000 7. both still have a powerful voice in the community and help with decisions where the community is not able to take one.242 3.398 6.10: Time based view on commits of contributors.482 30 8.000 8.000 3.838 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour Figure 5. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 Figure 5. which could be interpreted with an equal amount of employed and volunteered commits.3 Release Process Since the Plone 4. In some cases they also take a decision by themselves. The steady increase of commits is interesting to note with a boost before the Plone 4 release in late 2010. plone founders The Plone founders are Alexander Limi and Alan Runyan.088 5. The times seem to be equally distributed between office hours and evenings or weekends.000 4.2 plone project analysis 10.2.000 2. Now every six months.194 4.2 release in 2011 the Plone project changed it's release process in order to implement a fixed release cycle [Plo11].193 4.000 # Commits 6.254 7.000 1. Additionally the Plone project sets a feature freeze date two months before the release 7.
Only bug fixes and non-invasive changes are allowed.4 Development Most of the development of the Plone project is handled through the mailing list and bug trackers of the project [Plo#2. Minor patches and contributions often get committed directly to the repository while bigger changes and features have to go through the PLIP process [Plo#4. Major releases break backwards compatibility but may provide an upgrade path. no new feature is allowed to enter the codebase. If the feedback can be considered positive.2. Alpha releases are basically snapshots of the current development process. a solution to it and a working implementation.1 0.0 4. 0. the last release candidate is considered to be the final version and gets published on the previously set release date. Plo#1].0 3. A PLIP mostly derives from a discussion on the plone-developers mailing list. . Additionally.3 Figure 5.1 2. A PLIP is always owned by at least one person who is fully responsible for it. each major and minor release has several preceding releases. The development starts with the next major or minor release. further release candidates follow. Plo#1. minor and micro versioning scheme [Plo#10. Minor or feature releases normally provide new features and bug fixes but retain backwards compatibility. The community will give feedback on the idea and possible solutions.0 2.5. However one can also start directly with the creation of a PLIP and get the community feedback during the upcoming phases.2 4. Plo#1].4 3. After that date only bug fix releases are allowed for this series.1 2000 2002 2004 2006 2008 2010 2012 0. Once a beta release gets published. This process is based on the Python Enhancement Proposal process.5 3.1 3. New features and big changes have to be written down in a PLIP which contains a description of the feature or problem.7 0.2 plone project analysis 31 at which no new PLIP will get accepted unless it has been completely reviewed by that date.11: Major and feature releases of Plone. Micro releases are only bug fix releases and do not contain new features. A release candidate is published afterwards and only if problems are found.0 2.5 1. Plo#3]. 5. The Plone project uses a major. the creator of the idea will be asked to write a PLIP. If no show stopper bug comes up.9 0.
Proposal Approved Withdrawn Rejected # Commits Draft Review Final Review Accepted Figure 5.12: Amount of commits per month of core contributors.13: Possible paths of the status of Plone Improvement Proposals. The author of the PLIP is always considered as the main contact point for future improvements or discussions. It will be reviewed and if the framework team decides that the PLIP won't get accepted for Plone Core.5. From here the PLIP life cycle begins [Plo#3].200 1. It is not ready for a proposal but the discussion already starts and new solutions or ideas find their way into the PLIP.000 800 600 400 200 0 2002 2004 2006 Time Commits Average 2008 2010 2012 32 Figure 5. the author is encouraged to improve the PLIP and resubmit it at any later point in time. proposal Once the author thinks that the PLIP is finished and will get accepted they can submit it at any time. The two peaks seem to refer to the development of Plone 3 and Plone 4.400 1. where the author summarizes his ideas and tries to come up with a solution. .2 plone project analysis 1. The framework team will then comment on any newly submitted or updated PLIP. draft A PLIP always starts as draft.
accepted If the PLIP passes the Final Review phase. the PLIP will be pushed to the next release. A member of the framework team will get assigned to the PLIP and assists the author with any questions and help they might need. This phase should not take longer than two weeks and all critical bugs have to be fixed before that. the author of the PLIP can forward the implementation to the framework team. . Two members will then review the proposal along with two additional developers chosen by the author. it goes back to the Review state. If there are too many changes for the available time. the author of the PLIP starts with the development of the PLIP. approved As soon as the PLIP is approved. final review Once all major concerns have been solved. the original reviewers will review the PLIP one more time and confirm that all issues have been resolved and no new issues have been found. in most cases the PLIP gets implemented as an amendment and later submitted again as an improved PLIP. rejected If the PLIP was rejected by the framework team. review Once the development is complete. The reviews have to be in written form and publicly available to a all members of the community.2 plone project analysis 33 70 60 50 # Authors 40 30 20 10 0 2002 2004 2006 Time Authors Average 2008 2010 2012 Figure 5.5. If issues have been found. it can be merged and will be available in the next Plone release. The development of Plone 4 obviously did attract new developers.14: Amount of distinct authors of Plone Core over time.
Guido van Rossum. Python 2.0 however. Currently. which itself saw contributions from van Rossum in the eighties. Licensed under the Python Software License [Pyt#4] it is available for all major platforms. backwards incompatible release. both incompatible to each other.2 Community The Python project has a large user and developer community.5. Also.7 version. there are other interpreters available as well. Python 3.0 was first released in 2000 and since then evolved to the currently available Python 2.1 History The creator of Python. 5. It supports many programming paradigms. It is the successor of the 2. Many are working on the CPython interpreter and the standard library. However there are now many other conferences. since the 2. The subject of this analysis will be CPython.3 python project analysis 34 withdrawn An author can of course always decide to withdraw the PLIP if they think.3. the Python project created a transparent and community backed development process with van Rossum as its leader. one can frequently attend conferences and workshops worldwide [Pyt#1]. there are two versions of Python available. Python was a successor to the ABC programming language.x series. EuroPython or SciPy. was a major.x series and will replace it completely in the near future.3. such as PyCon DE. such as advanced libraries. The Python community is very eager to attend and offer opportunities to meet in person. The name alludes to the British television series Monty Python's Flying Circus van Rossum was watching while creating the programming language. 5. however there are also a lot of other current Python related projects. Therefore. The first conference was PyCon in North America in 2003. Python comes with an interpreter and an extensive standard library. The reference implementation of the interpreter is called CPython. imperative or functional programming styles. such as object oriented. which was published in 2008. conceived and implemented Python around 1989 at the CWI Institute in the Netherlands [Ven03]. 5. however. . He still is Python's principal author and project leader and therefore the project's main decision maker.3 python project analysis Python is an object oriented and interpreted programming language well known for its simplicity and easy to learn syntax [Pyt#6]. that the PLIP is no longer needed or obsolete.
such as several IRC channels and developer's blogs. The project leader Guido van Rossum appears to be busy with his position as other developers such as Georg Brandl are much more active. Then normally a developer will be offered the chance to become a core de- . The enquired person will sequently act as a mentor for the requester. One must have consistently contributed patches. Next to the already mentioned users and developers of Python people will be classified into several categories depending on how strongly they are involved in the development of Python [Pyt#5]. core developer The way to become a core developer is quite similar to the developer role above. for example the python-dev mailing list which is the main communication channel for Python development. developer One is able to gain the developer role when they have consistently shown contributions to Python. There are of course other communication methods available. The pythonideas mailing list on the other hand is for future ideas and goals of the Python project. It is possible to request the developer role by asking any other person.3 python project analysis 250 35 200 # Commits 150 100 50 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Guido van Rossum Benjamin Peterson Fred Drake Raymond Hettinger Georg Brandl Jack Jansen Figure 5.15: Monthly activity of the most active CPython developers. The communication inside the Python project mostly takes place through several mailing lists [Pyt#3]. There is however no set rule of how many patches or resolved issues are needed. Each mailing list stands for a certain topic. They then will decide if the requester is ready to gain the additional privileges. who already has the developer role.5. which meet a certain quality standard.
help requests and decisions will be forwarded to the expert. however later than usual office hours.000 5. Experts may also be asked to decide on features or bugs.925 5.373 3.041 4.869 2.722 1.3 python project analysis 36 10.000 4.186 .981 8.548 2.000 7. All issues. Also.992 4.17: Time based view on commits of core contributors.166 2. the core developer group will watch if the quality of the contributed patches was met and the development process understood.311 5.000 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Figure 5. The reference person will also act as a mentor for the new core developer. As the leader of the Python 1. It is interesting to note that almost all commits happen during the week.5.996 6.000 # Commits 6.870 4. An expert is the maintainer of his field of interest and therefore responsible for changes and new features to those areas.16: Yearly overview of commits to CPython. The two peaks appear to match the releases of the major releases Python 2 and Python 3. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour Figure 5.256 1. benevolent dictator for life ( bdfl ) Guido van Rossum is the only person who holds this title. expert Each core developer has the possibility to become an expert in a certain area of the Python project. veloper.649 9.386 105 445 627 289 582 1.900 2.
They are planned for a long time in advance.3. he has the privilege to outvote and overrule any decision made by an expert or core developer. project. Roughly. 5.3 2. Python uses a version naming with three numbers.3 Release Process For releases.5 2. Minor releases are feature releases with no incompatibilities between its predecessors. although they can be released in shorter time periods too. beta and release candidate releases which are testing releases. often with incompatible changes.4 1.2 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 1. 0.2 1. each release is proceeded by several alpha. Besides. .9 1. they get published every 18 months.0 3.18: Amount of commits per month of core contributors.1 2. WR01].19: Major releases of Python.5. An example for such a major release is Python 3.1 1.4 2.6 3.0.5 1. minor and micro versions [Pyt#2.6 2.1 3. Again this matches with the development phases of Python 2 and Python 3.2 2. New major releases are extremely scarce. as the word benevolent states.3 2.0 Figure 5.3 python project analysis 37 1. Micro releases are bug fix releases and get promulgated every six months.0 1. The numbers stand for major.000 800 # Commits 600 400 200 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Commits Average Figure 5. However his decisions should always be in favour of the project.
"Readability counts".org> Active Process 05-Jul-2001 05-Jul-2001 38 Introduction This document gives coding conventions for the Python code comprising the standard library in the main Python distribution. This voting however is completely deliberative and Guido van Rossum can still approve or reject a patch even if the voting disagrees with his decision. whereas +1 and -1 mean acceptance or rejection and +0 and -0 mean an indifferent decision with a slight positive or negative slant [War02].org>. Consistency with this style guide is readability of code and make it consistent across the wide spectrum of A style guide is about consistency. PEPs can then either be approved or rejected. .4 Development Since Python 2. They can vote +1. Where there's This PEP may Please see the companion informational PEP describing style guidelines for the C code in still be incomplete (in fact.3. Consistency within a project is more important. conflict. they are design documents which describe either a proposed feature. Figure 5. 5. Python code. it may never be finished <wink>). The development process is highly dependent on the so called Python Enhancement Proposal (PEP) [WHG00]. a process or just provide information. A Foolish Consistency is the Hobgoblin of Little Minds One of Guido's key insights is that code is read much more often than it is written. For each patch. The guidelines provided here are intended to improve the As PEP 20 [6] says. They are continually discussed in the community and revised until the community reaches a consensus. The Python project defines three types of PEPs. the Python community changed their development process towards a more open and transparent approach. This document was adapted from Guido's original Python Style Guide essay[2]. Consistency within one module or function is most important. -1. the Python community can vote for or against it. +0. -0.20: Excerpt from PEP 8: Style Guide for Python Code. Guido's style rules for the purposes of this PEP.0. important. The voting itself takes place on either the python-dev mailing list or will get announced on the python-announce mailing list. Barry Warsaw <barry at python. 13 Jun 2011) Guido van Rossum <guido at python. Loosely modelled on the Internet Request for Comments process. They are the primary way to propose new features and on approval are finalized with the commit of a patch. the C implementation of Python[1].5.3 python project analysis PEP: Title: Version: Last-Modified: Author: Status: Type: Created: Post-History: 8 Style Guide for Python Code 00f8e3bb1197 2011-06-13 12:48:33 -0400 (Mon. with some additions from Barry's style guide[5].
They always consist of a design document and a reference implementation. development workflows and other are mostly Process PEPs. decision making processes. The PEP process begins with a feature proposal for Python. 2. 1. Python 2 seemed to provide a major reason for developers to join. Additionally any PEPs which describe other PEPs. They will begin by submitting the PEP to the Python project. standards track pep The most common form of PEPs describes a feature proposal for the Python language. for example how a PEP should look like. the Python project suggests to submit small changes directly as a patch submission. process pep This kind of PEP is quite like the Standards Track PEP. The PEP editors will assign a number and a cat- .5. informational pep Unlike the Standards Track PEP. However it does not necessarily have to reach consensus inside the Python community and so one is free to ignore Informational PEPs. the Informational PEP does not propose a new feature.3 python project analysis 39 40 35 30 25 # Authors 20 15 10 5 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Authors Average Figure 5. except that it applies to other areas than the Python language and describes processes around Python. who have the responsibility for it. While all bigger proposals require a PEP. will be defined as Process PEPs. It provides general guidelines or information about a certain issue of Python. A PEP always has one or several authors. More precisely it should be presented to the python-ideas mailing list and subsequently sent to the PEP editors. 3. For example any guidelines.21: Amount of distinct authors of CPython over time.
if all PEP criteria are matched. instead of assigning the Draft status. defer a PEP. For example PEP 1 [WHG00]. if it turns out that the original idea did not fit the Python project. after it was accepted or not deferred. However the criteria are not fully binding and a PEP just has to be accepted by the BDFL. This includes a precise formulation of the PEP. Additionally. active Informational and Process PEPs can also be marked as Active. as it is continually improved and adapted to new workflows. deferred A PEP Editor can always. . which describes the process of PEPs has its status set to Active. In this case the original PEP would be marked as Replaced and superseded by the new PEP. The reject stage is just an option to drop a PEP. withdrawn A PEP can also always be withdrawn by the author. This could help if an author does not want to work on a PEP anymore. draft This is the default state of any new PEP on submission. as described above.5. lack of motivation by the author or not being in line with the Python philosophy. Mostly this status gets assigned. final Once a PEP has been accepted and has a reference implementation available. From there.22: Possible paths of the status of Python Enhancement Proposals. if they will never be completed. rejected At this stage a PEP can still be rejected. the PEP workflow begins. not breaking backwards compatibility and finally be accepted by the Benevolent Dictator For Life (BDFL). being poorly written. subsequent versions can replace a PEP. Reasons for a deferral could be duplication.3 python project analysis 40 egory as mentioned above. Draft Accepted Rejected Deferred Withdrawn Final Replaced Active Figure 5. replaced Mostly for Informational PEPs. for example because there is a better solution available. new PEPs always start with the Draft status. accepted A PEP will be able to get this status assigned. it can get the status Final by the BDFL.
One of the most important features of the new approach was to provide an interface for modules. they rewrote and redesigned the language and also changed the name to PHP Hypertext Processor. Rasmus Lerdorf created the first version of PHP for his own website. it requires a web server with a connected PHP installation.0 version . As such. This release was incompatible to the previous 4. With PHP version 3. PHP07]. It is widely available for all major platforms and is licensed under the PHP License [PHP#4]. it is incompatible to the widely used GNU GPL. Following a popularity boom in 1997 and 1998 it reached its limitations due to the design of the project and by being almost solely developed by Lerdorf.4 php project analysis 41 5.0 completely. naming the program Personal Home Page Tools [PHP#2]. He published the bundle one year later. it received another makeover in 1996.4 php project analysis PHP is a server side. PHP could be considered as an advanced programming interface. that while it is a Free Software license. PHP is a very popular programming language for web development and featuring a large number of websites [W3T#2.5. interpreted programming language designed for web applications and development [PHP#9]. PHP 5 was released featuring the successor Zend Engine 2. 5. Together. The design of the language was changed further in 1998 improving performance and the modularity of the codebase.1 History In 1994. Version 3.4. At that time. PHP truly began to evolve to a full featured programming language. Four years later. It is worth noticing. which can be used directly from the programming language. That also included the first name change to Forms Interpreter (FI) and then to Personal Home Page Construction Kit the same year. However it can also be used with a command line interface. imperative or procedural programming styles. The new engine was called Zend Engine and provided the core of PHP 4.0. after rewriting the original version. combining the two previous names to PHP/FI.0.0 of PHP was then released in 1998 and replaced PHP/FI 2. However. This time. the project changed its name to PHP Hypertext Processor. In 1997 Andi Gutmans and Zeev Suraski rewrote the PHP interpreter and approached Lerdorf discussing the problems PHP had. The abbreviation PHP originally stood for Personal Home Page [PHP#2].0. This version was also known as PHP/FI 2. which was released in 2000. It included several modules for database or browser interaction. such as object oriented. PHP comes with an extensive standard library and supports many programming paradigms.
Of course.4.4 php project analysis 42 250 200 # Commits 150 100 50 0 2000 2002 2004 2006 Time 2008 2010 2012 Ilia Alshanetsky Jani Taskinen ¨ Marcus Borger Pierre-Alain Joye Antony Dovgal Dmitry Stogov Figure 5. A lot of local PHP User Groups exist and provide weekly or monthly meetings and meet-ups such as workshops. The PHP community provides a large amount of conferences and workshops to meet in person and work together on PHP. there are many opportunities to meet other PHP contributors.5. however the most important is the internals mailing list. 5. which get distributed alongside the standard interpreter. several IRC channels and blogs of PHP developers are also used. there are many people working on PHP extensions and components. There exist mailing lists for almost all aspects of the project. The climax of development in 2007 stalled and the most active developers appear to lose interest since then. Most of the development process. While the International PHP Conference was the first of its kind in 2001 [PHP#3].23: Monthly activity of the most active PHP developers. there is no categorizing of developers and everyone is treated equally. Most of the communication inside the PHP project takes place through mailing lists [Mag10]. which means that one increases his karma by contributing to the pro- . and a large initiative was planned and executed to promote the transition from PHP 4 to PHP 5.2 Community The PHP project consists of a large user and developer community [Mag10]. However the project uses a concept named karma. Officially. future ideas and new contributions are handled through that list. Additionally to the PHP interpreter.
540 5.25: Time based view on commits of contributors.832 4. A lot of the commits appear to be happened during work days and times with some volunteer commits in the evenings and Sundays.000 7.4 php project analysis 43 7.000 8. module author Each developer has the possibility to become a module author. once they get a PHP Subversion account. ject with code.575 9. which gets distributed with the PHP release. several people are responsible for different parts of the code or modules and can be classified using those criteria [PHP#1].000 2.471 8.000 # Commits 5.637 .164 5. discussions and new ideas [Mag10].000 2.3 and PHP 5.000 3. Furthermore.935 6.994 6. developer One is called a PHP developer.000 4. The peaks could match with the development and releases of PHP 4. Once one has shown enough commitment.000 1.859 6.24: Yearly overview of commits to PHP. they can apply for an account. The account however will only be granted if a reference person approves.5. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 Figure 5.466 2002 2006 2004 Time 2008 2010 3.665 2012 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour Figure 5. This role has the responsibility for a certain PHP module. which means that one has to provide several patches and contributions to the PHP project first. According to the PHP community. an account needs to be earned. Examples for such 4.000 0 1998 2000 7.951 4.829 8.
php author This role defines a certain section of the PHP interpreter and its responsibility for it. 1. there can be more than one module authors.3 2011 2012 2013 2014 2015 Time 2016 2017 2018 2019 44 Pre Release Phase Security fixes only Release Lifetime End of Life Figure 5.1 4. The PHP project uses a versioning scheme with three numbers for releases: major.2 Figure 5.0 4.0 4.1 5.4 5. The new release cycle features two release managers who are voted by PHP developers.26: Preliminary PHP release cycle. Andi Gutmans and Zeev Suraski hold this role. Major releases get published quite seldom. which themselves are followed by a number of micro releases. . It is quite similar to the module author role. Minor releases can have new features and bug fixes. For each module.3 5.5. Before.3 Release Process In 2010. the PHP project set up a new release plan with detailed information about how the release process should work [PHP#6]. Micro release are bug fix only releases where backwards and API compatibility must be kept.4.27: Major releases of PHP.4 5. They are the only who can actively change the programming language syntax and concepts.1 6. who share the responsibility. 5. except that it covers only PHP itself.4 php project analysis 6.0 4. minor and micro.5 5.0 Version 5. can break backwards compatibility and are planned a long time in advance.0 2. Each major release is followed by a number of minor releases.6 5.0 4. individuals decided when a release happened and which features it included.3 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 3. modules are database or imaging modules. language designer Currently only Rasmus Lerdorf.2 5. however backwards compatibility must be kept.
200 1. the recent happenings in 2012 appear to show an again growing project.4 php project analysis 45 1.4 Development Most of the development process is handled through the PHP mailing lists [PHP#6. Those are documents which describe the new feature and its rationale. who is responsible for it.5.4 a major or minor release will get published each year. After that period. To help the development and decision process.000 800 # Commits 600 400 200 0 1998 2000 2002 2004 2006 Time 2008 2010 2012 Commits Average Figure 5. Generally the result is often a more comprehensive change or new features. Starting with PHP 5. A RFC document is always owned by at least one person. features and proposals through so called Request for Comments (RFC) [PHP#5]. which only contains bug fixes. Even if the previous graphs showed a stalling development. PHP#7]. Depending on the importance and affected sections of the PHP project. discuss the change on the developers mailing list. Every change needs to pass a peer review process. minor features or changes often get directly committed to the repository. who in case the need arises. the PHP project keeps track of new ideas. the following . As well every change gets reviewed by other developers. Mag10.28: Amount of commits per month of core contributors. Not every patch however needs to be discussed and approved first. only micro releases with security relevant fixes will get published. Each yearly release is then followed by a number of micro releases for two years. where other developers review the made changes. The RFC process begins with the author's submission of the RFC to the PHP wiki and an announcement to the internals mailing list. 5.4.
that the RFC is not ready yet for a discussion. . The Draft status means. While developers can vote for or against the RFC. The importance is defined by whether it actually changes the syntax or behaviour of the PHP language and is therefore irreversible or not. representatives from the PHP community. Those however have to be chosen by PHP developers [PHP#8]. Voting Declined Draft Discussion Accepted Withdrawn Implemented Figure 5. if needed. but can be extended if required. that it significantly influences a vote's outcome. draft Once a RFC gets submitted to the PHP wiki. however it can be improved also by other people and a preliminary discussion can be started. It can be longer however. Depending on the importance of a RFC. which can be one of the following [PHP#5]. After the discussion period has passed. it gets this status assigned.4 php project analysis 46 discussion period is set to a minimum of one to two weeks. the discussion phase starts with this status. however the opinion is that it should be changed in a way. such as participants of PHP related discussions or developers of PHP appendant projects can participate in the voting process. discussion Once the author of a RFC announces it for discussion.5. The vote is announced on the mailing list and followed by a voting period which should be at least one week. the author can either call for a vote or extend the discussion period as needed [PHP#7]. what considerable changes are. a RFC has an assignment status. All PHP developers are allowed to vote and. During the whole development process. it gets assigned to this status. There is no definition by the PHP project. the voting status gets assigned including a link to the voting site. voting After the discussion phase the voting begins. As previously described. it takes either 2/3 of all votes or 50 % plus one to get accepted.29: Possible paths of the status of Request for Comments. but not shorter [PHP#7]. A failed proposal can be resurrected at earliest six months after the last vote or if the author makes considerable changes to the RFC.
It is composed by a collection of tools and programs including a desktop shell in order to provide all the essential utilities a user might need when working with a computer. the RFC will be implemented or taken into action if it describes a community process. accessibility. implemented If the voting was successful. regular re- . internationalization.5 gnome project analysis GNOME is a desktop environment for UNIX based systems.30: Amount of distinct authors of PHP over time. declined If the majority voted against the RFC. After six months and several changes to it. it gets declined. the author can resubmit it. The GNOME project targets ease of use and user friendliness and therefore aims for coherent and good user interfaces [GNO#5]. withdrawn The author can withdraw the RFC without calling for a vote if they think the RFC is irrelevant or won't pass the voting. The name GNOME was initially an acronym for GNU Network Object Model Environment. 5. however that acronym was dropped. accepted Once a voting was successful. The number seems to be stable between 20 and 30 authors. the RFC is accepted and can be implemented. Officially.5 gnome project analysis 47 60 50 40 # Authors 30 20 10 0 1998 2000 2002 2004 2006 Time 2008 2010 2012 Authors Average Figure 5.5. GNOME is part of the GNU's Not Unix (GNU) project and licensed under the GNU GPL and the GNU Lesser General Public License (GNU LGPL).
5. GNO97]. meaning that it consists of several so called modules. they used the GIMP Tool Kit (GTK) originally developed for the GIMP graphics editor. Both were university students at the time when they set their aim to produce a desktop environment using only FOSS technologies. Instead of using Qt. libraries or utilities.31: Monthly activity of the most active GNOME Core developers. GNO#2. The desktop as well as the developer technologies can be found on workstations and large enterprises but also on mobile devices. the modules were reorganized into a GNOME Core suite and a GNOME Apps suite. With the recent GNOME 3 release a major overhaul with a significant redesign of the desktop environment and an entirely new user interface took place [GNO11]. GNOME is a modular project.5. . GNOME Core provides everything to run a basic desktop system and will therefore be analyzed in this context.5 gnome project analysis 48 leases and good support for users and developers. which at the time was licensed under a proprietary software license.5. Since the release of GNOME 3. which can be either applications. The disproportional amount of commits by Matthias Clasen can be interpreted with a high skill set and lots of effort he puts in the project. The GNOME project quickly grew into a large project which nowadays is the most popular desktop environment for UNIX type operating systems.1 History GNOME was first announced and started in 1997 by Miguel de Icaza and Federico Mena Quintero as a counterpart to KDE [Ger03. KDE relied on the Qt widget toolkit. 500 400 # Commits 300 200 100 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 Matthias Clasen Alexander Larsson Owen Taylor Emmanuele Bassi Christian Persch Kjartan Maraas Figure 5.
Spain Dublin. 5. there are similar roles for each module. Ireland Kristiansand.2 Community The GNOME project consists of a large user and developer community. GNO#7]. wishes or start discussions.5 gnome project analysis 49 event GUADEC I GUADEC II GUADEC III GUADEC IV GUADEC V GUADEC VI GUADEC VII GUADEC VIII GUADEC IX Desktop Summit GUADEC X Desktop Summit GUADEC XI venue Paris. which for example uses GNOME technologies such as GStreamer or GTK [GNO#2. Most of the communication inside the project is handled through mailing lists and IRC channels. Turkey Gran Canaria. Due to the large and modular composition of the GNOME project. Global decisions are mostly handled through the desktop-devel mailing list.2: Previous and planned GNOME conferences. the community holds a yearly conference under the name GUADEC. and while the conference only took place in Europe so far it is nevertheless considered worldwide by the community [GNO#1]. Spain The Hague. It stands for GNOME User and Developer European Conference. GNO#3. Netherlands Berlin. Germany Vilanova i la Geltrú. In this respect the developer community can be very much be seen as a flat structure [GNO#10.5. England Istanbul. Almost every GNOME module has a dedicated mailing list or IRC channel. Denmark Seville. committer Any person who contributed a reasonable amount of improvements to the GNOME project or to a single module can be- . Only very few teams and roles stand above all modules. Norway Stuttgart. France Copenhagen. Spain Birmingham. Ger03.5. GNO#10]. While there were about 3500 people contributing to GNOME and its applications. Additionally blogs are widely spread in the GNOME community and contributors often write blog posts about achievements. Spain date 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 Table 5. there is also a big community around the project. Next to several hackfests each year. Germany La Coruña.
063 22.000 # Commits 27. making and publishing releases.000 39.351 30. come a committer.580 40.000 15.608 2012 Figure 5.710 2002 19. The team size is not fixed and can vary over time.812 1998 2000 12.000 256 0 1996 5. Every module maintainer or translation team leader can act as a voucher.32: Yearly overview of commits to GNOME Core. maintainer Every module has one or more maintainers who will be responsible for releases.5 gnome project analysis 50 50.149 2004 Time 2006 24. A committer has full read and write access to all GNOME repositories. The leap in 2008 appears to be related to GNOME 2. one has to make a formal request to the accounts team along with one or several vouchers who can confirm ones contributions to the GNOME project.000 2008 45. Membership is only by invitation and often only when one person leaves the team to free up one space. The leaving person may recommend a new team member which the team will decide upon.929 24. Each commit will however be reviewed and approved by the maintainer of the module. They are the main contact for the community and therefore act as the leader of a certain module.22 or GNOME 2. . To become a maintainer one has either to create a new module which gets incorporated into the GNOME project or be asked by another maintainer.614 2010 47.264 48.24.820 20. A single module can be administered by multiple maintainers and one maintainer can administer several modules. approving or rejecting freeze break requests and defining the module list for GNOME releases. Furthermore the voucher will be responsible for the actions of the requesting person on the repositories. To get such an account.151 10. reviewing patches and the direction of a module.678 6.5. Their tasks include for example creating a development schedule. release team This team is responsible for a wide range of tasks concerning the development process of the GNOME project.817 19.
3 Release Process The GNOME project uses a versioning scheme with three numbers.5.4.3 28 3.4 3. An incrementation of the first number only occurs when the project does a ground-breaking change. played an important role in the first years of the GNOME project.10 2. design team Since GNOME 3 the design team holds a much more important role in the GNOME project as they primarily define the design of the GNOME user experience.0 Final release! GNOME 3.3.18 2. The numbers are however nevertheless called major.32 3.2. it only distinguishes between major and minor releases [GNO#4.2 1. GNO#6].2.4. 1.3.28 2.8 2.2.91 3.22 2.2 2.0 Final release! 3.14 2.0 1998 2000 2002 2004 2006 2008 2010 2012 2. This is done by designing the user interface and workflow of GNOME modules.3.1 26 28 19 Feature Proposals Period 7 September October 3.20 2.2 18 21 String Change Announcement String Freeze 16 Feature Freeze UI Freeze API/ABI Freeze 22 7 21 March November December January February Figure 5.30 3.3.90 3. Nowadays however they are more active in projects around GNOME technologies and often act as visionaries.26 2.1.x release series.x. For example the unstable 3.33: Release schedule which will lead to GNOME 3.5. However.x series will become the stable 3.16 2.3. 5. gnome founders Miguel de Icaza and Federico Mena Quintero.0 2.4 2.2 GNOME 3.24 2. such as using GTK+2 for GNOME 2. minor and micro numbers.3. .3. For the minor version number the GNOME project uses odd numbers indicating an unstable series and even numbers for stable releases.x or the new user experience with the GNOME shell and GTK+3 for GNOME 3.1 23 Code Freeze 3. Additionally they play an important part in the feature based development process.5 gnome project analysis 51 3.5 8 3.2 Figure 5.2. the original GNOME founders.4 2.6 2.0 1.34: Major releases of GNOME.3.92 3.12 2.
The release schedule includes future stable minor releases. while few minor changes may occur to comprise conferences or holidays. a module maintainer can decide to provide more stable releases [GNO#7]. GNO#6].000 # Commits 4.000 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 Commits Average Figure 5. Over the years it stayed mostly the same. It seems that most developers are employed. The schedule furthermore includes proposal and freeze periods which will be described in the following [GNO#4. The release schedule is fixed with a new major release appearing every six months. To achieve this. The unstable series consists of eight releases which are distributed over six months. Of course. Each stable release series consists of at least three releases which are named with x. .y.000 1.y.2.35: Amount of commits per month of core contributors.000 2.000 3. The high number on Monday can be explained with the release preparation which are always done on Monday evening. and so the current and future schedule overlap.5 gnome project analysis 52 7.0 to x. The project quite shows a linear growth with peaks every six months.000 5.36: Time based view on commits of core contributors.5.000 6. the release team publishes a release schedule in the same frequency [GNO#4]. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour Figure 5.
This excludes of course bug fixes. the freeze With the first beta released the first freeze takes action. hard code freeze With the release of the release candidate no source code changes are allowed without approval of the release team. After publishing the next major GNOME release the Hard Code Freeze ends but all other freezes remain in action for the stable series.5. No user interface changes. the proposal period ends.37: Amount of distinct authors of GNOME Core over time. Approximately a month later. Around two weeks later the release team meets and decides about proposed features with the community input given up to this point. . GNOME developers can propose features for the next major release and discuss them with the community. when the first unstable release gets published. Additionally new translatable strings must be announced to the translation and documentation team. new features or developer API changes are allowed without approval from the release team. string freeze With the second beta release no string changes are allowed anymore without confirmation of both the release and translation team.5 gnome project analysis 53 350 300 250 # Authors 200 150 100 50 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 Authors Average Figure 5. Especially the development of GNOME 3 which started in 2010 appears to have attracted additional developers. feature proposal period After a major release gets published the feature proposal period starts. Documentation and translation however can continue.
User Interface (UI) and API/ABI Freeze the feature has to be finished and working. All of these fields are required and a feature will not be accepted until all are completed. The development of each module was planned and executed by the maintainers. GNO#9]. a list of involved parties and the current state of the proposal. After each major release and until about a month later. however it is no longer in use. After that time the release team will meet and depending on the feedback of the community decide about the inclusion of each feature. A feature proposal is composed by a description of the problem to be solved. With the release of the first beta release and the establishment of the Feature. the release team together with the community decide about the inclusion of new modules. Since GNOME 3. The community has time to discuss the features and improve them for roughly one and a half months. The name was originally an acronym for Kool Desktop Environment and later for K Desktop Environment. Since 2010 and the release of KDE 4.6 kde project analysis KDE is a desktop environment designed to run on UNIX based systems as well as Microsoft Windows and Mac OS X systems [KDE#9.5. Next to the design driven approach the module inclusion changed to a feature inclusion approach [GNO#8. also known as KDE Base. However the design team has no decision making authority and a maintainer can ignore the design team's proposal. KDE SC is licensed under the GNU GPL and GNU LGPL. 5. This leads to a consistent process with a uniform user interface.4 Development Before the release of GNOME 3. If a feature gets accepted the author of the feature will be its leader and responsible for the completion. this analysis will be limited to the core of the KDE SC.6 kde project analysis 54 5.4 the project is known as KDE Software Compilation (KDE SC). one can propose a feature for inclusion. KDE is a modular project consisting of several libraries which allow developers to build their programs around the platform. It is composed by the desktop environment named Plasma Desktop and several core applications for the daily needs.5. This means that all new features concerning user interfaces or applications have to go through the design team [GNO#3]. If not. one or more authors. As the KDE project and the KDE SC stand for a wide range of technologies and applications. KDE#1]. Every GNOME contributor can create a feature proposal in which one describes a feature they would like to see in the next stable GNOME release. the development workflow changed into a more design driven development approach. it may be postponed to the next major release. .
most importantly kde-devel and kde-core-devel [KDE#10. That is also the reason. In 2004 it changed the name to Akademy.6 kde project analysis 55 5.6. Matthias Ettrich chose the Qt framework as the graphical library. In 2009 the KDE project renamed the project to KDE SC and redefined the project as a community which delivers FOSS for user interfaces by emphasizing the KDE technologies [KDE#8]. . Furthermore communication can happen over IRC channels. While the first one is mostly used for communication by application developers. the latter one is for communication on the KDE core project. At the same time. tablets and smartphones. 5. which was and is developed by the company Trolltech. However KDE SC only contains projects which derive from the project itself and share a common release cycle. The most important KDE conference is the annual Akademy which is held at different locations in Europe [KDE#7]. All software created with KDE technologies are KDE projects. such as for desktop computers. Also.6.2 Community The KDE project is one of the largest FOSS projects and according to the community the second largest after the Linux Kernel [KDE#9]. However. the community spans around projects based on KDE technologies. which was highly popular at that time. KDE#2]. There are about 1800 active contributors to the project and its surroundings and is used by over a million people. KDE 1.1 History KDE was first announced by Matthias Ettrich in 1996 as a desktop environment for end users with the same look and feel for all applications [KDE96]. it was debated if that license was compatible with the GNU GPL and in 2000 the framework was licensed under the GNU GPL which ceased the criticism. The centerpiece is the Plasma Workspace which exists for several devices. The first KDE conferences were however named after the current release which started with KDE One in 1997. blogs or forums. why the conferences did not take place annually at that time. Most of the communication in the KDE project takes place via mailing lists. KDE SC 4 was a new approach to the desktop metaphor and created a new user experience for users. netbooks. Trolltech dual licensed the framework under the Q Public License (QPL) and a proprietary software license. The name KDE was a word play with the existing Common Desktop Environment (CDE).0 was then released in 1998 [KDE#7]. Beginning with 2009 the project incorporated the conference into the Desktop Summit in collaboration with the GNOME project.5.
however an approval is . Germany Erlangen. Spain Dublin. Ireland Glasgow. Spain Tampere. there are many ways to become a module coordinator. The KDE sysadmin team will then check the application and grant an account or not. A module coordinator plans and executes releases and the direction of a single module. There are few groups who stand above those teams and only take care about coordinating the project [KDE#3. The primary communication method is the kde-coredevel mailing list which is publicly readable. instead the team discusses the issue and comes up with a solution together. Germany Trysil. Czech Republic Ludwigsburg. contributor After having contributed to any KDE project for some time and planning to contribute in the future. module coordinator As the KDE project is highly modular. KDE#5]. Germany Málaga.3: Previous and planned KDE conferences. date 1997 1999 2000 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 Due to the size of the KDE project it is organized around many independent teams with a communication structure between them. Belgium Gran Canaria. Scotland Sint-Katelijne-Waver. Germany Nové Hrady. Estonia Table 5. a KDE contributor account can be requested [KDE#2.5. In the request one must state why one is interested in having an account. each application or library has an independent team with its own structure besides a few exceptions. The most obvious is of course by unweary contributions to a project. Finland Berlin. Germany Tallinn. KDE#10]. Norway Nürnberg. There is no single person inside the team responsible for decision making.6 kde project analysis 56 event KDE One KDE Two KDE Three Beta KDE Three Kastle aKademy aKademy aKademy aKademy Akademy Desktop Summit Akademy Desktop Summit Akademy venue Arnsberg. As the teams are so diverse. core team One of the most important teams is the core team as it defines the overall direction the project is heading [KDE#10].
release team The actual release and the release schedules are provided and enforced by the release team [KDE#11]. . KDE#12]. Seigo Stephan Kulow 2008 2010 2012 David Faure Dirk Mueller Laurent Montel Marco Martin Figure 5.6. However he has still an important voice in the community and contributes indirectly to KDE by his role in the Qt project. required to join it.3 Release Process The KDE project uses a versioning scheme with three numbers and distinguishes between major and minor releases [KDE#11. Also they decide on code freeze breaks and take decision about future features of a release. The numbers are called major.6 kde project analysis 57 500 450 400 350 # Commits 300 250 200 150 100 50 0 1996 1998 2000 2002 2004 2006 Time Aaron J.5. The KDE project does not define clear restrictions to membership and therefore a membership is granted by invite only after distinguishing or outstanding work for the KDE project. kde founder Matthias Ettrich. The release team makes sure that all modules are following the release schedule and are in a good shape. It is composed by module coordinators and other release team members who actually implement the releases.38: Monthly activity of the most active KDE Base developers. the founder of the KDE project is no longer actively involved in the project as he works full time on the underlying Qt framework. 5. The most active developers almost switched completely when comparing the inception phase to nowadays. minor and micro numbers. KDE#6.
000 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 966 7.0 2. except bug fixes or small enhancements.947 26. the release team publishes a new release schedule after each major release.006 2004 2006 11.201 14.0 4.2 SC 4. The development and release of KDE 4 and following releases in 2008 certainly attracted a lot of attention.208 15.3 3. 1.000 10.000 2. A standard release however has to maintain backwards compatibility with its series. They are often planned a long time ahead.000 25.1 4. however a KDE application has to work on all releases of the same platform. Beginning with KDE SC 4 the cycle changed to a major release every six months and a maintenance release roughly every month except when a major release comes out.903 15.7 Figure 5.1 2.166 5.089 15.1 3.0 3.39: Yearly overview of commits to KDE Base.3 SC 4.4 SC 4.4 4.579 29.2 3.000 30.5.159 29.40: Platform and standard releases of KDE.6 1998 2000 2002 11. The major and minor numbers define major releases while the micro number defines maintenance releases.000 # Commits 20. Maintenance releases are not allowed to come with new features. The release is a platform or standard release depending on whether the major or minor numbers change.154 2008 2010 2012 1.2 3. A platform release defines a new series of releases which can break backwards compatibility to the previous platform release. usually including changes of used libraries or used library versions. The schedule includes all .5 4.5 SC 4.660 58 26.0 2.000 15.538 16. To ensure the release schedule. They can have new features and user interface changes.1 3.6 kde project analysis 35.578 15.219 Figure 5.
However it is possible to request an exception by the release team.500 2. soft message . Not finalized features have to be postponed to the next major release.000 500 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 Commits Average Figure 5.500 1. the development phase of KDE 4 and following releases is quite visible. deadlines and freezes which will lead to the next major release and includes future maintenance releases. This means of course that two release schedules will overlap during the month before the new major release. dependency freeze Approximately two weeks before the first beta release no new or additional dependency versions are allowed anymore. Additionally the existing API should be almost finished and if changes are made they should be reported to the relevant teams. soft api and hard feature freeze A week before the first beta release no new strings and changes to the existing messages can be made except corrections. The following freezes and releases are provided and enforced by the release team [KDE#6].6 kde project analysis 59 3. Again.000 2. . even if they were planned for this release cycle. Lastly no new features can be added to the projects.41: Amount of commits per month of core contributors.000 # Commits 1.5. soft feature freeze Approximately three weeks before the first beta release no new features are allowed except already approved and planned features.
Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour Figure 5.5. beta release Approximately two months before the major release the first beta release gets published.6 kde project analysis 60 180 160 140 120 # Authors 100 80 60 40 20 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 Authors Average Figure 5. The project appears to grow quite linearly with a small down before the start of the KDE 4 development and the appropriate boost during and after the development. message and documentation freeze Five weeks before the major release the API. The times are almost equally distributed probably meaning that there exist a lot of employed and volunteering developers in the community.43: Time based view on commits of core contributors. translatable messages and the documentation must be finished and can't be changed anymore.42: Amount of distinct authors of KDE Base over time. This is usually followed by a second beta release two weeks later. hard api . release candidate Approximately a month before the final release the first release candidate will be published. . Two weeks later the second release candidate follows.
6 kde project analysis 61 final release Three weeks after the last release candidate the final release will then be published. . During the soft feature freeze it is decided whether the feature will be available for the upcoming major release or if it will be postponed to the next major release. new project goals are set using feature proposals [KDE#3. This normally happens after each major release when KDE developers have the time to propose new features for the next major release.5. A KDE developer is free to implement the feature by himself. minor releases A new minor release will be published each following month until the next major release gets published. Each feature must have an author who is willing to implement it. This normally leads to four minor releases. it can continue.6.4 Development During the development of a new major release. KDE#4]. Otherwise it will be postponed. If the implementation already started and is almost finished. 5. This often limits the number of features to already contributing KDE developers. however the process is often accompanied by a discussion with the specific team and several adjustments to the implementation. This development process is a quite deliberate approach where people are free to implement what they see missing in the project.
the original founders are still present and have an influential voice.7.7.4 License A project cannot be counted as a FOSS project without being licensed under a FOSS license. in others the original authors are no longer involved.3 Scope of Analysis As FOSS projects often are hard to analyze due to their size and unclear definition of modules. founders In some projects. To analyze this further.7. . By covering all listed points a project should have been analyzed thoroughly and lead to a reasonable breakdown of all projects. This helps to provide a thorough analysis without leaving things unattended. Listing all used licenses can ensure this fact. the project category can help to contrast projects of the same and other categories. 5. They are essential to put a project under the right light and make it comparable with similar projects.1 Description of the Project A general description of the project provides information on the goals and current state of a project.7. the following catalogue was established based on the previously gathered data and analysis.5 History A project's history shaped the community and the structure of a project to the state it has today. As such it doesn't provide too much information about the project itself. 5. the authors have to be introduced and their role will be analyzed in the community part.5. 5.7 proposition for a project analysis catalogue To characterize the development processes of FOSS projects. However it is also interesting to see whether development models and communities differ if they are using a different FOSS license. the scope will be limited to a well known subset of the whole project.7 proposition for a project analysis catalogue 62 5. but is useful for later comparisons with other projects. 5. 5. As such the analysis of the history can bring up interesting findings.2 Project Category In order to provide methods to compare projects.7.
role of the founders In some projects the founders are still actively involved and in some not. a project would not exist. their influence varies. the founders often have a very important role in the project development process.7. Depending on the project. version naming Each project provides a specific version naming scheme to which they adopt and which characterizes major. Also. roles The development process is often defined and lead by important roles in the project. It is interesting to compare the different methods of communication in several projects depending on their development structure and size. As this takes time.6 Community The people behind the project are the driving force.7. conferences and meet . that there is enough interest available to provide the needed money for preparing such events. As this is a very essential part of the development processes it will be analyzed with the following classification.7 proposition for a project analysis catalogue 63 project age Projects always need time to evolve and find their best practise development process. It also shows. communication The communication is a vital thing in an open project. community size An important measure is the approximate size of a community. minor or bug fixing releases. Therefore it is important to analyze the diverse community of each project. This information is vital to understand the project's release schedule. the project age can give some information in what development process state this project is and how it will evolve in the future.7 Release Process The release process is the action which leads to new releases. . 5. 5. depending on what role a person has in the project.5.ups Meetings of developers are an important element of the development process in FOSS projects. Without them. Several structural decisions and changes inside the project can depend on its size.
As they define deadlines or important steps in the process of creating new releases it is most interesting to compare different schedules. This point covers. 5. groups of people who define new features and lead the development process. Minor releases on the other hand often only contain fixes.8 Development The actual development is closely interweaved with the release process and defines how and when the development of a project takes place. release schedule The release schedule defines a concrete plan up to a new release and is often either time or causal dependent.7. . important steps in the schedule These steps often define freezes or specific points in time when all members of the project are restricted to for example not provide new code in order to increase the stability of the new release. development workflow The actual development process as often defined by the project leaders provides ways and methods to propose and develop new features for the upcoming release.7 proposition for a project analysis catalogue 64 characterization of releases Most projects provide some kind of major and minor releases where major releases do come with new features and often backwards incompatible changes. feature inclusion process Whether projects do have established a concrete process for how and when new features are integrated in a project or not will be capped in this point.5. if existent. It is now interesting to see where and how the line between the two is drawn. development lead It is hardly imaginable that projects exist which have a completely unstructured development process and have no development leaders in place. It also covers the daily development and how new code finds its way into the project's repositories.
8 postgresql project analysis The PostgreSQL project facilitates an Object-Relational Database Management System (ORDBMS) which runs on all major systems such as Linux. 5. which consists of the PostgreSQL database server.5 Community The PostgreSQL project has a quite large community which will be described in the following. Not until 1996 it was developed in a university style fashion trying to explore new areas in database management systems. 5.4 History The project was started in 1986 by Lawrence A. Pos#8]. It was then released as FOSS by two students of Stonebraker with the new name PostgreSQL the adopted Structured Query Language (SQL). several tools and bindings around it [Pos#6].5. PostgreSQL is quite popular amongst its users and has won several prizes for the best database management system [Pos#2]. Rowe and Michael R.8. It only requires to maintain the copyright and licensing information in the licensed source code and therefore it is quite similar to a BSD license. Pos#10]. Stonebraker at the University of California in Berkeley under the name POSTGRES [Pos#9]. UNIX. 5. It then received a big development boost and emerged to one of the leading ORDBMSs.3 License The PostgreSQL project makes use of the PostgreSQL license. more specifically a ORDBMS [Pos#1].8 postgresql project analysis 65 5.1 Project Category PostgreSQL is a database management system. . 5.8. 5. which is a FOSS license [Pos#8. Microsoft Windows or Mac OS X [Pos#1.8. The group behind the project is known as PostgreSQL Global Development Group which consists of several volunteers and employed developers. According to the project it is the leading FOSS database system with thousands of users and contributors [Pos#11].2 Scope of Analysis The PostgreSQL Core Distribution will be analyzed.8.8.
Only bug and security fixes are allowed for those releases. Such a release occurs roughly once a year [Pos#12. roles The developers are split into three groups [Pos#4].5. . The most important mailing list for development is the pgsql-hackers mailing list [Pos#5]. role of the founders Michael R. although also IRC channels exist. characterization of releases The incrementation of a major or minor number defines a major release including new features and often backwards incompatible changes [Pos#14]. Major contributors are people who introduced or maintain big features to the project. 5. 38 major contributors and 42 contributors [Pos#4]. The core team decides on the general direction of the PostgreSQL project as well as the release cycle and the releases. Each major release is supported for five years by the PostgreSQL project. Pos#8]. Stonebraker and Lawrence A.6 Release Process The used release process is highly structured and will be described in the following. The contributors are all other who provide patches to the project. They are therefore no longer actively involved in the project. conferences and meet .ups The most important international conference is the annual PgCon which was first organized in 2007 [Pos#7].8 postgresql project analysis 66 community size According to the project there are six core team members. Rowe did not follow the project anymore when it was published as FOSS in 1996 [Pos#9].8. However there are a lot of local conferences and workshops available. However in some cases the project can decide to drop support for a specific release if bugs cannot be resolved without risking the stability. communication The development related communication takes mainly place through mailing lists. The number of total contributors might however be higher. minor and micro number [Pos#14]. version naming The PostgreSQL project uses a three digit number scheme for the releases which consists of a major. Adding no longer active people the number sums up to around 140. as the project only includes people who have made contributions over a long time. For each major release a number of minor releases exist which are defined by incrementing the micro version number.
Quite all decisions are made by them as well as most new features and code contributions. Pos#8. All other patches however have to be reviewed and are therefore sent to the pgsql-hackers mailing list. happen four times each two months apart. Pos#3]. depending on whether it is in progress or finished [Pos#13]. more alpha releases can follow. New features are proposed in the Commit Fests. development workflow Small patches are often submitted directly to the repository if they are done by a major contributor or a core team member [Pos#5]. development lead The PostgreSQL project is mostly driven by the core team [Pos#5. A patch can have several states.5. a review results in a discussion on the mailing list and follows an acceptance. feature inclusion process The already mentioned Commit Fest is a periodic break in which no new development is done. also known as Commit Fests. important steps in the schedule The Commit Fests are the only possibility to add new features to the project and are therefore a vital part of the development process [Pos#12.8. A single Commit Fest usually runs for about one month explaining the gap of one month between each Commit Fest.7 Development The development of the PostgreSQL project is closely entangled with the release process and will be described in the following. the following states might apply. Such reviews. One such event is lead by a Commit Fest manager who is responsible that all submitted patches will be reviewed. The release schedule gets planned and decided during the PgCon conference.8 postgresql project analysis 67 release schedule As major releases occur every year. . 5. already existing patches are reviewed and receive feedback by the core team and other developers [Pos#3]. If a patch is in progress. Pos#4]. if no beta releases are published. After the last Commit Fest. However. It basically starts each June with a commit review in which possible patches might be included in the next major release. Often. In the month between an alpha release is published. a return with feedback or a rejection. If no more critical errors are found several release candidates will be published which will lead to the next major release. the project uses the same release schedule every year along with some minor improvements from the last years [Pos#12].
waiting on author A new version of the patch is expected by the author. MariaDB was forked from the original MySQL when Oracle bought Sun Corporations as it was unclear how the development and licensing of MySQL would change after Oracle's acquisition [Mon#1. Mon#12]. It runs on all major platforms and is widely used for many web applications. Ora10. discussing review results The review was done. Both provide a compatible database server together with several tools for running it. 5.5. committed The patch was applied and no remaining issues are assured.9.1 Project Category MySQL and MariaDB are database management systems.9 mysql / mariadb project analysis MySQL is according to the project the world's most used ORDBMS [Sun08].9 mysql / mariadb project analysis 68 needs review A patch is not reviewed and waiting for a review. A new version of the patch is expected for the next Commit Fest. It is now waiting for a final review. returned with feedback The patch was reviewed and feedback was given. many of the original MySQL developers moved to the MariaDB project making it interesting to analyze both projects together. 5. more specifically ORDBMSs [Mon#1]. Ora#2]. . MySQL was originally developed by MySQL Ab. 5. rejected The patch was rejected and won't make it into the next major release. later bought by Sun Microsystems and now owned by Oracle Corporation [Sun08. The states of a patch in progress are the following. however it is discussed on the mailing list. Also. It is intended to be a drop-in replacement for MySQL with full compatibility to it.2 Scope of Analysis The analysis includes the MySQL Server package and MariaDB. ready for committer The review was done and no issues were found.9.
3 License MySQL is dual-licensed under the GNU GPL and a proprietary license. 5.9. Sun Microsystems bought MySQL Ab in 2008 which lead to the abandonment of the MySQL founders Micheal Widenius and David Axmark [Sun08].9 mysql / mariadb project analysis 69 5.9. although also IRC channels exist. the MariaDB community will be analyzed including facts about the pre-Oracle era of MySQL. The newly founded Monty Program Ab company however lists at least 20 people working on MariaDB [Mon#12].4 History The MySQL project was started in 1994 by Michael Widenius and David Axmark by launching the company MySQL Ab [Ora#2]. In 2010 Oracle Corporation bought Sun Microsystems and announced changes to the current development processes [Ora10].5 Community As most of the key-authors of MySQL moved to different projects such as MariaDB and since there is not much insight available about the current happenings inside Oracle. The first version of MariaDB was released in 2010 as MariaDB 5.1 which is compatible to MySQL 5. As the future of MySQL in terms of FOSS was quite unclear at that time Michael Widenius forked MySQL in order to provide a community developed FOSS database [Mon#12].ups The MariaDB project has not yet set up a conference. conferences and meet .9. .1 [Mon#9]. The most important mailing list are the maria-developers and mariacaptains mailing lists [Mon#11]. In 2000 MySQL was released as FOSS under a dual licensing model. which was quite popular at that time. community size The specific size of the community is not known and is fractured due to the two acquisitions by Sun Microsystems and Oracle Corporation. 5.5. Since then the MariaDB project tries to stay compatible with MySQL but also to provide better performance and more features. communication The communication of the developers mostly takes place through mailing lists. MariaDB is single licensed under the GNU GPL [Mon#10]. Originally it was a clone of the mSQL project. however the MySQL project mostly meet once a year at the MySQL Users Conference & Expo which was first organized in 2003 [Ora#3].
if nevertheless MariaDB is mostly driven by MariaDB captains (which he belongs too). A developer is a person who produces enhancements and new features for MariaDB [Mon#2. A major release is defined by an incrementation of the minor number and allows new features to be added to the release. Finally a release coordinator exists who normally is a captain [Mon#6]. Mon#5]. release schedule The MariaDB project does not have a fixed release schedule and is quite similar to the MySQL release schedule [Mon#7. In the current releases it marks the file format in which the database is stored. 5. He also does not follow their development anymore. all new features for the next stable major release will be collected.5. Mon#4. Every feature a MariaDB developer agrees to implement in the time frame to the next major release will be considered as a new feature. Mon#8]. minor and micro number [Ora#1]. To become a captain one has to make a formal request on which the other captains will vote [Mon#8].9 mysql / mariadb project analysis 70 roles The developers are split into two groups. role of the founders Micheal Widenius took a vital role in the fork and new project MariaDB [Mon#12.9. In most cases the releases are backwards compatible. However they have no right to commit their work before it was reviewed. Mon#1]. By definition the coordinator gains no additional rights and only leads the communication and release management of the project. the micro number defines minor releases in which only bug and security fixes may apply. characterization of releases The incrementation of a major number defines big and often incompatible changes to their predecessors [Ora#1]. but if not. After most features are . It has criteria in place when specific releases can happen. Finally. do the code reviews and take care of the project. The captains are developers who are working for a long time for the project and have made substantial improvements. Captains give the direction of the project.6 Release Process The used release process is structured and will be described in the following. Mon#3. version naming The MySQL/MariaDB project uses a three digit number scheme which consists of a major. David Axmark however left Sun in 2008 and is no longer actively involved in either the MySQL nor MariaDB project. After the last stable major release. He has an important voice in the community and still gives general directions. there are always upgrade paths available [Mon#9].
5. after a beta release the whole API cannot be changed anymore. 5. A feature can have multiple states. Finally the stable release should have no more open bugs or critical errors and is ready for general usage. development lead The development of the MariaDB project is mostly driven by the MariaDB captains [Mon#3. The criteria for beta releases are that the proposed features are finished and no serious bugs are open. . Mon#5]. complete The feature is ready and will be part of the next release. such as the following. feature inclusion process After a major release a developer can propose new features [Mon#5]. Bigger features will be accepted after each major release.9. cancelled The feature was cancelled for this release but might be proposed for the next. development workflow Small patches are often submitted directly to the repository if they are done by a captain. Mon#11]. The founder of MariaDB and MySQL Micheal Widenius plays an important role and even if not stated by the project has an important voice about the direction. code . important steps in the schedule The feature proposal period. alpha and beta releases are of course the most important steps in this schedule as they restrict new features or code changes further [Mon#7].7 Development The development of the MySQL/MariaDB project is loosely entangled with the release process and will be described in the following. The gamma or release candidates are believed to be ready for general usage. Mon#3]. All other patches by developers will be reviewed and applied if they suit the project well [Mon#4. It then will move to the so called worklog page of MariaDB where other developers see the current status of a feature. however testing is still required. assigned The feature was assigned to a developer who will be in charge to provide the feature for the next release. A feature will be accepted if a developer accepts that feature and is willing to implement it [Mon#2.review The feature will be reviewed by other MariaDB developers and captains. For example.9 mysql / mariadb project analysis 71 nearly finished one or several alpha releases follow.
however due to its structure it can be seen as independent from a companies influence. The mission of the project is to lead the advancement and it is also known to incorporate new products and software very quickly.assigned The feature is still unassigned and no developer has claimed this feature yet. however the latter one refers to the community which builds the project. As it only features FOSS. un . as the name already states. 5. For own software creations the GNU GPL is mostly used.10 fedora project analysis The Fedora project provides a so called Linux distribution which is a collection of FOSS and is based on the Linux kernel [Fed#15.10.10. 5.10 fedora project analysis 72 in .3 License As the projects goal is to provide a FOSS based product only FOSS licenses are allowed [Fed#10]. an operating system [Fed#15]. 5. The project provides a list of acceptable licenses.hold The feature will not be developed further until the status can be changed back to in progress. The distribution is also called Fedora operating system or Fedora project. This could happen if a technical problem arises or the feature is put up for a discussion.documentation The feature is completed code-wise but still has to be documented.10. in . The project is mostly sponsored by Red Hat. 5. Fed#14].1 Project Category The Fedora operating system is.2 Scope of Analysis The operating system provided by the Fedora project will be analyzed.5.4 History The original Fedora project was created in 2002 by Warren Togami in order to enhance the quality and number of packages available for . the Fedora operating system is also FOSS. 5.10.progress A developer is currently implementing this feature. which consists of a large collection of FOSS needed to run and work on a computer. on .
Fed#14. roles The Fedora project has a quite flat structure with several teams and Special Interest Groups (SIGs) [Fed#9. The usual way to be a part of a specific team is to provide several contributions until one can apply. Fed#12]. Since then the Fedora project provides a community distribution while Red Hat Enterprise Linux is an officially supported Linux distribution which derives from Fedora versions. . Later the project changed the name to Fedora.5 Community The Fedora project has a quite large community which will be described in the following. communication Most of the communication takes place over mailing lists [Fed#15.ups Since 2005 the Fedora project organizes the Fedora Users and Developers Conference (FUDCon) which is held annually in various places around the world [Fed#7]. Desktop or Usability. SIGs or technical matters [Fed#4]. blogs or the weekly newsletter [Fed#6. For example the total number of active accounts exceeds 30. 5. however the most important general development related mailing list is the devel mailing list. Additional communication happens through several IRC channels.5. Fed#2]. The general direction and guiding decisions however are handled by the Fedora project board which consists of five community elected people and four appointed by Red Hat [Fed#1]. Fed#8]. which handles new features. a community elected team. Examples for such teams and SIGs are Release Engineering. This number however does not describe the actual size accurately as it includes many users of the operating system. Fed#2. community size The exact size of the community is unknown. The technical leadership is handled by the Fedora Engineering Steering Committee (FESCo). Each team or SIG is in charge for a specific sub project or area in the project. In 2003 the development of Red Hat Linux stopped and was merged with the Fedora project. forums.10.000 people. Each of the mailing lists is quite focused on a certain sub-topic. Each team is lead by one or several people. Fed#9. Until 2006 the operating system was known as Fedora Core.10 fedora project analysis 73 the at that time existing Red Hat Linux distribution [Fed#15. conferences and meet . Fed#12]. however the project consists of a quite large group [Fed#13]. The name Fedora originates from the Red Hat logo which shows a person with a fedora hat.
10.10 fedora project analysis 74 role of the founders Warren Togami is still involved in the Fedora project. . Fed#5]. such as SpamAssassin or K12Linux which is a distribution built on top of Fedora [Fed#14]. 5.6 Release Process The release process used is highly structured and will be described in the following. After a major release the planning and development can start. This single number defines major releases.5. Therefore each incrementation of the version number defines a new major release. 5. feature freeze and feature complete milestones in the release schedule [Fed#5]. Fed#5]. The alpha release will be followed by a beta and final release candidate.10. no new feature will be accepted. however he focuses more on Fedora related projects. In some cases. version naming The Fedora project uses a single number versioning scheme [Fed#8. the schedule can be slightly adjusted if critical bugs appear and can't be solved in the original time frame. characterization of releases There are no minor releases since updates to the operating system come via single updates of the affected packages [Fed#8. important steps in the schedule The most important steps are the feature acceptance. development lead The development of the Fedora project is mostly driven by the FESCo which decides on new features and the technical direction of the project [Fed#4]. In each of the named steps the FESCo will decide if a feature will be accepted or be in the next release depending on its completeness. release schedule The Fedora project uses a fixed release cycle with a new major release every six months [Fed#5.7 Development The development of the Fedora project is quite entangled with the release process and will be described in the following. One week before the alpha release. The release schedule is proposed by the release engineering team and approved by the FESCo. Fed#11]. Depending on whether each of the previous releases was postponed or not the final release will be published approximately six months after the previous major release. Each major release is then maintained until one month after either two releases or 13 months.
before the beta release or if the owner does not update the feature status. 5. 5.11.11 debian project analysis 75 development workflow The development process of the Fedora project is quite open [Fed#11.3 License The project's goal is to provide an operating system consisting entirely of FOSS [Deb#11. an owner. Additionally a feature can be dropped if it is not completed at the feature freezer. The mission of the Debian project is to provide a free operating system in the meaning of FOSS. However. an operating system. Even if there are other kernels available. there are many SIGs available which steer the development of a certain area in the project.5. Deb#14]. as the name already states. Fed#4]. such as the Linux kernel [Deb#2.11. the current status and several other points. This includes a description of the problem.2 Scope of Analysis The Debian GNU/Linux operating system provided by the Debian project will be analyzed. such as the FreeBSD. feature inclusion process To propose a feature for the next major release a formal feature proposal has to be made [Fed#3. Any Fedora community member can propose them and the FESCo decides on the acceptance of the feature. Linux is the most prominent one. Debian often gets called Debian GNU/Linux. As already stated above.11 debian project analysis The Debian project provides an operating system on top of various kernels. ready for FESCo when it can be proposed to the committee and finally accepted if the voting by the FESCo was successful. 5. Depending on the SIG the development workflow can vary. A feature can be either incomplete when the proposal is not ready. it is possible to install non- . Fed#12]. to provide a full featured operating system with high standard and to have a big evolving community. however the general direction is always given by the FESCo. which consists of a large collection of FOSS needed to run and work on a computer. Therefore. ready when it is disposed for review.1 Project Category The Debian operating system is. Deb#13].11. NetBSD or Hurd kernel. The Debian project is known as a very stable operating system and is therefore often used on servers. 5.
Deb#14. Debian maintainer have restricted access capabilities [Deb#5].11. 5. The name is a fusion between Ian and the first name of his wife. in order to provide a distribution which was developed in an open style and in the spirit of a FOSS development process [Deb#2. forums and blogs available. So far it was organized in various regions and continents worldwide. Additionally . SSRD08]. but the GNU GPL is mostly used for own creations. Deb#6]. A Debian contributor is any person who contributes to the project. Deb#1. 5.5 Community The Debian project has a large community available which will be described in the following. conferences and meet . Deb#10]. Debra. The Debian project established several policies and contracts to ensure the future freedom of the project. although it was not the first. the concept of a distribution was quite new and Debian can be counted as one of the early distributions. The most important for development is the debian-devel mailing list. According to the Debian Free Software Guidelines (DFSG) the project itself only accepts FOSS licenses.5. At that time.4 History The Debian project was created by Ian Murdock in 1993. For quite every aspect or subproject there is a mailing list available. but has no additional rights [Deb#14]. communication Most of the communication is handled through several mailing lists [Deb#12. Additionally there are many IRC channels.11 debian project analysis 76 free software too. On top there is a project leader who gets elected by the Debian community every year [Deb#10. At least one Debian developer must then approve this person. Deb#9]. SSRD08]. roles The Debian project has a quite hierarchical structure with several teams [Deb#10.ups The most important conference in the Debian project is the annual DebConf which took first place in 2000 [Deb#3]. Debian is still the most significant distribution that is not backed by a commercial entity. To become a Debian maintainer one has to go through a formal process requesting the role. The Debian developers have full access rights and often maintain parts of the project [Deb#4].11. community size The community size is quite large and ranges between 800 and 1000 active developers [Per11. Beneath the project leader there is a technical committee which drives the project's technical decisions.
version naming The Debian project uses a three digit number scheme which consists of a major. At this time a freeze is called in and a release follows shortly thereafter.5. release schedule With three active release branches. testing and unstable [Deb#8. Deb09]. The Debian project does not have a fixed release schedule. However there is some effort to have regular releases and predictable freeze schedules. The micro version number indicates bug fixes to the major release. 5. For the next release the Debian project is trying to adopt a time based freeze and release cycle [McG11]. important steps in the schedule As the new release schedule is not clear yet.11. A new release is announced when the release team and core team think it is ready. The minor number was used until Debian 3.11. In that case the old stable will be named as oldstable and maintained for one more year. Deb#7.11 debian project analysis 77 there are many teams in charge for parts of the project. Ports or the distribution of the project. 5. Deb#7]. minor and micro number [Deb#8]. Deb#1]. the actual releases change if a new stable version will be introduced [McG11. such as Release Engineering.1 as a major release indicator. . However the final freeze and the announcement of release goals by the release team are certainly important steps within the schedule. Although he still works in the FOSS field he is no longer involved in the Debian project.7 Development The development of the Debian project leads directly to future releases and will be described in the following. Each of the three is a major release and indicated by a different major version number. however this is not the case anymore. role of the founders Ian Murdock led the project from its beginning until 1996 as the project leader when he passed this function to Bruce Perens [Deb#14. The testing branch will become the new stable and the unstable the new testing. a characterization of the important steps is not possible. characterization of releases Debian has always at least three active releases available: stable.6 Release Process The used release process is highly structured and will be described in the following.
development workflow As the stable branch is closed for new features.5. . At some point during the development the release team will announce the chosen release goals. The release team will decide on each goal and set it for a specific release or postpone it. Depending on that and the goals set by the project leader. Debian developers start to work.11 debian project analysis 78 development lead The development is mostly driven by the project leader and the technical committee who set the goals for future releases [Deb#10]. If those changes have been tested for long enough they eventually will be merged with the testing branch. Parts of the Debian project will either be maintained by single Debian developers or co-maintained by others. McG11]. Deb#4. Deb#7]. feature inclusion process The Debian project uses so called release goals which are proposed by Debian community members and chosen by the release team [Deb09. In addition the team leaders can set their own goals. most new features have to go directly into the unstable branch [Deb#14.
After inception however the number of people involved grows rapidly. Often. project Debian Drupal Fedora GNOME KDE MySQL/MariaDB PHP Plone PostgreSQL Python license Various. KDE. mainly GNU GPL GNU GPL Various.C O M PA R I S O N O F D E V E L O P M E N T P R O C E S S E S 6 As the analyzed projects were described in the previous chapter. Drupal. GNU LGPL GNU GPL PHP License GNU GPL PostgreSQL License Python Software Foundation License Table 6. mainly GNU GPL GNU GPL.1 project origin All analyzed projects share a quite different history. such as MySQL with MySQL Ab or GNOME show. The GNOME or Debian projects are an example for that. Projects like Plone or Fedora were an improvement and additional layer to an existing project. It is interesting to note. even if other people were involved too. Fedora and PHP are notable here. that many project founders tried to solve a personal problem with the project they were about to start.1: Used licenses in the analyzed projects. Some were developed with an university background like PostgreSQL or Python while other projects were born in the FOSS context. Michael Widenius of MySQL/MariaDB fits this case. GNU LGPL GNU GPL. However also commercial or philosophical background can initiate a project. Even if the number of developers increased over time. this chapter will compare the development processes and project details with each other. a single person was more involved in the project creation. This statement holds for all analyzed projects and is especially the case when the project was 79 . all projects were started by a small group of people which often consisted of at most two people. 6.
if one considers time and size differences between the projects.2: Project founders and origins. Stonebraker Guido van Rossum Table 6.2 community 80 project Debian Drupal Fedora GNOME KDE MySQL/MariaDB PHP Plone PostgreSQL Python origin 1993 2001 2002 1997 1996 1997 1994 1999 1986 1989 founder Ian Murdock Dries Buytaert Warren Togami Miguel de Icaza & Federico Mena Quintero Matthias Ettrich Michael Widenius & David Axmark Rasmus Lerdorf Alexander Limi & Alan Runyan Lawrence A. It seems that the development of such big releases attracts a lot of new developers. finally released as FOSS. Also it is worth noticing that almost every analyzed project has one or more rapid developer growth periods. 6. This of course biases the comparison between communities.0 and Plone 4. a lot of people were active in the projects. Furthermore the increased size stayed almost the same after the release. KDE 4. when finally released as FOSS. that the communities of each project seem to be quite different. Also taking in mind that only the central parts of the projects were an- .6.0. as the actual number of developers is almost always lower than the total sum of developers in the project history. Examples like PostgreSQL or Python show the rapid increase of people involved.2 community The previous project analysis has shown. The growth graph however is quite similar in all analyzed projects.0. 6. be it just developers or other.0. This will be compared in the following sections. Rowe & Michael R.2. This becomes clear when one examines the release and development of Python 2.1 Community Size As all of the analyzed projects share a quite long history. All of those versions are major releases with new features and approaches to their project goals. GNOME 3. Those periods can be matched with a certain major release of the projects.
Another interesting insight is the Plone project which claims to have about 300 active core developers. Also it is important to carefully distinguish between core developers and other contributors. Plone with the plone-developers.2 Communication On a worldwide distributed project the communication within a project is one of the most vital parts. The Drupal project for example only has about six to ten distinct authors to Drupal Core. there is always one mailing list which is the most important. In some projects this single mailing list is split into two. Fedora with the devel and Debian with the debian-devel mailing list. Projects like Fedora or Debian with a broad scope and smaller tasks like package creation can actually have a number of active developers which matches the claimed number. the resulting number can vary a lot. A plausible explanation for this is probably the fact that it is easily scalable. an analysis of code authors is not always a satisfying approach. one more general list for the project and the second for the core project. Every project has a wide array of communication methods in place. 6. That said the size comparison must be analyzed carefully with the above considerations in mind. The PostgreSQL project on the other hand gives an exact number of active and retired core developers. Only recently they adopted to give credit to the original author instead of referring to them in the commit message. It is not always the case that the actual number of developers is smaller.2. This is the case for KDE with the kde-devel and kde-core-devel mailing lists and MariaDB with the maria-developers and maria-captains mailing lists. Quite every project uses mailing lists as its favourite communication method. For example the GNOME project claims that over 3500 people contributed to the project. Although every project has lots of different lists for quite every aspect within the project.2 community 81 alyzed. Python with the python-dev. However one has to keep in mind that the comparison of a core piece of a project with a full operating system isn't valid and has low relevance. PHP with the internals.6. PostgreSQL with the pgsql-hackers. open and archived. The same probably holds true for the Drupal project with about 1200 enlisted developers and for the KDE project with about 1800 active contributors. only leaving out the number of minor contributors. the code repository however only shows a number between 50 to 70 active developers at the same time. This is true for GNOME with the desktop-devel. Since in some projects only core developers have access to the code repository. An exception is the . The fact that only GNOME Core was analyzed and no longer active developers were left out reduces the finding to currently about 350 active developers of GNOME Core.
Another interesting fact is that some projects include the conference in their release and development schedule. the used structures are middlingly similar. blogs. It is interesting to note that only after years communities started to organize them on a regular basis.2.3 Conferences As most of the developers are living in different cities. 6. Then.2 community 82 Drupal project which uses mailing lists however the most important communication channel is a mailing list akin forum on their project website. Moving one step up. that all projects use a fairly hierarchical development structure. developers or contributors get more rights but also more responsibilities.4 Roles The analysis of the projects has shown. newsletters and others. 6. For example the Debian project which has a very long history in comparison to others has a filed segmentation with clear duties and respon- . For example one manages certain parts of the project or provides guidance to new developers. for example the GNOME project in which the conference provides an extra development boost for the upcoming release in autumn. These however focus more on specific parts or goals of the project. each project organizes in addition frequent local meetups. sprints. Of course this structure varies over time and size of the project. countries or continents. especially if the projects are working within the same field. Each analyzed project organizes one or more annual conferences in place where developers and users can meet. Additionally in every project there are lots of other direct and indirect communications such as IRC channels. It also seems that most projects existed since years before the first conference was held. Keeping this fact and the different project scopes in mind. smaller conferences or other workshops. It is also interesting that some projects split the same function into two roles. at the top there is a project leader or a group filling the project leader role.2. Above these maintainers of a certain subsystem is always a rather small group managing the project's development. Due to the size of the project and the worldwide distribution of developers. Along with the growth of a project the number of attendees at a conference grew as well. Therefore conferences and meet-ups provide the possibility to meet in person. plan and design future goals more easily and to invigorate the community.6. Starting from the bottom of the hierarchy there is always room for casual developers or contributors. hackfests. the communication is almost always handled through the internet.
leaders and release coordinators are marked with . founders. Project leaders are printed in italics. .6.2 community 83 Founder Core Committer Maintainer Core Contributor (a) Drupal Release Manager Framework Team Core Developer (b) Plone BDFL Expert Core Developer Developer (c) Python Language Designer Author Module Author Developer (d) PHP Core Team Release Team Maintainer Design Team Release Team Module Coordinator Contributor (f) KDE Committer (e) GNOME Core Team Major Contributor Contributor (g) PostgreSQL Release Coordinator Captains Developer (h) MariaDB Project Leader Project Board FESCo SIG Developer (i) Fedora Technical Committee Developer Maintainer Contributor (j) Debian Figure 6.1: Comparison of development related roles in the projects. core developers are marked with and co-developers are marked with .
First. such as in the MariaDB project. while others have left their project. project leader teams were established. A younger project like MariaDB has a simpler model. releases. A release team is a critical part of a project. Therefore the project founders of the analyzed projects can be classified into three categories. It was already explained that even if there are more project founders. where the original leader is still active and sometimes gives input but has no power. that in projects where the project founder is still active.2 community 84 sibilities for each role. It was also pointed out that some project founders are still active and lead the project. This is the case for the Drupal project. This is true for Drupal. either as a dedicated team or represented by the project leader. The opposite are projects where the original founder no longer is present. In the Plone and MariaDB project the founders are members of the leadership team but have no special role. new features and are often the decision maker. as well as for Python and PHP. project founders which are still active in the project and have a leadership position. the structure is more hierarchical with the founder on the top. In all of those projects. Debian still has a project leader. but they can't decide anything. At most .5 Project Founders The project founders played a vital role during the inception of the project. In the KDE and GNOME projects the founders are working on related projects or topics and sometimes give their opinion.2. Fedora and GNOME. that one always has to start at the bottom of the hierarchy. who gets voted by the community. Furthermore the concept of having people who are responsible for certain subsystems seems to be widely established across all bigger projects. At last there are projects. All named projects established a leadership group which defines the future of the project. the structures analyzed here show. Sometimes the leader gathers other people around him trying to be not solely responsible for the project. but preserved the project leader hierarchy. Even if projects claim to be friendly to newcomers and an open community. Debian and PostgreSQL are good examples here. often one single person plays a leadership role. the development structure might look different without the leader. Fedora. PHP and Python. This is true for KDE. earning trust and providing enhancements to the projects before being promoted on holding a carrying business.6. In projects where the leader is no longer involved or does not hold any power. Debian is a special case because the original project leader passed on his duty. They define goals. It is also interesting to note. which nonetheless has the described groups on top. 6.
however it additionally releases those changes as further bug fix releases. 6. Except Drupal and Fedora. that the minor releases of a major release only include bug fixes and therefore are following the scheme of a major and micro version number. 6. except Drupal and Fedora.6. regardless of whether the major or minor number changes the release is always a major release. Also. . minor and micro number. which defines major and minor releases. In some projects.3. that an increment in the major number defines often a backwards incompatible release with new features. Such a major release is often a ground breaking change and often defines a new era for the project. An odd minor number therefore always defines development releases. Drupal 7 and so on. It is important to note. Fedora is an exception here.x release cycle. It is true for all projects. The Drupal project uses a two digit versioning scheme. if such changes occur. most projects provide an upgrade path. for example in the PHP 5. A major releases is generally extremely scarce.3 release process 85 they can give their opinion and community members might give their notion a higher value. It consists of a major. as most projects have gone through different processes and workflows during their time of existence. Nevertheless some of the different stages of the projects seem to be quite equivalent to each other. bug fixes can be included automatically in a running system. an increment of the minor version number defines a major release. The GNOME project always increments its minor number by two to define a stable release cycle. KDE 4. There are some exceptions where this is not the case. which characterizes a release. The Fedora Project just uses a single number to represent major releases. all projects use such a number.3 release process The release process seems to be the most diverse item in this analysis. Plone 4. In other words. This is true for GNOME. PHP and Debian. for example GNOME 3. The minor number almost always defines a feature release which is backwards compatible to the previous major release. which currently is 16. Due to the structure and automatic update process. use a three digit version naming scheme. as every new release increments the major number by one. This is also reflected by the comparatively low major number the projects have. For comparison the Debian project also pushes bug fixes to the users.1 Versioning Scheme All projects. However those changes can be seen as minor when comparing them to the incompatibilities of two major releases.
Although projects like Drupal and Python do not use a fixed release cycle for major releases. The PostgreSQL and PHP projects use a fixed release cycle with a duration of one year. Nevertheless there are some differences while comparing each project's schedule which will be outlined in the following. They are only allowed to include bug and security fixes.6. Also Fedora uses a similar cycle. 6. no new features and no incompatibilities. Projects like Plone. which do not have an all to big impact. they do however use a fixed release cycle for minor and bug fix releases.3: Used versioning schemes in the analyzed projects. Micro releases are a number of subset releases for the above mentioned feature releases. It means. In a nutshell it can be said that all projects use a similar versioning scheme with some minor exceptions. A fixed release cycle iterates over a given time frame and provides expectable release dates. GNOME and KDE projects use a fixed release cycle with a duration of six months. They are therefore a vital point for each project's future.3 release process 86 project Debian Drupal Fedora GNOME KDE MySQL/MariaDB PHP Plone PostgreSQL Python major minor micro Table 6. that each year there will be two major releases including a number of minor or bug fix releases. Except Fedora. The most distinguished difference is the decision of a fixed release cycle.3. as it is more or less bound to the GNOME release cycle.2 Release Schedule The release schedule leads to new major releases and often includes minor and bug fix releases. As such most projects have established a rather detailed release schedule which they accurately try to follow. The Python project publishes minor releases roughly every 18 months and bug fix releases roughly . all projects use such a number.
The Python project only allows new features until the first beta release which occurs about two months before the final release. confining other freezes more and more until the first alpha release. features. Currently the feature freeze is in act about eight months before the final release. strings and API freezes. however has its feature freeze roughly three months before the final release.3 release process 87 every six months. API and string freezes. After that point only bug fixes can be applied. documentation and more. After that no new features are allowed and only bugs get fixed. The Drupal project publishes bug fix releases on a monthly basis.6. However they will be analyzed deeply before they can be applied. Also. Of course they are restricted to new development and developers can still apply bug fixes. since the release schedule is a fixed one. At least the Debian project is currently trying to provide a fixed release schedule. The flexible release schedule of MySQL/MariaDB forces the project to establish criteria when specific releases can happen. As such freezes are a vital part of all analyzed project schedules. . Further beta releases from that point until the final releases do only get bug fixes. The Plone project is set somewhat in the middle having a feature freeze two months before the final release and then applying more and more restrictions during the releases of alpha. such as code. user interfaces. All projects however have some sort of freezes as part of the schedule. The most interesting facts are when the freezes occur and with which restrictions. The Fedora project is quite similar to that approach. they often keep in effect for the released major branch. beta and release candidate versions. The freezes are set in order and always have a soft freeze before a hard freeze. The PHP project has changed the layout of its schedule a lot during the last years while trying to elaborate its yearly release schedule. Freezes should help to confine areas where new bugs or drawbacks could appear. The GNOME project as well as the Debian project have established a freeze shortly before their final release including code. It also differentiates between soft and hard freezes. translatable strings. The freeze period of the GNOME project however has a defined start and end date. This continues until the final release is considered to be bug free. The KDE project on the other hand distributed the different freezes more evenly throughout the release cycle. Only MySQL/MariaDB and Debian do not have a fixed release cycle. feature. This applies for features. One of the most obvious consequences is the fact that bug fix releases only include fixes and no new features or user interface changes. A such criteria for a feature freeze is the publication of alpha releases. Following an alpha and beta release more restrictions apply.
. Hard Feature Freeze Dependency Freeze Development Soft Feature Freeze (e) GNOME Final Release (f) KDE Final Release Development Releases Duration 1 Year Development Feature Freeze No Fixed Duration Development Commit Fest Development Releases (g) PostgreSQL Final Release (h) MariaDB Final Release Freeze String Freeze Duration 6 Months Feature Submission Deadline Development Feature Freeze Development Releases No Fixed Duration Development Releases Development (i) Fedora (j) Debian Figure 6.2: Schematic representation of major and minor development cycles of the analyzed projects.6. UI. API Freeze Development Releases Feature Proposal Period (d) PHP Final Release Hard API & Message Freeze Duration 6 Months Duration 6 Months Discussion Decision Development Releases Development Soft Message & API.3 release process 88 Final Release Final Release UI & String Freeze Development Releases No Fixed Duration Development Code Freeze Feature Freeze Duration 6 Months Development Development Releases API & Feature Freeze (a) Drupal Final Release Feature Freeze (b) Plone Final Release Feature Freeze Feature Proposal Period Development Releases Duration 18 Months Development Development Releases Duration 1 Year Discussion Decision Development (c) Python Final Release Code Freeze String Freeze Feature. freezes are marked with and releases are marked with . Feature inclusion phases are marked with .
6. It is also interesting to note. All analyzed projects' development had a form of leadership. Projects like Fedora. while other projects.6. As such it is vital to understand how projects are being lead. feature.4 development While the release cycle defines the process around new releases. The naming is of course different. user interface and string freeze. release candidate and lastly the final release is published. beta. if they are still active.4. In fact it is the only analyzed project which does not have a single freeze but a series of development milestones which limit new features and development time by time. For example the GNOME project does not provide a special naming. Each project showed a hierarchical structure when it came to decisions related to the development of a project. 6. The PostgreSQL has replaced a single feature freeze with a series of Commit Fest which were explained earlier. Plone and PostgreSQL have established leadership groups who define the direction of the project as well as decide over new features. Also due to their modular structure. Often the development is lead by the founder. structured and divided. MariaDB. Drupal and PHP projects the original founder has a great influence when it comes to decide on changes or new features. beta and release candidate versions before publishing the final release. The MariaDB and PostgreSQL projects on the other hand are mostly enhanced and lead by the same group. While the Fedora and Plone project have an arbitrary or elected group they do not necessarily provide enhancements themselves. such as Drupal or Debian name their release accordingly. In the Python. API. After all freezes have been declared a number of alpha. While the KDE and GNOME projects have established core or release teams they do not necessarily have power on areas other than their duties.1 Development Lead The development of a project is always lead by a single person or a group of people. that every project uses some kind of alpha. Each phase comes with its freezes in the following order code. except for the odd minor number.4 development 89 Like MySQL/MariaDB the Drupal project does not have a fixed release cycle and therefore arranges the development and freezes into different phases. A minor exception is GNOME's design team which is involved in the shap- . the concrete development is mostly lead by the maintainers of single areas. the development process of a project defines the actual shape of it.
community and leadership processes. For example the PLIP process. In the analyzed projects a quite diverse passel of processes has been found. 6. Interestingly other projects started to adopt this process with minor changes. 6.4.6. Since the team cannot dictate other GNOME members what to do. It is also possible that patches are sent to the mailing list or to a bug tracking system and discussed there before being applied. how and when features or big changes come into a project. the above assumption still holds. In case of not gaining acceptance the patch is often discussed in the project's mailing lists or other suitable means of communication.4. This is often assisted by a bug tracking system which each of the analyzed project uses. It seems that all changes committed to the repositories are reviewed by other members of the project. Such changes are not tied to an existent feature inclusion process. The most structured and well laid-out process is Python's PEP process. As such this often only comprises bug fixes and other changes similar in size. The Debian project is structured very hierarchically and as such the overall direction is set by the elected project leader.4 development 90 ing of user interfaces. Quite all projects have some sort of team leaders or maintainers who can decide about a certain patch for a certain subsystem of the project. Some of the analyzed projects have established a feature inclusion process which will be highlighted in the next section. The technical committee then looks after the concrete implementation while the single team leaders are in place for certain areas of the project. which is used by the Plone project only uses it for development enhancements and not for com- .3 Feature Inclusion Process The feature inclusion process defines. It defines a well documented approach of new features and big changes from its inception until either acceptance or withdrawal. if established. In all analyzed projects it is possible to commit small patches and enhancements directly to the project's repository or have it committed by a core contributor if one has not enough rights. This process seems to work well for the Python community as well for development. It ranges from a very structured and well documented process like the one in the Python project to a more dynamic approach like the one in the KDE project.2 Development Workflow The development workflow of a project defines how changes and enhancements are brought into the project.
6.3: Schematic and simplified representation of feature inclusion processes of the analyzed projects.4 development 91 Feature Proposal Discussion Implementation Feature Proposal Discussion Implementation Decision Decision Review Withdrawn Accepted Withdrawn Rejected Accepted (a) Drupal (b) Plone Feature Proposal Discussion Implementation Feature Proposal Discussion Implementation Decision Review Voting Withdrawn Rejected Accepted Withdrawn Rejected Accepted (c) Python (d) PHP Feature Proposal Discussion Implementation Feature Proposal Discussion Implementation Decision Review Review Withdrawn Rejected Accepted Withdrawn Accepted (e) GNOME (f) KDE Feature Proposal Implementation Feature Proposal Discussion Implementation Decision Review Review Withdrawn Accepted Withdrawn Accepted (g) PostgreSQL (h) MariaDB Feature Proposal Discussion Implementation Feature Proposal Implementation Decision Review Decision Withdrawn Rejected Accepted Withdrawn Accepted (i) Fedora (j) Debian Figure 6. .
in both projects the named groups have the possibility to drop or postpone a certain feature if it is not ready for the upcoming release. As such the process is a simpler and more focused to development compared to the PEP process. it is similar to the PLIP process. but slightly more structured and not backed by a single person is the feature based development process of GNOME and Fedora. In both projects. No concrete steps. As such there is no real instance which could prohibit the development of a certain feature. The PostgreSQL project is the only project which has removed such a specific inclusion process altogether and replaced it with a series of Commit Fests. In both projects proposals follow a certain format and are more structured when compared to Drupal initiatives. A feature can be brought into a Commit Fest and evolves over time until it can be committed. A minor difference is the separate voting step on each proposal. The KDE and MariaDB projects use an even more dynamic approach where members can propose features. involved parties. but they have to be picked up and implemented by developers. The Debian project uses goals which can be proposed by community members and are chosen by the release team. Also the PHP project adopted a version of the PEP process which is called RFC.4 development 92 munity issues. features can be proposed which are then chosen by the GNOME release team and the FESCo. Also. This is antithetic to the previous projects. At a certain point in time the Drupal project founder and leader Dries Buytaert chooses the initiatives the project should follow for the next release. since goals are just single wordings without any structure. Since it also focuses on development. which is not existent in the other two. Given the analysis such a series of feature reviews is equivalent to a series of feature inclusion processes where the goal is always to get a certain enhancement into a project instead of discarding it directly. Similar to this.6. . A slightly more dynamic approach is the Drupal initiative process where each Drupal developer can propose an initiative with a certain goal. code or other are trailed to the goal.
[Oga+07].DISCUSSION 7 With the analysis performed and the single findings compared. stability or decline. many still grow at least linearly. Godfrey and Tu [GT00] but also by Johnson [Joh01] who claims that all FOSS projects start as a closed prototype and evolve into an open project over time. Roets. such as the PHP project.1 project origin As shown before. Some projects seem to maintain stability over time. all projects seem to evolve their structure and processes over time. This definition lines up very well with the findings of this analysis. Hertel.2 community In contrast to the Bazaar model by Raymond [Ray98] the project structure in the analyzed projects was always hierarchical. 7. Niedner and Herrmann [HNH03] or Johnson [Joh01]. 7. This fact has also been analyzed in related studies. that despite the age of a project. Schweik and Semenov [SS03] identified a life cycle with three phases: project initiation. While the previous chapter described the differences between the projects. In other the project is launched by a company with the primary motivation of economic success. The analysis has shown. Finally the main research results are outlined. seem to decline. Lakhani and Wolf [LW03]. So to say the projects are similar with equal structures and processes when viewed in a simplified manner. The probably most obvious common ground in the analysis was the establishment of a project analysis catalogue. while others. this chapter offers a discussion and comparison with related findings and the presented software engineering methods. with which FOSS projects could be analyzed systematically and satisfactorily for the goals of this thesis. In some cases the projects develop from existing projects or scientific studies. going open and project growth. Another important issue to note is that although it was not examined in this analysis. Similar results have been shown by Godfrey and Tu [GT00]. such as the Python project. This was shown by Scacchi [Sca06]. most projects are initiated to solve a personal issue or problem. they still share general mutuality of structure and processes. even if 93 . such as Raymond [Ray98]. Minnaar and Wright [RMW07] or Ogawa et al.
Ogawa et al. [Cro+05]. Bazaar like structures. Passive Users Initiator Active Users Co-Developers Release Coordinator Core Developers Figure 7.1: Free and Open Source Software project development structure as proposed by Crowston et al. Regarding the communication within the projects. [Oga+07] and Kim [Kim03]. While the analyzed projects do have a hierarchical structure. This affirms the findings by Crowston et al. as all projects do have mailing lists and in fact the most important communication channel seems to be the mailing list. Warsta and Abrahamsson [WA03] and Krishnamurthy [Kri02]. the communities are nevertheless very welcoming and it seems to be relatively easy to enter a community and step up the ladder. Bez99#2] criticizes the Bazaar model as too simplistic and not matching. the general hierarchical structure was similar. . This finding was considered to be true. This repeats itself when one analyzes the project structure with a a leader or leadership group who drive the project. Ghosh [Gho05] analyzed several different models ranging from hierarchical to completely flat. Crowston and Howison [CH05].2 community 94 there was only a flat hierarchical structure. That of course only is proven for the analyzed projects and not for all FOSS projects. In this aspect the analyzed models resemble the Bazaar model. Also Bezroukov [Bez99#1. which claims that it is very easy for new developers to join the project and take charge of important parts of the project. The latter was not identified in any of the analyzed projects and even if they did differ in terms of hierarchy levels. This correlates with the findings of Johnson [Joh01]. [Cro+05]. Most projects do have several mailing lists in place with one or two being the most important ones where the development of a project is planned.7. As noted earlier. the mailing list is the most used communication method in FOSS projects as shown by Schweik and Semenov [SS03].
In some cases. freezes and all other related duties. As shown by Mockus.7. The only main difference is the number of development releases and freezes and the point in time when freezes occur and what part of the project they do cover. most importantly the non available co-location of developers. Fixed cycles can also be found in agile software engineering methods. Minnaar and Wright [RMW07] however make a strong case for the Spiral model not being used or found in FOSS projects. that the phases described in the Waterfall model are often found in development processes of FOSS projects as Roets. Also Crowston et al. 7. Warsta and Abrahamsson [WA03] proof differences between agile methods and FOSS development methods. in which the processes differ. Fielding and Herbsleb [MFH02] the role of the release manager is vital for every project. Iterative or evolutionary software engineering models however are the most common pattern. the analyzed projects seem to benefit from such an approach. especially in mature projects. The Spiral model by Boehm [Boe88] is a good example and gives a good first match when compared to the iterative releases and development schedules.3 release process 95 7. However they agree that the processes show clear similarities. Agile methods seem to be much more appropriate when comparing them with FOSS development processes. Roets.4 development While it certainly is not used in mature projects. in the . It is also interesting to note. They point out an array of differences. The iterative process. Most of the analyzed projects adapted a fixed cycle and others are in the process of transition. especially in new projects. The analysis reflects this since each project has either a single person or a team in place to manage releases. the Waterfall model by Royce [Roy70] often appears in new projects or prototypes. Minnaar and Wright [RMW07] point out. the close relationship with the user and quick development and prototyping seem to make an argument for agile methods. The release schedule with fixed cycles is often already fixated before development starts and each project tries to stick to it as close as possible. While not equal to those methods. this role is also the same. Development releases and freezes are quite similar in all projects. However Koch [Koc04]. [Cro+05] rates the release managers as one of the most important people next to the founder or leader.3 release process An interesting fact is the move towards fixed release cycles. such as Extreme Programming or the Scrum method. For example the development workflow of the PostgreSQL with its regular Commit Fests resembles important steps in the Scrum software engineering method.
4 development Pre-Commit Testing 96 Contribution Initiation Review Development Parallel Community Production Community Figure 7. Minnaar and Wright [RMW07] agree that no existing software engineering model resembles the development methods of FOSS projects accurately.2: Life cycle model of Free and Open Source Software projects as proposed by Roets. Also Roets. They admittedly come up with a proposal of a FOSS development cycle which closely matches the given results.7. Minnaar and Wright [RMW07]. . Scrum terminology named sprints. This proposal is based on the findings by Jørgensen [Jør01].
such as the project origin. This included all development related parts of the projects. GNOME. as proposed earlier. Finally the outcome of the previous project analysis was compared. PostgreSQL and Python were chosen. Also traditional and agile software engineering methods were offered for later use. The FOSS projects Debian. Until this point the Grounded Theory approach was used. the release process with its schedules and cycles. Based on that. communication and structure of the project. FOSS projects were analyzed and categorized to find matching specimens. Six projects were examined thoroughly to identify a project analysis catalogue. Fedora. As mentioned before the most important finding was that the project analysis catalogue was adequate for a development process anal- 97 . the community. PHP. KDE. automated gathering of project data and the visualization thereof was discussed and explained. development lead and feature inclusion process. which was to analyze the development workflows of FOSS projects and to finally find matching patterns. Next. as well as each project's development process with the general workflow. The following discussion took the results of the previous analysis and compared it with similar researches or studies. Plone. This determined the further analysis and the constitution of the work.CONCLUSION 8 This thesis started with the problem and motivation of development processes in FOSS projects. The catalogue was then applied to the other four projects with Qualitative Content Analysis. the used theoretical background was explained and established. Drupal. High importance was given to a comparison with other research findings and whether they are similar or if the found results don't match with them. Data about the projects was collected and the chosen projects were analyzed in depth using the Grounded Theory research method. The methodology of how projects were chosen was defined. According to the project analysis catalogue differences and similarities between the projects were distinguished. MySQL/MariaDB. The instances of agile software engineering methods were the Extreme Programming and Scrum software engineering models. This included research methods such as the Grounded Theory or the Qualitative Content Analysis. The usage of such methods was vindicated by similar research papers and studies which also use same or similar research methods. As traditional software engineering methods the Waterfall and Spiral model were explained. Next. It defined the main goal of the work.
This was not analyzed in this thesis. Similarities can be found already in the project's inception phases. As such the processes and development methods found were quite different to the previously described software engineering methods. Another important finding is that the development processes of FOSS projects are similar between each other but cannot be resembled by traditional or agile software engineering methods. that only the core parts of the projects were analyzed and therefore. The development processes were all very agile and iterative. This still can be seen in several projects.conclusion 98 ysis of the projects. On the contrary. Therefore the processes of the analyzed FOSS projects aren't that different after all. This is very surprising as it is a widely spread opinion that FOSS projects do release when it's ready. such as Debian or Drupal. In this facet the Bazaar model is reaffirmed. It has to be noted however. An unexpected result was that the Bazaar model could not be identified in any of the analyzed projects. Similar to commercial projects all analyzed projects had people or teams in place to ensure the compliance with the release schedule. Of course. however both projects have a strong opinion for fixed release cycles and it is only be a matter of time until they implement them. Furthermore there was a noticeable move towards fixed release cycles and more generally to an already pre-defined release schedule. It states that the organization of a software system is similar to the group which designed and implemented the system. Finally the finding by Conway [Con68] can be corroborated and applied to the findings. According to the findings in this thesis this not only holds true for the final product but also for the development processes and workflows. There are only a few cases known in which the project restarted from scratch. However several aspects of each proposed method can be found in the engineering cycles. This generally concords with other findings. which all started due to personal motivation. The outcome of this is obviously an evolutionary process in which the product gets better with each cycle. Other researchers came to the same conclusion. a Bazaar like model could still be identified around the projects. This finding is also closely related to the previously noted hierarchical structure in the projects. however the Bazaar model is closely related to FOSS projects and therefore one would anticipate it in most of FOSS projects. no project is equal to another one. all projects had a hierarchical structure. The Python project stands as a primary example of a very . even if they were modular or had a flat structure. they are still very welcoming to new developers and often one can quickly progress and become a member in a leading group within the project. but the general processes exist in one form or another in all other projects. Despite the hierarchical structure of the projects.
conclusion 99 organized and structured group which also established a very formal and textured development process. These categories could provide material for an interesting study to see how they empower the different structures or workflows. further research is necessary. as the findings only hold for the chosen projects and their core parts. but also smaller or larger projects than the analyzed ones. as noted before. Concluding this section. Furthermore this analysis did not have a strong focus on the motivation of developers. Ideally it is able to describe processes adequately with a high focus on reusability and integrity. Also. This raises a number of questions for future research such as if they evolve with a similar process or if there are similar processes or workflows to be found at similar times. the community or interaction thereof. the work presented in this thesis provides a consistent framework for analysis and discussion of FOSS projects. This also includes the assets and drawbacks of fixed release cycles and why projects tend to adopt them. . such as less or more mature projects. As such. While the initial findings are promising. By no means this analysis can be considered as exhaustive. A further analysis of such kind should of course establish different project selection criteria. it would be interesting to apply the project analysis catalogue to an extensive set of projects and analyze differences. projects seem to evolve parallel to their processes over time. Free and Open Source Software projects are essential tools in the modern daily grind and we should be eager to see what else we can learn from Free and Open Source Software development processes and projects.
10 (1999). "The Social Structure of Free and Open Source Software Development".5 (1988). Vol.10 (1999). 2005. Armstrong. In: Communications of the ACM 49. N. S. In: Proceedings of the 4th International Conference on Music Information Retrieval. Turner. K.4 (1968). Michlmayr. [Asp05] [BA99] [BCD03] [Bec99] [Bez99#1] [Bez99#2] [Boe88] [BT75] [CH05] [CM07] [Con68] 100 . Capiluppi and M. 1. 123–128. Vol. Crowston and J. M. In: First Monday 4. "Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism)". In: Open Source Development. Bainbridge. "From the Cathedral to the Bazaar: An Empirical Study of the Lifecycle of Volunteer Community Projects".BIBLIOGRAPHY [Arm06] D. K. In: IEEE Computer 21. pp. M. V. Springer. 1999. "A Spiral Model of Software Development and Enhancement".12 (1999). pp. pp. In: First Monday 10. Cunningham and J.4 (1975). London School of Economics and Political Science. E. 61–72. "Embracing Change with Extreme Programming". 2007. "How Do Committees Invent?" In: Datamation 14. Andres. D. Extreme Programming Explained: Embrace Change. pp. 2003. 234. "Plone: A Model of a Mature Open Source Project". Bezroukov. 28–31. pp. N. Adoption and Innovation. In: IEEE Transactions on Software Engineering SE-1. In: IEEE Computer 32. 224.2 (2006). A.2 (2005). p. Master's Thesis. "Iterative Enhancement: A Practical Technique for Software Development". J. K. S. Aspeli. 31–44. Beck. W. isbn: 0201616416. J. Basili and A. B. In: First Monday 4. 390–396. Boehm. Downie. 221–222. R. "How People Describe their Music Information Needs: A Grounded Theory Analysis of Music Queries". Conway. pp. "The Quarks of Object-Oriented Development". J. Addison-Wesley. Beck and C. "A Second Look at the Cathedral and Bazaar". Howison. Bezroukov. 70–77. pp.
isbn: 0202302601.4 (2003). pp. R. "The Open Source Phenomenon". B. In: The International Conference on Software Maintenance. O.7 (2003). Bieman. 20. DeGrace and L. pp. M. pp. Conflict and Control: The 4th Workshop on Open Source Software Engineering. Grazzini.2 (2004). In: International Journal of Nursing Studies 41. 2004. Glaser and A. Hazzan et al. T. In: Research Policy 32. T. 96– 105. H. In: Proceedings of the 37th SIGCSE Technical Symposium on Computer Science Education (2006). 141–150. Herrmann. Stahl. G. 201–215. D. p. Global Software Development". K. 1967. University of Turin. G. "The GNOME Project: A Case Study of Open Source. IEEE Computer Society. H. 1990. Vol. Wicked Problems and Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms. "Understanding Free Software Developers: Findings from the FLOSS Study". P. Tu. "Motivation of Software Developers in Open Source Projects: An Internet Based Survey of Contributors to the Linux Kernel". Godfrey and Q. M. Working Paper. Crowston et al. [Cro+05] [DS90] [DTB04] [Ger03] [Gho05] [Gra09] [GS67] [GT00] [Haz+06] [Hea04] [HNH03] . pp. M. Ghosh. Crowston et al. "Qualitative Research in Computer Science Education". 23–46. Niedner and S. Yourdon Press. S. L. 2004. IEEE Computer Society. "Effective Work Practices for FLOSS Development: A Model and Propositions". In: Collaboration. In: IEEE METRICS. J. 1159–1177. "Towards A Portfolio of FLOSS Project Success Measures". 408–412. pp. Hertel. 2005. pp. "Open Source Software Development: A Case Study of FreeBSD". Strauss. Heath. 2000. The Discovery of Grounded Theory. "Evolution in Open Source Software: A Case Study". Aldine de Gruyter. In: Software Process: Improvement and Practice 8. Dinh-Trong and J.bibliography 101 [Cro+04] K. W. In: Proceedings of the 38th Annual Hawaii International Conference on System Sciences. 2009. 271. International Conference on Software Enginnering. In: Perspectives on Free and Open Source Software (2005). German. "Developing a Grounded Theory Approach: A Comparison of Glaser and Strauss".
"An Introduction to Open Source Communities". "How Open Source Software Works: "Free" User-to-User Assistance". In: Social Science Research Network (2003). Mayring. Co-Operation and Co-Ordination in an Open Source Software Project: GNOME". 35–40. K. 2003. Kim. "Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects". pp. In: Forum Qualitative Social Research 1. Blue Oxen Associates. 1983. E. B. "Putting it All in the Trunk: Incremental Software Development in the FreeBSD Open Source Project". Beltz. 10. "A Descriptive Process Model for OpenSource Software Development". In: Information Systems Journal 11.6 (2002). Part I. Lecture Notes in Computer Science 3092. Wolf. Working Paper. H. In: First Monday 7. Lakhani and R. isbn: 978-3-40725501-3. 1994. Koch and G. Tech. Master's Thesis. In: Research Policy 32. Lakhani and E. rep. 85–93.2 (2000). N. p. P. A. Kaplan and J. J. "Agile Principles and Open Source Software Development: A Theoretical and Empirical Discussion". In: Evaluating Health Care Information Systems Methods and Applications. S.6 (2002). Schneider. Springer. E. Maxwell. 923–943. Grundlagen und Techniken. Health Informatics. 135.bibliography 102 [Joh01] K. 1–27. The Simple Economics of Open Source. "Qualitative Content Analysis". 27–42. pp.4 (2001). Lerner and J. "Effort. "Community in Action". Mayring. University of Calgary. 2000. von Hippel. Krishnamurthy. 2001. pp. "Qualitative Research Methods for Evaluating Computer Information Systems". Koch. Vol. K. S. pp. Magnusson. Johnson. Tirole. Sage. In: php architect (July 2010). Jørgensen. P. In: Extreme Programming and Agile Processes in Software Engineering. In: Information Systems Journal 12. Vol. S. pp. pp. [Jør01] [Kim03] [KM94] [Koc04] [Kri02] [KS02] [LH02] [LT00] [LW03] [Mag10] [May00] [May83] . G. 45–68. Qualitative Inhaltsanalyse.1 (2002). "Cave or Community? An Empirical Investigation of 100 Mature Open Source Projects". 2004.
pp. isbn: 0803932502. In: Software Evolution and Feedback: Theory and Practice. "Visualizing Social Interaction in Open Source Software Projects". "Learning Computer Science Concepts with Scratch". "Two Case Studies of Open Source Software Development: Apache and Mozilla". pp. pp. Porter and L. A. R. Armoni and M. Ogawa et al. 309–346. "The Cathedral and the Bazaar". R. 345–355. 1990. In: Proceedings of the Conference on the Future of Software Engineering. M. 2007. Sage. Sahay. In: Database for Advances in Information Systems 32. Corbin. G. A. pp. W. Meerbaum-Salant. Pandit. In: Proceedings of the Sixth International Workshop on Computing Education Research (2010). In: ACM Transactions on Software Engineering and Methodology 11. Lau and S. pp. Roets. Strauss and J. 25–32. D. Royce. pp. L. T. Scacchi. Votta. Wright. "Understanding Open-Source Software Evolution". 181–205. 1–9. M. M. S. 2. 69–76. p.bibliography 103 [MFH02] A. "The Creation of Theory: A Recent Application of the Grounded Theory Method". 38–56. [MSABA10] [Oga+07] [Pan96] [PPV00] [Ray98] [RMW07] [Roy70] [SC90] [Sca06] [Sch95] [SLS01] .1 (2001). 10–19. Schwaber. In: First Monday 3. Perry. "Scrum Development Process". Minnaar and K. "Open Source: Towards Successful Systems Development Projects in Developing Countries". "Empirical Studies of Software Engineering: A Roadmap". K. Vol. "Using an Adapted Grounded Theory Approach for Inductive Theory Building about Virtual Team Development". A. pp. N. In: OOPSLA Business Object Design and Implementation (1995). Mockus. In: Proceedings of IEEE WESCON (1970). R. In: APVIS. IEEE Computer Society. Fielding and J. pp. 2006.3 (2002). 2000. W. E. 270. D. Herbsleb. Raymond. M. Basics of Qualitative Research: Grounded Theory Procedures and Techniques.4 (1996). F. Ben-Ari. "Managing the Development of Large Software Systems". M. Sarker. W.3 (1998). ACM. In: Computers in Developing Countries (2007). O. E. In: The Qualitative Report 2.
2003. Warsta and P. Abrahamsson. "Transition of Governance in a Mature Open Software Source Community: Evidence from the Debian Case". In: Information Economics and Policy 20. "The Institutional Design of Open Source Programming: Implications for Addressing Complex Public Policy and Management Problems". "How is Open Source Affecting Software Development?" In: IEEE Software 21. "Business Object Design and Implementation Workshop". B.4 (2008). pp. "Is Open Source Software Development Essentially an Agile Method?" In: Proceedings of the 3rd Workshop on Open Source Software Engineering 25th International Conference on Software Engineering. Sadowski. 28–33. Szyperski.1 (2003). J. Semenov. 143–147. pp. Sadowski-Rasters and G.4 (1995). 170–175. Spinellis and C. Duysters. pp. Sutherland. M. M. pp. G.1 (2004).bibliography 104 [SS03] C. D. [SS04] [SSRD08] [Sut95] [WA03] . In: First Monday 8. 323–332. In: ACM SIGPLAN OOPS Messenger 6. Schweik and A. J.
figure 5. figure 5.36 on page 52.43 on page 60.C O M PA R I S O N O F P R O J E C T G R A P H S Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour A (a) Drupal. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour (f) KDE.4 on page 25. figure 5.17 on page 36. 106 . Figure A. figure 5.10 on page 30. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour (c) Python. figure 5. figure 5.1: Overview of time based view graphs. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour (b) Plone. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour (e) GNOME.25 on page 43. Monday Tuesday Wednesday Day Thursday Friday Saturday Sunday 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Hour (d) PHP.
figure 5. 250 (b) Plone.8 on page 29.2: Overview of commits by author graphs.38 on page 57. figure 5. Figure A.15 on page 35. Seigo Stephan Kulow 2008 2010 2012 Matthias Clasen Alexander Larsson Owen Taylor Emmanuele Bassi Christian Persch Kjartan Maraas David Faure Dirk Mueller Laurent Montel Marco Martin (e) GNOME. 200 1998 2000 2002 2004 2006 Time Aaron J.31 on page 48. figure 5. 500 500 450 400 400 350 # Commits 300 # Commits 300 250 200 150 100 100 50 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 0 1996 (d) PHP. figure 5. figure 5. .comparison of project graphs 107 200 180 160 140 # Commits # Commits 120 100 80 60 40 20 0 2000 2002 2004 2006 Time 2008 2010 2012 0 2002 2004 2006 Time Steven Wittens Kjartan Mannes Hanno Schlichting David Glick Martin Aspeli Wichert Akkerman Alexander Limi Eric Steele 2008 2010 2012 200 250 150 100 50 Dries Buytaert G´ abor Hojtsy Angie Byron Neil Drumm (a) Drupal.1 on page 22. (f) KDE.23 on page 42. 200 250 200 # Commits # Commits 150 150 100 100 50 50 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Guido van Rossum Benjamin Peterson Fred Drake Raymond Hettinger Georg Brandl Jack Jansen 0 2000 2002 2004 2006 Time 2008 2010 2012 Ilia Alshanetsky Jani Taskinen ¨ Marcus Borger Pierre-Alain Joye Antony Dovgal Dmitry Stogov (c) Python. figure 5.
000 5.540 7.000 4.000 15.264 (d) PHP.000 # Commits 1.000 (b) Plone.981 7.000 0 2000 2002 2004 2006 Time 2008 2010 2012 2002 2004 2006 Time 2008 295 1.951 # Commits # Commits 6.000 2002 2006 2004 Time 5.000 0 105 445 627 289 582 1.710 0 1996 256 0 1998 2000 2002 2004 Time 2006 2008 2010 2012 1996 1998 2000 2002 2004 2006 Time (e) GNOME.817 # Commits 39.929 24.2 on page 24.000 1.000 # Commits 20.870 4.637 2012 29.903 15. figure 5.373 3.149 24.262 7.242 3.000 6.193 4. figure 5.900 2.000 3.000 10.000 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time 1.000 1998 2000 4.201 26.000 2.000 10.166 2.996 4. Figure A.548 2.398 6.000 500 0 999 1.935 6.614 8.838 3. 29.701 # Commits 6. 48.992 4.219 19.000 3.000 9.471 8.000 4.254 2.869 2. 10. figure 5.006 11.466 5. 966 (f) KDE. figure 5.041 4.000 15.678 6.000 7.500 2.386 6.538 11.32 on page 50. figure 5.159 50.9 on page 30.829 5.comparison of project graphs 108 2.164 8.608 35.812 5.000 3.311 5.000 577 2.038 4.16 on page 36.703 2.578 2012 9.000 1.000 47.166 10.665 4.925 5.000 30.623 1.351 19.000 2.194 4.208 22.000 45.579 15.063 12.000 .186 9.3: Overview of commits by year graphs.784 2012 6.000 1.047 1.575 2010 3.832 4.660 2008 40.000 5.994 2008 (c) Python.696 2.24 on page 43.500 1.722 1. figure 5.000 (a) Drupal.580 16.649 7.000 15.000 8.820 20.400 1.947 26.000 7.143 1.806 8.000 25.39 on page 58.154 30.089 2010 15.256 1. 8.859 7.151 14. 2.088 5.482 2010 7.000 27.
figure 5. .18 on page 37.000 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 1.000 2.000 500 0 1996 3.000 1. figure 5.000 5.000 3.6 on page 26.500 (d) PHP. 7.000 2.200 Commits (a) Drupal.12 on page 32.000 2.000 6.28 on page 45. figure 5.000 800 800 # Commits 600 # Commits 600 400 200 200 0 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Commits Average (b) Plone. figure 5.000 250 # Commits 200 150 100 50 0 2000 2002 2004 2006 Time 2008 2010 2012 # Commits 800 600 400 200 0 2002 2004 2006 Time Average Commits Average 2008 2010 2012 1.000 # Commits # Commits 4. 1.200 1. figure 5. (f) KDE. Figure A.4: Overview of commits by month graphs.41 on page 59.comparison of project graphs 109 1.000 1. figure 5. 400 1998 2000 2002 2004 2006 Time 2008 2010 2012 Commits Average (c) Python.35 on page 52. 1998 2000 2002 2004 2006 Time 2008 2010 2012 Commits Average Commits Average (e) GNOME.500 1.400 350 300 1.
comparison of project graphs
6 5 4 # Authors # Authors 2000 2002 2006 Time 2008 3 2
70 60 50 40 30 20
1 0 2004 2010 2012
10 0 2002 2004 2006 Time Average Authors Average 2008 2010 2012
(a) Drupal, figure 5.7 on page 27.
40 35 30 40 25 # Authors # Authors 20 15 10 10 5 0 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 Time Authors Average 0 1998 30 20 60 50
(b) Plone, figure 5.14 on page 33.
2006 Time
(c) Python, figure 5.21 on page 39.
180 350 300 250 # Authors 200 150 100 50 0 1996 1998 2000 2002 2004 2006 Time 2008 2010 2012 # Authors 160 140 120 100 80 60 40 20 0 1996
(d) PHP, figure 5.30 on page 47.
2004 2006 Time
(e) GNOME, figure 5.37 on page 53.
(f) KDE, figure 5.42 on page 60.
Figure A.5: Overview of authors by month graphs.
All stated websites were last checked on December 31st , 2011. Whenever possible, the publication date was added to the citation.
b.1 [Bui]
drupal BuiltWith. Drupal Usage Trends. url: http://trends. builtwith.com/cms/Drupal. D. Buytaert. Drupal Contributor Statistics. June 2011. url: http : / / buytaert . net / drupal - contributor statistics-2011. W3Techs. Usage Statistics and Market Share of Content Management Systems for Websites. url: http://w3techs.
com/technologies/overview/content _ management/ all.
[Wal11] [Dru#1] [Dru#2] [Dru#3] [Dru#4] [Dru#5] [Dru#6]
J. Walling. Drupal Events. Nov. 2011. url: http://www. listology.com/jwalling/list/drupal-events. Drupal Project. Core Developers. url: http://drupal.
Drupal Project. Drupal Core Initiatives. url: http : / /
Drupal Project. Drupal Core's Release Cycle. url: http: //drupal.org/node/935558. Drupal Project. History. url: http : / / drupal . org / about/history. Drupal Project. The Drupal Overview. url: http : / / drupal.org/node/265726. Drupal Project. Upgrading from Previous Versions. url: http://drupal.org/upgrade.
plone M. Aspeli. "Plone: A Model of a Mature Open Source Project". Master's Thesis. London School of Economics and Political Science, 2005. Black Duck Software Inc. Ohloh Plone Factoids. 2011. url: http://www.ohloh.net/p/plone/factoids.
project resources
[Plo#1] [Plo#2] [Plo#3] [Plo#4] [Plo#5] [Plo#6] [Plo#7] [Plo#8] [Plo#9] [Plo#10] [Plo#11] [Plo#12] [Plo#13] [Plo04]
Plone Project. Community Processes. url: http://dev. plone.org/wiki/CommunityProcesses. Plone Project. How You Can Contribute to Plone. url: http://dev.plone.org/wiki/ContributePlone. Plone Project. PLIP Lifecycle. url: http://dev.plone.
Plone Project. PLIP Process. url: http://dev.plone.
Plone Project. Plone Conferences. url: http : / / plone . org/events/conferences. Plone Project. Plone FAQ. url: http : / / plone . org / documentation/faq. Plone Project. Plone Founders. url: http://plone.org/
Plone Project. Plone Framework Team. url: http://dev.
Plone Project. Plone Release Managers. url: http : / / plone.org/team/ReleaseManagers. Plone Project. Plone Release Process. url: http://dev. plone.org/wiki/ReleaseProcess. Plone Project. Plone Sprints. url: http://plone.org/ events/sprints. Plone Project. Releases. url: http : / / plone . org / products/plone/releases. Plone Project. What is Plone? url: http://plone.org/ about/. Plone Project. Plone Gets Paid Release Manager. Oct. 2004. url: http : / / plone . org / news / plone - gets paid-release-management. Plone Project. Plone Alters PLIP Process to Implement a 6 Month Fixed Release Cycle. Mar. 2011. url: http : //plone.org/news/newsixmonthreleasecycle.
python B. Venners. The Making of Python - A Conversation with Guido van Rossum, Part I. Jan. 2003. url: http://www. artima.com/intv/pythonP.html. B. Warsaw. Voting Guidelines – PEP 10. Mar. 2002. url: http://www.python.org/dev/peps/pep-0010/.
35–40. Hylton and D. van Rossum. [Pyt#6] b. url: http : / / www . php . Doing Python Releases – PEP 101. Usage Statistics and Market Share of ServerSide Programming Languages for Websites. python .org/ dev/peps/pep-0101/. PEP Purpose and Guidelines – PEP 1. . url: http:// w3techs.4 php H. url: http : / / www .php. Request for Comments.html. In: php architect (July 2010). Credits. url: http://docs.project resources 113 [WHG00] B.net/ manual/en/index.python. url: http://www. php. PHP Manual. Warsaw.php.org/license. Aug. How to Become a Core Developer. org / community / workshops/. url: http : / / www . url: http : / / www .python.html.python. B.html. url: https://wiki.python.org/dev/peps/pep-0001/. Python Software Foundation. Following Python's Development. net/manual/en/history. Warsaw and G.php. What is Python? Executive Summary. Python Software Foundation. pp. Development Cycle. python . php . June 2000. PHP Group. url: http://www. "Community in Action". url: http://docs. PHP Group.php. PHP Group.net/conferences/index. net / credits.html. url: http : / / docs . url: http : / / www . [WR01] [Pyt#1] [Pyt#2] [Pyt#3] Python Software Foundation. org / doc / essays/blurb/.php. [Pyt#4] [Pyt#5] Python Software Foundation. 2001. python .com/technologies/overview/programming _ language/all. Goodger. org / devguide / communication. Python Software Foundation. PHP Conferences Around the World. W3Techs. Python Software Foundation. python.php. Conferences and Workshops.net/rfc.org/devguide/ coredev. J. Magnusson. PHP Group. [Mag10] [W3T#2] [PHP#1] [PHP#2] [PHP#3] [PHP#4] [PHP#5] PHP Group. History and License.php.org/devguide/devcycle. url: http://www. History of PHP. url: http://docs.
gnome. In: Software Process: Improvement and Practice 8. GNOME 3. GNOME Project.net/rfc/releaseprocess. German. Guide for New Release Team Members.org/hig-book/. Teams. Global Software Development". GNOME Release Schedule. net/manual/en/intro-whatcando. gnome . GNOME Project. GNOME 3.org/Design.php. url: http : //www.php. url: http://www. gnome .gnome.org/press/2011/04/gnome. url: https : / / live .gnome.3. pp. url: https://wiki. GNOME Project. Road Map. php.net/usage.php. GNOME Human Interface Guidelines. PHP Group.0 released. url: https : / / live .project resources 114 [PHP#6] [PHP#7] [PHP#8] [PHP#9] [PHP07] PHP Group.org/Schedule. GNOME Project. GNOME Project.gnome. org/about/. url: https : //wiki.3. RFC Release Process.org/ teams/.gnome. 2011. 201–215. [Ger03] [GNO#1] [GNO#2] [GNO#3] [GNO#4] [GNO#5] [GNO#6] [GNO#7] [GNO#8] [GNO#9] [GNO#10] [GNO11] GNOME Project. org/RoadMap.gnome.4 (2003). url: http:// guadec.org/?q=node/3. GNOME Project.0released-better-for-users-developers-3/. PHP Usage Stats. url: http://www. GNOME Project.x Development Series. url: http://www. GNOME Project. PHP Group. Apr.org/ThreePointThree.php. About GUADEC 2012. M. July 2007. url: http://developer.php. php. GNOME Project.4. Design Team. "The GNOME Project: A Case Study of Open Source. Proposed Features for GNOME 3. PHP Group. RFC Voting on PHP features.net/rfc/voting. org / ThreePointThree / Features. PHP Group. url: https: //live. What can PHP do? url: http://www. url: https://live. GNOME Project.net/rfc/voting_who. . url: https://live.gnome.gnome. url: https : / / live . org / ReleasePlanning / NewReleaseTeamMembers. b.5 gnome D. RFC Who can Vote? url: https : / / wiki . About Us.
b. KDE Software Compilation. url: http : / / techbase. KDE Project Announcement. Project Management. Contribute. General FAQ.kde. org / community/history/. Awards. org/Schedules.html. Aug.postgresql.org/Contribute/Get _ a _ Contributor _ Account. b. KDE History.gnome. url: http : / / kde . url: http://techbase. url: http:// techbase.org/documentation/posting.project resources 115 [GNO97] GNOME Project. url: http : / / kde .org/about/. url: http://mail. org / community/whatiskde/. Oct.7 postgresql PostgreSQL Global Development Group. KDE 4.org/community/whatiskde/softwarecompilation. KDE Project.6 kde KDE Project.8 _ Release _ Schedule. [KDE#6] KDE Project.org/archives/gtklist/1997-August/msg00123. Press Page. url: http : / / kde . Release Team. [KDE#9] [KDE#10] [KDE#11] [KDE#12] [KDE96] KDE Project.kde. 1996. KDE Project.php. KDE Project. [Pos#1] [Pos#2] PostgreSQL Global Development Group. url: http : / / techbase .kde. KDE Project. url: http://www. Development Model. KDE Project.org/Schedules/KDE4/4. url: http://techbase. url: http://www. org/Contribute. The GNOME Desktop Project.kde. org/community/whatiskde/management. org/community/whatiskde/devmodel.php. kde . url: http://kde. KDE Project. 1997. [KDE#7] [KDE#8] KDE Project. About KDE.kde. url: http://techbase.txt. . url: http:// kde. Schedules.postgresql. [KDE#1] [KDE#2] [KDE#3] [KDE#4] [KDE#5] KDE Project.8 Release Schedule. url: http : / / kde . About. KDE Project. KDE Project. url: http : / / kde . php. org/Development/FAQs/General_FAQ.org/about/awards/. Get a Contributor Account. org / presspage/. org/Projects/Release_Team.
Contributing to the MariaDB Project. About MariaDB. org/about/press/faq/.askmonty. askmonty. org/wiki/PostgreSQL_9.8 mysql / mariadb Monty Program Ab. Events. PostgreSQL 9.postgresql.askmonty. PostgreSQL 9.2_Development_Plan. PostgreSQL Global Development Group. Downloads. url: http : / / wiki . Contributing Code.postgresql.postgresql. Versioning Policy.org/en/contributing-code. History. url: http://wiki. url: http://www. url: http://wiki. [Mon#1] [Mon#2] [Mon#3] . PostgreSQL Global Development Group.org/about/ press/presskit91/. postgresql . Developer FAQ.org/en/about-mariadb.org/wiki/ Running_a_CommitFest. Frequently Asked Press Questions.org/about/eventarchive/.project resources 116 [Pos#3] [Pos#4] PostgreSQL Global Development Group. [Pos#5] [Pos#6] [Pos#7] [Pos#8] [Pos#9] [Pos#10] [Pos#11] [Pos#12] [Pos#13] [Pos#14] b.org/download/.postgresql. PostgreSQL Global Development Group.org/about/licence/. url: http://www. url: http://wiki.postgresql. url: http://www. Monty Program Ab. url: http://www. PostgreSQL Global Development Group.org/en/communitycontributing-to-the-mariadb-project. url: http://kb.postgresql.org/community/ contributors/.1 Press Kit. PostgreSQL Global Development Group. url: http://www.postgresql. url: http://www. PostgreSQL Global Development Group.postgresql. PostgreSQL Global Development Group. PostgreSQL Global Development Group. Monty Program Ab. PostgreSQL Global Development Group.org/wiki/CommitFest.org/support/ versioning/. Commit Fest. PostgreSQL Global Development Group. Running a Commit Fest. org / wiki / Developer_FAQ. url: http://www.postgresql.postgresql.2 Development Plan. url: http://www.org/about/history/. url: http://kb. PostgreSQL Global Development Group.postgresql. License. url: http:// kb. Contributor Profiles.
com/doc/refman/5. url: http://www. Monty Program Ab.mysql. url: http : / / fedoraproject . com / news . History of MySQL.askmonty. 1/en/choosing-version.askmonty.developers .and events/sun-to-acquire-mysql.com/doc/refman/5.askmonty. Choosing Which Version of MySQL to Install. askmonty .project resources 117 [Mon#4] [Mon#5] [Mon#6] [Mon#7] [Mon#8] Monty Program Ab. Plans for 5.users . url: http://dev. mysql . url: http : / / kb . 2010. Jan. [Fed#1] . Monty Program Ab. Oracle Corporation.askmonty.1.org/en/ what. url: http : //kb. Oracle Corporation. [Ora#1] Oracle Corporation.behind mariadb. Monty Program Ab. url: http : //kb. Monty Program Ab.becoming. Where Are Other Users and Developers of MariaDB? url: http : / / kb .org/en/mariadb-roadmap.mariacaptain. url: http : / / www .the. askmonty.is . Board.mysql. Sun to Acquire MySQL. What is MariaDB 5.html. askmonty . com / us / corporate/press/044428. org / en / who . url: http : //kb. Sun Microsystems Inc.mysql. url: http : / / www . org/wiki/Board.and . Who is Behind MariaDB? url: http : / / kb .are .org/en/release-coordinator.a. org / en / what . MySQL Users Conference & Expo. url: http://kb.6.criteria .6/en/history.html.are. What License Does MariaDB Use? url: http : / / kb .of mariadb.html.9 fedora Fedora Project.other . 2008.for . Monty Program Ab. Oracle Corporation. Jan. Monty Program Ab.org/en/what-is-mariadb-51. What Are the Criteria for Becoming a Maria-Captain? url: http://kb. [Mon#9] [Mon#10] Monty Program Ab.org/en/plans-for-56. oracle . Oracle Completes Acquisition of Sun. askmonty. url: http:// dev. org / en / where . Release Criteria.com/news-and-events/usersconference/2010/.org/en/release-criteria. askmonty . Release Coordinator.license does-mariadb-use. [Ora#2] [Ora#3] [Ora10] [Sun08] b. [Mon#11] [Mon#12] Monty Program Ab. MariaDB Roadmap.
[Fed#12] [Fed#13] [Fed#14] [Fed#15] Fedora Project. Licensing Guidelines. url: http : / / fedoraproject . What is Fedora and what Makes it Different. org/wiki/Statistics#Contributors. org / wiki / Releases / HistoricalSchedules.org/weblog/2011/06/12#develcountries-201106-3. FUDCon. url: http://fedoraproject. url: https://fedoraproject. Warren Togami Biography. url: http://fedoraproject.10 debian N.project resources 118 [Fed#2] [Fed#3] [Fed#4] Fedora Project. Fedora Weekly Newsletter. org / wiki / Fedora _ Engineering_Steering_Committee. Communicating and Getting Help. Fedora Project. Developers per Country.perrier. url: http : //fedoraproject.devel announce/2011/06/msg00003. Fedora Project. url: https : / / fedoraproject . June 2011. Fedora Project. [Fed#5] [Fed#6] [Fed#7] [Fed#8] Fedora Project.org/wiki/Licensing.org/wiki/FWN. Fedora Project. C. url: http://fedoraproject. b.eu.org/wiki/User:Wtogami. org/wiki/Join. url: http : //fedoraproject. url: http: //www. Bits from the Release Team. url: http://fedoraproject.org/about-fedora. June 2011.html. Features Policy Guidelines. org / wiki / ReleaseEngineering / Overview. url: http : / / fedoraproject . Perrier. [McG11] [Per11] . Join. Fedora Project. org/wiki/FUDCon.org/ wiki/SIGs. SIGs. Fedora Engineering Steering Committee. url: http : //fedoraproject. url: http : / / fedoraproject . Statistics. url: https : / / fedoraproject. Release Engineering. url: http : / / lists . Fedora Project.org/wiki/LifeCycle. debian . Fedora Project. McGovern. Fedora Project. Fedora Release Life Cycle.org/wiki/Communicate. Fedora Project. Fedora Project. Historical Fedora Release Schedules. url: http : //fedoraproject. [Fed#9] [Fed#10] [Fed#11] Fedora Project. org / debian .org/wiki/Features/Policy.
0 "Squeeze" Release Goals.debian. debian. Debian Releases. Debian Project.debian. Debian Project.org/doc/manuals/debian-faq/.org/.html. Debian Project. Ports.html.debian. url: http : //www. M.org/DebianDeveloper. url: http: //www.en. url: http://www.debian. Debian Maintainer.debian.debian.org/DebianMaintainer.4 (2008). Duysters. url: http://www. Debian Voting Information.debian. url: http : //www. Debian Project. License information. Debian Project.project resources 119 [SSRD08] B. Debian Project. Sadowski. Debian Project. url: http://debconf. Debian Project. "Transition of Governance in a Mature Open Software Source Community: Evidence from the Debian Case". DebConf. Sadowski-Rasters and G. Mailing Lists. url: http://www. org/MailingLists/. Debian Project. debian.en. url: http://www. pp. A Brief History of Debian. 323–332.debian. [Deb#1] [Deb#2] [Deb#3] [Deb#4] [Deb#5] [Deb#6] [Deb#7] [Deb#8] [Deb#9] [Deb#10] [Deb#11] [Deb#12] [Deb#13] [Deb#14] [Deb09] Debian Project. debian.org/devel/join/newmaint. url: http: //release. . About Debian.org/intro/organization.org/.org/ News/2009/20090730. url: http://www.org/legal/licenses/index. Debian New Members Corner. Debian's Organizational Structure. url: http://www. Debian Project. Debian Project.debian. url: http : / / wiki .debian.org/ ports/. Debian Project. July 2009. url: http://wiki. url: http: //www. Debian Developer.org/vote/. debian. In: Information Economics and Policy 20. org/intro/about. Debian GNU/Linux 6. Debian Project.org/doc/manuals/project-history/. G.org/releases/. Debian Release Management. Debian Project. url: http : / / www . The Debian GNU/Linux FAQ.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.