AN OPEN ONION PROCESS MODEL TO SUPPORT OPEN SOURCE DEVELOPMENT
AMINAT ABIOLA SHOWOLE
A thesis submitted in fulfilment of the requirements for the award of the degree of Doctor of Philosophy (Computer Science)
Faculty of Computer Science and Infonnation Systems Universiti Teknologi Malaysia
JANUARY 20 11 11
DECLARATION
I declared that this thesis entitled "An Open Onion Process Model to Support
Open Source Development" is the result of my own research except as cited in the references. The thesis has not been accepted for any degree and is not concurrently submitted in candidature of any other degree.
Signature: ···� ·····
Name: Arninat Abiola Showole
Date: 31ST January, 2011 Ill
To
My late fa ther, Alhaji G.S. Alamutu
My sweet mother Alhaja Safiat Atoke Alamutu,
My beloved Children Mubarak, Teslim, Hikmat & Yusrah
My darling husband and best fr iend, Abdul Wa siu Showole IV
ACKNOWLEDGEMENT
All Praises belong to Allah (SWT) fo r making it possible fo r me to get to this phase of my research. This PhD research is sponsored by Islamic Development Bank (IDB) Jeddah, Saudi Arabia and Federal University of Ahuja, Nigeria, to both whom I am very grateful.
My deepest appreciation goes to my principal supervisor Professor Dr. Hj. Shamsul Sahibuddin, fo r his persistent support in terms of guidance, encouragements and inspiration especially at the times when this research seemed unworkable. He has always given me the much needed courage to fo rge ahead and build high-level of confidence in me. All these have really taken me to this level. My profound gratitude goes to my co-supervisor, Associate Professor Dr. Ibrahim Suhaimi, for his guidance and motivation in the course of this research. He is an ever-listening, willing to help co-supervisor. My sincere appreciation goes to members of the fa culty of computer science and information system (FSKSM), UTM; and in particular, Associate Prof. Dr. Ali Selamat fo r his assistance especially at the early stages of this research and Professor Bob Colomb for guiding me, with his elderly expertise, towards the appropriate data analysis technique for this research.
Furthermore, I appreciate the open source community and open source repository providers (SourceForge.net, flossmole.org). They have indeed facilitated this research by providing free and up to date project activity details which have eased the data collection processes for this research. Mr. Nicholas, open source community, Malaysia. Industry-based practitioner though, he granted me audience and provided positive responses as I provoked his thoughts on open source academic 1ssues. v
My appreciation goes to my family friends particularly, Abd-Gafar and K.ifayah Fahm and the entire Nigerian communities in Malaysia, fo r their support and care of my children during the course of this research. My appreciation goes to people who have assisted me through my academic ladder climbing. Mr. Agosu was my wonderful mathematics secondary school teacher who gave me a solid fo undation in mathematics and statistics. Engineer Bayo Adeola is a fantastic brother to me, Dr A.K. Oj o is my mentor and Professor Olaide Abass of University of Lagos is a father-figure.
My deepest appreciation and humility goes to my late father, Alhaj i 'Ganiu S. Alamutu and my mother Alhaj a Safiat A. Alamutu fo r their parental care, endless support and perpetual prayers over me. My love goes to Alhaja R.Titilayo Oguntola, Engineer Wale Q. Alamutu, Mrs. Mariam A. Ibrahim and Late Mrs. Barakat Adebiyi ofblessed memory; they are my wonderful and worthy siblings indeed. My Mother in-law, late Alhaja Sidiqat Showole of blessed memory, was a one-in-a-million mother in law who had always showered her blessings and prayers upon me on a daily basis throughout her 8 years of stay with me; although I tried my best to be kind to her on a daily basis as well. I am convinced that her long years of prayers over me have indeed contributed to my success in this research.
My love and appreciation goes to my beloved children, Mubarak, Teslim, Hikmat and Yusrah, who have all shown adequate understanding and cooperation. They provided a balancing environment for my brain to operate in the course of this research. My love goes to my darling husband, Abdul Wasiu Abiodun Showole most encouraging, highly committed with persistent determination towards my success. VI
ABSTRACT
The need for technologies to building high quality software faster and cheaper has led to the advances in software development techniques such as software component, object orientation, software reuse and open source methodologies. Ability to revamp existing codes is the leading edge of open source over other methodologies. Interestingly, literature has often described open source development with onion. However, the previous open source onion descriptions have not been put to test. This research presents an improved onion model that has streamlined fo ur prominent open source onion models into a newly evolved five layered open onion model whose layers are distinctively modeled diagrammatically, evaluated statistically and validated with Delphi's approach. Relevant parameters, such as programming language support, user interface, and natural language support, were extracted from ten highly ranked SourceForge case studies and statistically evaluated using correlation, regression and averages; while a cross verification was performed by statistical analysis based on extracted details of II04 open source software projects details. The support for Pareto (80/20) principle in open source shows that 80% of proj ect developers' activities are actually regulated and controlled by 20% project administrators' activities. The development and validation of open source user satisfaction equation as well as the newly evolved open source success tree provide excellent measure; such as 100% Delphi experts' support for ability to avoid fatal errors and 100% fo r ability to build strong support for the project; to which an open source success rate largely depends. Major contributions of this study are that the open onion model evolves to improve the existing onion models of open source through the modeling, verification and the 4-round open onion Delphi validation stages. Vll
ABSTRAK
Keperluan teknologi bagi pembinaan perisian berkualiti tinggi dengan lebih cepat dan murah telah membawa kepada kemajuan dalam teknik pembangunan perisian seperti komponen perisian, orientasi objek, penggunaan semula perisian dan metodologi sumber terbuka. Kemampuan mengubah kod sedia ada merupakan kelebihan utama sumber terbuka melebihi metodologi lain. Apa yang menarik, pelbagai kertas kajian menggambarkan perkembangan sumber terbuka dengan bawang. Namun, gambaran bawang ini belum pemah diuji. Penyelidikan ini menawarkan suatu pembaharuan model bawang yang menggabungkan empat model bawang sumber terbuka terkemuka ke dalam suatu model evolusi baru lima lapisan bawang terbuka dimana setiap lapisan digambarkan dengan model berbeza, dinilai secara statistik dan disahkan melalui pendekatan Delphi. Parameter yang berkaitan, seperti sokongan bahasa pengaturcaraan, antara muka pengguna, dan sokongan bahasa tabii, diekstrak dari sepuluh kedudukan tertinggi kajian kes SourceForge dan dinilai secara statistik menggunakan korelasi, regresi dan purata; manakala pengesahan yang menyeluruh dilakukan dengan analisa statistik butiran yang diambil dari 1104 projek perisian sumber terbuka. Sokongan bagi prinsip Pareto (80/20) dalam sumber terbuka menunjukkan bahawa 80% dari kegiatan pemaju projek sebenamya diselaraskan oleh 20% kegiatan pentadbir projek. Pembangunan dan pengesahan persamaan kepuasan pengguna sumber terbuka serta pokok kejayaan sumber terbuka evolusi baru menyediakan pengukuran unggul seperti sokongan 1 00% pakar Delphi bagi keupayaan mengelakkan kesilapan besar dan 100% bagi kemampuan membina sokongan kuat projek; kadar kejayaan sumber terbuka sangat bergantung kepada ukuran-ukuran tersebut. Sumbangan utama dari kajian ini adalah bahawa model bawang terbuka berkembang bagi memperbaharui model bawang sumber terbuka sedia ada melalui pemodelan, penentusahan dan tahap pengesahan bawang terbuka Delphi 4-pusingan. Vlll
TABLE OF CONTENTS
CHAPTER TITLE PAGE
DECLARATION 11
ACKNOWLEDGEMENT iv
ABSTRACT VI
ABSTRAK Vll
TABLE OF CONTENTS Vlll
LIST OF TABLES XIV
LIST OF FIGURES XVJJJ
LIST OF DEFINITIONS XXI
LIST OF ACRONYMS XXll
LIST OF APPENDICES xxiv
1 INTRODUCTION
1.1. Problem Background
1.1.1. Conventional Software Development Paradigms 2
1.1.2. Open Source Approach to Software Development 6
1.1.3. Issues in Open Source Software Development 9
1.1.4. Varying Characteristics of Open Source Projects 11
1.2. Statement of the Problem 12
1.3. Research Questions 14
1.4. Objective of the Study 14
1.5. Scope ofResearch 14 IX u·� : :-., 1.6. . · � .. \ 16 Significance ofResearch ...... ,. ---.. 1.7. Thesis Organization 2r;-- [. . {H•- - � \ 17
2 LITERATURE REVIEW 20
2.1. Open Source Definition 20
2.2. Historical Background Of Open Source Software 22
2.3. The Philosophy of Open Source 24
2.3.1. Individual developer's views 25
2.3.2. Corporate Organization's views of Open Source 27
2.4. Software Process Models Vs. Open Source Models 29
2.4. 1. Traditional Software Engineering 29
2.4.2. Open Source Models 36
2.5. Related Open Source Onion Models 42
2.6. Software Quality In Relation to User Satisfaction 46
2.6.1. Software Quality Models 46
2.6.2. Software Quality Assurance (SQA) Perspectives 48
2.6.3. Statistical Software Quality Assurance (SQA) 49
2.6.4. Open Source Approach to SQA 49
2.7. Review Summary 51
3 RESEARCH METHODOLOGY 53
3.1. Research Methods 54
3.1.1. Quantitative Research in Software Engineering 55
3.1.2. Open onion Research Approach 56
3.1.3. Research Framework 56
3.2. Research Design and Procedure 58
3.2.1. Modeling 58
3.2.2. Units of Analysis 59 X
3.2.3. Case Study Selection Criteria 60
3.2.4. Research Settings 61
3.2.5. Data Collection 63
3.2.6. Case Study Selection Size 64
3.3. Research Hypotheses 65
3.4. Open onion validation Method 67
3.4.1. Selection of the Delphi Method 67
3.4.2. Selection of Panel of Experts Participants 68
3.4.3. Panel Qualifications 69
3.4.4. The Panel Size 70
3.5. Assumptions and Limitation 70
4 CASE STUDIES 72
4. 1. The scope of the Case Studies 74
4.2. Presentation of Case Studies 74
4.2.1. Openbravo ERP 75
4.2.2. ZK-Simply Aj ax and Mobile 79
4.2.3. Adempiere ERP 83
4.2.4. Notepad++ 86
4.2.5. ScummVM 90
4.2.6. WinMerge 94
4.2.7. Eclipse Checkstyle Plug-in 96
4.2.8. MinGW -Minimalist GNU for Windows 98
4.2.9. XOOPS Web Application Platform 10 I
4.2. 10. SW Test Automation Framework 103
4.3. ANALYSIS OF CASE STUDIES 108
4.3.1. Detailed Findings 108
4.3.2. Unit Parametric Quantitative Analysis 109 Xl
4.4. Summary of Case Studies 120
5 OPEN ONION MODELING 123
5.1. Open Onion Motivation 123
5.2. Open Onion Description 124
5.3. The Open Onion Framework 127
5.3.1. Why Onion and Not Carrot or Garlic? 128
5.3.2. Open Onion Acronym 129
5.4. Open Onion Layers Modeling 129
5.4.1. Project initiation layer 130
5.4.2. Developers Layer 133
5.4.3. Maintenance Layer 136
5.4.4. User layer Modeling 140
5.4.5. External Layer Descriptive Model 141
5.5. Open Source Success Criteria 143
5.5.1. Open Source User Satisfaction 145
5.5.2. Comparative Evaluation of Open Onion Model 146
6 STATISTICAL EVALUATION 149
6.1. Initiation Layer 149
6.2. Developer Layer 153
6.3. Maintenance Layer 158
6.4. User Layer 162
6.5. External Layer 166
6.6. Cross - Layer Evaluation 171
6.6.1. Result Summary on Source Forge Case studies 174
6.7. Verificationwith Flossmole Project 176
6.7.1. Open Source Projects Distribution on Flossmole 179 Xll
6.7.2. Project Environment 183
6.7.3. Intended Audience (Domain Audience) 184
6.7.4. License Description Analysis 186
6.7.5. Summary of Operating Systems (OS) 187
6.7.6. Programming Lang vs. Dev. Status (Flossmole) 188
6.7.7. Flossmole Project Result Summary 190
6.8. Summary of Experimental Evaluations 191
7 DELPHI'S VALIDATION OF OPEN ONION MODEL 194
7.1. The Delphi's Open onion validation Process 195
7.2. Instrument Design and Implementation 197
7.2.1. Delphi Round-!: Initial survey 197
7.2.2. Delphi Round-2: Questionnaire One: 198
7.2.3. Delphi Round-3: Questionnaire Two 199
7.2.4. Delphi Round-4: Questionnaire Three 199
7.3. Delphi Validation Results and Analysis 200
7.3. 1. Delphi Round-1 Results (14 respondents) 200
7.3.2. Analysis of Delphi round-! results 201
7.3.3. Round-2 Results (11 Respondents) 203
7.3.4. Analysis of Delphi Round-2 Results 208
7.3.5. Delphi Round-3: Open Source User Satisfaction 218
7.3.6. Analysis of Delphi Round-3 Results 220
7.3.7. Delphi Round-4 (1 1 Respondents) 221
7.3.8. Analysis of Delphi Round-4 Results 224
8 RESEARCH FINDINGS 225
8.1. The Pareto principle in Open onion 226
8.2. Open Source User satisfaction metrics 227 Xlll
8.3. Statistical Evaluation Findings 228
8.3.1. Results from SourceForge Case Studies 228
8.3.2. Results from Flossmole Projects 229
8.4. Case Studies Findings 230
8.5. 233
8.6. Findings on Hypotheses 235
9 CONCLUSION 238
9. 1. Research Summary 238
9.2. Contributions 240
9.2.1. The 5-layered Open Onion Model 240
9.2.2. Open Source Success Tree 241
9.2.3. Statistical Quantitative Improvement 241
9.2.4. Open Source User Satisfaction Metrics 242
9.2.5. Validation of Open Onion Model 242
9.2.6. Pareto Principles in Open Source Development 243
9.3. Future Work 244
REFERENCES 245
APPENDICES A-H 276 - 343 XIV
LIST OF TABLES
TABLE NO. TITLE PAGE
2.1 Comparative Evaluation of Software Process Models 34
2.2 Open Source Maintenance Matrix 41
3.1 Case Study Selection Criteria 61
4. 1 Case Study Highlights 73
4.2 Openbravo project details 78
4.3 ZK-Proj ect Details 80
4.4 Adempiere Project details on SourceForge.net 84
4.5 Notepad ++ Programming Syntax Highlights 87
4.6 Notepad ++ description 88
4.7 Scumm VM project details 91
4.8 WinMerge project details 95
4.9 Eclipse Checkstyle Plug-in activity 97
4.10 MinGW-Minimalist GNU fo r Windows 99
4.11 XOOPS Web Application Platform 102
4. 12 Software Test Automation Framework Details 104
4.13 Onion Layers Parameters 106 XV
4. 14 Case Study Summary 107
4.15 Domain Audience Analysis across the case studies 111
4. 16 Domain Audience Analysed 112
4. 17 Open Source License Properties 113
4. 18 Frequency Analysis of Open Source Licenses 114
4. 19 License Coding 115
4.20 User interface frequencyanalysis 116
4.21 Further analysis of user interface 117
4.22 Topics Covered frequency analysis 118
4.23 Programming Language Analysis (SourceForge) 119
5.1 Open Onion Layers Description 125
5.2 Open Onion Details 126
5.3 Comparative Evaluation of Open Source Onions 148
6. 1 Data for Project initiation layer 150
6.2 A VG for Initiation layer Table 152
6.3 Correlations Matrix fo r Project Initiation Layer 153
6.4 Developer Layer data 154
6.5 Developer License Relationships 155
6.6 Averages at Developer Layer 155
6.7 Developer Rank Correlation Matrix 156
6.8 Correlation Matrix for developer layer 157 XVI
6.9 Maintenance Layer Data 158
6.10 Correlation on Maintenance Layer (stable release) 159
6.1 1 Correlation fo r Maintenance Layer fo r Mature Projects 161
6. 12 User Layer Data 164
6. 13 Natural Language support - license 164
6.14 Downloads-topics covered 164
6.15 Correlation fo r User Layer 165
6.16 External Layer Data 167
6.17 Project Maturity V s Downloads 168
6.18 Natural Language Correlations for External Layer 168
6. 19 Project Age Correlations fo r External Layer 1 ()9
6.20 Further Correlations on External Layer 170
6.21 Correlation Matrix for Domain Audience 172
6.22 Licenses Analyzed on Average 172
6.23 Analysis by Project Rank by Group Average 173
6.24 Further Cross Correlations 173
6.25 Project Age vs. Downloads 174
6.26 Forges on Flossmole Projects 176
6.27 Project Environment Frequency Analysis 184
6.28 Intended Audience description 185
6.29 Position of Contributors 186 XVll
6.30 License description 187
6.31 Operating system description 188
6.32 Programming Language Analysis (Flossmole) 189
6.33 Development Status 189
6.34 Comparative Study of SourceForge and Flossmole 191
7.1 Summary of Open Onion Delphi Validation Process 196
7.2 Delphi Round I: Initial Survey 201
7.3 Delphi Round 1 Onion Layers Survey 201
7.4 Delphi Round-2 Result for Project Initiation Layer 204
7.5 Delphi Round-2 Result for developer layer 205
7.6 Delphi Round-2 Result for maintenance layer 206
7.7 Delphi Round-2 Result for user layer 207
7.8 Delphi Round-2 Result fo r external layer 208
7.9 Analysis of Delphi Round-2 (initiation layer) 211
7. 10 Analysis of Delphi Round-2 (developer layer) 212
7.11 Analysis of Delphi Round-2 (maintenance layer) 214
7.12 Analysis of Delphi Round-2 (user layer) 215
7. 13 Analysis of Delphi Round-2 (external layer) 217
7. 14 Delphi Round-3: User Satisfaction Survey 219
7.15 Delphi round-4 Experts' Responses 222 XVlll
LIST OF FIGURES
FIGURE NO TITLE PAGE
2.1 Market Share fo r Top Servers (Netcraft, 2008) 23
2.2 Waterfall Model Adapted from Royce (1987) 31
2.3 Spiral Model of Software Development (Boehm, 1996) 32
2.4 task_struct in Linux Kernel (Johnson and Troan, 2005) 37
2.5 Apache incubation process (Wahyudin and Tj oa, 2007) 40
2.6 Open source projects organization (Crowston 2003) 43
2.7 General Structure of an OSS Community (Kumiyo et al., 2002) 43
2.8 Linux Kernel Onion Adapted from (Antikainen et al., 2007) 44
2.9 Linux Kernel - Google Image 44
2.10 Onion Model (Herraiz et al., 2006) 45
3.1 Research Approach 57
4.1 Openbravo's Architecture 77
4.2 ZK on Android 81
4.3 ZK spreadsheet component 82
4.4 Adempiere Application Framework (SourceForge) 85
4.5 Adempiere System Migration Architecture (SourceForge) 86 XIX
4.6 Notepad ++ Arabic window screenshot 89
#' ·-...... / - < 4.7 Notepad++ prints source codes in col�(����� 89
/ "' \ ,...... , 4.8 Scripts on ScummVM 92 �--, ' d --· 1'1 I (;s;:/��\·, ( �,:; -� �-""''-\·J ::;)\I } �:· 4.9 WinMerge File compare window ��. - 94 ?-- � / r1 U \ //_ / �-- .. l�� 4.10 Eclipse Checkstyle plug-in screenshots 98
4. 11 STAX Monitor showing a STAX Job Executing Testcases 105
4. 12 STAFProc Daemon Output on Windows 105
4. 13 Starting STAFProc (a daemon) on Linux 106
4. 14 Project Rank Calculation (SourceForge) 110
5.1 Open Onion Model 125
5.2 Conceptual Framework 127
5.3 Initiation layer Modeling 131
5.4 Open Source Proj ect Planning Phase 132
5.5 Developer Layer Modeling 135
5.6 Maintenance Layer Activities Phases 137
5.7 Maintenance Layer Flowchart Diagram 138
5.8 Sequence Diagram for Open Source Bug tracking system 139
5.9 A model ofUser Layer 140
5.10 Open Source Adoption and Implementation in Malaysia 142
5.1 1 Synthesized Open source success tree** 144
6.1 Main Schema for Flossmole Data Sources (Flossmole) 178 XX
6.2 Flossmole Project Environment Distribution Chart 179
6.3 Flossmole Skilled Vs Unskilled Developer Chart 180
6.4 Distribution of Open Source Project community 181
6.5 Flossmole Project Development Status 181
6.6 Flossmole Stable Vs Unstable Projects 182 XXI
LIST OF DEFINITIONS
DEFINITION TITLE PAGE
2. 1 Quality Means User Satisfaction (Glass, 1998) 47
2.2 Quality from Line of Code perspective 48
4. 1 Total Rank Score (SourceForge) 109
5.1 Proposed Open Source User Satisfaction Metrics 146
6. 1 Regression for User Interface against Topics Covered 156
6.2 Regression for User Interface against Operating System 157 XXll
LIST OF ACRONYMS
t;. -- -
ACRONYM TITLE
RANK Open source project rank on SourceForge
DA Domain audience
UI No ofUser Interface
TC Topics Covered
OS Development Status
ND No of Developers
NA No of Admin
%CD % Core adminl developers
OS Operating system support
NF No of Forums
LT License Types
PL Programming Language
NL Natural Lang. Support
ML No ofMailing List
%BO % of bug open total bug
YR Year registered XXlll
DD Download volume
FM No of forummessages
%CC %of CVS commit to the total submissions
FR No of fe ature requests
TB Total bug posted
RDA Relative downloads per age (age calculated from year registered to Dec 2009)
BO Bugs open
BC Bugs closed
COTS commercial off the shelf software
FOSS Free/open source software oss open source software
CATHEDRAL Commercial software development model
BAZAAR Open Source development model (freedom to share) XXIV
LIST OF APPENDICES
APPENDIX TITLE PAGE
A INTERNATIONAL PUBLICATIONS 276
B OPEN ONION CODING AND ANALYSIS 278
c OSS ADOPTION IN MALAYSIA 283
D OPENBRAVO ERP SAMPLE REPOSITORIES LIST 284
E ANALYSIS OF FLOSSMOLE PROJECT 284
F LIST OF EXPERTS 296
G DELPHI VALIDATION ROUNDS 297
H DELPHI EXPERT'S BACKGROUND 315 CHAPTER 1
INTRODUCTION
This chapter introduces the current research. It is organized into three major parts. First, the research background which states the problem, research assumptions, questions, objectives and scope of research. This is fo llowed by, significance of the research. The final part spells out the thesis organization.
1.1. Problem Background
. . Today, software developments are faced with steadily mcreasmg expectations: software has to be developed faster, cheaper and better. There are also urgent quests for what makes some software succeed over another despite the fact that user requirements usually change middle way and at the same time, application complexity increases. Meeting all these demands requires an ability to continuously reuse past available and compatible codes in order to evolve high quality software. It could be deduced from Charles ( 1992) that quality software is not achievable within reasonable costs and budget time except it is able to reuse past "reusables". A software artifact that is used in more than one context (projects) with or without modification is considered reusable. 2
l.l.l.Conventional Software Development Paradigms
The pursuit of technologies for building systems fa ster, with lower cost and higher quality has led to the advances in software technologies such as component based system development, object orientation, service oriented architecture, software reuse and open source. One of the most important benefits that reuse or revamp delivers is quality. Software reuse is a fundamental approach to accelerate the production of high quality software and this is achievable by its ability to provide the benefit of faster, better and cheaper software development processes. Reuse standards are emphasized in McClure (2001). It is a process of building or assembling software applications and systems from previously developed software parts designed fo r reuse. Software reusability saves time to market; reduces software development cost and improves quality of the resulting software; (IEEE STD 1517, 2004, Fichman and Kemerer, 1997 and George, 1997).
Interestingly, most of the earlier software development technologies have some shortcomings which could be addressed with open source. For example, in component technology, level of component cohesion and coupling actually affect customization and project integration, architectural mismatch/complexities are real issues.
In object orientation, inheritance, high cost and risk of early adoption of object orientation are real issues (Kai et a!., 1999). With software reuse methodologies, lack of tools to support the problem solving process of locating relevant reuse components hinders the effectiveness of the approach. Open Source on the other hand, provides availability of source codes at "Zero-cost" which 1s a leading edge in developing cheaper, faster and high quality software systems.
Object-oriented software development methodologies have been around for close to two decades, but many of the problems associated with these methodologies at the beginning still remain unresolved (Raman and Richard, 2008). With object orientation, there is need for compositionality; that is, 00 languages do not support the specification of an explicit typed "Inheritance Interface" for programmers who 3
develop subclasses (Meijler and Nierstrasz, 1995). Often, object oriented problems are complete specifications of objects, attributes, structures, services, subjects as well as the degree to which members within a class are related to one another is often difficultto identify.
Another short commg of object orientation is that system modification, maintenance and testing can be difficult because of inheritance and behavior overriding. Replacement of object with a new object that implements changes to the business may impact all other objects that have inherited properties of the replaced object and this may lead to excessive testing of the whole system; (Fichman and Kemerer, 1997 and Gregor and Erik, 2001 ). Object oriented approach could only support reuse of object type definition (classes) at implementation (runtime) level as described in Fichman and Kemerer (1997) and in Qureshi and Hussain (2008).
Various case studies have also illustrated the high cost and risk of early adoption of object orientation. This includes the difficulty of achieving systematic reuse in practice by Fichman and Kemerer (199) and as presented in Kai et al., (1999). Clearly, there are problems of which neither procedural nor object oriented programming techniques are sufficient. Moreover, the degree to which members within a class are related to one another is often difficult to identify (Kiczales et al., 1997).
In the IEEE software reuse guide IEEE-STD 1517 (2004), it was stated that major shortcoming of objects is that they do not scale up well when used to build large, complex systems because they are too fine-grained and at too low an abstraction level.
Furthermore, component technology suggests that components could easily be acquired and integrated together or with some other 'components' or within an on-going software development proj ects and then have much better application being developed. However, the cornerstone of a component based development technology is its underlying software component model, which defines components and their composition mechanisms. However, current models use objects or 4
architectural units as components; which are not ideal for component reuse or systematic composition (Kung-Kiu and Zheng, 2007).
Object oriented languages and models do not support concurrency and distribution while actual component model such as Common Object Request Broker Architecture (CORBA) is designed to support interoperability rather than software composition and is not intended to support application evolution (Nierstrasz, 1995).
Component technology on the other hand encourages the design of pluggable individual software units. These component units were to be plugged into an application easily to enhance the operations of such application or probably to develop an entirely new application. According to Meijler and Nierstrasz (1995), such components comprise simulation components, as well as visualization, animation and statistical components. Component technology offers advantages of being easily customized to meet current business needs and modifiable to meet changing business needs over time. Software components contains valuable existing functionality wrapped into 'reusable' components, this makes it possible to compose a mixture of pre-developed components that preserve a business' core functionality and new components that take advantage of the newest technologies, such as the internet. Paradigm examples of software components are objects written in programming languages such as Smalltalk, C++, Java and some other parts like
Active X controls (IEEE-STD 1517, 2004).
However, component technology also exhibits certain setbacks in the area of determining the level of cohesion and coupling of components. It is also difficult fo r developers to adapt a component to a new platform if it were not developed for that platform (Qureshi and Hussain, 2008). Other difficulties associated with the component technology are the architectural mismatch or architectural complexity which results in some other component disadvantages. For example, customization and integration of already developed software components according requirement of new application is a major issue in component technology. It is also difficult fo r developers to adapt a component to a new platform if it were not developed for that platform. 5
In Staringer (1994) it was made known that component libraries are probably the dominant paradigm for software reuse, and that they suffer from lack of tools that support the problem-solvmg process of locatmg relevant components. Th1s explams why the it is difficultto agree with the abstract of Gill and Grover (2003) where in, after identifying the urgency fo r Software industries to strive for new techniques and approaches that could improve software developer productivity, reduce time-to market, deliver excellent performance and produce systems that are flexible, scalable, secure, and robust., then it was added: "Only software components can meet these demands". This research disagrees with Gill on this part going by the afore-mentioned weaknesses of component technology.
In the conventional software reuse, the lack of incentive is a significant discouraging factor impending on reuse investors which invariably implies that customers would have to pay more if reuse is eventually implemented without adequate financial compensations in terms of incentives from the stakeholders (James and Chester, 1991). The studies carried out by Karma and Ajay, (1999)
revealed that reuse in practice is more demanding than the perceived benefit of reuse such as ease of use and code compatibility and this they said has led to some of the barriers to software reuse adoption.
In software development firms, it is required to commit an initial investment to reuse in order to incorporate the needed software reuse programs, as observed in Isoda (1995), so as to generate long-term savings including life-cycle benefits such as maintenance (Banker and Kauffman, 1992) and (Basili, 1990). However, the reuse program success depends on standards and tools provided to developers, on the certification of software Knight and Dunn ( 1998), as well as on the incentives for developers to reuse (Poulin, 1995).
Ironically, it implies that none of these paradigms (component technology, object orientation and software reuse) have been able to effectively independently justify its capabilities of evolving high quality software cheaper and quicker. The edged which open source has over all is its capability to avail the source codes at relatively no cost in an easy-to-use fo rmat. 6
Notable academic research activities have been conducted in the field ofopen source. It was observed from Madey et a/.(2003); Gao and Madey (2007); Jin et al.
(2005); Jin Xu and Madey (2006), Oostendorp (2009); RaJdeep et al. (2006) and
Zheng et al. (2008) that most of the open source research activities are based on the social network analysis of open source development. Feitelson et al. (2006) conducted a research based on the distribution downloads as a yardstick for measuring a successful open source project. Timo and Virpi (2005) were fo cused on the maintenance process of open source as a way of mapping the maintenance activities of the chosen open source case studies to the existing ISO/IEC maintenance standards. Scotto et al. (2007) conducted a research on mining the open source repository.
In Zhao and Elbaum, (2003), survey on open source quality assurance activities were mainly based on testing phases of the software development where it was reported that there is need for more research on identifying the most efficient procedure to deploy and carry out quality assurance activities in open source.
Presently, most investors do not fully understand the open source model. The commercial models have well-defined profit motive, yet they are still developing and consequently unpredictable (Peeling and Satchell, 2001).
However, numerous issues could be identified within the context of the open source development model. Some of which are the Profitability, Security, collaborative, testing, interoperability, legal issues and acceptable software process model for open source development. For the purpose of defining the research boundary, the development of a layered software process model to support open source development would be fo cused in this research.
1.1.2. Open Source Approach to Software Development
Basically, there are two broad developmental paradigms of software development methodologies. Software could either fall under the category of commercial off the shelf software (COTS) or Free/open source software (FOSS), 7
henceforth referred to as open source software (OSS). This dichotomy results in a sharp difference between OSS development process and the traditional COTS models. According to Hansen (1999) both COTS and the advent of open source distributions have placed new requirements on software deployment by introducing new complexities to configuration management.
In the corporate COTS model, development is done under the aegis of COT vendor who views the codes as valuable intellectual property and controls when versions of the software are released. The open source, in contrast is a community based development which thrives with or without the presence of the original initiator of the project (Mockus et al., 2002), (Ferenc et al., 2004), (Jack, 2001) and (Kavanagh, 2004). Open source is an alternative paradigm, which encourages open access to source codes for further reuse and modifications. This goes a long way in addressing most of the core issues in software crisis such as software development time frame and software exceeding budgets. Attempts to handle some of the crisis have led to advances in research in the areas of perceptions on softwarequality.
In traditional software development paradigms, there is little evidence of developer views being sought or incorporated into specific quality initiatives (Wilson and Hall, 1998). This has a direct impact however, on the quality of software that the practitioner produces. Early measurement of users' perception, which usually changes with time as they progressively become more acquainted with the software product, was suggested in Stavrinoudis et al. (2005) with a view to improving software quality and reducing the common softwarecrisis.
The success of Linux and Apache has strengthened the opinion that the open source paradigm is one of the most promising strategies to enhance the maturity, quality, and efficiency of software development activities (Fuggetta, 2003). In open source development methodology, developers who are geographically dispersed usually work together to produce software. It is a collaborative development paradigm characterized by various developers (usually volunteers) and users broadly geographically dispersed. 8 However, open source mode of operation and robust functioning also poses novel and fundamentalquestions for research on principles by which productive open source work can best be organized smce the open source commumty mostly comprised of 'volunteer' developers, with differing styles and agendas, whoIS develop and debug the codes in parallel (Georg and Eric, 2003). The success of several open source softwaresystems has recently generated interest in studying and emulating the software engineering principles underlying this innovative development. Paradigm examples of successful open source development projects include: Apache web server, Bind provides DNS (Domain Name Service) for the Internet, Sendmail is the widely used e-mail transport softwareon the Internet, Emacsis a program text editor, Linux is an operating system kernel,as well as other Linux-based operating systems such as Ubuntu and Fedora. Open source software(OSS) has become the subject of much commercial interest of late. It addresses most of the core issues in softwarecrisis such as software development time, software exceeding budget as stated in Caliber (2006) and Fitzgerald (2005). Open source goes a long way in accelerating the software development process through 'software evolution methodology' and since it is mostly free,the acquisition cost is close to zero and is affordable. The major motivation behind open source is that when programmers can read, distribute, and modifysource code for a piece of software, 'the software evolves' (Yunwen and Kishida, 2003). Open source simply is software with its source code available which may be copied, used and redistributed with or without modification. Ideally, open source softwareis software whose source code is openly published, and is usually available at no charge, and which is oftendeveloped by voluntary efforts. It is a term used to describe the tradition of open standards, shared source code, and collaborative development. The most common type of reuse in open source is code reuse (Koch and Neumann, 2008; Mockus, 2007; Stefan, Georg and Sebastian, 2008). Open source developers reuse codes because they want to integrate functionalityquickly and because they can mitigate development cost through code reuse. 9 It is therefore not surprising to note that many firmsand governments have adopted open-source software, since thisenables these organizations to reduce costs. However, economists have found it difficultto understand the supply side of open source innovation, especially the labour supply (Siegel and Wright, 2007). However, the open-source approach is the software industry's most successfulfo rm of large-scale softwarereuse. Open-source softwareoffers the most impressive range of reusable assets for any softwareproject. Open-source softwareis available for virtually all activities, runs on every platform, and can be used in almost every business domain for which softwareis written (Booch, 2002).
1.1.3.lssues in Open Source Software Development Numerous issues could be identifiedwithin the context of the open source development model. Paradigm examples of such issues are empirical issues Daile et al (2008), problems associated with uses of open source by some software vendorsas discussed in Herwig and Kris (2005), architectural issues in Lennerholt et at. (2008) and issues of trust in Orsila et al. (2009). Other issues are profitability, security, collaborative, testing, interoperability, legal issues and acceptable software engineering standards. It is interesting to note that most softwareinvestors do not fully understand the open source model, its profitabilitymodel is still developing and therefore unpredictable (Satchell, 2001). Most of the problems with some softwarethat fail the market acceptability is that the development could not have been funded continuously until the softwareattains a high level of quality to be readily accepted by the community. Some proprietary software(e.g. MicrosoftWindows NT) has been continuously supported by the resource and management committee of the particular softwareproduct to continue pushing the products that they believe in for as long as it takes for them to take off. 10 Open source however solves this problem by having a zero cost base; so running out of capital (money) is not a problem as long as the group of developers (community) mamtains their mterest, the proJect (softwaredevelopment) keeps on going. Also, the ability for users to acquire complete softwarewithout having to sign licenses and make financial case to their management; aids initial take off. In open source development, creativity is more prevalent and the belief that defects are found and fixed more rapidly in open-source projects were confirmed in Paulson et al. (2004). The open source is an effective practice which has evolved as a set of customs, transmitted by imitation and example, without the theory or language to explain why the practice worked. However, lacking the theory and language hampered the open source community in two ways: It would be difficult to think systematically to improve the development method and it would be very difficultto explain or show the method to anyone else (Raymond, 1999). Most often,open source development is described based on case studies (Mockus et at., 2002) and (Gurbani et al., 2006). This is because open source development does not follow a strict software development methodology unlike the traditional softwaredevelopment which follows strictly, some softwaremodels such as the water fall and Spiral. However, the necessity to map softwaredevelopment within open source precepts into some 'well understood' software development stages is therefore indispensable and it is the focus of this research. Interestingly, the open source phenomenon works, however with lack of theory to explain why and how the open source model works which hampers the open source community in two ways according to Raymond ( 1999), saying that it becomes difficult to think systematically to improve the model and difficult to explain or teach how the model works. These imply that there is need for concrete softwareprocess models to support open source development processes which open onion model presents in this research. Numerous successful open source projects point at the fact that the open source model is viable; for example, Linux kernel development, Apache development and Mozilla development. 11 Interestingly, successfulopen source software(OSS) developments are quite different from one another. For example, Apache allows for volunteers to take part in all acnvitles while in Mysql, development is done mtemally withm the company of Sun Microsystems. An attempt to streamline the development has yielded the issue of open source being synonymous to "Onion". Therefore, the Open Source development is usually described with onions as presented in (Crowston and
Howison (2003); Kumiyo et al. (2002); Antikainen et al (2007) and Herraiz et al., (2006). Major challenge with previous open source onion models was the validation process as discussed in Crowston et al. (2004) which states: "The onion model of open source has a good-face validity which requires the onion to be put to fUrther test " This research presents the open onion model which has gone a step furtherin providing empirical evaluation and Delphi experts' validation across each layer of the open source onion model as well as the development and validation of open source user satisfaction metrics.
1.1.4. Varying Characteristics of Open Source Projects This section examined the challenges faced by today's software development efforts. As discussed Section 1.1.1 attempts to overcome these challenges have led to the advances in various softwaredevelopment paradigms; such as object orientation, component technology and softwarereuse. However, these methodologies have series of shortfalls for which open source development methodology has been identified to overcome as spelt out in Section 1.1.2. Interestingly, open source development paradigm has yet unresolved issues to which research answers are still being sought and despite the fact that open source development has proved successful, it is still observed that it has varying characteristics which makes it difficult to teach open source model as well as a 12 difficultyto explicitly explain the underlying success theories (DeKoenigsberg, 2008; Feitelson a!., 2006; David Hinds, 2008; Rajdeep et al., 2006 and Weber, 2004). et In practice, some of the open source projects have shown their disparity in development approaches. Successfulopen-source projects can be quite different from one other. Some open source projects such as Apache, are very democratic and volunteers are welcome to participate in all activities, others, such as Mysql, where almost all of the developers work for one company, primarily do their development internallyand then release the results; users and developers engage with each other to report bugs, request new features, and generally discuss the software, but development happens less visibly. Linux development is very central, where the final decision lies on the owner of the core afterpassing through the designated lieutenants (Antikainen et al., 2007). There are even some projects that do not have a community at all, but consist of just a web page where new versions are made available for people to download and perhaps email address where comments can be sent (Goldman and Richard, 2005). an In traditional software process model, due to budget overrun and late delivery, many projects are forced to be aborted or are missing implementation of some components or are delivered without thorough debugging (Tsoi, 1998). This makes it clear why traditional softwareprocess models are not suitable for open source development.
1.2. Statement of the Problem The process of finding various solutions to end some of the softwarecrisis such as softwarebeing developed faster, cheaper with high quality, has led to the advances in software developmentparadigms such as object orientation, component technology and software reuse; however, realizing the shortcomings of these paradigms as discussed in Section 1.1.1, have led to the motivation towards open source development. This is because open source has offered more robust software 13 development methodology that has resulted in high quality software. Forinstance, Linux, Apache and Mozilla are high quality software outputs from open source development paradtgrn. It is however interesting to note that open source development exhibit varying characteristics as earlier explained in Section 1.1.4. Despite high quality software output fromopen source development processes; there are quite a number of issues yet unresolved under the open source development methodology. Some of these issues are as stated below: (i) There are four existing open source onion approaches as at the time of writing this thesis (Crowston and Howison (2003); Kumiyo et al. (2002); Antikainen et
al. (2007) and Herraiz et al. (2006). Interestingly, all these open source onion concepts were briefly descriptive and were not put to test. Validating these open source onions is an issue as described by Crowston et al. (2004): "The onion
model of open source has a good-face validity which requires the onion to be put to fu rther test ". (ii) Availability of open source theory for educational purposes and for younger generations to build upon was another issue as explain by Raymond ( 1999) thus: "Lack of Theory to explain why and how the open source model works hampers the open source community in two ways, it becomes difficult to think
systematically to improve the model and it becomes difficult to explain I teach how the model works ". (iii) Considering the fact that human are very difficult to satisfy,it becomes thought provoking to make out the right user satisfaction metrics within open source
development precept. The study of Feitelson et al. (2006) was focused on considering open source quality and success fromthe number of downloads criteria alone. This research would therefore investigate the open source user satisfaction metrics using Delphi's approach in order to ascertain the open source project quality fromthe user satisfaction perspective. 14
1.3.Research Questions (i) What characteristics of Open Source projects have made them synonymous to onions layers? (ii) How well could the onion models of open source be generalized? (iii) How well can each layer of the Onion be modeled? (iv) To what extent could the open onion model be evaluated and validated? (v) What characteristics of open source projects are the open source users mostly on the lookout for?
1.4. Objective of the Study (i) To evolve an improved open omon model of open source from literature reviews and case studies. (ii) To evaluate model To develop openthe proposed source user open satisfaction onion metricsstatistically fromthe analysis of the case (iii) studies. (iv) To validate both the open onion model and the open source user satisfaction metrics using Delphi's approach.
1.5. Scope of Research This section discusses the boundaries of this research. It sufficesto note that the open onion model is developed into fivelayers of the onion model and that the study is confined to the open source development project characteristics and not how the open source codes were developed; therefore; statistical analysis is used in the evaluation of the case studies. This study does not cover legal issues involved in open source and interoperability between open source and COT software projects is not investigated. Other aspects of the research boundaries are discussed in sections that follow. 15 This research caries out a literature reviews on previous open source onion models; performs comprehensive case studies on ten highly ranked and very active open source development proJects fromSourceForge and extracteddata for one thousand one hundred and four (ll 04) projects fromFlossmole repository.
The term highly ranked projects in this case, refers to the SourceForge project rank. This research has therefore adopted the SourceForge project ranking style as the l 0 case studies are adopted according to their SourceForge ranks without any alterations. Ranking order was not considered necessary for the Flossmole projects because project data were submitted into the Flossmole from various heterogeneous forges such as freshmeat,sourcef orge and savannah. Despite the fact that there are some existing onion models of open source as at time of thesis writing as earlier described in Section 1.2, those onions were not validated using any known validation techniques. This research improves the previous onion models of open source by evolving a more generalized onion model of open source that is capable of mapping and merging some layers of the existing onions into S-layers of newly proposed openonion model. The layers of which would be named according to the activities that are taking place (for example developers, maintenance and users) within each of the layers of the onion. Each layer was modeled descriptively using EDraw Max4 and evaluated statistically using SPSS 16.0. Validation of the proposed open onion model would be performed across the onion layers using Delphi's approach to be carried out in four rounds. Since not all open source projects succeed as discussed by Katsamakas and Georgantzas (2007), it is therefore a challenge to identifyopen source success factors from open source user satisfaction perspectives. User satisfaction is a usefulmetrics to definingsuccessful software quality metric (Glass, 1998; Jiang et al., 2002; and William et al., 2004). This is because user satisfaction is usually a key component in achieving successfulsoftware project status. This research assumes that open source user satisfaction is a fundamental metric for measuring an open source project success. Therefore, the open source success metrics were examined during the open onion Delphi experts' validation 16 rounds and this was used in Chapter 5 to develop the open source user satisfaction equation.
1.6. Significance of Research The necessity to map softwaredevelopment within open source precepts into some 'well understood' softwaredevelopment stages is indispensable. Consequently, a 'softwareprocess model' for open source development is highly imperative. In order to achieve this, open onion approach is developed to characterize open source development projects into layers based on some of its predetermined parameters, as obtained fromthe analysis of case studies, such as domain audience, programming language, operating systems support and project license, which presents a simplified open source development tasks. Generally, softwarepr ocess comprises of activities, methods and practices necessary to develop a softwaresystem Humphrey ( 1990). While there are diverse views on presentations of process models, Osterweil ( 1997), Lehman ( 1987) and Kahen et al. (2001) maintain that formal representations such as computer programming are too deterministic for process enacted by humans. Therefore Johnson (2001) upholds that informal representations of process models are more appropriate for human enactment as opposed to process automation. Previous researches on open source have mostly focused on network analysis (Andrew et at., 2008; De Sousa et at., 2009; Jin et at., 2005; Jin Xu and Madey, 2006; Lin, 2008; Rajdeep et al., 2006; Zheng et at., 2008). Maintenance activities in open source have also being researched justifiably by Timo and Virpi (2005). Interestingly, academic research literatures have oftendescribed open source with onion-like structure (Crowston and Howison, 2006; De Sousa Jr et al., 2009; Herraiz et al., 2006 and Kumiyo et al., 2002). It then became a serious thought-provoking issue for the author on why onions? Why not carrot or garlic? The literatures have oftenpresented the onion descriptions passively without putting the model to some 17 form of validation. Consequently, this thesis provides statistical evaluation of case studies and Delphi's validation of each layer of the open source onion model. An open omon model was evolved from the case studies; descriptive modeling and statistical evaluation were adopted. In this research, descriptive modeling, case studies and empirical statistical studies have revealed some valuable results and Delphi's validation experts have substantiated the validity of the results. The case studies were carefullyexamined in Chapter 4 and this led to the development of the open onion model in Chapter 5. Empirical results of case studies evaluation of Chapter 6 form the basis for the development of the Delphi's open onion validation process in Chapter 7. The outcome of this research thus provides open source policy makers, developers and open source governmentadopters, the appropriate guidelines for future improvement onopen source development phases and consequently improving the quality of open source development projects from user satisfaction perspectives. The outcome of this research can also be used to facilitate discussions on common representation of open source development approaches which would eventually support open source process management and improvement by helping in identifying problem areas before they occur. For example user satisfaction metrics which was developed in this research shows what are likely to attract open source users towards a particular open source project.
1.7. Thesis Organization This thesis is organized into nine chapters as detailed below:
(i) Chapter 1 Introduction: This chapter presents a detailed introduction of the research in terms of problem background, statement of the problem, research 18 assumptions and objectives of the research, research scope, research methods, research significance and contribution to knowledge.
(ii) Chapter 2 Literature review: This chapter reviews the relevant literature on open source developments and reviews previous onion models in open source. A comparative evaluation of previous onions models was also presented. This chapter is divided into six sections. First is the open source definition followed by the historical background of open source. The third section reviews the philosophy of open source. Notable software process models were presented in the fourth section and the fifthsection presents previous onion models of open source. The last section of this chapter reviews literature on open source process models borrowing fromsuccessful open source projects; Linux, Apache and Mozilla.
(iii) Chapter 3 Research Methodology: The overall methods adopted in developing this research are described in this chapter. The case studies from SourceForge, the development approach to the proposed open onion model was described, the empirical evaluation methods were examined and the Delphi's validation approach was discussed as well.
(iv) Chapter 4 Case Studies: Ten case studies were investigated on SourceForge. Project activity data for the case studies were presented. The projects details obtained from thecase studies triggered the open onion modeling, analysis and validation in subsequent chapters.
(v) Chapter 5 Open Onion Modeling: In this chapter, the open onion model was developed. Descriptions of open onion layers, the research framework and the open onion Meta models were presented. The last section discusses comparative evaluation of open onion model against the previous onion models.
(vi) Chapter 6 Evaluation of Open Onion Model: In this chapter, the case studies were analysed quantitatively to identify valuable results. Based 19 activity details of the case studies, twenty parameters (for example, Domain audience, license types, topics covered, development status, programming language and natural language support)were mvestigated. This ledto the formulation of the Open Source User Satisfaction equation.
(vii) Chapter Validation of Open Onion Model. This chapter presents the experimental7 validation of two parts. Delphi's expert validation technique was adopted. The first part was the validation of the open onion model across the layers of the onion. The second part was the validation of open source user satisfaction equation SourceForge case studies were experimented and Flossmole was used as cross validation experiment for the case studies and opens source user satisfaction equation are presented.
(viii) Chapter 8 Results. In this chapter, detailed findings and results were presented. Open onion logic was presented and proved. Prominence of Pareto 80/20 rule of project developer/administrator was shown.
(ix) Chapter 9. Conclusion. This chapter wraps up this thesis with conclusions and future research. First the conformance of the thesis to the research objective was presented, next the major contributions were stated the finally the conclusions, recommendations and future work were presented. CHAPTER 2
LITERATURE REVIEW
Open source is a concept of shared source codes, artifacts and community based collaborative softwaredevelopmental paradigm. Open source approach to software development utilizesthe tenet of geographically distributed methodology to have peered reviewed and transparency of processes to achieve better quality, higher reliability, greater flexibility, lower cost as well as end to voracious vendor lock-in. This chapter documents the review of literature in open source. It begins with OSI, open source initiative definition(OSI, 2009) and taxonomy, and the historical background of open source. Next, it presents the philosophy of open source. Notable traditional software process models were presented followed by related work on open source research. The next section reviews the approaches to open source development by top-level successful open source projects; in particular, Linux, Apache and Mozilla were reviewed. Software quality models were reviewed and review summary was presented last.
2.1.0pen Source Definition As defined by the open source initiative (OSI), Open source does not just mean access to the source code. The distribution terms of open-source softwaremust comply with the certain criteria (Kavanagh, 2004) as listed below: 21
(i) Free redistribution: software to be available for redistribution without payment.
(ii) Source code: the softwareto be distributed with the source code or well publicized access to it.
(iii) Derived works: license to allow modification of the softwareand distribution of resulting derived works.
(iv) Integrity of the author's source code: distribution of "patch files" used to recreate the derived work (rather than fullsource code) to be permitted.
(v) No discrimination against persons or groups
(vi) No discrimination against fields of endeavor: This implies for example, that limiting use to non-commercial purposes is not permitted.
(vii) Distribution of license: must be no need to execute extra licenses for redistributed software.
(viii) License must not be specific to a product: license rights not to depend on the softwarebeing distributed with other specified software.
(ix) License must not restrict other software: the license must not place restrictions on softwaredistributed together with the licensed software.
(x) License must be technology-neutral. (Henley and Kemp, 2008) 22 The open source definitions were studied in order to have background knowledge of open source philosophy. This definitionshows clearly that open source program must includesource code. The source code must be in a form in which a programmer could modify it. Meaning that it is not allowed to deliberately obfuscate source code, it must also allow distribution in source code as well as compiled form; and where the product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost such as downloading via the Internetwithout charge. It also shows that open source license allows modifications and derived works and in open source distribution, there is no discriminate against any person or group of persons or field of endeavor. These rich definitions of open source, has prompted for a further research on the details' of the genesis of the open source culture. The historical background as detailed in Section 2.2 shows that the culture of free softwarehas been in existence for decades before IBM's software unbundling began which actually separated the free software culture which were usually integrated hardware systems prior to distribution.
2.2. Historical Background Of Open Source Software In the beginning, there was only free(Libre) software.Later on, proprietary software emerged and was dominant until lately (Barahona, 2000). When IBM sold the first large-scale commercial computers, in the 1960s, they came with some software which was free(Libre). That is, the software was freelyshared among users. Proprietary softwarebegan with the ''unbundling" of IBM softwarein the late 1960s, and by the mid-1970s proprietary software became popular (Grad, 2002; Humphrey, 2002). In late 1970s and early 1980s, Richard Stallman, formerly a programmer at the MIT AI Laboratory as discussed in Suvasa (2002) and Richard (2000) launched the GNU Project and the Free SoftwareFoundation in Stallman 23 ( 1984) with a goal of building a freeoperating system. It all started by some programming tools coding such as a compiler and an editor by Richard. The GNU compiler now supports over thirty different architectures and seven programming languages (Stallman, 2006). The GNU General Public License (GPL) was designed not only to ensure that the softwareproduced by GNU will remain free, but to promote the production of more free software(Kuma r, 2006). At the same time, the computer science research group (CSRG) of the University of Californiaat Berkeley was improving the UNIX system and building applications which eventually become the BSD UNIX (Sarkinen, 2007). However, in the late 1980s, it was finally distributed under the ''BSD license" which is one of the first open source licenses. Unfortunately, at that time every user of BSD Unix also needed an AT&T UNIX license, since some parts of the kerneland several important utilities, which were needed for a usable system, were still proprietary.
80% - Apache
- 11icrosoft.
Sun - lighttp NCSA - Other 40% �- � 0% ;=: 10 ID ID " " (X) (X) 0\ 0\ 0 0 ...... N N (') (') ..,. ..,. 10 10 ID ID " " (X) (X) 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 ...... N N N N N N N N N N N N N N N N NN ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\ ::> :J'\'00 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 Ill 0 ..- Linus Torvalds, who was then unhappy with Tanenbaum's Minix Jorrit et al. (2006), was implementing the first versions of the Linux kernel.The collaborative exercise by many people makes the kernel more usable The Linux kerneland other 24 GNU applications which are used on top of it are GPL licensed. In 1993, both GNU/Linux and 386BSD were reasonably stable platfonns. Since then, 386BSD has evolved into a family of BSD based operating systems such as NetBSD, FreeBSD, and OpenBSD (Dinh-Trong and Bieman, 2004). In the late 1990s, open source systems based on GNU/Linux are gaining public acceptance, and have become a real alternative to proprietary systems, competing head to head with the market leaders (like Windows NT in servers). In Figure 2.1, the best choice is open source with an outstanding case of Apache as Web server, with a market share consistently over 50% of the market (Netcraft,2008). The Linux kernelis seriously developing and it is being used in various GNU/Linux distributions such as Stackware, Debian, Red Hat and Mandrake. A comparative study on the maintainability of four open-source operating systems: Linux, FreeBSD, NetBSD, and OpenBSD were observed in Yu et al. (2006) and currently, the open source movement are said to have matured enough to be referred to as a balanced methodology of softwaredevelopment (Krzysztofand Sebastian, 2005). 2.3. The Philosophy of Open Source Better software development is achievable when existing codes could be revamped quickly and cheaply. Open source culture allows for developers to contribute codes to on-going open source projects and provides free access to source codes of existing projects. However, there are various reasons why developers may wish to contribute to open source development projects; of prominence are individual's view as discussed in Section 2.3.1 and corporate organizational views as presented in Section 2.3.2 and as revealed fromextensive reviews of Bitzer et al., (2007); Gardinali (2003); Hars and Ou (2002); Hertel et al. (2003); Lakhani and Wolf (2003); Yunwen and Kishida (2003); Fitzgerald et al. (2005); Lakhani and Eric (2003). The two views are presented in the sections that follow. 25 2.3.l.lndividual developer's views (i) Law of Reciprocal Giving: According to Raymond (1999 and 2004), higher future returnsare captured when an open source patch is released for free because it gives rise to reciprocal giving. It implies that distributing the patch to the public for freewill encourage other softwaredevelopers to do the same with their own privately produced patches, and many of these patches will tum out to be usefulto others in the community. (ii) Striking equilibrium: As a result of the reciprocal gtvmg, releasing the patch for freeis the optimal choice for each developer in order to obtain the required equilibrium outcome; although Raymond relies rather heavily on a social psychological notion of reciprocal giving. (iii) Reputation of Programmer: By voluntarily contributing to Open Source, a developer's reputation as a skilled programmer could be enhanced. For example, by revealing one's programming code, the developer can signal his skill level, or stock of programming human capital, to the community of softwaredevelopers. This could lead to differentially higher expected future returnsthrough higher futureskill prices. (iv) Labour-market signaling functions: The labour market signaling function of voluntary contributions is the central notion in the work of Lernerand Tirole (2000). They also note that the signaling incentive to voluntary contributions suggests that strategic complementarities may be important. In order to signal one's skills most effectively, an open-source developer will mostly likely want to participate in open-source projects that also attract many other developers. (v) The Higher larger community the better: The marginal benefit of voluntarily contributing increases with the number of developers involved in the project. Along these lines Johnson and Troan (2005) modeled a developer's decision to invest effort in developing code that will become a 26 public good, and fo rmally illustrates the effect of a changing contributor population size. (vi) Although the central fo cus in Lernerand Tirole (2000) is on the signaling role of open-source participation, and in Raymond ( 1999 and 200 I) it is on reciprocal giving, the role of non-pecuniary benefits is also clearly recognized in previous research. (vii) The Gift Culture: Slightly away from theabove mentioned researches is the issue of non pecuniary benefit. For example, in Raymond (1999) the open source community is conceived of as a gift culture in which a developer's status in that community depends on the quality of the software gift that he/she gives to others. (viii) Ego Gratification: Another source of non-pecuniary benefits identified in Raymond (1999) is ego-gratification, or peer recognition. Developers are likened to craftsman who wants others to admire their artistic style of coding. (ix) Ideological Satisfaction: Non-pecuniary benefits can also come in the fo rm of ideological satisfaction fo r those who believe software should be supplied free of charge or that Microsoft abuses its market position. The voluntary contributions optimization model outlined above not only provides a useful and simple theoretical framework for identifying the main factors that affect supply at the individual level, but it can also be adapted to help explain the decision of commercial firms voluntarily to open up internally developed code. Following another example in Raymond (2001), suppose the internally developed software is an intermediate good in the firm's production process, e.g. an accounting package. As in the individual developer's decision problem, the firm may choose to keep the initially developed code closed, or may release the code into the public domain. The initial development costs are sunk. 27 2.3.2.Corporate Organization's views of Open Source At corporate levels, the main advantages of releasing the codes voluntarily to open source could be summarized thus: (i) Higher quality assurance process: The main reason for firms to release their internally developed codes has been expressed in Raymond (1999); "Given enough eyeball, all bugs are shallow". Firms may want to release their code into the public domain in order to receive programming input from hundreds of additional developers enabling wider testing strategies of the codes. However, while the firms may hope to benefit from the dispersed knowledge of developers in the wider open-source community, there is also a chance that no help will be fo rthcoming at all. This is because the desire of developers to participate in an open-source project initiated by a commercial firm may be weak (Sauer, 2007). With firm-initiated projects, developers are less likely to reap non-pecuniary benefits related to ideological satisfaction and/or enhanced status in the open-source community. For example, contributing to improved functionality of an accounting package for a commercial firm is generally considered to be less 'challenging' than contributing to a mathematical program to be used by researchers. Developers may also intensely fear that the firm will 'hijack' the resulting software product and eventually close it off from further open-source development. It is fo r these latter reasons that the fo rm of intellectual property protection, or the license under which a project is released, can be a critical factor in the developer's decision to supply labour into open source development. (ii) Spread the Risk of development: In the firm'sperspective, opening up the code, even under a restrictive license such as GPL, can be advantageous for some other reasons. For example, releasing the code can help spread the risk of development. If the code remains closed, or internal to the firm, it could be costly to find suitable replacement programmers after the original In house developers have left 28 (iii) Project license affects developer's contribution: A review of the effects of open source licenses on the open source developer contributions was carried out (Ashley and Hyunju, 2007; Determann et a!., 2007; Ueda, 2005), (Valimaki and Oksanen, 2005), (Lerner and Tirole, 2005). It was observed that in some cases, it may be necessary fo r a firm (or other project initiator) to induce developers' participation in an open-source project by putting the project under a restrictive license such as the GNU General Public License (GPL). GPL is a restrictive license because it requires that the initial code and all modifications remain freely available, that any derivative work is also licensed as GPL, and that the resulting code not be mixed with closed source software in any re-distributed works. GPL makes commercialization of the resulting code difficult. Placing the project under GPL, rather than Berkeley SoftwareDi stribution (BSD) or some other less restrictive license, can help satisfy ideological preferences, reduce the fear of hijacking, and induce greater participation from the developer community. (iv) Improved Maintenance: Releasing the code to the:open-�ou n.:e community can provide more continuity and fluid program maintenance, acting as a fo rm of insurance against the deleterious effects of turnover in the market for developers (Raymond, 2001). (v) Support Services: Firms can also benefit from providing complementary support and consulting services fo r open-source products, from increased operating system standardization which lowers the costs of providing complementary proprietary software and hardware products, and from embedding open-source components in proprietary software and hardware bundles in order to lower licensing fees. As a result of these potential benefits, several large firms have been known to fund open-source projects directly and offer salaries to open-source developers (Berlecon Research, 2002). It can be concluded based on Jing and Jiang (2008) that free Libre open source software has a very bright development prospects. 29 In this section, it was stressed that open source goes beyond only access to source codes; emphasizing that the software must also comply to the open source distribution standards as spelt out in the open source definition in SectiOn 2.1. The historical review on open source fr om the 1960's IBM software unbundling to the GNU, BSD and Linux distribution of open source kernel was presented in Section 2.2 The philosophy on why open source developers are motivated to contribute to the open source development is described in Section 2.3 as viewed from individual perspective Section 2.3.1 and corporate organizational views Section 2.3.2. It is interesting to note that license types actually influence developers' motivation in open source development. It is evident from Figure 2.1 that the open source philosophy works since it is observed that the Apache compares favorably well with the dominant Microsoft and Sun which have been in the server market fo r many years before Apache was developed. 2.4. Software Process Models V s. Open Source Models In this section, the existing traditional process models such as waterfall and spiral models are discussed as well as the current open source development model in order to shed some light on the variability and disparity between the two software development approaches. 2.4.1. Traditional Software Engineering An engmeenng approach to software development is characterized by a practical, orderly and measured development of software whose principal aim is to produce satisfactory systems on time and within budget. Finally, this approach is measured. During each phase of the software process, software metrics are appliedto the product that has been produced in order to gauge the quality, cost and reliability 30 of what has been produced. Open source is considered another innovative approach to software development which still comes under the fi eld of software engineering. It is usually recommended that one or more developmental models appropnate for a software project be determined (ISO/IEC 12207, 2002). Software process models such as the waterfall, incremental, evolutionary, rapid prototyping and the spiral models are practical example. A project may need a combination of these models, or different models fo r different phases, builds, or portions of the product or service. Software models are usually constructed with standard processes and activities. The processes and activities may be recursed, revisited, overlapped, or iterated. It is noticeable that, because of the presence of system-level activities, the developmental models need to be compatible and consistent with the project or the system's life cycle model (Moore, 2008). (i) Waterfall model Waterfall model is the classic life cycle model. Waterfall is the "commonsense" approach which was introduced by Royce (1987). The waterfall model is the oldest software process model. It is a top down model and provides a baseline management which identifies a fixed asset of documents produced as a result of each phase in the life cycle. A review of the waterfall model is represented in Figure 2.2 and as documented in Royce (1987) and Walker (1998) shows that it generates very long phases for software developments. The problems with systems developed with waterfall model, which were not discovered during the development life cycle, come up after implementation and deployment of the system. The waterfall model's approach has indeed helped in eliminating many difficulties previously encountered on software projects; and it has actually become the basis for most software acquisition standards in government and industry. 31 �------� I Chan�ed � ------� I Requircmcnh I I I r------I I V&V I -, ------' C01Ulllf\IC41Cd I R<-lui•cm . .. ------V&V I � Ro:quiremcnts Spc�iAClltioo ------, I -- '.'&V I Dc�iga I Rc:q11it'CblCnlS � I En!!ltl Figure 2.2 WaterfaU Model Adapted from Royce (1987) (ii) Spiral Model The spiral model is developed to overcome the disadvantages of the waterfall Model of Boehm ( 1996); however in order to fo llow spiral, highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task. Therefore, spiral model is intended for large, expensive and complicated projects. 32 & Cumulatove cost Progress 1. Determine objectives .. 2. Identify and resolve risks Review \' / ___.- 11 1tegrati�,. / 4. Plan the next Test / iteration Release Implementation -----· 3. Development and Test Figure 2.3 Spiral Model of Software Development (Boehm, 1996) Donaldson and Siegel (2007) have explained that the use of risk assessment into project plan development can help organizations deal with real-life hazards and help ensure the proj ect's successful completion especially where there is one way to divide development into stages except fo r the project planners to divide the development into some set of stages that makes sense. A spiral model of software development and enhancement which was presented in Boehm (1988) was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. Figure 2.3 shows the iteration phases of spiral model and each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. 33 (iii) Rapid Application Development (RAD) I Prototyping Lifecycle A prototyping approach to software development focuses on producing prototypes as the project progresses. A prototype is an executable model that accurately reflects a subset of the properties of a system being developed. It also aids the understanding of the system being developed. Making changes to prototype is easier than changing a whole system. There are several fo rms of RAD; for instance DRAD (Dumb RAD), GRAD (Generator RAD) and CRAD (Composition RAD). However, it was clearly stated in Boehm (1999) that of the several RAD fo rms available, the one which is most frequently used fo r ambitious systems, Dumb RAD, is the least effective. GRAD's main problem is scalability, as the generators often offer ease of expression and assembly at the cost of efficiency. DRAD occurs most frequently when a decision-maker sets an arbitrarily short deadline fo r completing a software project. This needs to be avoided at all costs because it can only result in disaster (Boehm, 1999). The RAD approach was made possible with significant advances in software development environments to allow rapid generation and change of screens and other user interface fe atures. The end user is allowed to work with the screens online, as if in a production environment. Most RAD software has predesigned set of RAD - business-objects. Therefore, tool choice largely determines the set of object definitions, attributes, and methods that are available for use and reuse (Zubeck, 1997). 34 Table 2.1: Comparative Evaluation of Software Process Models .... - I • I I m.tOO\ f.l.'f ll'll ltiJ!.{Ii----1 JiJtmf" - mmm-..- UTI!n'l. Reflects Iteration is expensive Offers cheaper engineering-like Engineering development approach Practices UF.U'�Jlll !ilt!I[W For long-term Inflexible Very flexible, applicable to both projects long and short-term projects Prototypes are Suitable for Large Suitable of all kinds of software used at each stage projects projects I I I Risk is quickly Very Expensive Cheaper with diverse experts identified and working on their preferred resolved modules of interest and skills. Quick product Poor documentation Availability ofMVS/CVS delivery commit activities, and various open source well achieved bug tracking and code commit standards with developers � involved facilitates ease of documentation. .!J�Ui r1 :�.�.1 mlfll1 1111 B..- Saves time and Identifying which Only one open source approach. development suitable RAD efforts approach to adopt as there are many forms ofRAD Meets an Process is less visible Community-based immediate need of Usually used in Existence of Projects forums and customers combination with developers communications waterfall networks. I:K'li11 I tlll'li1I I Incremental software II' Systems are usually Sophisticated development of poorly structured. development and process system management tools enhance the specifications well structured tendencies of the development. The down side to RAD is the propensity of the end user to fo rce scope creep into the development effort. In most RAD lifecycle fa ilures, the end users and developers were caught in an unending cycle of enhancements, with the users asking for more the developers trying to satisfy them (Zoltai, 2000). This actually negates the philosophy of open source which was earlier discussed in Section 2.3 35 Usually, software development team do not to use a pure RAD approach, they blend limited prototyping with requirements and design development during a conventional waterfall lifecycle. The prototypes developed are specifically fo cused on subset of the application, and do not provide an integrated interface. The prototypes are used to validate requirements and design elements, and the development of additional requirements or the addition of user interface options not readily supported by the development environment is actively discouraged (Zoltai, 2000). Given the fact that there are quite a number of RAD versions, the choice of which RAD to choose or whether or not an RAD approach is required for a given software development effort is a question which Reilly and Carmel (1995) tried to provide answers. Moreover, the emphases on fast delivery of software products have resulted in poor documentation, and systems being delivered with known bugs (Rapley, 1995). (iv) The Evolutionary Development model The concerns on the problems associated with previously discussed models, has led to the fo rmulation of the evolutionary development model McCracken, (1982), whose stages consist of expanding increments of an operational software product, with the directions of evolution being detennined by operational experience. Evolutionary computation (EC) is a search technique which uses computational models of processes of evolution and selection are encoded in evolutionary algorithms (EAs) and used to solve problems in the fields of engineering and science (Rafal et al., 2005). A review of the conventional software process models unveils the weaknesses associated with those models and presents a clear basis for the open source process model. Table 2. 1 presents a comparative study on the earlier discussed process models (waterfall, spiral, RAD, evolutionary development models) and matches them to the open source development methodology. 36 The comparative evaluation software process models on Table 2. 1 clearly show the strength of open source development model over the conventional software process models. It was shown clearly that the shortcomings of the conventional software process models could be overcome by the open source process model fo r example, the suitability of open source models to both long and short term projects provides a leading edge when compared to spiral model. 2.4.2. Open Source Models All open source projects fo llow the open source culture (Raymond, 1999). Interestingly, Free and OSS development is an existing phenomenon without any clear ideal process model (Otso, 2008). The open source development fo llows different approaches; some systems such as Apache allows developers to take part in all aspects of the project development while some other open source development happen less visibly internally within a single company such as Mysql of Sun Microsystems, and finished resulting software released under open source license. (i) Linux Development Process A kernel is the lowest level of software running on an operating system. For the Linux kernel, it is the lowest level of software running on a Linux system. A kernel is responsible for managing the hardware, running user programs, and maintaining the overall security and integrity of the whole system. It is this kernel, which after its initial release by Linus Torvalds in 1991 started the development of Linux as a whole. The kernel is a relatively small part of the software on a full Linux system; paradigm examples of components from the GNU project are GNOME, KDE desktop projects and the X.org project. However, it is the core which determines how well the system performs (Erik and Michael, 2001). The Linux kernel is one of the largest individual components on almost any Linux system. 37 The Linux development process is important in the understanding of access rights, relationships among files, signals and job control. The UNIX's hallmark is its process model and Linux adopted most of UNIX's process model and added new ideas to evolve the lightweight threads implementation. Linux processes however incorporated the UNIX systems as a fundamental building block. Figure 2.4 shows the algorithm perfonned on task_struct in Linux kernel. Under Linux model, the fundamental data structure within the kernel controlling all processes is the process structure, which grows and shrinks dynamically as processes are fo rked and finished or killed; this is called task_struct in the kernel source code. The sample code which is presented in Figure 2.4 shows how to get the actual size of the process structure. On the Intel 386 machines, it is exactly 960 bytes, but unlike the UNIX systems, the process is very light weight process. It does occupy only a little space. The task_struct could always be overwritten (overlapped) on the kernel stack because it is per-task structure, exactly as the kernel stack. The kernel stack has a fixed size of 8192 bytes on the Intel X86 machines. The kennel usually decreases the size of the usable kernel stack to around 7232 bytes by allocating the task structure at the bottom of the stack. This is because, 7KB is enough for the kernel stack operations and the remaining is used for the task struct (Johnson and Troan, 2005). The advantages of this arrangement are that the kernel does not have to access the memory to get its kernel structure therefore; the memory usage is greatly reduced. It also implies that the task_struct will always start on a PAGE_SIZE boundary which implies that the cache line is always aligned on most hardware in the market. Code samples could be obtained from Linux samples in (OpenGroup, 2004). #define KERNEL #include Main() Printf ("sizeof(struct task_struct) - % d/n", Sizekf (struct task_struct)); Figure 2.4 task_struct in Linux Kernel (Johnson and Troan, 2005) 38 (ii) Apache Development Process Unlike most of the other open source projects, Apache has not been organized around a single person or primary contributor (Yunwen and Kishida, 2003). Apache HTTP Server is a well known Web server which is licensed with the Open Source illitiatives as an approved License (Apache2.0, 2004). The first version of Apache was released at December 1995. The project is led by Apache Foundation which owns trademark to the product and the project has IBM as an associate. The Apache project uses CVS as a version management system and Buzgilla as a defect management system (Mockus et al., 2000; Mockus et al., 2002); (Rosen, 2004) and (ApacheFoundation, 2004). According to Netcraft (2008) survey, Apache is used in over 70 percent of web servers and it has over near 40 million users (Koponen, 2004). In the Apache project over 3000 different people has submitted problem reports. Furthermore, nearly different 400 people submitted code to the project. The project has 50 core members that are specially mentioned in (Mockus et al., 2002). The plans of the Apache project are presented in the homepage of the project. The plans will present general guidelines of the project. The actual plans would be as discussed in the mailing lists of the project. The defect management and version management processes are based on use of the Bugzilla and CVS systems (Jackson, 2002). Before a project could be admitted as part of the Apache Software Foundation (ASF) project, it must have gone through highly rigorous stages. It must first incubate Apache-incubate (2008) and then it progresses to the stage of podling, and then graduate either as a top-level project or a sub project under an existing project. The stages are summarized below: a) Apache Incubation Development Process In October 2002 the Board of Directors of the Apache Software Foundation passed a resolution creating the Apache Incubator PMC which is usually referred 39 to as the "Incubator PMC" on accepting new products into the Foundation, providing guidance and support to help each, new product engender their own collaborative community, educating new developers in the philosophy and guidelines for collaborative development as defined by the members of the fo undation, and proposing to the board on the promotion of such products to independent PMC status once their community has reached maturity. Figure 2.5 shows the incubation stages of the apache process. b) Objectives of the Apa che Process To provide a clear path fo r potential projects and sub-projects within the ASF to move from proposal stage through to full membership in such as way as to ensure that new projects and sub-projects are developing products according to the ASF's philosophy and guidelines fo r collaborative development, that the ownership of any code initially submitted by the project is fo rmally and legally transferred to the ASF and that only those products that meet the Apache's requirements are fullyaccepted into the ASF. c) Overview of the Apa che Process The incubation process covers the establishment of a candidate, acceptance (or rejection) of a candidate leading to the potential establishment of a Podling and associated incubation process, which ultimately leads to the establishment or a new Apache Top-Level-Project (TLP) or sub-project within an existing Apache Project as shown in Figure 2.5 below. . '. '. � ..._ / ,':).( - ;;q_:;\ 40 f :. t LiP P. , ; \ . \\ I ··� -' Ql.,.\ �1-' /' acce�------� Pod ling engagement \ Project establishment ) Candidate - "/ / " continuation I I rejection termination Figure 2.5 Apache incubation process adapted from Wahyudin and Tjoa (2007) d) The IncubationSta ge s According to the guidelines, in order to enter the Incubator, a Candidate MUST be nominated fo r incubation by a member of the Apache Software Foundation ("The Champion"); and be approved by a Sponsor. To start the approval process, a proposal MUST be submitted to the Sponsor. The decision to approve the candidate proposal MUST be taken on a vote by the Sponsor, in accordance with that Entity's charter. Further details on apache incubator activities are discussed in Duenas et a/. (2007) and by Wahyudin and Tj oa (2007). (iii) Mozilla Development Process Mozilla web browser project was launched at January 1998, when Netscape released the source code of the Netscape web browser. Now Mozilla has millions of users. Mozilla is licensed with the Mozilla Public License (MPL). The proj ect is led by the Mozilla Foundation. It has multiple associates such as American Online (AOL). The project uses CVS as a version management system and Buzgilla as a defect management system (Koponen, 2004 and den Besten et al., 2008). About 7000 people have submitted problem reports to the Mozilla project and near 500 people have submitted code to the project (Mockus et al., 2002). The core developers are responsible fo r one or more modules as a module owner. There are 60 different core developers in the project (Mozilla, 2004). The Mozilla project's 41 version management and defect management processes are based on usage of the Bugzilla and CVS systems. Table 2.2 : Open Source Maintenance Matrix (Timo and Virpi, 2005) Tasks A B c D E F G H I J K L M Problem initial analysis (A) s c c c Problem reporting (B) c s c c Problem verification (C) c c s c c Problem documentation(D) c c c s c Problem assign (E) s c c Implementation (F) c s c c Submit modification(G) c c s Discussion(H) s c Review (I) c s Acceptance (J) c c s Pre-release testing (K) s c Packaging (L) c s c Announcement (M) c s S - Strong correlation c - correlation The studies carried out by Timo and Virpi (2005) have revealed that maintenance activities and tasks of both Mozilla and Apache projects have two pre delivery tasks: Implement defect management system and procedure; and Implement version management system and procedure as shown on Table 2.2. The post-delivery actions are planned as a fo rm of the roadmap. The procedures fo r the modification requests were implemented as a fo rm of the defect management system. The version management process was integrated to the version management system that was in use. In Table 2.2, the post-delivery tasks and the bonds between the tasks were identified as presented in Timo and Virpi (2005). 42 It is interesting to note that the Linux, high quality pioneer open source operating system software, has been represented with onion structure. Figure 2.6 clearly shows that Linux has been organized around a person, the project owner, Linus Torvalds and then further surrounded by the lieutenants. The Apache development process, though not organized around a single person like Linux, is organized around a central control system, which is the Apache fo undation. The Mozilla project is also led by Mozilla fo undation which makes use of CVS and their bug tracking systems such as Bugzilla. These projects have been reviewed in this research as they stimulate thoughts on why they are actually organized in the onion structures. In line with the research objectives, the onion-like organizations of these projects form the basis fo r investigating the general onion structures of open source projects. Interestingly, quite a number of literatures have described various open source projects with onion structures. These are discussed in detail in subsequent section. It is however bothersome to note that none of the reviewed onion descriptions of open source have been verified nor validated. In this r�s�arch the open onion model has been evaluated statistically and validated using Delphi's approach in Chapter 6 and Chapter 7 respectively. 2.5. Related Open Source Onion Models Open Source approach is omon structured. This research would not be complete without a review on previous onion models of open source. The idea of onion model of open source started in 2002 with Kumiyo et al. (2002). However, Crowton's onion model of open source is very famous when the hypothesized that Open Source Software (OSS) development was represented with an onion-like structure (Crowston and Howison, 2003). The phenomenon of open source being viewed as an onion structure has since then begun. Research literatures on open source such as Crowston and Howison (2006a); De Sousa et al. (2009); Herraiz et al. (2006) as well as Muller-Bim et al. (2009) have made particular references to Crowston (2003). 43 Active users Iniliator Rdcas.e Core developers coordinator Figure 2.6 Open source projects organization (Crowston and Howison, 2003) The idea of describing open source with onion models is prominent in the literature, it is however interesting to note that the reviewed open source onion models are yet to be evaluated and empirically validated across each of the onion layers as at the time of writing this thesis. It is therefore evident that, previous open source onions were only a presentation of the idea and not a detailed development of the model. ...--- ···- ·-- . _,... // ' / I i \ i' (' Core• Membei'B \ Active Developers \\ Porlphoml Developers Bug rixars ,/ 6ll!) Ruvortors .,""'· ,-· .. . . ,...., ...... H... Roaders . . .. Passlvo Users Figure 2.7 General Structure of an OSS Community (Kumiyo et al., 2002) 44 Figure 2.8 Linux Kernel Onion Adapted from (Antikainen et al., 2007) Figure 2.9 Linux Kernel - Google Image Kumiyo, in Figure 2.7, has represented open source development with an 8- layered onion model. In the Kumiyo's onion model, the project leader is located at the centre, the core members are next. These are fo llowed by active developers; 45 peripheral developers, bug fixers, bug reporter, readers and passive users are at the outermost layer of the onion. As shown in Figure 2.8, Antikainen has represented Linux Kernel with a ? layered onion model. According to the author of this thesis, this model has fa cilitated the understanding of the Linux kernel Goggle image of Figure 2.9. The Antikainen's Linux kernel onion, Figure 2.8 is such that Linus Torvalds, being the benevolent dictator and the final arbiter of all changes accepted into the Linux kernel Antikainen et al. (2007) is situated at the centre. Next to him are the lieutenants, to whom patches (small changes into an existing core) are delivered. Next to the lieutenants are Maintainers, coders, Janitors and Testers occupying consecutive layers in that order. The readers are at the outermost layer of the Linux Kernel Onion. User Figure 2.10 Onion Model (Herraiz et al., 2006) In Herraiz et al., (2006), a 4-layered onion model was used to represent the structure of free-Libre-Open source development as shown in Figure 2.10. The Herraiz's onion model was based on Crowston's onion model though the model has utilized only fo ur layers. The core developers are located at the center of the onion. Bug reporters and fixers as placed on the same level of the onion layer, are said to be 46 next to the core as shown on Figure 2.1 0. Mailing list contributors are next and plain users do occupy the outermost part of the model. Meanwhile, it was observed that the users are not covered in the onion virtual model, as it is not enclosed in the onion ring and referred to as 'plain users'. 2.6. Software Quality In Relation to User Satisfaction In determining software user satisfaction, the most striking satisfaction criterion is quality. It is however interesting to note that quality has diverse views. In this section, software quality is discussed and user satisfaction is based on some quality metrics of the software being developed as a product to be used by the "user". Quality views are very diverse ranging from transcendent view, to product view, user view, manufacturing view and value-based view (Koch and Neumann, 2008). 2.6.1.Software Quality Models The Oxford English dictionary defines Quality as a "degree of excellence or a general excellence or attribute in faculty relative nature or character". In terms of attributes, quality refers to measurable characteristics. Software being a non measurable entity is more challenging to characterize than physical objects. But it must be measured if we must identifythe quality associated with such software. Generally, two kinds of quality are encountered in software development: qualitative design and quality of conformance. Quality of design includes requirements, specifications, and design of the system while Quality of conformance fo cuses on implementation. If the implementation fo llows the design and the resulting system meets its requirement and performance goals, conformance quality is high. Other complexities associated with measurement of software quality have been extensively discussed in Basili (2007). Interestingly, programs characteristics 47 are measured relative to properties such as cyclomatic complexity, cohesion, number of function points and lines of codes (Pressman and Scott, 2005;Roger 200 I). It is a known fact that metrics is a fundamental yardstick for quality control. The primary diffi culty in determining such metrics is that software projects are effectively unrepeatable in practice (Boehm and Basili, 2000). However, quality as associated with the economic factors affecting open source development and adoption has been extensively reviewed in Sauer (2007). An intuitive relationship between the user and the different quality attributes has been developed by Glass (1998) as represented in Definition 2. 1 below. This suggests that the overall quality of a software producthas a direct relationship to the user satisfaction. Definition2.1: Quality Means User Satisfaction (Glass, 1998) U.."'er satisfaction = compliant product + good quality + delivety within budget and schedule Demarco ( 1999) explains that the quality of a product is a function of how much it changes the world fo r the better. High quality software according to Wolfgang et al. (2005) is typically defined by quality attributes like customer satisfaction, which is mainly determined by projects being on budget and time which is key priority over other factors. In this section, a review of software quality perspectives was presented and Glass (1998) quality definition in which quality is based on user satisfaction was particularly referenced. 48 2.6.2.Software Quality Assurance (SQA) Perspectives Quality Assurance, or QA, is the set of tools, techniques and procedures, which are employed to ensure that the end product (in this context, a software system) has a high level of quality. QA should be applied across all phases of the software development cycle, not only the final implementation and by QA team. It should also be an integrated part of the process to have a good effect. These fa ctors have continually changed the rules of software development from one project/paradigm to the next. The changing nature means that most traditional measures of software productivity areincreasingly irrelevant. An example is the metric of new source lines of codes (LOC) produced per person/day on a large project. Even stronger progress indicators can be generated by combining productivity per IT platform with the number of IT platforms in use. Effe ctively, an example in the hardware and communication field include Plots showing high exponential growth in number of transistors in use, the Peta flops of computing power available, or in numbers of Internet packets handled per year. A software example similar to these counting rules is the Line of codes in service (LOCS) as represented in Definition2.2 thus: Definition 2.2: Quality from Line of Code perspective LOCS =Executable Lines Of Machine Codes per Computing Platfonn * Number Platforms In Use Metrics such as LOCS, transistors, Peta flops, and packets at least pass a market test fo r value because they are items that people and organisations have paid market prices to obtain. Beyond this, however we would prefer metrics that more closely reflect value added to people and organisations. This is an area where our research on Quality Assurance activities in Open source development processes is meant to address. 49 2.6.3. Statistical Software Quality Assurance (SQA) Software quality fo cuses on the degree of correctness of an implementation of a function conceived to "meet the user's needs". It also is concerned with the "goodness" of such an implementation. Ideally, this measure of "goodness" should be quantifiable, indicating how well the software is designed and coded according to measurable, quantifiable criteria (Gaffuey, 1981 ). This is where "metrics" fit into software quality assurance. Statistical SQA reflects a growing trend throughout industry to become more quantitative about quality in Roger (200 l) and using statistical approach to software quality managements (Pressman and Scott, 2005). 50 The amount of core members is usually small as compared to the overall project developers. In open source projects anyone of the users can submit modifications or submit defect reports. Some of the challenges are therefore to ensure that old data is accessible, assigned to the core members that have unofficial specialty area in the project. The developers perform tests before submitting the modification. A steering group reviews all the modifications before acceptance. The steering group is fo rmed from the core members. A new version of the software is released, when the core member, who is assigned as a release manager, expresses a release request and the other core developers accepts release request. In the release, the software acquired and packaged from the version management system (CVS) are released as installation files (Mockus et al., 2002). ln the Mozilla project anyone can submit modifications or defect reports to the defect management system, Bugzilla. Most of the problems are assigned to the developers. The developers perform the tests before submitting the modification to the project. Tests can be such as compiling and few test cases. The software is compiled daily and the "smoke tests" are done by the test teams. All <.:hanges are inspected before acceptance. The inspections are done by the module owner and the one of the super reviewers. Accepted modifications are taken to the version management system, CVS. The new version of the software is released when a milestone of the roadmap is reached. ln the release, software is packaged from the version management system and released as installation files (Mockus et al. , 2000). The implement version or configuration management system and procedure activity correspond to implement and configuration management process in the ISO/IEC model. In the Open Source projects, the procedures is based on the configuration management system, such as CVS which is also distributed software development paradigm; (Koponen, 2004). The initial analysis, verification and documentation activity users detects problems or modification needs. The users should be required to do initial analysis of the problem before reporting the problem or request. Raymond (I999) states that open source software development have two basic implementation models, the bazaar and the cathedral. In 51 the cathedral model projects, the implementation task is given to a developer who has developed that a part of the software. In the bazaar model projects, the user or the developer that reports the problem can implement the modification. Usually the projects are mixture of both models. Before submitting modifications, the developer should test modification locally. After the local testing, the developer can submit modification to the project. Modification submissions should use the defect management system or the version management system depending of the status of the submitter. Approval for the modification is obtained from the core developers. Suitability and correctness of the modification could be discussed with the other developers. If the modifications to same problem are implemented concurrently, the project manager must choose. It is important to note that as more open source software systems are deployed by individuals and enterprises, it is vital to study their development and maintenance processes separately from traditional software systems since they are different (Xiong et al., 2009). However it was observed that distributed systems have both pros and cons in terms of cost of maintenance activities. As suggested by Schneberger ( 1997), the two major factors impacting on the maintenance of distributed systems are component simplicity and system complexity. 2.7. Review Summary Open source encourages the ability to share and redistribute source codes free of charge without any racial bias. The ability to succeed in open source depends highly on learning from existing successful open source projects. Borrowing from the development and maintenance in previous successful open source projects such as Linux, Apache, and Mozilla, it was realized that different open source projects have varied documentation policies and project management norms. The waterfall model has been to the disadvantage of the end users in that the users would not get hold of the resulting software product until it is completed. Even 52 the revised waterfall model still gives rise to excessive documentation as discussed in Section 2.4. 1. The spiral model requires highly experienced professional across various iterative stages of the development and this has made it very expensive; more so, the higher the number of iterations the more expensive and time consuming the development becomes. Rapid prototyping as clearly stated in Section 2 .. 4. 1 could be closely related to the open source model but the difference is that a prototype is not a completed project but in case of open source development, completed version of open source projects are rapidly released into the free market while other functionality are awaiting the 'incubation' for example in apache and final commit status into the subsequent release version of the project. Interestingly, previous researches have attempted to describe open source as onion model given the perceived structure of open source development as discussed in Section 2.5. In general, going by the literature, it was clearly noticed that the reviewed onion models of open source, have between 4 and � layers, depending on the context of their application. CHAPTER 3 RESEARCH METHODOLOGY This Chapter presents the methodology employed in this research. It details the processes in which the open onion model was evolved, evaluated and validated. It also discusses how relevant data were collected and analysed. This chapter is divided into five main sections. The research method was first presented along with the research framework. The presentation of the research framework gave the description of the whole research starting from literature review, to problem fo rmulation and evaluation, to model development, use of case studies and validation. Next, the research design and procedures were presented in which modeling styles were discussed, units of analysis were presented which led to the development of open source user satisfaction metrics presentation. The research methods, case studies selection criteria and research settings were equally presented. The data collection methods were presented in which the data sources and data elements selection criteria were discussed. The third section presents the research hypothesis. The validation techniques adopted was described in the fo urth section of this chapter and finally, the research assumptions and limitations were presented. The complete research procedure is accomplished in the steps illustrated in research framework of Figure 3.1, the sample selection criteria is presented in Table 3.1 which represent the procedure fo r the data collection and screening exercise on SourceForge. 54 3.1. Research Methods The number of research on free-Libre and open source software developments, generally referred to in this research as open source, has increased in the recent years. Much of the research differs from typical software engineering research due to the differences between the traditional closed source software development projects and open source model as captured on Table 2.1. In open source projects development, the users and the software being developed are inseparable and the research targeting one of them needs to take also the other into account. The research method used is empirical. This was previously used by notable open source researchers such as Dag et al. (2007); Daile et al. (2008); Feitelson et al. (2006) and Paulson et al. (2004). The empirical approach is based on the case studies as earlier used in Dinh-Trong and Bieman (2004); Dinh-Trong and Bieman (2005); Gurbani et al. (2006); Jensen and Scacchi (2007); Mockus et al. (2000); Rigby et al. (2008) and Zhou et a!. (2007) as well as statistical details of existing open source projects as it was earlier used by Hinds (2008) and Vreugdenhil (2009). Validation technique was based on Delphi's approach of experts' opinion. This was earlier adopted in various computer science and open source researches (Delbecq et al., 1975; Iv et a!., 2008; Linda, 1981; Murray, 1971; Murray et al., 1982; Richard, 1979 and Ryynanen et al., 2008). With this rich approach, empirical data was obtained from ten highly ranked open source proj ects which were evaluated as case studies and whose statistical activity details were tracked from SourceForge repository. One advantage of the statistical method is that there is no impact of the researcher on what is being studied. Another advantage is that data are not based on perceptions of the research subjects, but the residuals of actual activity. The research methods discussed in this section is fo cused on open source software development characteristics. The accessibility to huge process related data are practically the edge which open source software development process has over 55 the conventional closed source development paradigm and this provides a unique positive and promising effect on open source academic research activity. In this research, research approaches were adopted. Quantitative research approach was adopted, case studies were utilized and descriptive modeling styles were also utilized across each layer of the proposed open onion model. Evolution of the model was developed from case studies and evaluation of the analysis of the case studies yielded valuable results. Validation of the evolved open onion model was done across each layer of the onion using Delphi's approach. The user satisfaction metrics were also captured from the results of the Delphi open onion validation rounds which were used in the development of user satisfaction equation. 3.1.1.Quant itative Research in Software Engineering Softwareengmeenng, like other engineering disciplines, is a prescriptive science field. Softwareengineering is essentially a science about how software should be made, not how it is made. In contrary, Free and OSS development is an existing phenomenon without any clear ideal model (Otso, 2008). The goal of prescriptive sciences is to define how things should be done. Observations and experiments are targeted at seeing if the prescribed approach works and how it could be improved. In particular the study of software developmentmethods in software engineering is prescriptive, trying to define the best possible ways to develop softwareinstead of observing how engineers appear to do it. This is understandable, considering the fact that softwareengineering was founded in order to solve the "software crisis"by creating better ways to develop software. The opposite of prescriptive science is descriptive science. Examples of descriptive science are physics and sociology. In general all natural sciences and most social sciences are descriptive. Descriptive sciences aim at understanding phenomena with no particular intention to change them, though the results of the research can be used to change things. 56 In this dichotomy, meaningfulresearch on open source would necessarily be descriptive. This could be supported with the fact that most research on open source is usually descriptive by using statistical quantitative methods. Paradigm examples are Jin et al. (2005); Jonathan and Alexander (1999); Warren (2001); Warren et al. (2004); Polancic et al. (2004); Robles et al. (2009) and Zelkowitz et al. (2006) in which descriptive approaches have been adopted. Following this trend of open source research, the open onion model has been developed by using statistical evaluation to analyze the case studies and Delphi's approach to validate the proposed model. - 3.1.2. Open onion Research Approach A proposed open onion model was developed in this res.earch with five layers. Each of the fivelayers of the open onion was descriptively and uniquely modeled diagrammatically. Ten case studies were investigated fromSourceForge open source repository in which data for ten highly ranked open source projects were collected. A statistical evaluation by quantitative analysis was performed using correlation and regression, averages and percentages on the case studies details. Secondly, data fromFlossmole (2004-2009) repository, covering 1 104 project details was collected and the analyses performed were also nonparametric. Validation of the proposed open onion model was performed using Delphi's approach. 3.1.3.Research Framework The research frameworkis developed in six phases as depicted in Figure 3 .1. First the literature review, then problem formulation and case studies. Next phase was model development which is fromcase studies, followed by model evaluation and finallyvalidation phase. 57 Literature Review I I Problem Formulation/ �Case Studies • Identify and analysis the problem • Develop Case studies in relation • Identify the objective to the problem • Develop hypothesis • Using SourceForge and Floss • Comparative evaluation of mole project repositories. previous onion models Open� Onion Model Development/ • Evolution of Open Onion Model • The Open Onion descriptive modeling • Development of relevant parameters required for validation across the open onion layers • Development of Open source user satisfaction metrics. Evaluationl iValidation • Evaluate each layer of the open • Develop Delphi's survey using omon. four rounds of Delphi validation • Statistical evaluation of case ______.. stages. studies. • Validate each layer of the open • Nonparametric analysis of onion model. evaluation parameters. • Validate open source user satisfaction metrics. Figure 3.1 Research Approach Extensive review of literature was performed in two parts. The first part described a detailed review of the historical background of open source in Section 2.2 and philosophy of open source Section 2.3. This is followed by a comparative review of traditional softwareprocess models agains the open source models Section 2.4. 58 The second part reviews the existing open source onion models Section 2.5 as well as a review of softwarequality in relation to softwareuser satisfaction. Section 2.6. The methodology is supportedby statistical SQA Section 2.6.3. The Delphi validation was performed in four-rounds and it has revealed valuable results ad discribed in Section 3.5 below. 3.2. Research Design and Procedure A cross sectional study design is chosen in which data collection was from two sources: SourceForge.net and Flossmole.org. In this section, the modeling techniques, units of analysis and study population are defined. The research methods, case study selection criteria and research settings are also discussed. 3.2.1.Modeling Iterative development models allow developers to respond quickly to changing user requirements. Various types of graphical modeling were adopted for each layer of the open onion model. This is with a view to capturing various activities going on within each layer of open source development with the open onion model. First the open onion model was visually represented in Chapter 5 with a bisected onion. This is done because it captures accurately the author's view of the onion model. All fivelayers of the proposed open onion model are uniquely visually modeled while separating the open onion model into its constituent layers (initiation, developer, maintenance, user and externallayers). This was absolutely necessary in order to visualize what processes, input and outputs are necessary at the each layer within an open source development. 59 3.2.2. Units of Analysis The main unit of analysis is open source project development characterization of project activities. These characterizations are intuitively developed into some parameters representing each layer of the open onion model. The maJor aspects considered under this study comprise of twenty parameters: project name, rank, domain audience, user interface, topics covered, license types, programming Language, number of developers, number of project administrators, operating system support, registered year, number of downloads, natural language support, development status, number of forums, forum messages, mailing list, percentage of bugs open, percentage CVS commit activities and featured requests. The above mentioned parameters were identified as necessary due to the SQA characteristics discussed earlier in Section 2.6. This is in line with the user satisfaction view of SQA criteria as adapted from Glass(19 98) and due to the fact that softwarequality is the quantifiable degree of correctness of an implementation of function conceived to meet user's needs Geffney( 1981). Since each open source project is synonymous to an onion, as discussed in earlier in Section 2.5; this study defines open source softwareproj ect fromthe open onion perspective, as a five layered structure with each layer possessing some characteristics interwoven with other subsequent layers. Ten case studies have been selected for investigation within the open source softwareproj ects on SourceForge and twenty parameters were modeled across the five layers of the proposed open onion model. The case studies are 10 projects hosted on SourceForge and they have been chosen due to their high rank fromthe software map under the software development categorization on SourceForge. In particular, the study population is limited to softwaredevelopment projects under SourceForge software map since this research is focused on open source 60 development model in order to control uniform required project parameters and to be able to measure based on the expectations for softwaredevelopment projects in the open source context. This study population definition results in samples which are homogeneous (from asingle forge) and more group-focused (softwaredevelopm ent group) which would increase the likelihood ofuncovering significant explanations on variations (if any) within the dependent variables. This research has pointed out to the fact that project properties for developers (developer layer) are distinguishable from that of users (user layer). Prior studies on open source software projects have assumed the notion that "user is also a developer", and have used the concept of "user-developer". However, many projects such as open officeare targeted at end-users who do not have to be programmers. While it is recognized that such projects exist, the developer and user activities have been separated into two different layers. 3.2.3. Case Study Selection Criteria Generally, case study methods are used to probe deeply and intensively in order to gain insight and understanding of phenomena that are new, not-understood, or unexamined. Case study methods allow researchers to understand the "how" and "why" of contemporary events, problems and situations in ways that does not require control over those events or problems (Yin, 2009). In fact, a case study has a distinct advantage when a 'how' or 'why' question is being asked about a contemporary set of events over which the investigator has little or no control. In Software Engineering, case studies are also useful in answering a "which is better" question (Kitchenham et al., 1995). The case studies for this research are presented in Chapter 4. Summary of the study selection criteria is presented on Table 3.1. In the collection of existing statistics, project rank and 61 maturity observation windows were utilized and the activity data from project registration date on SourceForge till August 2009 were utilized. Table 3.1 Case Study Selection Criteria Criteria Test Criteria (Reject It) Study Population Not softwaredevelopment project on SourceForge.net softwaremap Data Availability No development activities and lower than 50 in project rank on SourceForge Project Maturity Development status less < 5 (Meaning that projects must have reached stable/release or mature status) Data integrity Evidence found of data corruption in available data. The characterization of open source project based on av i provides representation of actual activities, and not merelya lperceivedable archival proj dataect activities. Thus having the ability to capture a large sample of objectively-created open source project development activities is a rare opportunity in terms of the study samples. 3.2.4. Research Settings The main setting chosen for this research is SourceForge hosting platform for open source software development projects and Flossmole was used for cross verification purposes. On the SourceForge hosting site, individual projects are maintained and recognized based on a unique project name and a unique set of project web pages. Each project has at least one registered administrator who organizes and sets access privileges for the dedicated source code repository and public forum facilities which are made available by SourceForge. For example, the 62 author of this thesis is a project administrator on source forge this was as a result of registering the open onion project on the platform. The project community members can be identifiedbased on their registration with the project or participation in project forums. However it is interesting to note that some individuals, usually referred to as "lurkers", may view the project pages and forum without posting to the forum or registering with the projects. These individuals are considered to exist at the externallayer of the open onion model. SourceForge is the largest Open Source softwaredevelopment web site, with the largest repository of Open Source code and applications available on the Internet. is owned and operated by OSTG (Open Source Technology Group) Inc. SourceForge.netIt provides free services to Open Source developers. The SourceForge.net web site is database driven and the supporting database includes historic and status statistics on over 158,303 (as at December 291\ 2009) projects and over 1.5 million registered users' activities at the project management web site. SourceForge on a daily basis rt:ports over 1,365,642 downloads, 2,586 code commits, 2,620 forum posts and about 369 bugs (SourceForge activity report as at 301h December, 2009) tracked. Other hosting platforms such as Savannah and Freshmeat could have been selected. However, SourceForge was chosen in order to provide a uniform basis for sample selection criteria for the case studies, which has advantages of both in terms of controlling the variations associated with the nature of different hosting platforms as well as for logistic reasons. However, some data was obtained from Flossmole repository for cross validation purposes. This implies that the Flossmole data on various open source project activities was analysed and used to support the result obtained fromthe analysis of the study on SourceForge repository and strengthening the validation process for the open onion approach. 63 3.2.5. Data Collection Since Open Source Software is typically web based, and usually developed by global virtual teams, it provides researchers the opportunity for the acquisition of data directly from online data sources. This method of using data from online open source repositories has been used by several prior studies, including Mockus et al. (2002); Ghosh (2000); K.rishnamurthy(2003); Hinds (2008) and Vreugdenhil (2009). In this research, data was collected on open source softwaredevelopment projects from SourceForge, a large open source project management website supporting open source softwaredevelopment with project management tools, bug tracking software,mail list services, discussion forums, and version control software (SourceForge, 2009). While SourceForge does not support many large high profile projects such as those that maintain their own developer sites (e.g. Apache, Linux, Perl and Sendmail), some large projects have moved to SourceForge, including Samba. Each project in SourceForge has a unique project number, and each developer is assigned a unique ID which they register with SourceForge. SourceForge hosts a large set of data fromwhich the case studies have been selected and various relevant parameters have been defined for each layer of the open onion model based on the analysis of the preliminary analysis of case studies. The details of case studies are discussed in detail in Chapter 4 of this research. SourceForge organization the pnmary source of archival data for this research. An intensive review of theIS SourceForge platform was performed to identify the availability of various data elements and to determine appropriated data extraction methods. Part of this review included the reading of SourceForge procedural documents and announcements to identify any situations or changes that might influence the integrity of the data on the site. Open omon project was also registered on SourceForge (http://sourceforge.net/projects/openonions/) in order to gain access to administrative 64 privileges and to understand in detail, how the SourceForge projects are formally operated. The open onion project development status is currently at Alpha stage (dev stat 2), which shows no files have been released under this project on SourceForge.= that The open onion fileswere deliberately not uploaded and released under the open onion project on SourceForge. This work is PhD thesis-based research; therefore research time was concentrated on achieving the PhD program. If the author had considered uploading the research results as release fileson SourceForge, then the project's development status would have gained a higher ranking in SourceForge, but it was not uploaded since it must firstbe presented under PhD research platform before furtherrelease could be considered on any other platforms. As at thesis compilation, the development status of open onion on SourceForge remains at alpha status. For this research however, data was acquired from SourceForge through two of channels. One channd involves the extraction of statistical data as well as screenkinds shots from existing or archival project websites. Selected web page screen images for the 10 case studies are presented in Chapter 4. The other channel involves acquiring access to and querying research database which have been previously created by third parties based on data dumps from the SourceForge archives. The research database which was used in this study is the University of Notre Dame (UND) database of SourceForge data dumps. 3.2.6. Case Study Selection Size Based on a review on SourceForge data sources, various data elements were selected based on their availability and the extent to which they could be used in creating research variables to operationalize the previously defined open onion layers. These variables were defined so as to logically and directly correspond with associated onion layers. Since the statistical research method is used, the research 65 variables were defined and major concernswere both availability and integrity of the SourceForge data elements. Data was collected for all the five layers of the Open onion model, each unit of which were analysed. In this research, ten case studies were selected for data acquisition and analysis. While other open source researches have focused on large set of data spanning over l 00 open source projects such as Hinds (2008) whose research was basically on information systems for business administration purposes, other pure computer science doctoral research on open source have focused on five open source projects as case studies such as Scharff(2002). This research has a combined approach of both case study and statistical evaluation with Delphi's approach to validate the developed model. 3.3. Research Hypotheses In order to develop answers to the research questions which were presented earlier in Section 1.3 and to have an improved onion model of open source which has an empirical basis for its structure as spelt out in the research objectives in Section 1.4; five hypotheses were proposed. Each of the hypothesis representing the determinant factors affecting each layer of the 5-layered proposed open onion model. The hypotheses were developed afterthe analysis of case studies as stated below: l) At project Initiation Layer, Project Registration date, Proj_unix_ name, Project_ Url, Domain audience, Prog_lang support and License types were tracked. Hypothesis 1 Every op en source development project must first be registered on an op en source development platform. By doing so, it must set some of the project characteristics (p roject rules) such as programming language, license type and its target audience. The hosting site such as SourceForge would then provide the project_unix_name and the URLfor the project would be created and made available. 66 Developer Layer is focused on characteristics such as Programming Language, 2) operating system support, License types and Topics Covered. Hypothesis 2 Open Source developer motivation is highly influenced by the project 's programming language and license typ es. 3) At Maintenance Layer, number of project administrators, number of developers, programming language, operating systems support, percentage bug open and percentage CVS commits were tracked. Hypothesis 3 Percentage bug op en is highly influenced by the programming language, operating systems and the number of project administrators. CVS commits is also influenced by the number of developers and administrators. User Layer tracks activity details on number of downloads forums and domain 4) Audience, User Interface, Topics Covered, Natural Language support and License. Hypothesis 4 Topics covered do have a negative effect on the domain audience and the Op en source project fo rums are affected by the natural language support (p roject translations in more than one language). At externallayer, number of downloads, number of forums, forum messages, natural 5) language support, project age and topics covered are tracked. 67 Hypothesis 5 Open source project age grows with its number of fo rums and fo rum messages. Th e age of open source project is likely to affect its download, while download is the yardstick fo r open source acceptance, adoption and implementations at various external levels. 3.4. Open onion validation Method The validation method embarked upon was Delphi's approach in four rounds. Details on the Delphi's procedure are presented in this section. The reason for selecting Delphi's method was first discussed followed by panel selection, panel qualification and panel size. 3.4.1. Selection of the Delphi Method The Delphi technique was invented by Olaf Helmer and Norman Dalkey of the Rand Corporation in 1953 for the purpose of addressing a specific military problem (Helmer and Heimer-Hirschberg, 1983). The purpose of Delphi's approach is to find concrete responses to a particular issue of concern in termsof problems or questions from a group of experts in the domain of the research. Delphi has been a frequently used methodology in computing and IT related studies. An on-line search of Proquest doctoral dissertations since 2000 revealed that 3438 studies have been conducted on computer science topics using Delphi technique (UMI Proquest Digital Dissertations, 2000). On the computer science and IT related research papers, 749 researches have been conducted using Delphi as obtained fromACM digital search on the ACM portal ACM-Delphi (26 September 201 0) and 392 papers from IEEE explore online digital search (IEEE-Delphi, 26 September, 201 0). Practical examples of such computer science research papers are 68 (Alexander, 2001; Bobrow et al., 1990; Chen, 1989; Gorton, 1995; Ishikawa, 1993; lv et at., 2008; Jianli; Ken et al., 2008; Linda, 1981; Richard, 1979; Roberta & William C. Wood, 1990). particular,Ryynanen et al. (2008) has applied the use of Delphi to open source relatedIn research. The most fundamental idea behind Delphi technique is the old saying; two heads are better than one which means that a group response gets closer to the truth in reality than that of only one individual passing the judgment. The Delphi's method is well suited for the current research problem, which is validation of the open onion model and open source user satisfaction equation being developed by this research. First the questions on the parameters used in the validation of each layer of the open onion model are subjective and call for value judgment, the results especially fromthe quality criteria of open source user satisfaction metrics could not be analysed in a strictly statistical manner. Secondly, since open source developers and researchers from the industry as well as the academic communities who are experts in the fieldare widely scattered geographically, this method would allow for input fromhighly qualified individuals mostly through electronic mail. Finally the participants as highly professional software developer and heavy technology dependent users as well as academic professionals in the fieldof computing and open source researchers would be able to fluentlycommunicate their ideas in writing and be motivated by their own existing commitment to the open source development topic. 3.4.2. Selection of Panel of Experts Participants The success of a Delphi study is largely dependent on the quality of the participants. The approach becomes realizable when experts do feel personally involved with the problems, or when participants do have pertinent information to share, when they are motivated to include the Delphi exercise in the schedule of their competing tasks, and when the respondents and when they are highly interested in resulting outcome of the aggregated judgment of the panel of respondents for which 69 they too would have value and to which they would not otherwise have access (Delbecq et al., 1975). The panelists used in this research were all experienced open source practitioners and /or researchers on open sourcedevelopment. 3.4.3. Panel Qualifications The panel was constituted in a balanced way in two parts fromthe academic community and from the open source developers who are industry practitioners. The constitution of the panel ranged fromhighly ranked academicians fromrespectable universities such as the respondents from Universidad Alfonso in Spain, Carnegie Mellon University in Pittsburgh and Multimedia University in Malaysia. Secondly, the vibrant open source community of developers ranging from MIMOS researchers to prominent open source developers in highly rated industries such as Novell Sdn. Malaysia and Android open source softwareeducator in USA all took part in the validation of the open onion model of open source development. The complete list of Delphi open onion experts is attached in Appendix F. In order to identify potential participants, the author counted on the literature reviews on previous onion models of open source which provide the clue on obtaining the electronic mail contacts of academic professional experts of open source. On the other hand, the International Malaysia open source developer conference (OSDC.my) which took place at Berjaya Time Square Hotel in Kuala Lumpur Malaysia, 29 June- 1 July 2010, provi es the hub to link up with the world of open source experts who are not necessarily �based in Malaysia but have travelled far away from their country of residence purposely to attend the conference. Substantial contacts were obtained fromthe conference; and brief discussions and interviews were conducted with the open source experts in order to identify the relevant respondents for the Delphi open onion validation rounds. In all, fourteen open source experts responded positively and only twelve of them were able to 70 actually participate all through to the final round of the Delphi open onion validation survey. 3.4.4. The Panel Size The panel size of fourteen fitswithin the guidelines recommended for Delphi studies. Helmer and Dalkey used a panel of seven experts in their original Delphi survey experiment in 1953 (Helmer and Heimer-Hirschberg, 1983). A panel that consists of a homogenous group, such as a group of experts from same general discipline area, need only involve ten to fifteenpeople (Delbecq et al., 1975). 3.5.Assumptions and Limitation I. In setting the boundaries of this research, the research would be based the following assumptions and limitations. on 2. This study is conducted on a neutral ground 3. It is assumed that contributors who are geographically dispersed operate under some degree of autonomy 4. Open source development depends on planned, coordination and supervisory activities. 5. Legal issues in open source development are not covered in this research. Other researches on legal issues, such as (Josh-Lerner and Tirole, 2005), (Bornfreund,2005) and (Kumar, 2006) have been carried out by notable researchers. 71 6. This research would exclude the development of interoperability framework for open source projects as well as integrating open source with closed source software. 7. Open source business model not covered in this research. Various researches on the profitability andIS business models have been previously carried out by various researchers in various institutions; at the frontlineis the oxford university business school (Sauer, 2007). CHAPTER 4 CASE STUDIES This chapter presents the case studies that were used in this research. Ten highly ranked open source projects were investigated from SourceForge for the purpose of evaluating the proposed open onion model. Secondly, another repository such as flossmole was also analyzed for cross verification purposes. The flossmole project was chosen in order to strengthen the evaluation process of the SourceForge case studies. The purpose of the case studies is to be able to evolve the open onion model smce open source development is usually described with "onion" structure as discussed Section 2.5. Details have been gathered concerningactivity data for each of the projects with used in the case studies. The open onion model facilitates an understanding of the onion-like structure of the open source development across projects. The externallayer validation for example, facilitate the understanding of to what extent does the open source project have impact on the most external communities which are not necessarily part of an open source developers' forum. Each of the case studies is an active open source project. Each has been explored and analysed using same set of parametric variables. As evident fromthe research approach which presented in Section 3.2, the case studies are highly utilized in the evolution and evaluation of the proposed open onion model. The selection processes of the case studies' project rank/maturity selection criteria was extensively discussed in Section 3.3.3 and the details of the 73 selection procedure was presented in Table 3.1. Introduction to the case studies on Table 4. 1 below gives the necessary highlights. Table 4.1 Case Study Highlights - ,- Rank = 1, 1 Openbravo ERP Enterprise Resource Planning (ERP) DS =5 Asynchronous JavaScript and XML ZK-Simply Aj ax and Rank = 2, 2 technology platform fo r web-based Mobile DS =6 development e.g. Google Maps Business Application Suite to support Rank = 3, 3 Adempiere ERP specialists, implementers and end users DS =5 Source Code Editor that supports over 40 programming languages. It is written in C++ Rank =4, 4 Notepad Plus and uses win32 API and STL (Standard DS =5 Template Library) Cross Platform Interpreter fo r Adventure Games such as LucasArts adventure games, Rank = 5, 5 ScummVM Simon and Sorcerer by AdventureSoft, DS =5 Breadth a Steel Sky by Revolution. Visual Text File diffe rencing and Merging tool for Win32 platforms. Used in visualizing Rank = 6, 6 Win Merge the recent changes versions of a project and DS = 6 merging the changes within versions. Source Code analyzer. Ensuring that Java codes adhere to the set of coding standards Eclipse Checkstyle Plug- Rank =7, 7 by integrating the Java code Editor into the m DS =5 Eclipse IDE (integrated development environment) Minimalist GNU for Windows is a port of MinGW-Minimalist GNU Rank = 8, 8 GNU compiler collection (GCC) to support for Windows DS =6 the native windows application development. Rank = 9, 9 XOOPS Web App. Dynamic web application platform written in Platform PHP. DS =6 A Test automation framework providing end- SW Test Automation Rank = 10, 10 to-end, multi-platform automation solution to Framework DS =5 testers. 74 4.1. The scope of the Case Studies order to verifythe open onion model, ten highly ranked proJects were extensivelyIn evaluated from SourceForge, one thousand one hundred and four (1104) cases were evaluated from Flossmole projects and validation was done in three parts: i) Data for the ten highly ranked open source development projects from SourceForge repository (April-May 2009). This were extensively studied and evaluated as case studies and details fromthe studies form the basis for the development of the proposed open onion model in Chapter 5. ii) Data from Flossmoleproj ects repository (2004-2009). This project repository has comprehensive data on over 2000 open source projects. However, the forges that feed the Flossmole project with data are heterogeneous; meaning that all the project data on Flossmole are not from asingle source. Further discussion on the heterogeneity of the Flossmole project is later discussed in Chapter 6. However, the data was very useful in strengthening the results obtained fromthe SourceForge experiment. 4.2. Presentation of Case Studies The diverse open source softwaredevelopment projects discussed in this chapter were chosen for a number of reasons. Most often,open source development is described based on case studies; for example, Mockus (2002); Gurbani (2006); Timo and Virpi (2005) and Scharff (2002) whichet impliesal. that there is etneed al. for concrete softwareprocess models to support open source development processes which open onion model attempts to propose. Case Studies facilitate the study of ongoing activities without acquiring potentially intrusive intervention or creating artificial situations. Because of the complex landscape of open source projects and the inherent context-sensitive nature 75 of open source activity, each case aims to challenge, complement and enforce the relevance of each layer of the open onion model. For example, each of the chosen open source projects exhibits onion-like characteristics interms of their project activity structures. Table 4.13 is the detailed breakdown of the quantifiable variables for each of the parameters which were captured fromthe case studies project details such as Table 4.2 and Table 4.3. In this Chapter, ten case studies fromSourceForge.net were presented and they are: Openbravo ERP, a Web based Enterprise Resource Planning (ERP) for Small and Medium Enterprises (SME) Section 4.2.1; ZK-Simply Ajax and Mobile implementing Ajax (Asynchronous JavaScript and XML) technologies with direct RIA (Rich InternetApplication) capabilities Section 4.2.2; Adempiere ERP is a Business Suite comprising of ERP/CRM/MFG/SCMJPOS in Section 4.2.3; Notepad Plus, a freesource code editor and Notepad Section 4.2.4; Scumm VM, a cross platform interpreter for point-and-click adventure games engine Section 4.2.5; WinMerge is an Open Source visual text file differencing and merging tool for Win32 platforms Section 4.2.6; Eclipse Checkstyle Plug-in, integrates the source code analyzer, Checkstyle, with Eclipse IDE (Integrated Development Environment) Section 4.2.7; MinGW-Minimalist GNU for Windows, a native Windows port of the GNU Compiler Collection (GCC), with freelydistributable import libraries and header files for building native Windows applications Section 4.2.8; XOOPX Web Application Platform, allows administrators to easily create dynamic websites with features Section 4.2.9 and the SW Test Automation Framework (ST AF), as discussed in Section 4.2.1 0 is multiplatform and Multilanguage frameworkdesigned around reusable services such as process invocation, resource management, logging and monitoring. 4.2.1. Open bravo ERP Openbravo ERP in Openbravo (2009) is a Web based Enterprise Resource Planning (ERP) for Small and Medium Enterprises (SME) which is built on both MVC and MOD frameworks. MVC (Model View Control) is a proven web 76 applications development framework, which helps to decouple the database, user interface elements, and business logic. The separation of these elements into different files results in a more structured code, facilitating development and maintenance. The MDD (Model Driven Development) is a software designapproach that relies on metadata stored in a dictionary to model the behavior of the application. This results in a drastic reduction in manual coding and fewer bugs, allowing business experts with little coding experience to configurethe application to suit the needs of each enterprise. Openbravo is an open source; Web based enterprise management solution for small and medium sized enterprises. The application provides for fullyintegrated management of key business functionssuch as Customer relationship management (CRM), billing, data, procurement, inventory, projects, services, production, financial/accounting and business intelligence. Openbravo's architecture is "revolutionary" because it utilizes "a unique combination of MVC and MDD development frameworks", as well as its own engine for generating application binaries from the MDD dictionary, called WAD (Wizard for Application Development), the engine, built by Openbravo. The files generated by WAD are compliant with the MVC standard. Openbravo ERPuses modem technologies to meet the strict performance and scalability requirements of enterprise grade environments. It supports java and javascript, SQL and PLISQL, XML, and XHTML. Figure 4.1 shows Openbravo's architecture in which its operating environment is comprised of two parts. The first part is the development and customization environment. This part is comprised of application MDD directory (licensed under Apache 2.0), WAD which is also licensed under Apache 2.0 and MVC foundation frameworkwith Mozilla License, and the execution environment in which the Openbravo is actually implemented. 77 DevelopmentI Cu-stomlz•tlon E'Cacutlou C:llVIfOQOlC�flt c.-nYiron-.u::nt S•uHe < Odt lln•r es vc found;llkn frimeworlr. .; , I , -· llue solt111:1rn Oruubc.-vo'.-_. Oprulhao !nvitob1nr-nt st.lel< Figure 4.1 Openbravo's Architecture Opcnbravo has been chosen as one of the::case studies because it fits into the five-layered open onion model of study. Its initiation, developers, maintenance, user and external activities could be tracked. As characterized by all technology development, it is generally not conducive for firms whose primary purpose is not technology development, to sponsor a technology development project. When a firmsponsors an open source project and community, however, in most cases when the project is successful,a spinoff organization will be created or the community will take the project. Open source enterprise software Openbravo (www.openbravo.com) is an example of such organisation. Openbravo was begun from two individuals' experiences in the mid-1990s with the development of softwareto manage a university (Spaulding, 2009). Appendix 0 shows an example of Openbravo's repository list and last commit activities. Table 4.2 shows Openbravo's project details as extracted from SourceForge repository. 78 Table 4.2 Openbravo project details Release Date 2009-12-01 Data Acquisition Date June, 2009 Project Rank(RANK) 1 Topics Covered(TC) Accounting, Point-Of-Sale, ERP, CRM, Project Management Operating System(OS) OS Independent (Written in an interpreted language) License Type (L T) Mozilla Public License 1.1 (MPL 1.1) Arabic, Brazilian Portuguese, Bulgarian, Chinese (Simplified), Natural Language Support(NL) English, French, German, Italian, Malay, Polish, Portuguese, Spanish Domain Audience(DA) End Users/Desktop, Developers, Financial and Insurance Industry, Information Technology, Manufacturing, Management User Interface(UI) Web-based Database Environment Oracle, PostgreSQL (pgsql) Programming Language(PL): Java, JavaScript, PUSQL Registered Date 2006-03-09 Number of Developers (ND) 82 Number of Administrators (NA) 16 Development Status (DS) Production/Stable (5) Number of Forums (NF) 16 Forum Messages(FM) 31244 Mailing List(ML) 2 Bugs open(BO) 561 Total bug(TB) 6379 79 4.2.2.ZK-Simply Ajax and Mobile ZK is Ajax Java frameworkwith direct RIA (Rich InternetApplication) capabilities with over 200 Ajax components and a markup language (SEIRAND, 2008). It is therefore implies that developing Ajax/RIA becomes as simple desktop applications and HTMLIXUL pages. ZK-Ajax also supports JSF/JSP/JavaEE/Spring, Ajax Push, and Ajax script in Java/Ruby/Groovy/Python/JavaScript. Over a decade, web applications have evolved from static HTML pages, to dynamic HTML (DHTML) pages, to pages using applets and Flash, and finally, to those incorporating Ajax (Asynchronous JavaScript and XML) technologies. Two great examples of Ajax are Google Maps and Google Suggest. Ajax breathes new life into web applications by delivering the same level of interactivity and responsiveness as desktop applications. However, unlike applets or Flash, Ajax is based on the standard browser and Java Script, and no proprietary plug-in is required (Chen and Cheng, 2007). Ajax supports next-generation DHTML; hence, it relies heavily on JavaScript to listen to events triggered by user activity and manipulates the visual representation of a page, that is DOM) (The document object model) or in the browser dynamically. Unlike most other Ajax a framework, ZK Ajax framework does not require a user to have any knowledge of JavaScript to develop Ajax-based web applications, since the ZK engine auto-generates the JavaScript code. To develop a web application with ZK, you need to know only a little about HTML. To simplifydevelopment of web application, the ZK team has also defined the ZK User Interface Markup Language (ZUML) to provide an intuitive way to create ZK components by simply declaring an enclosing tag, which is similar in format to an HTML tag. Further literature details on ZK-Ajax could be discovered at (Apress, 2007). 80 � �. Table 4.3 zK-P•oject Details 1( 1I �� L l!JR/1..�� l� Y � } Release Date 2009-1 1-03 ")�)' -=- -=����? Data Acquisition Date June, 2009 ,�'--.��/ Project Rank(RANK) 2 Topics Covered(TC) Software Development, Enterprise, AJAX All 32-bit MS Windows (95/98/NT/2000/XP), All POSIX Operating System(OS) (Linux/BSD!UNIX-like OSs), Other Virtualization GNU General Public License (GPL), GNU Library or Lesser License Type (LT) General Public License (LGPL) Arabic, Bulgarian, Catalan, Chinese (Simplified), Chinese (Traditional), Czech, Dutch, English, French, German, Natural Language Hungarian, Indonesian, Italian, Japanese, Korean, Portuguese, Support(NL) Romanian, Russian, Slovak, Spanish, Swedish, Turkish, Ukrainian Developers, System Administrators, Financial and Insurance Domain Audience(DA) Industry, Healthcare Industry, Information Technology, Telecommunications Industry User Interface(UI) Handheld/Mobile/PDA, Web-based Programming Language (PL) Groovy, Java, JavaScript, Python, Ruby Registered Date 2005-1 1-10 Number of Developers (NO) 14 Number of Administrators 3 (NA) Development Status (OS) Mature (6) Number of Forums (NF) 5 Forum Messages(FM) 29899 Mailing List(ML) 2 Bugs open(BO) 53 Total bug(TB) 1797 81 The development activities of ZK-Ajax framework are suitable for openonions case study. Analysis of its suitability and how each layer of the onion model could be traced to its characteristic features are furtherinvestigated. At the user layer, it was discovered that ZK is a leading open source Ajax Mobile frameworkcurre ntly having over I ,200,000 downloads, user layer variable. ZK empowers a variety of companies and institutions, which make this open source product relevant at the externallayer of the onions model. The companies range fromsmall to large firms, including Barclays, Sun Microsystems, Swiss RE, Alcatel-Lucent, and many others. Further analysis of the suitability of ZK-Simply Ajax frameworkwith respect to the open onion model is detailed in Table 4.3 and a comprehensive overall case studies numerical matrix is concretely presented in summary on Table 4.14. The ZK-Ajax developer community is very active with over 20 translations, 00 articles/blogs, 100,000 lines of codes, 1,200,000 downloads from over I19 0countries.ZK technical support is designed to save development time and enable enterprises to achieve the highest level of user experience, productivity, and performance. Some of its supported customers include Sun Microsystems, Swiss Re, Unisys and MMC. The ZK-Ajax has some other features but only those features relevant to this research have been discussed. Figure 4.2 ZK on Android 82 Figure 4.2 is a screen shot showing ZK ing on android. Android is a mobile operating system running on the Linux kernel.runn It was initially developed by AndroidInc., a firm later purchased by Google, and lately by the Open Handset Alliance (Wikipedia, 2009). It allows developers to write managed code in the Java programming language, controlling the android device via Google-developed Java libraries. The unveiling of the Android distribution on November 5, 2007 was announced with the founding of the Open Handset Alliance a consortium of forty- seven hardware, software, and telecommunications companies devoted to advancing open standards for mobile devices. Google released most of the Android code under the Apache License, a free software andopen source license. fiiO lclt yjirN ,pofrtcs ]001' ljdp Addrt�l l.alN.tP./IbO� ltJ.I.OI�•v� Nl Tra..,cl &pcnsc Cak:ulator BSI•SU�1(B1:84) A B c D F G H 1 Trove! 5115.39 Travel Expense j 2 ;\C comrodatiOn I9S4.12 > Me�Is 809.58 lnctdental ,..,iScellaneou-s 1 • & 850.55 ]I I ' Total L!!ti2i!:J • :I , I 10 II " I] • (To t al Ro....Ou ...., m>nt • 0 . 5 ) · 4 364 . 8 2 Figure 4.3 ZK spreadsheet component Google along with other 33 companies announced the Open Handset Alliance (OHA), which promises open standards for mobile devices, promising to reinvent the cell phone and entire wireless telecommunication industry. Companies such as Verizon and AT&T operate vertically integrated telecommunication ecologies of 83 stores, resellers, content providers, and network services. Android is new software 'stack' for mobile phones based on open source software and a revolutionary programming paradigm, is based on the successfulimplementation OHA (Garfinkel, 2008). It is called as stack because its software extendsfrom the lowest level controlling the phone's hardware to the highest levels of user interaction. ZK provides a rich user experience by leveraging off-the-shelf web accessibility compliant Ajax components with versatile Reach InternetApplication (RIA) features to create a responsive and engaging user experience maximizing users' satisfaction and work efficiency. The screenshot in Figure 4.3 shows the ZK spreadsheet component as a simple to use report sheet, which maximizes user satisfaction. 4.2.3.Adempiere ERP ADempiere is Business Suite ERP/CRM/MFG/SCM/POS. Its focus is on the community which includes subject matter specialists, implementers and end-users. The Adempiere is a community fork of Compiere; Adempiere's business model. Adempiere is a fork of the original development of Compiere (Mahboob and Ikram, 2007; Schmelich and Alt, 2008; Zain, 2009). In 2006 the community was dissatisfiedwith its ability to affect Compiere and thus created a fork called Adempiere, Adempiere (2009) and its business model strategies were also discussed in Spaulding (2009) on how it was possible for Adempiere to maintain its community effectively. Red l.org was the URL maintained by the firstproject manager of the ADempiere project, (Oon, 201 0). It was also the site where the idea of ADempiere was firstproposed to the community. On September 1st 2006 in the forums of Red l.org the idea of a fork was brought to the Compiere community because many people in the community felt that the Compiere project was becoming less open and free. Over the next week the proposal was discussed and the result was the start of the ADempiere project. Red 1.org provides the tutorials and forums' knowledge base for the community concerningADe mpiere. 84 ADempiere's is referred to as an application framework because its application dictionary resolves the need to touch source code or base softwareto a minimum, and allow changes to be made rapidly and conveniently to not only the look and feel of the data model but also the business model. An application frameworkbasically facilitates application development without starting from the scratch. Table 4.4 provides details on the Adempiere projects. Table 4.4 Adempiere Project details on SourceForge.net Release Date 2009-09- 16 Data Acquisition Date June, 2009 Project Rank(RANK) 3 Topics Covered(TC) Accounting, Object Oriented, ERP All 32-bit MS Windows (95/98/NT/2000/XP), All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX Operating System(OS) (Linux/BSDIUNIX-like Operating Systems), Microsoft Windows Server 2003, Solaris License Type (LT) GNU General Public License (GPL) Arabic, Bosnian, Brazilian Portuguese, Catalan, Chinese Natural Language Support(NL) (Simplified), English, German, Indonesian, Italian, Japanese, Romanian, Russian, Spanish, Thai Developers, Customer Service, Financial and Insurance Industry, Domain Audience(DA) Information Technology, Manufacturing, Non-Profit Organizations User Interface(UI) Java Swing, Web-based Registered Date 2006-09-09 Database Environment Oracle, PostgreSQL (pgsql) Programming Language (PL) Java Number of Developers (ND) 86 Number of Administrators (NA) 9 Development Status (DS) Production/ Stable (5) Number of Forums (NF) 37 Forum Messages(FM) 38035 Mailing List(ML) Production/stable (5) Bugs open(BO) 485 Total bug(TB) 2345 85 The Adempiere framework provides the opportunity for new softwareto be created by simply introducing its data model as tables and columns arranged within windows and attached to menu trees. Each User login will be controlled by its allowed role or roles to access or not to access certain menu of windows or processes or reports. Figure 4.4 is a snapshot of Adempiere Application framework. The Adempiere Architecture Figure 4.5 comprised of the Adempiere application framework, together with the vertical ISintegration tools (import loaders, pack packaging, OSGI modules and migration scripts) on the horizontal application level. The vertical applications are the Adempiere softwareson which other new vertical application can be incorporated and reused. In this scenario it is possible for a new application to be designed and modeled accordingly to fitonto the Adempiere framework and this is said to be the most tasking. Standard CRUD fur ctrons .1 nd Top Bar T.uks x hil tJ -:' • • •. � s�cw cd Log n -· i"lcrw APPLICATION DATA MODEl Role Access Pr c·fer·c 1cc Window Ta b Field • Refe rence to T.1 b es b c C II frc-ld C:�llour World Lan�111�c Set R.rn 1 rrl1C Lo�cr vVorkflow Doc M111agcr VCI'� onrnr, Figure 4.4 Adempiere Application Framework (SourceForge) 86 TA MOD OR N u u ._c. a:: Vertical Integration To ols 2Pack Pack�gtng Figure 4.5 Adempiere System Migration Architecture (SourceForge) Data model, Process and Report module, as shown in Figure 4.5, represent the modeling and design phase. Next is the system migration. There are various migration tools that can be used in the final integration of legacy application data or model into ADempiere. Some of those tools are: Import loaders used by this model; ADCK with XML2AD enhanced model 2Pack with XML2ASD enhanced model Migration Scripts. The OSGI Module is a migration tool under construction as at time of compilation of this thesis. 4.2.4.Notepad ++ Notepad++ is a free source code editor as described in lipping et al. (2007); Kane and Band (2009) and Notepad replacement that supports several languages. It runs in the Microsoft Windows environment. Based on its powerful editing component Scintilla Notepad++ is written in C++ and uses pure Win32 API and STL (Standard Template Library). As evident in Table 4.5, Notepad++ supports the highest number of programming languages syntax. 87 Table 4.5 Notepad ++Programming Syntax Highlights Supportedlanguages : c C++ Java C# XML HTML PHP css makefile ASCII art(.nfo) doxygen ini file batch file Javascript ASP VBNBS SQL Objective-C RC resource file Pascal Perl Python Lua TeX TCL Assembler Ruby Lisp Scheme Properties Diff SmaUtalk Postscript VHDL Ada Caml Auto It KiXtart Matlab Verilog Haskell InnoSetup CMake YAML The STL is a generic collection of class templates and algorithms that allow programmers to easily implement standard data structures like queues, lists, and stacks, which ensures a higher execution speed and smaller program size. Its use is governed by GPL License. More review on Notepad++ could be fo und in Michingan (2009), however, some of its prominent characteristic features on are as presented in Table 4.6 of Notepad++ description table. Notepad ++ supports 44 programming languages syntax as shown in Table 4.5. Its project descriptions are presented on Table 4.6 and it also has some other features such as, highlighting user defined syntax, auto completion facility, multi document and multi view. Some of the screen shots are displayed such as in Figure 4.6 Notepad++ Arabic window screenshot and Figure 4.7 which shows how Notepad++ prints source codes in colors. 88 Table 4.6 Notepad ++ description Release Date 2009-12-17 Data Acquisition Date June, 2009 Project Rank(RANK) 4 Topics Covered(TC) Software Development, Text Editors 32-bit MS Windows (95/98), 32-bit MS Windows (NT/2000/XP), Operating System(OS) 64-bit MS Windows, All 32-bit MS Windows (95/98/NT/2000/XP), Win2K, WinME, Microsoft Windows Server 2003, WinXP, WINE License Type (LT) GNU General Public License (GPL) Afrikaans, Albanian, Arabic, Basque (Euskara), Belarusian, Brazilian Portuguese, Bulgarian, Catalan, Chinese (Simplified), Chinese (Traditional), Croatian, Czech, Danish, Dutch, English, Finnish, French, Galician, Georgian, German, Greek, Hebrew, Natural Language Support{NL) Hungarian, Indonesian, Italian, Japanese, Korean, Lithuanian, Malay, Norwegian, Persian, Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, Thai, Turkish, Ukrainian End Users/Desktop, Developers, System Administrators, Education, Domain Audience(DA) Advanced End Users, Quality Engineers User Interface(UI) Win32 (MS Windows) Registered Date 2003-11-24 Programming Language (PL) C++ Number of Developers (ND) 5 Number of Administrators (NA) 1 Development Status (DS) Production/stable (5) Number of Forums (NF) 9 Forum Messages(FM) 46792 Mailing List(ML) I Bugs open(BO) 993 Total bug(TB) 2498 89 �[Q)c;, Notepnd" new I rJ f'k9ns A111 Macro .:.1,� �.,.a W ...u.ll � .,.... �:..;1_.a .:...., >'j>oJ ..iJ. e I rlil 41 !• · .• a� lP �w FJ St> t! A .... 1'1 ... •X X Cl liil � (J rnew 1 !'] �,_J .UU.J-J ..sl-;�) u-'� � jl "J�,.s�U � �J ru-u � Wj-J � � INS\ UTF·S Dos\Windows Ln: 10 Col: 1 Sel: 0. nbch01: 747' No1mal text file Figure 4.6 Notepad ++ Arabic window screenshot • Jnor>l'"'" .. SCRIPT LA:�-;1_1..\ .:a::• J•vaSC' I"ll'l • 3h·:• • , . /in.c - .:Jc r .l�t: ,. <"l_e�� e:ld�o't.e 'tleldVa.lu.e, t1.eld - �t:.Lo.n 1 r -.•.d.· ., ..:''tabl� "1dt t.- · tu.u• · l:>6t" I ��------t"tut - . ,_-{ ..- .. .hlJlo:, •. ' .:t•'liJ' ' 4.t: I • ". lo: :-,...- tOD.,.' hr·, ,·,·I· 1 ..' n ,. :" " · r; ;:t.. l�v '· - 9�·· · r.anl • r • 1 lot. • � .. L Figure 4.7: Notepad++ prints sourcecodes in colors 90 The author is motivated to have chosen Notepad++ as one of the case studies due to the fa ct it exhibits various interesting features. Apart from the fa ct that it is one of the high ranking open source proJects, its programming language support is much more than any of the other remaining projects; its natural language supp011 (translations) is encouraging. This facilitated the extraction of all the required data relating to every layer of the open onion model case study, the Notepad++. Detailed analysis of the Notepad++ case study as it compares with the remaining nine case studies was presented in the summary Table 4. 14. 4.2.5. ScummVM ScummVM is a cross-platform interpreter for several point-and-click adventure engines. This includes all SCUMM-based adventures by LucasArts, Simon the Sorcerer l and 2 by AdventureSoft, Beneath a Steel Sky and Broken Sword l and 2 by Revolution. Scumm VM is a program which facilitates the running of classic graphical point-and-click adventure games, provided their data files are already installed. Scumm VM has been described as software emulators for computer hardware emulating complete systems in software or the runtime fo r the classic Lucasarts for virtual models as well (Schattkowsky, 2008). ScummVM just replaces the executables shipped with the games, allowing you to play them on systems for which they were never designed. Quite a number of research on adventure games, such as Grand et al., (2004); Haigh-Hutchinson (2009); Millington and Funge (2009); Moreno-Ger et al. (2007) have made reference to Scumm software. The Scumm VM project details are presented in Table 4.7. Scumm runs on many different platforms, smce Scumm VM's portable platform backend and its graphics can be improved with the use of graphics filters, including super2xsai, supereagle, advmame2x, advmame3x, hq2x and hq3x. Some bugs which are existed in the original game's executable script are fixed on 91 Scumm VM. It is also possible to re-encode the game's audio files into popular fo rmats, such as MP3, OGG or FLAC so that the game itself takes up less space. Scumm VM is a project in which there is an attempt to rewrite the original executable file of a given game, based on the game's original source code or by using reverse engineering techniques to see the code that's contained in the game's executable and rewrite it in C++ (Moreno-Ger et al., 2007). Table 4.7 ScummVM project details Release Date 2009-1 1-08 Data Acquisition Date June, 2009 Project Rank(RANK) 5 Topics Covered(TC) Interpreters, Games/Entertainment 32-bit MS Windows (NT/2000/XP), All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX (Linux/BSDIUNIX-like Operating Systems), Operating System(OS) AmigaOS, OS X, BeOS, IBM OS/2, Linux, MorphOS, OS Portable (Source code to work with many OS platforms), PalmOS, Sega Dreamcast, Sony Playstation 2, Solaris, SymbianOS, WinCE. License Type (LT) GNU General Public License (GPL) Natural Language Support(NL) English Domain Audience(DA) End Users/Desktop User Interface: Cocoa (MacOS X), Handheld/Mobile/PDA, User Interface(UI) SDL, Win32 (MS Windows), X Window System (XI I) Registered Date 2001-10-05 Programming Language (PL) C++ Number of Developers (ND) 49 Number of Administrators (NA) 5 Development Status (DS) Production/stable (5) Number of Forums (NF) 0 Forum Messages(FM) 0 Mailing List(ML) 3 Bugs open(BO) 228 Total bug(TB) 4745 92 This means that ScummVM's executable can be used to replace the game's original one, but of course the game's data files (graphics, audio and game scripts) are needed to play the game itself. Therefore, ScummVM is NOT an emulator of a specific operating system, as, fo r example, DOS Box is for DOS. Scumm VM is actually a full rewrite of each game's engine, which has many advantages. The scripting language implemented on Scumm VM is represented briefly in Figure 4.8 below. !ltartScene (1) ( load "ctor"' ) put_�ctor (actor_number, X, Y) put_object (object nurnber, _ X, ¥) i:f (action pickup) ( if (object_to_pickup () -- objecc_A) < actor walk (X, ¥) actor-do act ion (action nUMber) put object in inventory (object A) remove_obj�ct:from_,.cene (object_A ) while ("'cene not ended) ( n�nale_actor_accion� C) ) endScene ( ) Figure 4.8 Scripts on ScummVM Most game engines allow the player to save much more games than the original interpreters did. Scumm VM however offers added functionality which did not exist in the original games. For example, it offers full mouse functionality in older Sierra AGI games, which had no mouse support. It's possible to listen to a supported game's MT-32 music score (if present) without an actual MT-32, via a sophisticated system which emulates it. Scumm VM utilizes less system resources than an emulator, as games run directly in Scumm VM and not through an emulated platform, which might have a different CPU and a diffe rent memory management. 93 The approach that is taken when implementing a game under Scumm VM has some disadvantages in that the logic of each game in Scumm VM has been rewritten from scratch, some bugs which were not present with the original game interpreter might exist in Scumm VM (Haigh-Hutchinson, 2009). For this purpose, there is a bug tracker in Scumm VM, where users report such findings to the ScummVM team, which are then usually fixed. Despite the contribution of adventure games to the development of game culture, today they are not as commercially successful as in their prime of the 1980s and early 1990s when several adventure games were published per year. In contrast, this has been reduced to one or two a year, with major players in the sector such as Sierra and LucasArt. The reasons for this decline are difficult to ascertain although advances in computer graphics and 30 modeling, changes in garners' tastes, motivations and attitudes have all contributed to transformations in game culture. In addition, graphic adventure games cannot be run on modem computers because they were built fo r older models such as the C64 and Amiga. To address this emulators such as the open source project Scumm VM have been developed and provide a free engine for some of the LucasArts graphic adventure games to run on modem computers (Millington and Funge, 2009). On the other hand both because text adventure games use simpler fo rmats they can run on most computers and are also suitable for running on hand-held, personal digital assistants (POAs). Consequently although traditional adventure games are rare today, action adventure games, role-playing game, continue their legacy by combining elements of adventure games with other game styles (Sakaguchi and Mazalov, 2004). The Adventure Lantern Sener (2006) has described ScummVM version 0.9.0 as a brilliant tool while emphasizing its support for "The Legend of Kyrandia" and "The Feeble Files" games, it also fixes the games program where appropriate, adding that it's the only proper way to enjoy LucasArts adventures on current PCs. 94 4.2.6. WinMerge WinMerge is an Open Source visual text file differencing and merging tool for Win32 platforms. It is highly useful for determining what has changed between project versions, and then merging changes between versions. The WinMerge project detail was presented in Table 4.8. WinMerge is a windows tool for visual difference display and merging, fo r both files and directories. Some of its capabilities are Unicode support, flexible syntax coloring editor; windows shell integration; side-by side line differences and highlights diffe rences inside lines. Figure 4.9 is the screen shot for WinMerge file compare window; which shows two files being opened for concurrent editing. - � X vo1d r·oUpc!&t�Cut.DnCopyLE:ttTo CCr. cpp �� n t [Ern.- /1 dcb\lQ vet.:tlon lil Dit'liell.cp p f .d• f _I•':[IJG 1/ deb·.111 '·'H31 r. 1n [•u\lie>�. ial1ne CD1rDoc' CD1tV1ev: : Get.DocUttent ! 111l.1ae CDuDoc• CDiJ:Vlet.>: : GetDo·;unmt 1 ., ) < ) DOS Figure 4.9 WinMerge File compare window 95 Table 4.8 WinMerge project details Release Date 2009-06-09 Data Acquisition Date June, 2009 Project Rank(RANK) 6 Topics Covered(TC) Version Control, File Management 32-bit MS Windows (95/98), 32-bit MS Windows (NT/2000/X P), 64-bit MS Windows, All 32-bit MS Operating System(OS) Windows (95/98/NT/2000/XP), Vista, Win2K, Windows 7, Win98 OSR2, WinME, WinNT, WinXP. License Type (LT) GNU General Public License (GPL) Brazilian Portuguese, Bulgarian, Catalan, Chinese (Simplified), Chinese (Traditional), Croatian, Czech, Natural Language Danish, Dutch, English, French, German, Hungarian, Support(NL) Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Russian, Slovak, Spanish, Swedish, Turkish Domain Audience(DA) Developers, System Administrators User Interface(UI) Win32 (MS Windows) Registered Date 2000-10-20 Programming Language (PL) C++ Number of Developers (ND) 14 Number of Administrators 2 (NA) Development Status (OS) Mature (6) Number of Forums (NF) 2 Forum Messages(FM) 44781 Mailing List(ML) 6 Bugs open(BO) 219 Total bug(TB) 1978 96 The advantages with WinMerge are its ability to perform visual differencing and merging of text files (Fulop et a!., 2006), it has flexible editor with syntax highlighting, line numbers and word-wrap which has been described as a very nice tool for performing virtual differencing and it does not work fo r binary files such as Word document (Balmer, 2009). The highlighted differences inside lines and the difference pane show current difference in two vertical panes. Location pane shows map of files compared as seen on the screen shot in Figure 4.9. WinMerge is a win32 visual differencing and merging tool Xie et al. (2005) which compares fo lders in one level or recursive, and shows fo lder of compared results flat or in a tree-style view. Regular Expression based file filters allow excluding and including items. It compares binary files in fo lder well as text files. On shell integration, it supports 64-bit Windows versions, archive file using 7-Zip. It facilitates fast compare using file sizes and dates. It enables the Creation of patch file in Normal-, Context- and Unifiedfo rmats. 4.2.7.Eclipse Checkstyle Plug-in The Eclipse Checkstyle plug-in is a code checking plug in for Eclipse (Bouillon and Krinke, 2004). It integrates the source code analyzer, Checkstyle, into Eclipse IDE (Integrated Development Environment). Checkstyle is an open source development tool written by Oliver Bum and Lars Kuhne. Checkstyle plug-in fo r Eclipse is a configurable development tool that verifies whether certain Java code adheres to a coding standard (Nandigam et al., 2008). When installed, it ensures that the Java code adheres to a set of coding standards. Eclipse Checkstyle project details are presented in Table 4.9. Checkstyle distillation and conformance to coding standards, Carlson (2005) does this by inspecting the Java source code and pointing out items that deviate from a defined set of coding rules. Apart from using the Eclipse Checkstyle plug-in, it is also possible to use Checkstyle fromthe command line. 97 Table 4.9 Eclipse Checkstyle Plug-in activity Release Date 2009-ll-04 Data Acquisition Date June, 2009 Project Rank(RANK) 7 Quality Assurance, Source code analysis, Source code Topics Covered(TC) review Operating System(OS) OS Independent (Written in an interpreted language) License Type (LT) GNU Library or Lesser General Public License (LGPL) Natural Language English, French, German Support(NL) Domain Audience(DA) Developers, Quality Engineers User Interface(UI) Eclipse, Java SWT Registered Date 2003-05-03 Programming Language (PL) Java Number of Developers (ND) 5 Number of Administrators 2 (NA) Development Status (DS) Production/Stable (5) Number of Forums (NF) 3 Forum Messages(FM) 150 Mailing List(ML) 0 Bugs open(BO) 6 Total bug(TB) 306 Checkstyle Eclipse plug-in code is constantly inspected for problems. Within the Eclipse workbench one can be notified of problems via the Eclipse Problems View and source code annotations just the as it is to see the compiler errors or 98 wammgs. The Eclipse Checkstyle plug-in integrates the Checkstyle Java code auditor into the Eclipse IDE. The plug-in provides real-time feedback to the user about violations of rules that check for coding style and possible error prone code constructs. Figure 4. 10 is an eclipse Checkstyle plug-in screenshot. With the eclipse Checkstyle plug-in, code is constantly inspected fo r problems . .ill Re¢xMessages.java .ill AbslractQudfixTeslCase.)ava .ill EmptyStabementTest.)ava ITl O>ed -: � import com . pupp!a:crawl.. �:;ool.s.ch eck.sc.y�e . apl..Check; (l I pub� ic c1a.ss Hethod.L.:..mi.�Check extends Check f!] � � private int �x • 30 ; �ub11o int : : qecDetaulcTokens () ( ; return new i ne [) 7okenTyp es . CLASS_DEF, t � { 0 �-=: · - ! public void .5eeHax ( int l�m.l.t) ( rr..ax - l.un.J.c; " 2 pub li c vo1d v� 3�c.r o k�n ( OeeatLA3r aac.) { 2 ! !1.n:1 che cs..:s:.c:;;• n d� b.e:lc.w t.::e ::.h..S3_L;E!" !�.r=:..,:;..:::::_::=:e 4< Deeal.l.riSI obj 3 lock • ase . t l. ndF.:..�.5eT oken ( To kenType .5 . CBJDL �C;o ; ' - _ _. r ':.• . e ::...i..o"Tl:e::- ... t j_ I:!: -:·-�.:::i:::-�:: :!f -e ,...:s-s...... - � - 1 nt rt.ethodDefs ... obj :Bl.ock. qec.Ch��dCounc. ( Toke nT}'J:e.5. l·fE'r'H�D_.CE:) ; � ' ::e�-==� e:::-:::-c ...... :r :_-..... -: - �ea=!".e·:i ' It (me ehodOe t� > max) ( l.oq ( a!lt. .Q'et.Ll.neNo ( ) , "me�hod.l.l.mic." , max) ; . - , ��, , Figure 4.10 Eclipse Checkstyle plug-in screenshots 4.2.8.MinGW-Minimalist GNU for Windows MinGW is a contraction of "Minimalist GNU for Windows". It is a port of the GNU compiler collection to support the development of the native Microsoft Windows application. There are several C/C++ compilers available for Windows but MinGW has been described to be having easy installation and configuration toolsets which provides the header files and libraries needed for C/C++ development (Lee, 2004). It is a native Windows port of the GNU Compiler Collection (GCC), with freely distributable import libraries and header files fo r building native Windows applications; includes extensions to the MSVC runtime, Microsoft Visual C++, to 99 support C99 functionality (latest version of C programming language); Oracle 9i introduced the option of native PL/SQL object compilation. Table 4.10 MinGW-Minimalist GNU for Windows Release Date 2009-10-02 Data Acquisition Date June, 2009 Project Rank(RANK) 8 Build Tools, Debuggers, Compilers, Interpreters, Topics Covered(TC) Code Generators c64-bit MS Windows, All 32-bit MS Windows Operating System(OS) (95/98/NT/2000/XP), MinGW/MSYS (MS Windows) BSD License, GNU General Public License (GPL), License Type (LT) Public Domain Natural Language English Support(NL) Domain Audience(DA) Developers, Education, Information Technology User Interface(UI) Win32 (MS Windows) Registered Date 2000-02-09 Programming Language (PL) Ada, C, C++, Fortran, Java, Pascal Number of Developers (ND) 52 Number of Administrators 3 (NA) Development Status (DS) Mature (6) Number of Forums (NF) 0 Forum Messages(FM) 0 Mailing List(ML) 5 Bugs open(BO) 358 Total bug(TB) 1382 100 Coot, which is a molecular graphics application for electron density-based building, with emphasis on protein model-building, in its recent additions to the software, makes it possible to run Coot from MinGW shells with some manual adjustments to the environment (Lohkamp et al., 2005) This means that the PLISQL libraries are first converted into C code and then translated into platform independent machine code. This code can be executed directly and thus performs better by generating platform-independent byte code (p code) from the PLISQLsources and interpreting it at runtime. Initially, this concept only worked on Linux platforms and Windows was given second-class treatment (Petersen, 2003). Table 4. 10 shows the details of the variables which were captured on MinGW-Minima list GNU for windows. There are three contrasts applicable at this stage: MinGW, MSys and mingwPORTs. The Min GW, which means "Minimalist GNU for Windows", is a port of the GNU Compiler Collection (GCC), and GNU Binutils (Binary Utilities) for use in the development of native Microsoft Windows applications. Offered in easily installed binary package fo rmat, for native deployment on MS-Windows, or user built from source, for cross-hosted use on UNIX or GNU/Linux, the suite exploits Microsoft's standard system DLLs to provide the C-Runtime and Windows API. It is augmented by additional function libraries for improved ISO C99 compatibility, and further, by community supported add-on tools and libraries, many pre built many more in the fo rm of "mingwPORTs", to be built by the end user. MinGW provides a complete Open Source programming tool set which is suitable fo r the development of native MS-Windows applications, and which do not depend on any 3rd-party C Runtime DLLs. MSYS, a contraction of "Minimal SYStem", is a Bourne Shell command line interpreter system. Offered as an alternative to Microsoft's cmd.exe, this provides a general purpose command line environment, which is particularly suited to use with MinGW, for porting of Open Source applications to the MS-Windows platform; it includes a small selection of UNIX tools, chosen to facilitate that objective, and 10 l using it is a necessary prerequisite for building mingwPORTs. Detailed summary of MinGW is provided in Table 4. 14 alongside the other case studies being evaluated 4.2.9.XOOPS Web Application Platform XOOPS is a program that allows administrators to easily create dynamic websites. It is a tool used fo r developing small to large dynamic community websites, intra company portals, corporate portals, weblogs and much more. It can be installed on an Internet host with a PHP-capable web server (e.g., Apache) and a database (e.g., Mysql). According to Gargiulo et al. (2005), XOOPS has been successfullyintegrated with PLEIADI architectural platform, PHP modules and web portals with its capability to build high level portal management systems and the use of stylesheet technology to implement dynamic web pages. X OOPS is released under the terms of the GNl J General Public License (GPL) and is freeto use and modify. It is free to redistribute as long as you abide by the distribution terms of the GPL. XOOPS is an acronym of eXtensible Object Oriented Portal System and the effect of XOOP - Intergrated learning has been extensively discussed in (Hsieh, 2009). The XOOPS project details were presented in Table 4.11. Though started as a portal system, XOOPS is in fact steadily on the track of Content Management System. It is a PHP based open source CMS (Fukuhara et al., 2006) It serves as a web framework for use by small, medium and large sites. XOOPS is a dynamic web application platform written in PHP fo r the Mysql database. Its object orientation makes it an ideal tool for developing small or large community websites, intra-company and corporate portals and weblogs. It is database-driven, Modularized with Theme-based skinable interface it supports personalization and user Management. It also provides multi-byte language support and versatile group permissions systems. 102 Table 4.11 XOOPS Web Application Platform Release Date 2009-11-30 Data Acquisition Date June, 2009 Project Rank(RANK) 9 Topics Covered(TC) Message Boards, Site Management, CMS Systems Operating System(OS) OS Independent (Written in an interpreted language) License Type (LT) GNU General Public License (GPL) Arabic, Brazilian Portuguese, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English, French, Natural Language German, Hungarian, Italian, Japanese, Korean, Lithuanian, Support(NL) Malay, Norwegian, Persian, Polish, Portuguese, Romanian, Russian, Spanish, Swedish, Thai, Turkish. End Users/Desktop, Developers, System Administrators, Domain Audience(DA) Other Audience, Advanced End Users, Non-Profit Organizations User Interface(UI) Web-based Registered Date 200 1-12-07 Programming Language JavaScript, PHP (PL) Number of Developers (ND) 150 Number of 2 Administrators(NA) Development Status (DS) Mature (6) Number of Forums (NF) 3 Forum Messages(FM) 2235 Mailing List(ML) 10 Bugs open(BO) 58 Total bug(TB) 1045 103 4.2.10. SW Test Automation Framework STAF is an open source framework designed to provide services fo r process invocation, resource management, logging, monitoring etc. [t enables the user to fo cus on building high level automation solutions fo r testing (Rastic et al., 2007) The Software Testing Automation Framework (STAF) supports continuous integration as an automated testing framework to improve software development processes with an advantage of its agility that allows for rapid delivery of high quality software (Eunha et al., 2009). It is a framework designed to improve the level of reuse and automation in test cases and test environments. The goal of STAF is to provide a complete end-to-end automation solution for testers. The Software Testing Automation Framework (ST AF) is an open source, multi-platform, multi-language framework designed around the idea of reusable components, called services (such as process invocation, resource management, logging, and monitoring). According to Rankin (2002), STAF is a two phased approach to automation. The first phase addresses the reuse issues in which STAF was designed around the idea of reusable components called services while the second phase tackle the automation problems The STAF project fe atures are given in Table 4.12. interestingly, some of the main fe atures of STAX are: support for parallel execution, user-defined granularity of execution control, support fo r nested test cases, the ability to control the length of execution time, the ability to import modules at run-time, support for existing Python and Java modules and packages, and the ability to extend both the ST AX language as well as the ST AX monitoring application. Given these capabilities, it is possible to build sophisticated scripts to automate your entire test environment, while ensuring maximum efficiency and control. Other STAF services are also provided to help you to create an end-to-end automation solution. By using these services in your test cases and automated solutions, you can develop more robust, dynamic test cases and test environments. 104 Table 4.12 Software Test Automation Framework Details (STAF) Release Date 2009-12-15 Data Acquisition Date June, 2009 Project Rank(RANK) lO Topics Covered(TC) Testing, Framework 64-bit MS Windows, All 32-bit MS Windows Operating System(OS) (95/98/NT/2000/XP), All POSIX (Linux/BSD!UNIX-Iike Operating Systems), Vista License Type (LT) Eclipse Public License Natural Language English Support(NL) Domain Audience(DA) Developers, Other Audience, Quality Engineers User Interface(UI) Command-line, Non-interactive (Daemon) Registered Date 2001 -08-08 Programming Language (PL) C, C++, Java, Perl, Python, Tel Number of Developers (NO) 6 Number of Administrators 3 (NA) Development Status (DS) Production/Stable (5) Number of Forums (NF) 2 Forum Messages(FM) 9373 Mailing List(ML) 3 Bugs open(BO) 105 Total bug(TB) 1327 The screen shots of the ST AF window showing STAX job execution testcases is presented in Figure 4. 11, the Stafproc daemon output window ts presented in Figure 4. 12 and its daemon on Linux is shown on Figure 4. 13 105 • .... Job .e2 tOO 00 2"5> A T9CIA COO 00 24) C:0 SIM3a T�t"SI D (00 00 1'5) • Job • J coo 00 l�) A Te�IA tOO 00 241 • �bJ'f4CioU2 ,. .•, O Figure 4.11 STAX Monitor showing a ST AX Job Executing Testcases Figure 4.12 STAFProc Daemon Output on Windows 106 Figure 4.13 Starting ST AFProc (a daemon) on Linux Table 4.13 Onion Layers Parameters .. n...... ,...... Jt(\ll;nll Iit\111 lll\l{lf'"ll.'t ... -IJ.W!W A Initiation Layer • Proj_name, Project_Url, Date registered, • Domain audience, Prog_lang support, License types B Developer Layer • Prog_Lang, Op_Sys, License types, Topics Covered c Maintenance • No of proj_admin, Prog_Lang, Os support Layer • Percentage of bug open, Percentage of CVS commits D User Layer • Domain Audience, User Interface, Topics Covered • Natural Language support, License E ExternalLayer • No_downloads, Topics covered, License type • Natural Language Support, No_of_forums, Forum_messages • Downloads, Project age, Where, Pro}_ name = project name is the name with which the project was registered. Prog_lang support = the programming language which the project support Os support = operating system support Project_age = Age of the project calculated from the date registered (inclusive) Na tural Language support = Natural language translations for the project (e.g. Arabic) % CVS commit = committed codes/ total codes submitted * 100% %bug open = bug open/total bug * 1 00% %CD= Core administrators/ developers *JOO% Other details of the Ta ble are described in the legend (Table 4.13). 107 Table 4.14 Case Study Summary BC Case Studies RANK DA Ul TC LT PL ND NA %CD OS YR DD NL DS NF FM ML %80 %CC %FR RDA BO TB Openbravo I 6 I 6 2 3 82 16 20% 0 2006 976,985 10 5 16 31244 2 8.79% 7.96% 0.00% 244,246 561 6379 5818 ERP ZK-Simply Aj ax and 2 4 I 3 I 5 14 3 21% 2 2005 881,788 22 6 5 29899 2 2.95% 13.64% 21.39% 176,358 53 1797 1744 Mobile Adempiere 3 6 2 3 I I 86 9 10% 5 2006 399,259 14 5 37 38035 5 20.68% 3.22% 44.47% 99,8 15 485 2345 1860 ERP Notepad Plus 4 2 3 2 I I 5 I 20% 2 2003 15,592,736 36 5 9 46792 I 39.75% 1.95% 29.77% 2,227,534 993 2498 1505 ScummVM 5 I 6 2 I I 49 5 10% 14 2001 6,725,805 I 5 0 0 3 4.81% 1.88% 22.72% I ,681 .451 228 4745 4517 WinMerge 6 2 3 2 I I 14 2 14% 2 2000 5,027,5 12 24 6 2 44781 6 11.07% 5.54% 36.92% 502,751 219 1978 1759 Eclipse Check 7 2 5 2 3 I 5 2 40% 0 2003 3,722,591 3 5 3 150 0 1.96% 1.71% 15.87% 531,799 6 306 300 style Plug-in MinGW-Min. GNU for 8 3 3 5 4 6 52 3 6% 2 2000 20,744,162 I 6 0 0 5 25.90% 0. 11% 73.61% 2,074,4 16 358 1382 1024 Windows XOOPS Web 9 3 I 3 I I 150 2 1% 0 2001 7,252,595 25 6 3 2235 10 5.55% 18.05% 67.07% 805,844 58 1045 987 App. Platfonn SW Test Auto. 10 3 4 2 5 6 6 3 50% 3 2001 338,375 I 5 2 9373 3 7.91% 5.44% 33.12% 37,597 105 1327 1222 Framework Average 19% ---- -....___ -- RANK- Project rank DA-No of Domain audience UI-No of User Interface TC-No of Topi cs Covered DS=Developm ent Status ND=No of Develope rs NA= No of Administrators %CD=% Core adminl develope rs OS=Ooerating system suppon NF=No of Forums LT= License Types PL= Programming language NL=Natural language Support ML=No of Mailing List %80=% of bug ope n to total bug YR-Year regi stered DO= Download volume FM-No of fo rum messages %CC- % of CYS commit to the total submissions FR= No of feature requ ests TB-Total bug po sted RDA-Relative downloads oer ae.e (agecalculated fromye ar regi stered to Dec 2009) I BO=Bugs open I BC=Bugs closed ' \, ..... v ' .,...- ... . p ·, t' c-J, ,·�· :-. . ..., I . ,, �·.P""' . ."J I � I )"' , .. _: I . ' ; o/ : ., I (:J'l] __ �r • ("i> .. ... - ,:..;· ...... _ ��...... / --<. f� 108 4.3. ANALYSIS OF CASE STUDIES This section discusses the details of the findings on the case studies from SourceForge by analyzing each unit of the relevant parameters such as the project rank, domain audience, license types, user interface, topics covered, programming language and concurrent version control (CVS). 4.3.1. Detailed Findings Before proceeding on the unit parametric analysis, detailed findings are first presented. In the open onion approach, open source project developments have been broken down into five onion layers. These layers have been identified as the critical phases affecting the long-term sustainability of open source development proj ects. Ten highly ranked open source projects were investigated and used as case studies as presented in Section 4.2. Data was collected from SourceForge.net repository and analysed using nonparametric methods in line with the research method as earlier discussed in Section 3 .1. Identified critical parameters under study as shown in Table 4. 13, are: project rank, domain audience, topics covered, license types, programming languages, natural language support, size of developers, size of project administrators (the core), operating system support, project age (calculated from project registration date), download size, user interface, fo rum size, fo rum messages, mailing lists and development status (which indicates the maturity level of the open source project). Availability of data relating to core administrators and other proj ect developers provides an opportunity to calculate the percentage of core administrators with respect to the overall project developers which yields a fa ntastic result of application of Pareto principles in open source development approach. It was discovered that the percentage of core developers versus project developers fo r the 109 upper 5 proj ects were calculated was 16% while it was 22% for the lower 5 projects, which gives an average of 19% core developers to 81% of overall developers, providing an mteresting result ofthe Pareto pnnciple of80/20 rule. The CVS commit activities and featured requests were also tracked on the case studies. The details on CVS commit versus the actual code submissions provide an opportunity to analyze the percentage of CVS commit activities. It was observed that on the average, only 5.95% of codes submitted are actually committed into the core. This could probably explain why there seems to be robust and high-quality open source projects being developed. Developers want their submissions to be accepted and committed to the core therefore; they tend to write robust codes. Relative downloads per project age was calculated and details on bug open and bug closed provides the basis fo r calculating the percentage of bug open and percentage bug closed. The afore-mentioned parameters are eventually used in the statistical nonparametric analysis for the case studies. 4.3.2. Unit Parametric Quantitative Analysis (i) Project Rank The project rank is comprised of ordinal data set. The rank order is as obtained from SourceForge.net and it is calculated based on project traffic, development and communication variables as shown in Definition 4.1. Definition 4.1: Total Rank Score (SourceForge) Total Rank Score = (traffic + Development+ Communication)* 20,000,000, where 20,000,000 is a constant value. ll0 A project with the highest score value among all projects on SourceForge becomes the most highly ranked project on the repository, and it goes on in that order. Appendix B (No 3) shows a rank table snapshot. Traffic [ ( log(last_7_ days_downloads + I) I log(highest_7 _day_downloacls + I) ) + ( log(last_7_clay _logo_hits + I) I log(highest_7_ day_logo_hits + I)) + ( log(last_7_clay_site_hits + l)/log(hi ghest_7_day_site_hits +I)) ] I 3 ( log( [ 2,254 + I) / log(2, 191,506 + I)) + (log(22,966 + I) / log(3,813,755 + I)) + (log(259,460 + I) I log( I ,350,986 + I)) ] I 3 0.69 1 52880 I Development [ ( log (last_7_ days_scm_commits + I) I log(highest_7_clay_c ommits + I)) + ( I 00-days_since_last_file_release I I 00) + (I 00-days_since_last_admin_login I I 00) ] I 3 [ ( log (56 + I) I log( + I) )I 0.62 1] I 3 0.680487949 36,803,853 Communication = [(log (last_7_days_tracker_entries + I) I log (highest_7_day_entries + I)) + (log (last_7_clays_ML_posts +I) I log (highest_7_clay_ml_posts + I) ) + ( log(last_7_days_forum_posts + I) I log(highest_7_day _forum_posts + I)) ] I 3 [ (log(33 +1)1log(481 + 1)) + ( log(O + I)I log( I + I) ) + ( log(232 +I) I log(690 + I) ) ] I 3 0.46817588056105 Total Score = (Traffic + Development + Communication) * 20,000,000 36,803,853 Figure 4.14 Project Rank Calculation (SourceForge) 111 In the rank table snapshot on Appendix B, the project column represents the project name, rank is its rank as calculated Figure 4. 14, score is the summation of traffic, development and communication all multiplied by 20,000,000; and the constant, 20, 000, 000 is a used for all rank calculation in order to get whole values instead of decimal numbers. Domain Audience The domain audience describes various types of targeted audience for each of the open source proj ects under investigation. For example, the target audience could be the manufacturing and Information Technology (IT) domain. Table 4.15 Domain Audience Analysis across the case studies Domain Domain Name Frequency Developer 9 IT 4 End User/Desktop 4 System Administrators 2 Quality Engineers 2 Manufacturing 2 Finance/Insurance 2 Customer Service 2 Education 1 Non-Government Organization (NGO) 1 Others not Specified 2 Total 31 112 The details on Table 4.15 reveal the expanded view of the domain audience. The case studies have shown that at least 3 popular domain would be required fo r an active open source development project. From this study, it was discovered that Developers, Information Technology and End-user/Desktop Application domains are the relevant domains with developers as audience, being the highest on the list. Table 4.16 shows the domain audience percentage analysis across the case studies. It is therefore evident that the open source audiences are mostly software developers' experts. The second column of Table 4.16 reveals that nine out of the ten case studies have software developers as their main audience. This therefore partly influences the type of domain audience that needs to be targeted for the Delphi open onion validation. Table 4.16 Domain Audience Analysed Domain Audience frequency percentage Developer 9 29% IT 4 13% End user/d eskto p 4 13% Syst em Admin 2 6% Qu ality Engineer 2 6% M a n u fact u r i n g 2 6% Finance/Insurance 2 6% Customer Service 2 6% Education 1 3% NGO 1 3% Others 2 6% 31 100% 113 License Type The License Type indicates the type of license(s) binding on the use and adoption of a particular open source project fo r example the GPL (GNU General Public License) and BSD (Berkeley Software Distribution) licenses. Table 4. 17 explains the characteristics associated with each of the open source licenses. GPL is a free software license written by Richard Stallman in the mid-80s. This license pioneered a concept known as copyleft. Table 4.17 Open Source License Properties Contains special privileges for Can be mixed Modifications Can be re- the with can be taken License licensed original non-free private and not by anyone copyright software. returned to you. holder over your modifications. GPL (GNU General No No No No Public License) LGPL(GNU Lesser Yes No No No General Public License) BSD(Berkeley Software Yes Yes No No Distribution) NPL(Netscape Yes Yes No Yes Public License) MPL (Mozilla Public Yes Yes No No License) Public Domain Yes Yes Yes No Adaptedfr om: www.pe rens. com/A rticles/OSD. html 114 The GNU General Public License (GPL) is a widely used free software license, originally written by Richard Stallman for the GNU project. The GPL is the most popular and well-known example of the type of strong copyleft license that requires derived works to be available under the same copyleft. In ensuing copyleft provisions, this means that when modified versions of free software are distributed, they must be distributed under the same terms as the original software. Thus, all enhancements and additions to copylefted software must also be distributed as free software. This is sometimes referred to as "share and share alike". Table 4.18 shows the frequency analysis of open source licenses fo r the projects used in the case studies of this research. The result shows that the most frequently adopted license for a highly rated open source development projects is GPL License meaning that all other licenses are of relatively lower priority as evident from Table 4.18. Although, all the licenses adopted by the ten projects fa ll within the category of Licenses that are popular and widely used or with strong communities, GPL is most prominent. Table 4.18 Frequency Analysis of Open Source Licenses �icense Types !Frequency !Valid GNU Public License (GPL) 6 Mozilla Public License I Lesser GNU Public License(LGPL) 1 Barkely (BSD) 1 Eclipse Public License 1 !rota! 10 In this research, for ease of analysis of the case studies, the License types were coded using nominal values as presented in Table 4. 19 in which the GPL, the most frequently subscribed license is assigned the coded value of 1 meaning GPL= I 115 and other licenses are assigned other nominal values. That is MPL = 2, BSD = 3, LGPL = 4 and EPL = 5. Table 4.19 License Coding License Type Code GNU Public License (GPL) 1 Mozilla Public License (MPL) 2 Barkley (BSD) 3 Lesser GNU Public License (LGPL) 4 Eclipse Public License (EPL) 5 lt is a recognized fa ct that GPL is the most frequently subscribed open source license as evident from Table 4.18; the author has therefore considered it appropriate to assign the highest priority to GPL in the open source license ranking hierarchy. Hence GPL = 1 while others are literarily assigned the nominal values of 2 to 5 which are in fact having the same priority in the License hierarchy. The condition associated with GPL license requires that developers who use GPL code in their product must make the source code available to anyone, including when they share or sell the object code. [n this case, the source code must also contain any changes the developers might have made. However, if GPL code is used but not shared or sold, the code is not required to be made available and any changes may remain private. This permits developers and organizations to use and modify GPL code fo r private purposes without being required to make their changes available to the public. 116 Supporters of GPL however claim that by mandating that derivative works remain free, it fo sters the growth of free software and requires equal participation by all users. Hence, according to Kumar (2006), scholars and advocates are struggling to articulate the legal ground work that makes the GPL license enforceable. User Interface User interface represents the type of user-machine interaction platforms (user interfaces) being supported by each of the projects within the case studies. For example web based and xwindow systems as shown on Table 4.20, suggests that open source developments are usually web-based. Highest frequency of 4 is associated with 'web based' as the most prominent interfaces. Next in the rank is the win 32 fo llowed by java/java swing. This suggests that JavaScript, web based and win32 are the mostly used interfaces. It therefore implies that the most important user interfaces for a quality open source development project will have to either be web based combined with or without java swing and win32 user interface. Table 4.20 User interface frequency analysis User Interface User Interface Frequency web based 4 Java/ java swing 2 win 32 3 Eclipse 1 xwindow sys (x 11) 1 MacOS X 1 SDL 1 Command line 1 117 A further analysis of user interface was presented in Table 4.21 which shows clearly that the web-based development takes the highest percentage of 29% over all other remaining 7 user-interfaces investigated under this study. Table 4.21 Further analysis of user interface USER INTERFACE FREQUENCY PERCENTAGE WEBBASED 4 29% JAVA/JAVASWING 2 14% WIN32 3 21% ECLIPSE 1 7% XWIN DOWSYS 1 7% MACOSX 1 7% SOL 1 7% COMMANDLINE 1 7% 14 100% Topics covered Topics Covered represent the popular topics needed to be covered by an active and popularly accepted open source project. Three most frequent topics are observed from the analysis; accounting, point of sale and project management. In Table 4.22, it shows clearly that projects which covered two topics have the highest frequency of five out of the ten projects under survey, while next in rank are projects that have covered three topics. The two topics fo r a quality open source development proj ect are definitely any two out of: Software Development, Accounting, and ERP. This is evident from the topics covered expanded details, which is presented in Appendix B (No l ). 118 Table 4.22 Topics Covered frequency analysis Topicscovered Frequency Va lid 2 topics 5 3 topics 3 5 topics 1 6 topics 1 Total 10 Programming Language (Prog_Lang) In this section, the programming Languages utilized across the case studies is investigated. It was observed that some of the projects have adopted more than one programming language in the development of the project. For instance, ZK project has adopted the use of 5 programming languages which are Groovy, Java, JavaScript, Python and Ruby as presented in Table 4.23. Other open source projects have adopted the use of only one programming language in the development of the project. For example, Adempiere uses Java programming language, as evident from Table 4.4 and Notepad++ has engaged the use of C++ programming language as shown on Table 4.6. Analysis of programming languages across the case studies reveals that most frequently used programming languages are Java I JavaScript as shown clearly in Table 4.23 fo llowed by C/C++. While Java/JavaScript takes 33% of the 27 programmmg languages utilized across experiment, 26% goes to C/C++ programming languages. Further breakdown of the programming languages are presented in Appendix B (No 4). ll9 Table 4.23 Programming Language Analysis (SourceForge) Programming Languages Frequency Percentage Valid Groovy 1 4% Ada 1 4% C/C++ 7 26% Fortran 1 4% Java/Java script 9 33% Pascal 1 4% Perl 1 4% PhP 1 4% PL/SQL 1 4% Python 2 7% Ruby 1 4% Tel 1 4% Total 27 Concurrent Versions System (CVS) CVS is a tool used by many software developers to manage changes within their source code tree. CVS provides the means to store not only the current version of a piece of source code, but a record of all changes (and who made those changes) that have occurred to that source code. Use of CVS is particularly common on projects with multiple developers, since CVS ensures changes made by one developer are not accidentally removed when other developers posts their changes to the source tree. The CVS can function as a communication device as well as record keeper except where the communication capability is not explored (Moshe and Karl, 2003). 120 Anonymous CVS Access is also possible. Each project's SourceForge.net CVS repository can be checked out through anonymous (pserver) CVS. The module you the needs to be checked out must be specified as the module name. When prompted for a password fo r anonymous pressing the enter key is sufficient. To determine the names of the modules created by this project, the CVS repository may be examined via the provided web-based CVS repository viewer. 4.4. Summary of Case Studies In this chapter, ten case studies were investigated. First, the case studies highlights were developed and presented in Table 4. 1; project details fo r each of the case studies were extracted from SourceForge within a fair range of timing of one month covering data from the date of project inception till June, 2009. For example, the details of Openbravo project features is captured on Table 4.2 and Table 4.4 presents the project details for Adempire Screenshots were also presented to facilitate deeper understanding into each of the projects considered under the case studies. For instance, Figure 4.1 presents the screenshot of Openbravo architecture. Figure 4.2 shows that ZK Simply Aj ax actually runs on Android mobile. Figure 4.4 shows the Adempiere Application Framework and Figure 4.6 shows that Notepad++ supports Arabic scripts. Openbravo ranked first among the ten projects investigated as at time of data collection, and it is an enterprise resource planning solution. Adempiere is a business application suite. The ZK Simply Aj ax and Mobile supports asynchronous Javascripts and XML which makes it useful for web-based application development on which most businesses are based since most business solutions are delivered efficiently with the availability of web programming. The flexibilityof Notepad ++ to support more than twenty natural languages makes it unique and attractive. Its flexibility for displaying programming codes in colors and in 2-window view as shown in Figure 4.7 is a unique characteristic. Results of the investigated case studies 121 show that most highly ranked open source project supports business solutions and end users. Following the investigations on the ten case studies, some parametric measures were adopted; the parameters fo r each layer of the onion are presented in Table 4. 13. The summary for the extracted data for each layered abstraction is given on Table 4. 14 which shows that Openbravo ERP ranked first. The Openbravo project was registered 2006, meaning that it is aged 4years and as at the time of this research, it has reached stable version of level 5 of development status (DS on Table 4.14). This also shows clearly that Openbravo's download is not as high as Notepad ++ and neither is it closer in downloads to MinGNU fo r windows. However, the rank number 1 project, Openbravo has the highest number of project administrators, 16 and a very high number of developers, 82. Meanwhile, project at the lower rank in this study such as Min GNU is 10 years old, with 1 (one) administrator, 52 developers with over 20.7million downloads and XOOPS , 9 years old, 2 administrators, 150 developers with over 7 .2million downloads. These two proj ects, MinGNU and XOOP, though lower in rank, have attained maturity level, 6 of Development Status. Twenty parameters were evaluated in this study; highlights of these parameters are presented in Section 3.3.2. The parameters which have been used in the final statistical analysis, across the five onion layers, were unilaterally investigated. The parameters such as project rank, domain audience, license types, user interface, topics covered, programming languages and concurrent version system were quantitatively investigated in Section 4.3.2. The unit parametric analysis of the project rank clearly shows that the project rank is a scaled parameter according to the SourceForge rank calculation which was presented earlier in Figure 4.14. Based on the SourceForge case studies, Section 4.3.2 reveals that the most frequently used open source license is GPL as 122 shown clearly on Table 4.17 with GPL emerging with the highest frequency in the Table 4. 18 analysis. With highest acceptance rate attached to the web-based user mterface. Th1s IS shown clearly m the results presented in Table 4.20. lnterestmgly, projects which have covered at most two topics have are more common within the open source projects as evident from the results presented in Table 4.22 reveals that projects which have covered two topics have the highest frequency of occurrence among the ten proj ects under investigation. Table 4.23 shows that the mostly adopted programming languages is Java with the highest frequency of 33% among of all the 12 programming languages investigated. CHAPTER S OPEN ONION MODEL DEVELOPMENT This chapter presents the major contribution of this research; the open onion model is discussed. First the developmental stages of open onion model are described, the motivational issues are discussed and the structure of the model is established. Finally, descriptive models were developed fo r each of the layers of the open onion using diagrams. Actually, diagrams are best in describing the open source development as it shows from Koj i et al. (2009) that use of diagrams is a preferred approach in the description of the development of Ubuntu Linux distribution. 5.1. Open Onion Motivation The long-term research interest on having a cheaper, high-quality software development that would be delivered within a required minimum time frame and budget cost, as discussed earlier under problem background in Section 1.1, has been a major motivation in this research. This is partly due to a fact that high-level of pirated software has dominated the commercial software market places of today, coupled with the fact that certain commercial vendors have perpetually dominated the software market leaving corporate entities and personal software users to their mercies. Customarily, is the quest for reasons behind the success of some prominent open source projects such as Linux, Apache and Mozilla as discussed in Section 124 2.4.2. However, the major challenge with open source development is that it lacks systematic approach to software development. This may be due to its lack of clear ideal process model as dtscussed m Otso (2008), unlike the conventional software development practices of paradigm examples such as waterfall and spiral models as discussed in Section 2.4. 1. The questions then are how it could be possible to make open source development into an organized software development model that could: Be easier to understand the developmental stages, to explain/teach the open source development to others and how to make open source into some fo rm of engineering-like approach to software development such that it becomes easier to identify the project start point and end point as well as predict I fo recast the success/failure chances of any given open source project. The open onion model has addressed all these questions and the methodology of coming up with the solutions to these questions have been presented earlier in Figure 3.1. Starting with a conceptual view of the open onion as depicted in Figure 5.1, the entry point into the open source development is called the project initiation layer, according to this research. This then progresses with a continuous growth and advancement from the initiation layer to the remaining fo ur layers of the onions. The open onion description is presented in Table 5.1 and details of the onion layers are captured in Table 5.2. 5.2. Open Onion Description The open onion representation is presented in Figure 5.1 and the layers' detailed description of the open onion approach is in Table 5.1 which explains the five layers of the open onion. The first layer is the project initiation layer, second layer is maintenance layer, third layer is developer layer, fo rth layer is user layer and the fifth layer is the external layer. Detailed description of each layer is presented in Table 5.2 125 Table 5.1 Open Onion Layers Description Layers Description a Project Initiation Layer b Developers Layer c Th e Ma intenance Layer d Us ers Layers e ExternalLayer Figure 5.1 Open Onion Model 126 Table 5.2 Open Onion Details Layer a Project This is the root of the project. This is the initiation phase. The initiation open source project initiator is the person who started the layer project and eventually, does not necessarily have to be the core maintainer(s). Layer b Developer This is the developer's layer. These are the people that are very layer much interested in the particular open source project and are actually working according to the available policy documentations and guidelines to maintain top-level quality of such projects. However, their contributions are subject to ratification by maintenance layer c Layer c Maintenance This is the maintenance layer. .The maintainers are those people layer who are responsible fo r the acceptance and rejection of submissions. They match the submissions to the overall objective ofthe project and determine the suitability of adding such contribution to the existing overall efforts. Layer d User layer This is fo r the users. These set of people are not necessarily programmers, but they want to have a hands-on experience in order to understand the utilities of the resulting end-product. They are therefore considered very important in the development as their contributions also help in the successful implementation of the project. Layer e External Various organisations that actually get hold of the raw codes of layer open source projects and adapt it to suite their organizational needs whereby evolving new high quality software cheaper and fa ster. Such organisations may not necessarily release the new resulting software 'open'. The new package therefore becomes a guided asset of such organisation. 127 5.3.The Open Onion Framework In Figure 5.2, the conceptual framework of the open omon model was presented and it shows the five layers in the open onion model which are: proj ect initiation, developer, maintenance layer, user and external layers. Each of the model layers has been extensively modeled in Section 5.4. Open Source Project initiation layer I Outline of the Publish the ' Conceptual requirement Project outline on the Internet \ \ \ Developers Layer \ \ M aintenance layer: \ Preparation for code Motivational Contributions acceptance ..... System's Core: Managing ...... the Submissions � V&V: Ensuring conformance to project \ specifications I Source Code Analysis for Integrity I User Layer / / ' / [ External Layer ]; Figure 5.2 Conceptual Framework 128 Figure 5.3 shows that the conceptualization of the project is usually presented in terms of prototypes and published on the internet fo r others to use and improve, although the open source proj ect mitiat10n reqmres some planning phase as presented in Figure 5.4. The project initiation layer was described in detail in Section 5.4.1. The developer layer, comprises of many aspects as well as many integrated tools such as version control, bug tracker, testing tools and proj ect publicity as discussed in Section 5.4.2 and as modeled in Figure 5.5. It basically consists of individuals or group of individuals willing to contribute to the open source proj ect for some motivational reasons either at individual level or at corporate organizational levels as earlier discussed in Section 2.3. At maintenance layer, various activities take place; some of which are the core administrative management of numerous submissions to the project fo r various high quality codes and patches being submitted by developers into the project. The core maintainers would verify, validate (based on some predefined set proj ect rules) and test-run the submissions locally before further decisions on the status of such submissions. Accept�d codes are committed into the proj ect while unsuitable codes are rejected and discarded. Details on maintenance layer activities are discussed in Section 5.4.3. The user layer was .also detailed in Section 5.4.4 and external layer was discussed in Section 5.4.5. 5.3.1. Why Onion and Not Carrot or Garlic? As observed in the earlier chapter on onion models, the onions models have been used in some contexts under the software engineering paradigm. Today it would be observed that 'onion' is usually the descriptive phenomenon for open source development (Crowston and Howison, 2003, 2006a) and (De Sousa et al., 2009). However, none of these researches has modeled distinctively, each of the various layers of the described onions independently. The open onion is a unique model which delved into how the 'onion layers' characteristics could be visually modeled, statistically analyzed to represent the open source development. 129 5.3.2. Open Onion Acronym It is a clear fact that most literature on open source recogntzes ·onion' as an accurate descriptive word for open source development as earlier discussed in Section 2.5. This actually inspired the author to give the name "Open onion Model". The acronym Op en representing open source, Onions representing the various researchers' views including but not limited to the Crowston et al. (2004) on the arrangement of open source development participants. It is a Model because it represents the visualization of the open source development. A nicely bisected big onion was chosen for this experiment. Figure 5.1 is a pictographic capture of the bisectional onion from the author's kitchen sometimes in January 2008 fo llowing the conceptualization ofthe 'open onion' research phenomenon. 5.4. Open Onion Layers Modeling Current trends in software engmeenng have placed more emphasis on design diagrams rather than on the final programming codes (Terry, 1995). [n some cases, diagrams are used as a means of actually developing a system by directly manipulating the diagrams themselves (Jungpil and Jinwoo, 1999). A phenomenon that fo llows is that many software engineering methodologies have proposed various diagrams and detailed prescriptive models of how to manipulate these diagrams for systems analysis and design. It is however noted from Otte et a/.(2008), that the average proportions of the development activities in open source lifecycle are such that, design takes 25%, coding is 48.4% and testing takes the remaining 26.6% in which it shows an almost uniformly distributed picture independent to the project size. This research has descriptively modeled the open source activities with five onion layers. The extracted details from each of the layers are discussed separately in subsequent sections that fo llow. The initiation layer was modeled in Section 5.4. 1 the 130 project planning activities in Figure 5.4 actually triggered a further modeling of the activities taking place at the developer layer. The developer layer activity modeling was presented m Section 5.4.2. The Maintenance layer was modeled diagrammatically as discussed in Section 5.4.3. Flowchart diagram was used to capture the lower level of event activities within each phase of the maintenance layer activity. The maintenance layer data flow diagram was presented in Figure 5.7. Interestingly, as noticed from the developer layer model Figure 5.5, bug and bug tracking activities are vital within the context of open sources development as a metrics for quality assurance purposes. Therefore, within the context of maintenance layer modeling, the author deemed it necessary to model the open source bug lifespan with UML sequence diagram and this was presented in Figure 5.8. A graphical model was adopted at the user layer, Figure 5.9. The user layer was modeled graphically because it only shows pictorially, what happens at the highest levels of abstraction in the user layer as discussed in Section 5.4.4. At the external layer, the author used a theoretical descriptive model where activities within the external layer were presented descriptively as evident fromSection 5.4.5. 5.4.1. Project initiation layer The first layer of the open onion, as presented earlier in Figure 5.1, is the project initiation layer. This is the first layer 'a' of the open onion model, henceforth referred to as 'initiation layer' which is diagrammatically modeled in Figure 5.3. 131 Process Feedback Registration Project Initiation Open source Interested Process Participants hosting site (e.g. Source Forge) Figure 5.3 Initiation layer Modeling The initiation layer, in its simplest fo rm is represented diagrammatically in Figure 5.3 which shows that open source project initiation process actively begins with project registration with an open source hosting platform (e.g. SourceForge). The hosting platform keeps and maintains repositories on project activity details for every registered project on that platform. This platform facilitates collaborative project developments services, usually fo r free, to the project initiators (core project owners). The registered project will then assigned its unix_name, url and a conducive environment of feedbacks on collaboration is created. The hosting platform mostly maintains the CVS, SVN activities fo r such projects and the provision of exclusive rights to project initiators in terms of posting of release files, granting access to the CVS and committing codes to the project repositories. The onion like collaboration is achieved by through the feedback from the mailing lists and fe ature request activities. 132 Select Project Repository. e.g. fresh meat, Sourceforge f The Onion Root \ Open Source Process Initiation Layer Create software architecture Start build the community pc� velop r:.management processes Figure 5.4 Open Source Project Planning Phase Meanwhile, it cannot be concluded that all open source projects are initiated by way of registering at an open source development platform. Linux and Mozilla for example are "high-class" open source projects which are not registered on any of the prominent open source platforms (such as SourceForge); these projects actually maintain their own project development activities and repositories without being subscribed or affiliated to any of the prominent open source development platforms. The project initiation process (leftmost part) in Figure 5.4, actually encapsulates the inherent activities prior to project registration which this research has recognized as the project planning phase. In this thesis the encapsulated activities prior to project initiation is referred to as the "open source project planning phase" as represented in Figure 5.4 During the project planning phase, the initiators would take into considerations such details as defining the project milestones, selecting the right repository/platform to get the project registered and publicized, creating software architecture for the project, developing project management process and start to build around the project concurrently as the project gets registered as shown on Figure 5.4. 133 5.4.2. Developers Layer The developer layer is the second layer, 'b ' of the proposed open onion model as shown in Figure 5.1 and Table 5. 1. This layer was modeled using EDraw 4 UML modeling tool. As depicted in Figure 5.5, the developer layer is comprised of some which are usually performed by open source developers. These activities are represented with labeled blocks such as the use of electronic communication channel, high internet speed, version control tools, bug tracker, testing and package management tools, and project publicity as shown on Figure 5.5 which fo rm the expanded views ofthe open onion framework of Figure 5.2. In Figure 5.5, three mam modules are identified and they are Developer activities (Left blue circular model), User/Developer methodology (orange middle rectangular box) and software engineering tools (Rightmost part of the developer layer model). On the developer activities, there are sub modules representing the people involved (developers), communication channels (usually web-based), software engineering tools (e.g. SVN, CVS, Bug tracker, testing tools, rewrites/revamp/refactoring phase and task list). For the methodology adoption, issues relating to architectural details such as programming language support, development frameworks were identified. Finally, for the software engineering tools, it is required fo r developers to have high speed internet development fa cility in order to facilitate ease of communication channels such as emails, instant messaging, web fo rum postings and wikis. Version control tool must be used by developers, fo r example, SVN, CVS and GIT tools. Bug tracking is mandatory exercise in open source development. Bugzilla is a sophisticated bug tracker, Ma int is a web-based php/mysql bug tracker, Trac is a tool which integrates wikis and bug tracking while interfacing with sub version control system. Gnat is a GNU bug tracking system; SharpForge includes fo rum work item tracking, release management wiki and subversion control management. SourceForge provides in-built bug tracker for its hosted projects to use at default. 134 Apart from the earlier mentioned tools, testing tools are also important at the developer layer. Tinderbox is a tool which runs continuous build process and informs the users of code details, Debugger (GDB) is a GNU debugger. XPCOM is used fo r managing memory leak and overflow in Mozilla; LCLint (Splint) is a validation tool. The use of package management tools, such ".rpm " of Redhat and advanced package tool (APT) with ".deb " used by Linux distribution, cannot be overemphasized. In open source developments, code revamp and refactoring is the norm. In the author's opinion, this is could be largely attributed to the fact that the open source culture encourages the availability of source codes being openly published in a ready-to-use fo rmat, according to OSI definition stated in Section 2.1. It is therefore not surprising to see that most open source projects codes are inherited from previous projects/developers and are further enhanced or extended to get readily implemented within the context of the codebase at hand. Therefore, at developer layer, code revamp and refactoring are expected while the developments of fresh codes are also anticipated to facilitate a rapidly evolving high quality open source software development. The most interesting aspect of open source developer layer is that the mailing list, release logs and the directory lists are maintained. The logs in most cases provide details of "who" has submitted "what" to the project development. This is a fo rm of motivation for the developers. It is usually an achievement to see a developer's name being mentioned as an active contributor to an open source project. It gives fame, publicity and sometime implies a "show off'. It is a usual ego gratification being mentioned by various research literatures on open source (Ghosh, 2002). • This is necessaryfor open source because of distributed de-..elopment internet speed principles; it adopts geographically distributed teams; work is done at places of del.€1opment different time zones; there exists large group of individuals =3 • Em ails - Electronic mailing lists are used to ensure em ails are deliwre d to all interested parties at once. it implies that at least one ofthe parties may reply to it communication in private or to the whole group. channels • Real time communication is also applicable for some projects where IRC instant messaging electronic • Web forum is another method of communication is web forum when open source users ha-..e problems thatis where to get help. • V\likis is anothe forum forcomm unicating between del.€1opers and users. _____J • S\IN & CVS (both are centralized repository) Version Control • Mostopen source project now use distributed -..ersion control system e.g. git Tools used by the linux kernel (which scale better than the svn and c�). Howe-..er.� People � is the most prominent. • Bug Tracker is usually web based. it keeps track of status of various lssue�s;n- / the de-..elopment project. simple textfile is not sufficient! Com onmunicati • Sophisticated bug tracker, web based php/mysql bug tracker. Task List \ Bugzilla : Maint- on Channel • Tr ao-integrating wiki and bug tracking while interfacing with sub -..ersion control Bug Tracker system. Gnat- GNU Bug tracking system,SharpForge- indudes fo rums. work item traking, release management, wiki and l.€rsion controlmanagemenl ( • SourceForge- provides bug tracking system as part of its services therefore any rewrites/ project hosted on sourceforge at difault to using it. refactoring/ Developer Layer Software I • Testing tools: Most open source projects undergo frequent integration. therefore revamps (Activities) Eng\ineerin tools to help automate testing during integration are often used. g Tools • Tinderbox is an example of such tool. it runs continuous build process and I informs users the part of sourcecodes that has issues and on which platforms. Te sting & • Debugger- GNU Debugger (GOB). Package • 1\foemory leak and Ol.€rflow tools e.g XPCOM used by mozilla. Testing \ management • Validation tools are often used in the context of HTM.JXM. or with programming Version Tool ) Tools Languages e.g LCLint (Splint) ontrol ;- • Package �mt tools: A collection of tools to automate the process of Installing, � upgrading, configuring, and removing software packages from computer. Bug Tracker � Examples are RPM (.rpm) red hat package mgmt; APT (.deb fileform art) ad.vao ced..packag. ing..to.oL mos1 4£.us .ed..io..Lioux.dis.trib.utioo____ _ • For some reasons. most open source codes usually undergo refactoring.:J some 1 Refactoring & of the possible reasons could be: Revamps • code was inherited from previous de-..eloper; codes may need enhancements or extension in orderto be implemted withinthe existing codebase. code does not meetde-..elooer's standards I • Maintaining software directory and release logs e.g Freshmeat (directory.fsf.org) Project Publicity • Through articles e.g Linuxweekly news, IBM De-..eloper works, O'Reilly etc. • Maintaing mailing lists ____j1 Figure 5.5 Developer Layer Modeling 136 5.4.3. Maintenance Layer Responsibilities associated with the Maintenance layer, are represented in Figure 5.6. With particular reference to Figure 5.1, maintenance layer is labeled "c" and its description was presented in Table 5.1. The maintenance layer activity in open source development as shown in Figure 5.6 is such that, the core maintenance is performed by a group of maintenance team mostly comprising of the project owners and other key developers who have attained the maintenance status. At this layer, problem discovery is a 'watch word'. The maintainers always want to quickly discover that a problem exists through the developer mailing list (very high priority is given to mails submitted by the core developers) either through the BUGDB (anyone with internet and email could have access) or USENET (newsgroup or discussion group usually with high level of noise therefore only few developers are interested in this news). Code development and code testing is crucial at this point. The identification of optimal solution among numerous submissions can be quite challenging at this layer of the open source development. The identification of a 'volunteer' (developer) willing to work on the problem at hand is also a challenging. This is particularly challenging to the maintenance team in that developers tend to work on problems which they are most familiar since there is usually no rigid assignment method fo r module/ patches development jobs. This is probably fo llowed by identifying a solution which in tum results into another challenging situation of identifying an optimal solution from the various alternative solutions that have been submitted. Then arises the need for developing and testing the code within developer's local copy of source, presenting the code changes to the appropriate layer fo r a review (mostly to the core maintainers) and lastly is to get the codes committed and documented to the repository. When a solution is identified as optimal, it will then be 137 presented to the team fo r review. If such solution successfully passes through this stage of review, then it is committed and then code changes to the repository are documented. In order to achieve remarkable project maintenance which will provide user satisfaction and therefore improve quality of software development, the inherent details are captured and presented in Figure 5.7, the maintenance flowchart diagram. Figure 5.6 Maintenance Layer Activities Phases The maintenance layer activities phases depicted in Figure 5.6 shows the seven important phases in the maintenance process: problem discovery, development of test codes, identification of optimal solution, presentation of code changes fo r a review, discovery of new functions required, committing the codes and documenting the code changes to repository. The maintenance layer flowchart diagram Figure 5. 7 shows the steps involved in the maintenance phase. In Figure 5. 7, submitted modifications, leftmost arrow in, go through the defect management system (e.g. Bugzilla) and configuration management system (e.g. CVS) as earlier described in Figure 5.6. Then it gets analysed, classified and locally tested. The decision on 138 suitability and correctness of such submissions is left to the core developers' decision and accepted codes go through to the version control and gets committed into codebase, while the unsuitable submissiOns are usually reJected. Develop Maintenance Plan Process Implementation Defect Management System (e.g. Bugzilla) ConfiguraMn Management System (e.g. CVS) Problem Analysis & Reporting Initial Problem Analysis and Classification Program Classification/ Documentation C ___ ) ...______. ( Test Modifications Locally ) The Core Developers Suitability and Correctness Not Suitable , .... --..... , Rejected Patches \ / ' ...... ___, Code Accepted Release Management (Version Control) Figure 5.7 Maintenance Layer Flowchart Diagram 139 • Open Source Bug Life Span Actor lmoke nxect invalid in\Oke Duplicated respond � s respond the ------tj------0 I Figure 5.8 Sequence Diagram for Open Source Bug tracking system Associated with the maintenance layer activities is the "critical watch" over the bug lifespan of the open source project. The time lag between posting of new bug (bug open) and resolving the bug (bug closed) usually needs to be minimal. This time lag shows the efficiency level associated with the maintenance activities. Figure 5.8 is a sequence diagram, which the author has developed to represent the open source bug tracking system. In this thesis the open source bug lifespan has been modeled with sequence diagram, as represented in Figure 5.8. This shows that there are fo ur stages which an open source bug passes through as soon as it is submitted. First is to be identified as 140 a new bug, and next is to get the bug assigned to developer(s) which in most cases is done based on individual developers' interest, fo llowed by getting the bug resolved and finally closed. The inter process activities fo r each of these stages, such as sending request, getting response from interested developer, are also captured in the diagram. 5.4.4. User layer Modeling Developers and users of open source are sometimes said to be the same (Erik and Michael, 2001 ). This research has however identified the distinctive fe atures between open source developers and the open source users. The Developers have therefore been recognized as professional skilled programmers, while the users could be either skilled or unskilled. Sourceforge� / freshmeat.net _r+ Internet...... -· Skilled ( Some Users: I and Unskilled �\�, L �� Prominent OpenS ource Repositories � Savannah. nonguu..org Figure 5.9 A model of User Layer 141 To this end, the users could be sending end user requests on feature amendments needed on the software and would naturally require a fe edback. This is why bidirectional arrow was used to denote two way communications across the user layer model of Figure 5.9. In the open onion user layer Figure 5.9, it is easy to track the number of downloads. This "download weight" is a yardstick to measure popularity level of the open source software. Quality of software was earlier attributed to its user acceptance, as seen in Definition 2.1, where quality means user satisfaction. At this level prior to validation, the user satisfaction level is partly measured number of downloads. 5.4.5.External Layer Descriptive Model Many firms see a potential value in the communities of interested customers that have grown around products in various industries. These 'customer communities' or 'communities of interest' give enthusiasts the opportunity to socialize around a common fo cus (Fredberg, 2009). This phenomenon provides a motivating context fo r analyzing how Firms make use of open source communities. The OSS development depends on the efforts of a large number of geographically dispersed individuals participating in different communities. This way of working allows more people to be involved in the process of software creation than the individuals within the boundaries of a firm. In addition, as clearly stated in Section 2.1, OSS is open and made public; its definition includes statements regarding the right to usage and redistribution. This research discusses the external layer of the open onion model from the point of view of downloads weight, natural language support, topics covered, license type, no of fo rums, fo rum messages, project _age and development status as presented on Table 4.13. 142 Previous research such as Lerner and Tirole (2002) however, has pointed to open source benefits such as; reciprocal giving, equilibrium striking, future monetary rewards, ego gratification, programmer reputation, labour market signaling function, gift culture, ideological satisfaction and open source license type as the key fa ctors influencing the individual as well as organisation's decision to contribute voluntarily to open-source development. It is observed that fitms are faced various experience in working with open source communities (Dahlander and Magnusson, 2008). These are copyright problems; and the challenge of keeping communities vital. This results in the firms' demand fo r validating and checking software for robustness and searching fo r possible market applications. Given all these issues, it ts still interesting to note that firms, and Governments establishments, still engage massively with the adoption and implementations of open source software for their internal use. For instance, OSS Malaysia, has adopted open source implementations at both federal and state levels. The adoption of OSS in Malaysia presented in Appendix C where the amazing adoption and implementation of open source is prominent at both federal and state levels. 250 200 150 100 so 0 -+-00 -MySpG -MySfG -+-MyNtW--MyWkS ...... MyM Figure 5.10 : Open Source Adoption and Implementation in Malaysia (Senarai Agensi Sektor Awam - Jabatan Perkhidmatan Awarn -1 8/05/09) 143 Figure 5.10 represents the analysis of open source adoption and implementation in Malaysia whose data was presented in Appendix C. Result shows that the two mostly adopted and implemented open source projects are MyM and Mywks with their peaks on Saba fo llowed by Serawak and the least adopted open source is D whose peak is still on Saba fo llowed by Serawak. In this research validation of external layer revealed that projects which have reached mature status tend to provide the required level of user satisfaction which, in this research is the quality factor being considered. These projects are more reckoned with than others. 5.5. Open Source Success Criteria The success tree on Figure 5. 11 was generated from extensive reviews of open source development success-based literature. DeKoenigsberg (2008) is of the opinion that when open source projects borrow tricks and tips from one another, the best practices evolves over time. In Feitelson et al. (2006) success of open source project was attributed to project popularity. In this research, project popularity is represented by "the ability to build support fo r the project". Although Hinds and Lee (2008) have suggested that social network structure was instrumental towards the success of an OSS project, as measured by activity and output; it was eventually concluded in Hinds (2008) the social network structure has no effect on the success of open source afterreviewing the hypothesis. Other success criteria fo r open source projects have been reviewed such as Fogel (2005); Jiang et al. (2002); Misra et al., (2009); Punter et al. (2009); Rajdeep et al. (2006); Subramaniam et al. (2009); Tsirakidis et al. (2009); Vreugdenhil (2009) and summarized with a fishbone diagram of Figure 5.11. This research has modeled relevant aspects of the success criteria for an open source development project. Open source success tree in Figure 5.11 points at various factors to be considered while an open source proj ect is initially set up and gradually finds its fe et into the high-ranking open source proj ect domains. 144 First, which is the most important, is to learn from others. This further implies that the community of open source around a given project can only be built and sustained by constantly meeting and communicating with other project leaders. It involves the project leader(s) joining and contributing to at least one on-going open source project, and to search for similar project. The second factor is to develop leadership and communication skills. Here it is expected that proj ect developer define project goals and vision, decision making roles, develop project rules and set up leader activities. Another important fa ctor is the need to build support for the project. At this stage, the project leaders 'find' people who share same vision and goals, allows every project participant to assume a 'sales man ro le', quest for sponsor and donations fa ll within this level. Community building is either by word of mouth or postings of the discussions on boards are crucial at this stage. findpeople whoshare /same � Learn from Others Build Support for Project :�:: � uni� meet communicate with � & other Proj. Leaders �-- word:::: of mouth E��eryone ·a 'sates man' posting on discussion board join & contribute to Look for Sponsor or ----.>.... at least one project donations Search for similar - project Decision ma -e l s- \ World Class Open k-i ng- r-o -....._ Failure to build a communi� __ Source Project --,,..; Define Project - Goats and Visison lJlderestimating people focus on code only -- de��etop project rules No pre�ous mgmt experience De��etop leadership& communication skills Leader abili� Avoid Falai Errors unclear goals and objecti��es Figure 5.11 Synthesized Open source success tree •• (**This success rree wa•· validated aloug witlr the ope11 ouiou model parameters. Tire detailed Vllfidtttiou stages overe discussed;, Clraprer 7.) 145 Lastly is to avoid fatal errors. This implies that the core project developers must avoid an unclear goals and objectives of the project. It is always required to have previous management skill before embarking on large-scale open source development involving numerous developers to be managed across the proj ect life cycle. It is actually a fa tal error to underestimate people. Failure to build a community around an open source project would make such project unpopular which has a resulting negative effe ct on the project ranking as shown in Definition 4. 1, total rank score and Figure 4.14. [n order to yield a required level of project success, it is not recommended to fo cus solely on code development without considering basically all aspects of the successful takeoff of such an open source project. The author developed open source success tree, Figure 5.1 1 which shows the various factors affecting the development of an active and quality open source project that would deliver user satisfaction as presented in Definition 5.1 and in-turn yields the desired quality. 5.5.1. Open Source User Satisfaction Software quality is the quantifiable degree of correctness of an implementation of function conceived to meet user's needs (Geffn ey, 1981 ). Literature studies have shown that overall quality of a software product has a direct relationship to the user satisfaction (Glass, 1998; Jiang et al., 2002). Analysis of case studies has revealed that each project development stages have associated activities which are referred to as "parameters" in this research. The twenty parameters earlier mentioned in Section 3.4 and on Table 4. 13 were captured from the project details of the case studies and these are subjected to the Delphi's validation of the user satisfaction characteristics in which high download volume and high bug closed (Table 4. 14) features are identified to be necessary parameters affecting user satisfaction. This is in line with the user 146 satisfaction view of SQA criteria as which was presented in Definition 2.1 as adapted from Glass ( 1998). These have led to the intuitive motivation towards the development of open source user satisfaction metrics. In this research, the author has defined open source user satisfaction, as the metrics for measuring "Open Source Quality" as stated below. Definition 5.1 is a proposed Open source user satisfaction equation which would also be subjected to Delphi's validation along with the proposed open onion layers of this research. Definition 5.1: Proposed Open Source User Satisfaction Metrics Op en So urce Us er Satisfaction = High Download Vo lume + High Percentage of Bug Closed As evident from the user satisfaction criteria, it therefore implies that the two key elements of open source user satisfactions are: download volume and percentage of bug closed. 5.5.2. Comparative Evaluation of Open Onion Model This section discusses the comparative evaluation of the open onion model based on the existing open source onion models. As at time of thesis writing, there are fo ur onion models of open source (Crowston et al., 2004; Kumiyo et al., 2002, Antikainen et al., 2007 and Herraiz et al., 2006). Each of these models has been compared with the proposed open onion model in Table 5.3. The fo ur onion models of open source have in fact motivated the evolution and development of the open onion model of this research. However, it is observed 147 that some of the layers of these prevwus omon models could be leveraged and merged into some levels of similar layers. For example, the Crowston's onion Core developer (most internal) is observed to serve the same role as the Kumiuyo's Project leader/Core members and at the same time this could be likened to Linus To vald I Lieutenant 's roles in Antikainen' s onion. Evoution of the open onion model has leveraged the layers of all these fo ur previous onion models of open source by merging the similar layers into a more genreralised layer labels such as: Initiation layer, comprising of the most internal layer of all the fo ur onion models, Developer layer, comprising of the developers, Co-developer, Active/ Peripheral Developers and Coders/ Jenitars. The Ma intenance layer comprises of Release Coordinator, Active Developers, Maintainers, and Bug fixers, Us er layer comprises of Active Users, Readers, Testers, Mailing list while the most external part, Exernal layer consists of Passive Users, Readers and Plain Users. Table 5.3 shows that all the open source models are usually described with onion as evident from the colums which specified the number of onion layers used. The previous fo ur onion models being evaluated and the proposed open onion mdoel have utilized onion structures in representing the open source development. As evident from Table 5.3, the fo ur onion models as well as the open onion model have used case studies in descussing the evolution of the onion models. An (x) shows that the option was not supported while a (--J ) clearly shows support fo r the option. The open onion model however has an edge in that it is the only onion model of open source that have broven up the onion layers fo r modeling of each unit of the layers. The open onion model has also evaluated statistically (empirically) each of the layers of the open onion grouping some parameters (validated by Delphi's approach) across each layer of the onion model and then performing statistical evaluation of the model. The previous fo ur onion models are yet to be validated as at time of writing up this thesis. The open onion model does the validation of the open onion model using Delphi's approach and this was extensively discussed in Chapter 7. l48 Table 5.3 Comparative Evaluation of Open Source Onions Omon layers Proposed Crowston Kumiyo Antikainen Herraiz "open onion" Model Number of onion 5 layers : � Most Internal f ore Develope• jeot Linus Core Project Leader/Core Torvalds/ Developer Initiation members I Lieutenant Layer Developer Co-developer Active/ Coders/ Developer Developer Peripheral Janitors Layer �Developers Maintainers Release ctive Maintainers Bug ft xers Maintainers Coordinator Developers Layer ----. I User Active Users Readers Testers Mailing list User Layer � Most External Passive Users Passive Users Readers Plain Users External Layer - L____ _ Use if Onion ..j rlayers Descriptions of the layers Use of case studies Break the onion X X X into each layer for modeling Model Evaluated X X X statistically (empirically) Validation X X X X Validation X X X Delphi's Technique lx Approach Adopted CHAPTER 6 STATISTICAL EVALUATION OF OPEN ONION MODEL The selection of variables for each of the layers is based on the case studies as well as literature analysis of various incumbent characteristic activities that are performed within the open source development as characterised by each layer of the onion. Basically, correlation, regression, averages and frequencies are used in the analysis. This significant (2-tailed) of correlation matrices implies that the P value is significant at 0.05 (P:S0.05); meaning that the acceptable confidence level should not be less than 95%. 6.1. Initiation Layer This is the first layer of the open onion model as presented earlier on Table 5.1. The initiation layer identifies important variables needed to achieve high quality open source development project as defined by the author in terms of user satisfaction. It therefore implies that the initiation strategy goes a long way in affecting the quality or success of such a project. The data in relation to the variables affecting the first layer of the open onion model i.e. the project initiation layer is statistically evaluated. The data fo r the project initiation layer is presented in Table 6. 1 and evaluated statistically with SPSS 1 6.0 tool. !50 Table 6.1 Data for Project initiation layer Project Domain User Prog_lang License Case Studies Rank audience Interface support types Openbravo ERP l 6 1 3 2 ZK-Simply Ajax and Mobile 2 4 1 5 l Adempiere ERP 3 6 1 1 1 Notepad Plus 4 2 2 1 1 ScummVM 5 1 5 I 1 WinMerge 6 2 2 1 1 Eclipse Checkstyle Plug-in 7 2 4 1 3 MinGW-Minimalist GNU for 8 2 .,..... � ,. 3 6 -T\' 0-" Windows 4/� ' !;:: - XOOPS Web Application 1 :.J 9 3 1 �·\ Ll� l?df{y Platform .\ *\. - --·--·-./ \,. . A"-.., ,-""• SW Test Automation 10 3 u l t",_,.- .... �- 3 6 5 ...... � Framework For this study, proj ect activity data was obtained from SourceForge, the largest open source repository, as discussed earlier in Chapter 3. The projects fo r case studies were selected from the SourceForge software map, under the software development sub-categorization. The software development category was chosen fo r this experiment because this research is fo cused on open source development projects. SourceForge repository was queried to extract relevant development details on each of the case studies. The Table 6.1 represents project initiation matrix extracted for the projects' case studies on the initiation layer alone. However, detailed extracted data across all onion layer parameters has been presented earlier in 151 Table 4. 14, the case study summary. As discussed earlier in Section 4.3 .2, the project rank signifies an ordinal data as obtained from SourceForge project rank in line with the activities performed on each of the projects and as calculated using the rank table calculation methodology presented in Figure 4.14 Domain audience was earlier presented in Section 4.3.2 as the parameter fo r capturing the types of targeted audiences fo r each of the projects. Programming languages (Prog_Lang) support and user interfa ce are scaled values while the license types are nominal values. The nominal scaling of license types are such that GPL = I which is the highest coded value in Table 4. 19. The author deemed it fit to assign the highest level - 1 coding to GPL as shown in Table 4.19. This is fo llowing an observation that GPL has the highest frequency occurrence across the ten projects under study as evident from on Table 4. 18. ln this chapter, a deeper analysis of the License type on Table 4.18 revealed that 60% of open source projects are licensed under GPL (GPL Project frequency of 6 out of I 0 projects gives 60%) while other licenses such as Mozilla public license, Lesser GNU GPL license, Barkley BSDL and Eclipse Public license have to contend with the remaining 40% of open source projects. An explanation to why this is so, could be better appreciated from the open source license properties represented in Table 4. 17, which shows clearly that software under GNU public license (GPL) is not allowed to be mixed with any other non-free software. It also refuses modifications made on the project to be taken privately without returning back to the open source community. The GPL does not provide any special privileges for the original copyright holder which is called 'copyleft' property. This invariably implies that open source proj ect contributors have confidence in GPL licensed proj ects since it would not be taken private by any other contributor in terms of direct redistribution fo r financial gains. Details on copyleft properties in open source and its implications have been discussed further in (Ashley and Hyunju, 2007; Mustonen, 2003; Osterloh and Rota, 2007; Wiegand, 1993). 152 After the regrouping of Table 6. 1 based on project rank, into high rank (upper 5 projects) and low rank (lower 5 projects), the average domain audience and average programming languages were calculated and presented in Table 6.2. The author considered it necessary to adopt the averaging strategy in order to provide evidence fo r and an insight into the final recommendations on how many domain audiences and programming languages support are ideal, successful and quality open source project. Table 6.2 A VG for Initiation layer Table Project Rank High ( Upper 5) Low (Lower 5) AVG Domain Audience 3.8 2.6 AVG Prog_Lang 2.2 3 Result shows that three domain audiences and two programming languages are required. Domain audience frequency analysis of Table 4.15 and its further analysis on Table 4.16 show that the most targeted audiences are developers The analysis on Table 4.23 and its further descriptions on Appendix B (No 4) show that 33% of open source projects make use of Java/Java script, 26% use C/C++ while only about 7% make use of python programming language. The remaining 34% are evenly distributed among the other programming languages such as Groovy, Ada, FORTRAN, Pascal, Perl, PhP, Pl/SQL, Ruby and Tel. Result also shows that project rank has a slightly negative affect the domain audience. r(8) = -.522. The domain audience and programming language do not show any correlation. Therefore, there is no confidence that there is a correlation between domain audience and programming language. Also, there is no sign of any correlation between programming language and project ranking. 153 Table 6.3 Correlations Matrix for Project Initiation Layer DOMAIN Prog_Lang RANK DOMAIN Pearson Correlation 1.000 Sig. (2-tailed) N 10.000 Prog_Lang Pearson Correlation .202 1.000 Sig. (2-tailed) .576 N 10 10.000 RANK Pearson Correlation -.522 .198 1.000 Sig. (2-tailed) .122 .583 N 10 10 10.000 +. Correlation is significant at the 0.5 level (2-tailed). 6.2. Developer Layer Data captured under developer layer is presented in Table 6.4. In addition to the data at initiation layer, operating systems and number of developers are as well captured for this layer. With respect to the operating system, 0 means projects which are operating system independent. Other numbers signify the actual number of operating system which the application can support. For instance, Openbravo has op_sys = 0 which implies that the application is operating system independent and ZK-Simply Aj ax and Mobile has op _ sys = 2 which implies that it basically suppotts two operating systems. Precisely, it was noticed that ZK supports all 32-bit MS Windows (95/98/NT/2000/XP) and all POSLX (Linux/BSD/UNIX-like) Operating Systems. 154 Table 6.4 Developer Layer data CASE STUDIES Rank Prog Op User License Topics No of _Lang _Sys Interface Covered developers Openbravo ERP 1 3 0 1 2 6 82 ZK-Simply Ajax and 2 5 2 1 1 3 14 Mobile Adempiere ERP 3 1 5 1 1 3 86 Notepad Plus 4 1 2 2 1 2 5 ScummVM 5 1 14 5 1 2 49 WinMerge 6 1 2 2 1 2 14 Eclipse Checkstyle Plug- 7 1 0 4 3 2 5 in MinGW -Minimalist 8 6 2 2 4 5 52 GNU for Windows XOOPS Web 9 1 0 1 1 3 150 Application Platform SW Test Automation 10 6 3 3 5 2 6 Framework A further analysis of developer layer activities on Table 6.5, it shows that under this study, an average of 53 developers actually to contributed to the project published under GPL (code 1), meaning that GPL license is most popular. However, the author also observed that Mozilla license (code 2) and BSD License (code 4) are equally very popular among developers as high number of developers contribute towards Openbravo (82 developers) licensed under Mozilla and XOOP (52 developers) which is licensed under BSD, details on Table 6.4. A possible explanation is partly due to the fact that both Mozilla and BSD licenses have similar properties of allowing the modified versions of the open source 155 project to be taken personal and not returned to the community and Table 4. 17 provides details on the licenses. The author therefore deduced that Mozilla and BSD licenses are likely to be more acceptable to open source developers than the LGPL and ECLIPSE licenses base on this study. Table 6.5 Developer License Relationships License GPL Others A VG Developers 53 36 Furthermore, the results on Table 6.6 shows that there is no clear effect between number of developers fo r high ranked projects (47 developers) and low ranked projects 45 developers) as both ranked groups have close values for average developers. Results revealed that the required number of topics for both high and low ranked proj ects is effectively 3 topics to be covered on the average. Prominent topics covered across the case studies as shown on Appendix B No l, are Accounting, AJAX, Build tool, code generators, compilers, CRM (customer relationship management), debuggers, Dynamic content, ERP (Enterprise Resource Planning), File management Framework, game/ entertainment, Interpreter, Point-of-sale, Project Management, Quality Assurance, site management, Software Development, text editor and Version Control. Table 6.6 Averages at Developer Layer Developer Layer high (upper 5) low (lower 5) AVG Topics Covered 3.2 2.8 AVG Developer 47.2 45.4 AVG Prog_Lang 2.2 3 156 Table 6.7 Developer Rank Correlation Matrix Correlations Rank No developers Rank Pearson Correlation 1.000 Sig. (2-tailed) N 10.000 No of Pearson Correlation .024 1.000 Developers Sig. (2-tailed) .947 N 10 10.000 It was observed in Table 6.7 that the number of developers does not correlate with project rank. The more detailed correlation matrix fo r developer layer is presented in Table 6.8 which shows that the user interface has a negative correlation with topics covered. This means that as the user interface's limit approaches zero (web based = 0), there is a high tendency to cover more topics. This is with a confidence level of 86%. The derived regression equation in Definition 6.1 shows the actual relationship between user interface and topics covered. Definition 6.1: Regression for User Interface against Topics Covered y (user interfa ce) = -0.5 x(topics covered) + 3. 7 That is; y = -0.5 (x) + 3.7 !57 Table 6.8 correlation matrix for developer layer Topics User Interface Op_Sys Pearson Correlation 1.000 Topics Sig. (2-tailed) N 10.000 - Pearson Correlation .506 1.000 User Interface Sig. (2-tailed) .136 N 10 10.000 Pearson Correlation -.321 .611 1.000 Opsys Sig. (2-tailed) .366 .061 N 10 10 10.000 However, a higher positive correlation occurs between operating system support and user interface with confidence level of 94% which is more reliable. The regression fo r this relationship is given in Definition 6.2 as fo llows: Definition 6.2: Regression for User Interface against Operating System y' (user interfa ce) = 0. 2 x' (operating systems) + 1.6 That is; y' = 0.2(x') + 1.6 !58 6.3. Maintenance Layer Data captured under maintenance layer is represented in Table 6.9. At this layer, number of project administrators, bug open, bug closed, CVS commit and projects' development status are captured. Table 6.9 Maintenance Layer Data No of Os 0/o 0/o CVS proj_ Prog %bug Dev- Case Studies Rank suppo bug comm admi lang closed status n rt open its Openbravo ERP 1 16 3 0 8.79 91.21 7.96 5 ZK-Simply Ajax and 2 3 5 2 2.95 97.05 13.64 6 Mobile Adempiere ERP 3 9 1 5 20.68 79.32 3.22 5 Notepad Plus 4 1 1 2 39.75 60.25 1.95 5 ScummVM 5 5 1 14 4.81 95.19 1.88 5 WinMerge 6 2 1 2 11.07 88.93 5.54 6 Eclipse Checkstyle 7 2 1 1.96 98.04 1.71 5 Plug-in 0 MinGW-Minimalist 8 3 6 2 25.9 74.1 0.11 6 GNU for Windows XOOPS Web Application 9 2 I 0 5.55 94.45 18.05 6 Platform SW Test Automation 10 3 6 3 7.91 92.09 5.44 5 Framework % Projects with OS => 30% independence !59 A split-file correlation matrix based on development status is presented in Table 6. 10 and Table 6.1 1 while considering project maturity. Stable release project (5) and mature project (6). In this experiment, 6 projects have reached stable/release status (dev_status = 5), while the remaining 4 proj ects are Mature (dev_stat us = 6). Table 6.10 Correlation on Maintenance Layer (stable release version) Correlations Percv Noproja Progl Ossupp Percbu scorn Dev status Rank dmin ang ort go pen mits 5 Rank Pearson 1 Correlation Sig. (2-tailed) N 6 Noproja Pearson -.716 1 dmin Correlation Sig. (2-tailed) .110 N 6 6 Pearson Proglang .527 .087 1 Correlation Sig. (2-tailed) .283 .870 N 6 6 6 Pearson Ossuppo .036 -.121 -.242 1 rt Correlation Sig. (2-tailed) .946 .819 .643 N 6 6 6 6 Pearson Percbug -.325 -.213 -.282 -.166 I open Correlation Sig. (2-tailed) .529 .686 .588 .754 N 6 6 6 6 6 Percvsco Pearson -.241 .764 .671 -.393 -.226 1 mmits Correlation Sig. (2-tailed) .645 .077 .144 .441 .666 N 6 6 6 6 6 6 160 Correlations Percv Noproja Progl Ossupp Percbu scorn Dev status Rank dmin ang ort gopen mits Pearson 5 Rank 1 Correlation Sig. (2-tailed) N 6 Noproja Pearson -.716 I dmin Correlation Sig. (2-tailed) .110 N 6 6 Pearson Proglang .527 .087 1 Correlation Sig. (2-tailed) .283 .870 N 6 6 6 Pearson Ossuppo .036 -.121 -.242 1 rt Correlation Sig. (2-tailed) .946 .819 .643 N 6 6 6 6 Perc bug Pearson -.325 -.213 -.282 -.166 1 open Correlation Sig. (2-tailed) .529 .686 .588 .754 N 6 6 6 6 6 Percvsco Pearson -.241 .764 .671 -.393 -.226 1 mmits Correlation Sig. (2-tailed) .645 .077 .144 .441 .666 N 6 6 6 6 6 6 *. Correlation is significant at the 0.05 level (2-tailed). Result shows that, number of project administrators have a negative effect on project rank especially for proj ects which are yet to attain maturity level, that is projects grouped under stable I release status ( dev_status =5). 161 Table 6.11 Correlation for Maintenance Layer for Mature Projects Nopr Percb Percv ojad Proglan Ossuppo ugope scorn Dev_status Rank min g rt n mits 6 Rank Pearson Correlation 1 Sig. (2-tailed) N 4 Noprojadmin Pearson -.466 1 Correlation Sig. (2-tailed) .534 N 4 4 Proglang Pearson * -.338 .988 1 Correlation Sig. (2-tailed) .662 .012 N 4 4 4 Ossupport Pearson -.592 .577 .570 1 Correlation Sig. (2-tailed) .408 .423 .430 N 4 4 4 4 Percbugopen Pearson .475 .344 .482 .378 1 Correlation Sig. (2-tailed) .525 .656 .518 .622 N 4 4 4 4 4 Percvscommi Pearson -.128 -.353 -.456 -.723 -.888 1 ts Correlation Sig. (2-tailed) .872 .647 .544 .277 .112 N 4 4 4 4 4 4 A concrete explanation to this is that projects which are still subject to frequent changes and releases may have problems with coordination and communication when projects administrators are many as compared to projects under 162 the same status with less number of administrators. This is in-line with the Pareto principle which supports open source developer/ administrator 80:20 ratio. Correlation matrix for projects with stable release versions is presented in Table 6.10 and maintenance layer correlation fo r mature project is presented in Table 6. 11. Result shows that programming language has significantly high correlation on project rank especially fo r matured open source projects. Projects which support more programming languages would have a high ranks. This could be understood from the point that more programming language support would attract more download activities which eventually leads to high rank for that project. Furthermore, the Operating system support has a negative effect on project rank and a positive effect on number of project administrators and programming language support. For example, a project which is operating system independent (oss support = 0) is likely to attain high ranking more than a project that is operating system dependent ( oss support =2). The CVS commit has significantly negative effect on operating system support and bug open. The project with operating system independence (oss support = 0) is would be observed to produce higher rate of CVS commit activities than projects which is operating system dependent. 6.4. User Layer The user layer activity data is presented in Table 6.12. User interface, Topics covered, Download volume and Natural Language support are of particular importance at this layer as shown on the layers of Table 4.13. In this section, seven parameters were evaluated: Rank, Domain Audience, Us er Interface, Topics Covered, No Downloads, Natural Language support and License. These parameters were subjected to statistical correlations. Result shows that some of the parameters have significant effects on the other as evident from Table 163 6. 16. This was necessary in order to identify what parameters are determinant factors of user satisfaction metrics as stated in the objective of this research. It was observed from Table 6. 13 that license type has significant impact on natural language support. Open source projects with GPL licenses exhibit characteristics of supporting an average of 20 natural languages while projects with other licenses could only support an average of 4 natural languages. Result of analysis on Table 6. 14 shows there is no confidence that user interface has any impact on open source project topics covered. However, there is significant effect of user interface on projects' volume of downloads. Proj ects which are web based in fact have higher download volumes over projects which support only win32 platform. However, win 32 platform still attract more download volume over other user interfaces as clearly evident from Table 6. 14. In order to identify the significance levels of the effects of the user layer variables, the correlation matrix for user layer was presented in Table 6. 15. Result shows that user interface has a significantly negative correlation with domain audience. That is for a user interface = 0 (web based) then the number of targeted domain audience increases significantly with a confidence level of 98%. This clearly explains why the download is extremely high for web based applications. The author therefore concludes that domain audience has positive effect on the volume of downloads. The open source topics covered was observed to have significantly positive correlation with domain audience with a confidence level of 96% while user interface is observed to have a slightly negative effect on topics covered and natural language support. 164 Table 6.12 User Layer Data Case Studies Rank Domain User Topics No Natural License Audience Interface Covered Downloads Language support Openbravo ERP 1 6 1 6 976985 10 2 ZK-Simply Ajax 2 4 I 3 881788 22 1 and Mobile Adempiere ERP 3 6 1 3 399259 14 1 Notepad Plus 4 2 3 2 15592736 36 1 ScummVM 5 1 6 2 6725805 1 1 WinMerge 6 2 3 2 5027512 24 1 Eclipse 7 2 5 2 3722591 3 3 Checkstyle Plug-in MinGW- 8 3 3 5 20744162 1 4 Minimalist GNU for Windows XOOPS Web 9 3 1 3 7252595 25 1 Application Platform SW Test 10 3 4 2 338375 l 5 Automation Framework Table 6.13 Natural Language support - license License GPL Others AVG Nat_Lang 20 4 Table 6.14 Downloads-topics covered AVG User Interface Web based Win 32 others Downloads 202,377,656.75 13,788,136.67 3,595,590.33 ITopics covered 165 Table 6.15 Correlation for User Layer Topics Natural Domain User Covere Languag Audience Interface d e support Domain Pearson 1.000 Audience Correlation Sig. (2-tailed) N 10.000 User Pearson -.716* 1.000 Interface Correlation Sig. (2-tailed) .020 N 10 10.000 Topics Pearson .652* -.545 1.000 Covered Correlation Sig. (2-tailed) .041 .103 N 10 10 10.000 Pearson Natural .008 -.535 -.207 1.000 Language Correlation support Sig. (2-tailed) .982 .111 .566 N 10 10 10 10.000 �r. Correlation is significant at the 0.05 level (2-tailed). The correlation matrix for user layer as presented in Table 6.15, clearly shows that user interface has significantly negative correlation with domain audience with a high confidence level of 98%. Topics covered have significantly positive effect on domain audience with a confidence level of 96% and a negative effect on user interface. The negative effect of Natural language support could be observed on user interface as well. 166 6.5.External Layer At the external layer of the open omon model, parameters captured are Project Rank, downloads, Topics covered, License types, natural language support, number of fo rums, fo rum messages, project age and development status. Table 6. 16 provides details of the extracted data fo r this layer. A further analysis on this Table 6. 16 yields Table 6.17 in which analysis was performed based on project development status. Results show that mature projects gain more popularity and yield higher user-satisfaction than projects which are still undergoing constant and rapid reviews such as those within the brackets of stable release versions as evident from Table 6. 17. In order to measure the quality of open source software the author defined open source quality from user satisfaction angle which is heavily dependent on project download volume as earlier presented in Section 3.3.2 and as stated in Definition 4. 1. Therefore, the author concludes that quality open source software project (Mature projects) do provide higher user satisfaction (higher downloads volume) over less quality projects whose development status are not yet mature. This result also confirms the Hypothesis 5 of Section 3.7 on download volume being a fundamental index to measure the adoption and level of implementation of open source project at external layer. In support of the accomplishment of the set research objectives of Section 1.4 Sub-Section iiv, this result also improves an understanding of open source user satisfaction-quality criteria. 167 Table 6.16 External Layer Data Natural Topics No of Forum Dev Case Ran Down Licens Languag Projec covere forum message statu Studies k loads e type t_age d e s s s Support Openbravo lO ERP I 976985 6 2 16 31244 4 5 ZK-Simp1y Ajax and 2 881788 3 1 22 5 29899 5 6 Mobile Adempiere ERP 3 399259 3 1 14 37 38035 4 5 Notepad Plus 4 15592736 2 1 36 9 46792 7 5 ScummVM 5 6725805 2 1 1 0 0 9 5 WinMerge 6 50275 12 2 1 24 2 44781 10 6 Eclipse Checkstyle 7 3722591 2 3 3 3 150 7 5 Plug-in MinGW- Minimalist GNU for 8 20744 162 5 4 1 0 0 10 6 Windows XOOPS Web Applicatio 9 7252595 3 1 25 2235 9 6 n Platform SW Test Automatio n 10 338375 2 5 I 2 9373 9 5 Framewor k %of Mature 30% Projects 168 Table 6.17: Project Maturity Vs Downloads Natural Development Topics Language No of Forum Project status Down loads covered Support forums messages _age Stable Release Version (5) 4,625,959 3 11 11 20,932 7 Mature (6) 8,476,514 3 18 2 19,229 9 Table 6.18 Natural Language Correlations for External Layer Natural Language License Support type Natural Language Pearson 1.000 Support Correlation Sig. (2-tailed) N 10.000 License type Pearson 1.000 Correlation .678. Sig. (2-tailed) .031 N 10 10.000 The interesting result from Table6. 18 reveals that there is significantly high correlation between Natural language support for open source projects and license types. An explanation to this is that the higher the license value (as limit approaches 5), the higher the numbers of people who are willing to render "free" support services to open source development projects. 169 Part of the support as evident from the above analysis is the natural language support in terms of contributions by way of language translations that could be published at various fo ra in order to get the project delivered across diverse complex multi-cultural existence and groups. The open source project license frequency analysis was earlier presented in Table 4.18 and it shows that GNU public license (GPL) is the most popular; this provides an explanation to why GNU licensed projects have exceptionally high frequency of Natural language support. Evidence from Table 6.20 supports an average of 20 natural languages support by GPL licensed projects as against 4 on the average natural language support for other types of open source licensed projects. Table 6.20 confirms the result on Table 6.18. Table 6.19 Project Age Correlations for External Layer Project No of _age Rank forums Pearson Project 1.000 _age Correlation Sig. (2-tailed) N 10.000 Rank Pearson Correlation .806** 1.000 Sig. (2-tailed) .005 N 10 10.000 No of forums Pearson Correlation -.754* -.543 1.000 Sig. (2-tailed) .019 .131 N 9 9 9.000 170 Paradigm examples of GPL Licensed projects are Notepad ++ with over 35 Natural languages being supported and XOOPS Web Application Platform with support for over 25 natural languages as evident from Table 6. 16. However, inorder to ease the analysis, License types were further attached with coding values in which the most frequent license is attached the value of 5 as evident from Table 4. 19. Therefore at this stage of the analysis, the license value at 5 implies GNU Public License (GPL). Table 6.20 Further Correlations on External Layer Natural Forum Language messages Support Forum Pearson messages Correlation 1.000 Sig. (2- tailed) N 10.000 Natural Pearson .698* 1.000 Language Correlation Support Sig. (2- tailed) .025 N 10 10.000 k. Correlation is significant at the 0.05 level (2 tailed). Further analysis on the external layer was performed in order to test the research hypotheses. Hypothesis 4.1 is further supported by the correlation matrix on Table 6. 19. As evident from the Table 6.19, project age has an extremely significant positive correlation with the project rank; this is at confidence level of99.95% with a P-value of 0.005. The project age also has a significantly negative effect on number of fo rums with a high confidence level of99.8 1% and a P-value of0.019. 171 Furthermore, Table 6.21 reveals a significantly positive correlation between natural language support and fo rum messages. The more natural languages being supported the higher the fo rum messages generated. The correlation is with a confidence level of99.75% ofP-value of0.025. 6.6. Cross - Layer Evaluation In order to validate our open-onion model, we have used I 0-highly ranked SourceForge proj ects as earlier discussed in Section 3.4.2. Pearson correlation results for the linear data sets, domain audience, user interface and topics covered are experimented. From Table 6.22, it was evident that in open source development projects, the user interface impact negatively on the domain audience. The lower the user interface variable, (e.g. I = web based, Appendix B No.2) the higher the domain audiences such as in terms of service industries to be supported (e.g. Manufacturing, consumer service, finance and insurance industry as shown on Table 4.15). The significant(2-tailed) implies that the P value is significant at 0.05 (P:S0.05); meaning that the acceptable confidence level should not be less than 95%. Table 6.22 therefore reveals that user interface has a negative correlation with domain audience; meaning that the lower the number of domain audiences, the higher the user interfaces and vice versa. This is with a high confidence level of 95.9%. The topics-covered has a significantlypositive effect on domain audience at a higher confidence level of 96.3%. However, the author presents in this analysis that topics covered does not have any significant effect on user interface and vice versa as evident from theTable 6.22. 172 Table 6.21 Correlation Matrix for Domain Audience domain user topics Audience interface covered Domain Pearson Correlation 1.000 Audience Sig. (2-tailed) N 10.000 User Pearson Co1Telation -.653* 1.000 Interface Sig. (2-tailed) .041 N 10 10.000 Topics Pearson Correlation - .661 * . 545 1.000 Covered Sig. (2-tailed) .037 .103 N 10 10 10.000 *. Correlation IS s1gmficant at the 0.05 level (2-taded). The License types have been categorized broadly into two thus: GPL and Others as shown on Table 6.23. This is because GPL license ranks highest in the frequency analysis Table 4. 18 as discussed earlier in Section 4.3.2. This means that GPL is the most popular license amongst all license types, based on these case studies. Table 6.22 Licenses Analyzed on Average License Types GPL Others A VG Domain Audience 2.8 3.5 A VG User Interface 2.7 3.3 A VG Topics Covered 2.5 3.8 173 GPL license was therefore analysed based on its relativity to average domain audience as shown on Table 6. 14 for average user interface and average topics covered across the board for the ten projects. The author discovered that projects with average domain audience of 2.8 are "ideal" open source projects. The average user interface of 2. 7 and average topics covered of 2.5 are "ideal" fo r a "quality open source project" which satisfies the predefined In order to ease the analysis, a re-categorization of the Project ranking into high rank (upper 5) and Low rank (lower 5) was done as shown on Table 6.24. The higher the license variable, it gives rise to a higher project rank and vice versa. That is, fo r example, fo r a license code of l = GPL, as discussed earlier in Section 4.3.2 then we expect to have higher project ranking. Table 6.23 Analysis by Project Rank by Group Average Proj ect Rank High(upper 5) Low (Lower 5) AVG Domain Audience 3.6 2.6 A VG User [nterface 2.6 3.2 AVG Topics Covered 3.2 2.8 Table 6.24 Further Cross Correlations No of Project forums _age No of Pearson 1.000 Forums Correlation Sig. (2-tailed) N 9.000 Project Pearson -.754* 1.000 _age Correlation Sig. (2-tailed) .019 N 9 10.000 174 Meanwhile, the domain audience has impact on the project ranking. The higher the number of audience, the better the chances of such projects ranking high. Topics covered are also observed to have significant impact on the Domain audience. License type has effect on the project ranking. The higher the license variable gives rise to a higher project rank and vice versa. That is fo r license code of I= GPL for example, as shown on Table 6. 19, then it is expected to have higher project ranking. As evident from Table 6.22, the topics covered have significant effect on domain audience, meaning that the more the topics which are covered, the higher the expected audience resulting in higher project community building. The user interface also impacts negatively on the topics covered. Meaning that in order to cover more topics, there is needed to reduce the number of user interfaces. For example, web based interface tends to support more project topics than other interfaces. Table 6.25 reveals that download volume is higher for projects between the age brackets of 8-10 years relative to younger projects of age less than 8 years. Table 6.25 Project Age vs. Downloads Proj_Age 4 yrs s Proj_Age s 7yrs 8 yrs s Proj_Age s 10yrs Downloads 752,677 8,486,254 6.6.1. Result Summary on Source Forge Case studies In this study, the research approach is concerned with the use of open onion model to improve the understanding of open source development from the point of view of user satisfaction as discussed earlier in Section 4.3.2 and identifying the levels to which the parameters under the analysis affect each other to be provide an adequate guide for software proj ect decision makers who would be using the results ofthis research on the long run. 175 The open onion approach was statistically evaluated. Earlier in Section 5.2, the open-onion was presented as a five-layered approach to open source model. In this Section, each of the layers of the onions presented in Figure 5.1 was statistically evaluated. Result shows that Java programming Language is highly reckoned with in the open source programming arena. Open source project rank, rank calculation was earlier presented on Figure 4. 14, has only a slightly negative effe ct on domain audience; the GNU License is more acceptable to open source contributors; these were earlier presented in Section 6. 1. This however provides evidence to support the results obtained in Table 6.5 in which more open source developers do work on GPL licensed projects than they do fo r projects with other licenses. The extent to which user interface affects topics covered as well as operating systems adoption were also investigated. The regression equations presented on Definition 6.1 and Definition 6.2 provide evidences fo r identifying the extent of correlations presented on Table 6.8. Although, the number of developers do not affect the proj ect rank as shown on Table 6. 7, evidence on Table 6.10 shows that number of project administrators, working on projects with stable release version status, do in fa ct affect the proj ect rank negatively. Interestingly, there is a different result for mature projects in which the project administrators do not have any effect on the project rank. It also shows that projects with web-based user interface provide higher user satisfaction than those with other user interfaces such as Win32. This result is evident from the high volume of average download attached to Web-based projects as presented on Table 6. 14. Also, projects with GPL licenses have facility for more natural language support as shown on Table 6. 13. Mature proj ects yield higher user satisfaction over those projects undergoing constant reviews and changes. This evidence is supported in Table 6.17 in which user satisfaction metrics of project average download volume, reveals an extremely high value over the projects with stable release version status. 176 6.7. Verificationwith Flossmole Project In this Section, data covering a period of five years(2005-2009) was obtarned from Flossmole and anlysed. The Flossmole project was utilized in order to have cross-verification of the statistical evaluation of SourceForge project data. The Flossmole, freely provides data on open source projects in multiple fo rmats for anyone to download. Donated data from other research teams are integrated and in built tools are provided for data gathering. Community fo rum is provided for researchers to discuss public data about open source software development. Data are sourced from multiple open source platforms and coded for identification as presented on Table 6.26. Table 6.26 Forges on Flossmole Projects SN Heterogeneous Forges Forge Code (GC) 1 Google Code 2 Fresh meat (FM) 3 Objectweb (OW) 4 Rubyforge (RF) 5 Github (GH) 6 Free Software Foundation (FSF) 7 Savannah (SV) 8 Sourceforge (SF) 9 Deb ian (DEB) 10 SourceKibitzer (SK) (Now Defunct) Flossmole project was used to track the variables necessary for consideration on the developer layer and User layer. First, Data reduction was performed in order to be able to visualize the most relevant variables. 177 The Flossmole project contains over 300 GB of data covering the period 2004-2009 was extracted and used fo r strengthening the validation exercise. This repository was chosen to further validate the onions model because it readily provides open source project development activity data acquired through its over 200 web spidering operations, and growing each month. It contains data fo r more than 200,000 different open source projects and their developers. � I u .=::::J -- ...... � U �,_._....�rn<"' VAA.O-«AR( tOO) .._ .... :=:J __bo'WJ ,...,_ 0 �_, VARCt-t.A.Q.{2-SS) u IH"'L� �-v� so> • ... � ..._...... ,..._...,..a.ot::.O!I>) V...... CC>-t"""""< � d�-<-• 1...-T('S) ..,..,.g �� 'C'd OAT'FT I,...,F �� U t'V� VAA.c::::.1AR(10). � Of"'l-k>nQ._r�t'ne VARC>-tAR.( 2SS) Q JH"'l-�� VAR�R.( 1 OO> C:li -• ...,�-•-••• ..... 1_...'( :t.O) � d�tpot._... '"'-""""�'-< 1000) <""-"""' � d� 1NT( 10) �� v.ARCHA.R.-(�SS) .-.c:b.... V/4AC'Ifo-tAR(20) 0 lt'y�C�Okl' R OA.T C p..o..rentp.,X.h ...... � L.»...... _ '-'-f_.._ "-.t..-..1 o.A"T'r"""T"W� �� VAIA�&.OO) INTC l1) U �t.DI$0...WCC' tel E:.;lc;I(Wt4'!' �� OATCTlMt; ... - 1 ::::::J � ...... - � ·•AQ(!;I)) ::::J ...... ��,�-� V'AI __j ...a:.;i U lN'T(1i0) � ,_...... ,_.-..- •NT( 11 I) loc ...... ,..,. UdocINT(lO) Q pro)_u� VA�( .IOO) :=:J cSaoi:A ,..,.... c.:ll ��-oc 1...-rcO> • 0 \lflrl' V,A,RQ-4AA(255) t.A �rcc idJN,(11) � ...... -.a ...... ,. 1 de r'c.-gc � � rt,.C),A T . -�(;:ac..JIO:) � :1-T(:,..) UnornINT . . -.- ...,., ::::J 1"0<'0- ::::::J --_.....-J-..::... ==:�.-....,�� U I'Ot'OC tel INT(�) VI"'MM� VAR.Ct "«AAI . ...oroS 100) U � ..cl JNT(.ll) � lfOPQCt GlOOr"""""""""-� t..C.) VARC>1A..R.(2SS) l 0 ..._.t U Cl�rcoe- td tNT( I) � l'o-� IOnoCI n.no,...,. VA.R.C�:.,0) � re..-.J_urt VAR�255) fOof'OO' hOmO ... � � VAA.CHAR(2�S) cat.c: •c Figure 6.1 Main Schema for Flossmole Data Sources (Fiossmole) 179 6.7.l.Open Source Projects Distribution on Flossmole As described earlier in Section 3.3.4, although the case studies are mainly from SourceForge, a cross verification exercise was performed with Flossmole project (2004-2009) to concretize the statistical results obtained from the SourceForge. The statistical analysis was performed on the Flossmole projects and results are presented in this section. Distribution of Open Source Projec; lnput/OUtJHit (Daemon) 7% � Web Environment 41"& Other Environment 130,:, Figure 6.2 Flossmole project Environment Distribution Chart Figure 6.2 is a descriptive statistics of Pie chart representing the distribution of open source projects under the Flossmole. The result reveals that 41% of the open source proj ect is Web Environment fo llowed by 15% MS Windows. Console (Text Based) and Other Environment each has 13%, while Gnome and KDE are the least of the open source project with 2% and 1% respectively. 180 Figure 6.3, it is a descriptive statistics representing the distribution of open source project targets. The result reveals that 65% of Open source project are usually targeted at professional coders (Programmers). Here, Professional Programmers are categorized as a combination of Unix Administrators, Testers, and Developers as Programmers. The remaining 38% that consist of Document Writer, Graphic Designer, Support Manager and the undefined developers are categorized as Unskilled Programmers. Distribution of Open Source Project Developers Unskilled Programme I'S 38% Progrcunme rs 62.% Figure 6.3 Flossmole Skilled Vs Unskilled Open Source Developer Chart 181 • Developer • Doc Writer • Graphic/Other Designer • Project Manager Su p rt nd T�stld" Undefined Unix Admin 2% Figure 6.4 Distribution of Open Source Project community membership Percentage Distribution of Projects Under Survey Planning rv1 ture a S% Pre-Alpha 3% Production/ Stable 5596 Figure 6.5 Flossmole Project Development Status 182 The Figure 6.4 is a descriptive statistics representing the distribution of open source project developer community. The result reveals that those classified as Professional coders (Programmers) consist of 58% Developer, 2% Unix Admin and 1% Tester. Those that are classified as Amateur or Unskilled Programmers consist of 19% Project Manager, 16% Undefined, 3% Document Writer and l% Support Manager. Graphic/Other Designer class are very insignificant with approximately 0. 1%. The Figure 6.5 is a descriptive statistics representing the percentage distribution fo r maturity levels of projects under survey. In Flossmole, the projects are coded as 7, 8, 9 10, 11 and 12 fo r Planning, Pre-Alpa, Alpha, Beta, Production/Stable and Mature stage respectively. The result reveals that Production/Stable has 55%, Beta 22%, Alpha 12%, Planning has 5% while Pre Alpha and Mature both have 3% each. Percentage Distribution of Project Under Survey Figure 6.6 Flossmole Stable Vs Unstable Projects 183 The Figure 6.6 is a descriptive statistics representing the percentage distribution of projects under survey combining the codes 7, 8, 9 and I 0 and defining them as those that have not reached stable released version status, while codes 11 and 12 are used to represent those projects which have reached the status of stable released version. The result shows that only 42% have reached stable released version status while the remaining 58% have not reached stable released version status. 6.7.2.Project Environment The Flossmole project provides details on over 5000 projects sourced from varying fo rges. Prominent among these fo rges are Google Code, Freshmeat, Objectweb, Rubyforge, Github, Free Software Foundation, Savannah, SourceForge, Debian and the SourceKibitzer as shown on Table 6. 15. The author is aware that SourceKibitzer is now defunct; the project only actively supplied data to Flossmole between the periods of February to September 2007. In this section, project environment refers to the environment within which an open source project could be used. For the Flossmole project, the most prominent project environment is Web-based as shown on Table 6.27. Although, 1104 projects were analysed on Flossmole as shown on Appendix E (N1 - N9), only 98 unique projects have been analysed for project environment studies as evident from Table 6.27. The reason is that some projects appear under more than one instance. Appendix E, N9 reveals that Acceleo for instance appears 31 times in the frequency count though under differing data bundles but still within the whole Flossmole project. In this research, analysis is based on counting a proj ect once in the development cycle as shown on Appendix E, Nll. Result on Table 6.27 shows that there are actually 98 projects whose project environment could be analysed for Flossmole under this study. Result shows that the most prominent environment is Web-based. This provides support for the fo r the results obtained fo r SourceForge proj ects where the most prominent user interface 184 was web-based as earlier discussed in Section 4.3.2. The result shows evidence of support for research Hypothesis 2 in Section 3.7. This provides details of a better understanding of the open source development environment. Table 6.27: Project Environment Frequency Analysis Cumulative Frequency Percent Valid Percent Percent Valid Console (Text Based) 13 13.3 13.3 13.3 Gnome 2 2.0 2.0 15.3 KDE 1 1.0 1.0 1 6.3 No lnpuUOutput (Daemon) 7 7.1 7. 1 23.5 Other Environment 13 13.3 13.3 36.7 Web Environment 40 40.8 40.8 77.6 Win32 (MS Windows) 14 14.3 14.3 91.8 X1 1 Applications 8 8.2 8.2 100.0 Total 98 100.0 100.0 6.7.3.Intended Audience (Domain Audience) The intended audience of the open source projects on Flossmole was critically analysed. Result on Table 6.28 shows that 89% of the domain audiences are software developers while 25% are system administrators and only 20% are end users. A comparison of the results obtained on Flossmole and that of SourceForge confirmed that currently, open source projects are highly targeted at software developers. Result on Table 6.6 shows that a higher number of developers yield higher ranked project and Table 6.26 shows that indeed, more developers are highly targeted by open source projects since every proj ect aspires to be highly ranked. 142 185 projects on Flossmole were tracked fo r the intended audience as shown on Table 6.38 as against the 1104 projects as presented in Appendix E, N2. However analysis of the Flossmole reveals that 58.8% of the total contributors are software developer fo llowed by 18.8% of Project Managers as shown on Table 6.29 and the least of the contributors are Graphics Designer which accounts for 0. 1 %. The evaluated developers in this case are skilled programmers as earlier shown on Figure 6.3. Table 6.28: Intended Audience description Intended Audience description Cumulative Frequency Percent Valid Percent Percent Valid Developers 89 62.7 62.7 62.7 End Users/Desktop 20 14.1 14.1 76.8 Other Audience 8 5.6 5.6 82.4 System Administrators 25 17.6 17.6 100.0 Total 142 100.0 100.0 186 Table 6.29 : Position of Contributors Position Valid Cumulative Frequency Percent Percent Percent Valid Developer 646 58.5 58.5 58.5 Doc Writer 34 3.1 3.1 61.6 Graphic/Other Designer 1 .1 .1 61.7 Project Manager (!OS 18.6 18.6 80.3 Support Manager 7 .6 .6 80.9 Tester 12 1.1 1.1 82.0 Undefined 176 15.9 15.9 97.9 Unix Admin 23 2.1 2.1 100.0 fotal 1104 100.0 100.0 6.7 .4. License Description Analysis It is interesting to observe that the result obtained on License types fo r Flossmole project does not tally with that of SourceForge projects. Table 6.29 is the license description result for Flossmole project and it reveals that the most highly subscribed open source license is LGPL as against the SourceForge result on Table 6.2 in which GPL has the highest acceptance rate. Out of the 101 projects investigated for License types as shown on Table 6.30, results show that LGPL license were highly subscribed to as against the result obtained in Section 4.3.2 which revealed that GPL were highly subscribed open source license. The author's explanation to this indicates that the result is due to the fact that the Flossmole projects provides sets of data, fo rged from many data sources as presented earlier on Figure 6.2, that are large enough to reveal the inherent hidden properties which were not captured in the SourceForge data of fewer case studies. 10 187 Proj ects were investigated on SourceForge and 1104 projects were analysed for Flossmole projects as presented in Appendix E, N9. Table 6.30: License description License description Cumulative Frequency Percent Valid Percent Percent Valid Artistic License 1 .6 .6 42.5 BSD License 8 4.6 4.6 47.1 Eclipse Public License 2 1.1 48.3 (EPL) 1.1 GNU General Public 7 4.0 4.0 52.3 License (GPL) GNU Lesser General 81 46.6 46.6 98.9 Public License (LGPL) OSI Approved I .6 .6 99.4 Other/Proprietary .6 100.0 License I .6 .,.._--- Total 101 IOO.O IOO.O _. , -.. ' ' · (;. 6.7.5.Summary of Operating Systems (OS) \\ The operating system descriptive result on Table 6.30 reveals that most open source proj ects are OS independent. As against the highlighted 30% OS independence revealed fo r SourceForge result on Table 6.9, Flossmole provides a variance in the result. Analysis on Table 6.3 1 reveals a 65.8% OS independence. This is also attributed to the analysis of large sets of data from Flossmole as discussed earlier in Section 4.3.2. 188 Table 6.31: Operating system description Operating system description Valid Cumulative Frequency Percent Percent Percent Valid Linux 15 13.5 13.5 13.5 MacOS 1 .9 .9 14.4 Microsoft 3 2.7 2.7 17.1 OS Independent 73 65.8 65.8 82.9 PO SIX 3 2.7 2.7 85.6 SunOS/Solaris 1 .9 .9 86.5 Windows 5 4.5 4.5 91.0 Windows 1 .9 .9 91.9 95/98/2000 Windows CE 1 .9 .9 92.8 Windows NT/2000 8 7.2 7.2 100.0 Total 111 100.0 100.0 6. 7 .6. Programming Languages vs. Development Status (Flossmole) Programming Language were analysed and results on Table 6.32 shows that Java is the most active programming language. This provides support for the claim which was earlier revealed by SourceForge project on Table 4.23. Proj ects within the Production I Stable release version are more within the open source development. This is evident from Table 6.33 189 Table 6.32: Programming Language Analysis (Flossmole) Programming language Cumulative Frequency Percent Valid Percent Percent Valid Assembly 1 .9 .9 .9 c 8 7.2 7.2 8.1 C++ 4 3.6 3.6 11.7 Erlang 1 .9 .9 12.6 Java 85 76.6 76.6 89.2 Objective C 1 .9 .9 90.1 Other 3 2.7 2.7 92.8 Perl 4 3.6 3.6 96.4 PHP 1 .9 .9 97.3 PL/SQL 2 1.8 1.8 99.1 Python 1 .9 .9 100.0 Total Ill 100.0 100.0 . �- I• Table 6.33 Development Status / Count Percent development status Alpha II 12.2% Beta 20 22.2% Mature 3 3.3% Planning 4 4.4% Pre-Alpha 3 3.3% Production/stable 49 54.4% Overall 90 100.0% Excluded 0 Total 90 190 6.7.7. Flossmole Project Result Summary In this section, Flossmole project was examined for the purpose of answering the research question (iv) which was stated earlier in Section 1.3. As at the time of data writing this thesis, there were l 0 major fo rges of data sources fo r Flossmole project as earlier presented on Table 6.25 along with its main data source schema presented in Figure 6.1. The Flossmole experiment supports the earlier claim that open source project environment is mainly web-based as shown by the SourceForge experiment on Table 4.21 and as shown fo r Flossmole experiment on Figure 6.2. A further analysis also revealed that most open source project developers are skilled programmers as evident from Figure 6.3 and these developers actually take a high percentage of 58% of the total open source project members. This claim is clearly shown on the result presented in Figure 6.4. This result shows support for earlier observation, as presented on Table 6.26, in which very few of the numerous open source projects actually reach the mature status. In Figure 6.5, the 1104 Flossmole project under investigation revealed that only 3% of the total projects are categorized to have hit their maturity status. However, it is interesting to observe that highly ranked open source proj ects fall between mature as well as projects with production/stable release status. The result of Flossmole project presented on Figure 6.5 shows that only 3% of the Flossmole projects investigated were mature while 55% of same total are on production/stable release status. Meanwhile, the result on Table 6. 16 reveals that 30% of the SourceForge projects case studies are mature while the remaining 70% of the projects are on production/stable release status. The disparity in these percentages are better explained from the point of view of the fact that the investigated Flossmole provides a large set of data covering all the 6 phases of the open source project development status as discussed in Section 6.7. 1. A further analysis revealed that those projects with production/stable status are actually constituted of 58% unstable projects and 42% projects with stable status as shown on Figure 6.6 191 6.8. Summary of Experimental Evaluations In this chapter, the open omen layers were statistically evaluated Unit parametric analyses were performed in Section 4.3.2 based on the pre-defined parameters which were earlier discussed in Section 4.3.1. In Section 4.3.2, the open onion parameters were systematically analysed on a single-unit basis; the results of the unit parametric analysis were extensively discussed in Section 4.4. This was fo llowed by statistical validation exercise which was performed on each of the 5 layers of the open onion based on SourceForge case studies. Table 6.34 Comparative Study of SourceForge and Flossmole Parameters Major Metrics SourceForge Flossmole Project Web-based Web-based Web-based Environment Domain Audience Software Developer Software Developer Software Developer License Types GPL, LGPL GPL LGPL Operating System OS Independent OS Independent OS Independent Programming Java Java Java Language Mature Projects (%) Less Mature Less Mature Projects Projects Pro·J ect Status Production/Stable (%) High No of High No of Prod/Stable projects Prod/Stable proj ects It was observed that across some of the layers, there were some levels of interdependencies, as expected of the onion behavior. Therefore, a cross-layered evaluation was performed as discussed in Section 6.6. Detailed results of SourceForge case studies experimental validation was comprehensively presented in 192 Section 6.6. 1 [n order to answer the research question iv on verification of the open onion mode as earlier presented in Section 1.3, a larger set of data was sought from a single secondary source, Flossmole but with l 0 different forges which are GC, FM, OW, RF, GH, FSF, SV, SF, DEB and SK as presented earlier on Table 6.26. The result reveals that when the investigated study is limited to a single fo rge, the validation exercise would be strengthen as against having data from heterogeneous fo rges. The author's claim of homogenous data sources is supported by results of this research in which validation of the onion model was better performed with concentrated data from SourceForge as against the large data of wide disparity of fo rges from Flossmole. This study demonstrates that Open omon layers could be validated on a consistent and highly concentrated homogenous data sources. For instance, the SourceForge data which was extracted fo r I 0 case studies was seen to support the validation exercise across all the five layers of the onions since it was possible to pass the data through each of the five layers as well as onto the cross-layered validation phases. However, the Flossmolc projects could not scale well in the open onion analysis. This is due to the disparity of the data schemas of the heterogeneous open source repositories who have generously donated data to the Flossmole. Due to this reason, it was difficult to distribute the Flossmole data across the 5 layers of the open onion model and as a result, only a best-fit approach was adopted in analysis of the Flossmole. The best-fit was identified to be the single-unit parametric analysis, as earlier performed on the SourceForge parameters which were discussed earlier on Section 4.3.2. The unit parametric analysis was performed a results presented on Table 6.33. Table 6.33 represents parametric units' relationships between Flossmole and SourceForge. The result shows that SourceForge and Flossmole agree on 5 project metrics which are Project Environment, Domain Audience, Operating System, Programming Language and Project development Status. The disparity was only on the open source licenses which are concluded in this research as either GPL or LGPL. SourceForge validation supports GPL licenses while Flossmole projects 193 actually provides support fo r LGPL licenses as the major determinant license metrics as shown on Table 6.33 Results from the parametric evaluation on Flossmole analysis reveals that the valid numbers of project cases were not all the same across the units of analysis. Table 6.26 for instance result reveals 98 valid projects analysed for project environment. Table 6.27 was a validation for 142 projects. The whole of the 1104 projects which were investigated under the Flossmole were analysed on Table 6.28 for positions occupied by open source contributors, only 101 projects had their Licenses details available for validation as shown on Table 6.29. Exactly 111 projects were tracked for operating systems and programming languages support matrices as presented on Table 6.30 and Table 6.3 1 respectively and the development status details were analysed for 90 proj ects as shown on Table 6.32. The inconsistencies in the project counts across each unit of analysis is a result of the in-balances in the availability of required data records and this put the author in a difficult position to probe further on the correlations and regressions analysis which were preformed conveniently during the SourceForge experimental evaluation. For instance, Table 6.3 shows the correlations Matrix fo r Proj ect Initiation Layer on and Definition 6. 1 is the Regression equation for User Interface with respect to the Topics Covered. However, result for the best-fit approach on each unit parametric analysis ofFlossmole was presented earlier in Section 6.7.7. CHAPTER 7 DELPHI'S VALIDATION OF OPEN ONION MODEL The open onion model which was developed in Chapter 5 based on case studies and evaluated statistically in Chapter 6 is put to further test by being validated using Delphi's approach. Each layer of the open onion model was evaluated statistically in Section 6.1. The parameters fo r the evaluation were obtained from the proj ect details of the case studies as presented on Table 4. 14 of the case study summary. In this chapter, these parameters are now being validated to ascertain their viability and acceptability by the experts in the field of open source development. Detailed discussions of how the study participants were identified and selected, an explanation of how the survey instruments were designed and implemented and a description of the data analysis process have been discussed in Section 3.5 in the research methodology of Chapter 3. Included in this chapter is the discussion of the instruments utilized, details of data collected and the analysis of the results and comments from open onion Delphi validation experts. A summary of the open onion Delphi process is presented on Table 7 .1. The author used modified Delphi process to first elicit acceptance level of the concept of onion model of open source development through the preliminary survey of Delphi round 1. The outcome of the first round was now used in the ascertaining the general view of experts on the onion model concept in open source and further identifies the experts' readiness to participate in all rounds of the Delphi process. Appendix G (Nol) shows the preliminary roundl survey. Rounds 2 to 4 are presented in Appendix G (No 2 to No 4). 195 7.1. The Delphi's Open onion validation Process This Section describes the procedures that were used to validate the open omon model. The purpose of the validation was to asce1iain that the parameters utilized in evaluation of each layer of the open onion model (Chapter 6) are valid and to identify the validity of the open source user satisfaction metric which was earlier developed in Section 5.5.1 A panel of fo urteen experts participated in a fo ur-round Delphi process designed to identify and validate the essential parameters and metrics fo r the open onion model as well as open source user satisfaction equation of Definition 5.1. Out of the fo urteen experts who participated at the initial round, only twelve experts were able to participate in the whole of the fo ur rounds of the survey. The complete summary of the whole validation survey is presented in Table 7 .l In the Delphi round-1 of the open onion Delphi validation survey, demographic information and one concrete question on open source onion phenomenon was asked "Do you think open source development is truly onion structured?" In the Delphi round-2, data was collected in 3 parts; characteristics of each layer of the open onion was solicited, parameters for each layer were validated and some open ended questions on the relevance of each layer of the open onion model to the overall open source development process were inquired. Delphi round 3 was performed based on revised level of importance of enlisted parameters were further validated on a 5-point scale; which means that the five most essential fe atures, affecting open source user satisfaction metrics were investigated. Delphi round 4 open onion validation survey was performed with a view to assessing the importance/ relevance of open onion model to the overall open source development process in order to ascertain how it has improved the open source development process. The Delphi round-4 survey was designed such that an open ended question fo rmat was adopted thus: "What can you comment on the OPEN ONION MODEL Development". Interesting responses were obtained from all fo ur rgl ounds of the Delphi validation, details of which are discussed in sections that fo llow with summary fo r all fo ur rounds presented on Table 7.1. Table 7.1 Summary of Open Onion Delphi Validation Process Validation Round 1 Round2 Round 3 Round 4 Stages Instrument Open ended survey Questionnaire 1 Questionnaire 2 Questionnaire 3 Data Demographic Information I Data was collected in 3 parts: Revised level of importance of I Assessment of importance/ relevance of Collected and one concrete question Characteristics of each layer of enlisted parameters (on a 5- the overall open onion model to open on open source onion the open onion was asked point scale) which means five source development process improvement property phenomenon was most essential fe atures, were asked using open ended question Parameters fo r each layer were asked affecting open source user fo rmat fo r experts to respond to the open validated and satisfaction metrics were ended inquiry. Open ended questions on the investigated. relevance of each layer of the onion to the overall open source development process were inquired. Data Compiles general views of Compute means, ranges and Compute the mean and level Qualitative evaluation of the open ended Analysis experts on the onion determine level of agreement of agreement for each of the question was adopted. concepts in open source for each of the fe atures by using fe atures being assessed across Categorization of the various experts' development. percentages. the layers of the open onion comments model. Identifying level of support Tally votes determine the level Identifying the importance of the fo r the open source onion consensus on each of the Tally vote determines the comments using value judgment which concept features being verified. level of correctness of the would be based on analysi8 of previous open source user satisfaction Prepare questionnaire 1 by Prepare Questionnaire 2 using responses in earlier rounds. equation being proposed in separating the open onion parameters receiving highest Analyze the differences among the this research. layers into their constituent rating. experts' opinions. validation parameters, Prepare Questionnaire 3 to Draw conclusions based on the results. characteristics and fe atures. wrap up the Delphi open onion model validation. 197 7 .2. Instrument Design and Implementation The participants' description is such that each participant in the Delphi open omon validation rounds is provided with Delphi expert key which is a unique identifier within the class of distinguished open source expe1is. The expert keys have assisted in masking the name identity of Delphi open onion validation participants in order to avoid group influences and bias. The names and contacts of the Delphi open onion validation experts are therefore made confidential as the survey did not indicate to the experts (in survey questionnaires) that their identity would be disclosed to the public. Appendix F is the list of participated experts together with their affiliations; using the Delphi expert keys as identification names of each of the Delphi open onion validation experts. 7 .2.1. Delphi Round-1: Initial survey The first round as suggested by Helmer (1983) is to begin a Delphi study with an open ended question as a way of defining and identifying potential subject matter which would be expatiated upon in subsequent questionnaires. The first round in the open omon model validation as attached in the Appendix G (No. l) is in three parts. The first part constituted of a brief introduction to the concept of onion models of open source by providing comparative evaluation Table 5.3 on previous onion models of open source and our newly proposed open onion model. This was fo llowed by a brief survey designed to collect some demographic data on the participants; along with confirmation of the availability of participants to take part in all fo ur rounds of the Delphi validation. In the last part, reward of letter of appreciation as an open source Delphi expert was clearly indicated and one open-ended question was asked thus: "In your own op inion and based on your experience, would you agree that op en source development is onion structured?" 198 The survey was sent out to participants as an open office document ( odt) fo rmat attachment via electronic mail. Over 30 experts were contacted through electronic mail for the validation purposes; however a total of 14 experts eventually responded to the Delphi open onion round-I validation survey. 7.2.2. Delphi Round-2: Questionnaire One: Based on the responses obtained from the initial survey, open onion model validation was conducted on each layer of the onion. Since the proposed open onion model is five layered, the Delphi round-2 validation consists of five parts. The five parts of this open onion Delphi round two are based on validating each of the layers of the open onion model: Initiation layer, Maintenance layer, Developer layer, Us er Layer and external Layer as shown on the attached Appendix G (No 2). Twelve parameters were evaluated in the initiation layer after asking a general question on the relevance of the initiation layer to the onion model of open source development. Eight parameters were evaluated for the developer layer after seeking experts' opinion on the relevance of the developer layer to the open source development. At maintenance layer, as done for the previous layers, expert opinion on the relevance of the maintenance layer within open onion development was sought, it was fo llowed by thirteen fundamental survey questions on the maintenance layer activities. Eight survey questions were generated for the user layer and it was preceded with a general question on the relevance of user layer to the open onion model development. The External layer was also developed in same manner. After identifying the relevance of the external layer to the open onion development, a twelve question survey was presented on external layer of the open onion model validation. Across the layers of the open onion model validation phases, the survey questions capture both the characteristics as well as the proposed parameters being 199 validated at each layer. For instance, at external layer, the characteristics being surveyed are: • "Does a user at ex ternal layer usually make contributions to the source codes? " • "At external layer, open source users download only the source codes without contributing to the open source project development". The surveyed external layer parameters are download volume, topics covered, Natural Language support, license typ es, number of project fo rums, fo rum messages and project age ". The overall open onion parameters were earlier generated base on results of the analysis of case studies as presented on Table 4.13. 7 .2.3. Delphi Round-3: Questionnaire Two The open source user satisfaction metrics were being validated at the Delphi round-3. Based on the parameters evaluated and selected by the experts in Delphi round-2, this Delphi round-3 seeks to identify the actual parameter(s) being considered fundamental to the open source user satisfaction metrics. Four parameters were evaluated in Delphi round-3 as shown on Table 7.6 and they are: open source project age, development status, download volume, project fo rums and fo rum messages. Appendix G (No 3) shows the detailed questionnaire fo r this round. 7.2.4.Delphi Round-4: Questionnaire Three The Delphi final round-4 features the diagram of the open onion model for clarity of description, along with the brief descriptive table on each layer of the open onion model. Open onion validation parameters were revisited in a tabular fo rmat showing relevant parameters for each layer of the onion model. 200 This round seeks the experts' opinion on the overall open onion model in some fo rm of positional statements that shows the stand-point of each of the open source experts on the validation of the open onion process model as well as their consensus on the key factors influencing the open source user satisfaction. Appendix G (No 4) shows questionnaire 3, which is the main content of round fo ur Delphi open onion validation phase. 7.3. Delphi Validation Results and Analysis In this Delphi validation fo urteen experts responded positively to the initial Delphi round- ! survey. Out of the fo urteen, eleven experts took part in the second and third rounds of Delphi while ten took part in the last round of the Delphi. The validation was performed in fo ur rounds and the results are discussed in subsections of this section of the thesis. 7.3.1.Delphi Round-1 Results (14 respondents) In this round, the demographic details were obtained on the experts. Delphi open onion validation experts' availability levels were sought. After describing a general review on the previous onion concepts in open source, a concrete open ended question on experts' views on the degree of agreement/disagreement of open source experts on the onion structures of open source was asked. Table 7.2 below shows the results obtained from this Delphi round- ! open onion validation survey. 201 Table 7.2 Delphi Round 1: Initial Survey ' Instruments Options Score %Score Open source development is indeed onion Yes 14 100% structured No (Not at all) - NA Experts Availability for the Delphi rounds Round I 3 21% All 4 rounds 11 79% 1 No of votes outof 14 expetts who patticipated in Delphi round I Table 7.3 Delphi Round 1 Onion Layers Survey Instrument Frequency of responses to the options (out of 11) Analysis Do you think these layers are Yes No Can't say Yes Score %Yes essential to the open source development process? Initiation layer 8 I 2 8/9 89% Developer layer 10 0 I 10/10 100% Maintenance layer 9 2 - 9/11 82% User layer 9 2 - 9/1 1 82% External layer 5 4 2 5/9 56% 7 .3 .2 . Analysis of Delphi round-1 results All respondents agree to the fact that open source is onion structured (14/14 agreed to YES) while none of the experts choose a No response. On the availability of the experts; three Delphi open source experts who eventually declined after Delphi round- 1 validation had earlier declared their un-availability beyond the round- 1. 202 Eventually, Delphi Round-! experts' respondents are 14 while Delphi Round-2 through Round-4 validation experts is 11 respondents which are in correlation to the results obtained on Table 7.2. Table 7.3 reveals the results of a survey on the relevance levels of each of the proposed open onion layers. Result shows that 89% of the experts show their support in fa vor of project initiation layer, I 00% accept the relevance of developer layer, 82% supports the relevance of maintenance layer, 82% also support the relevance of user layer and only 56% support the relevance of external layer. At the external layer on Figure 7.3, only 56% of the respondents agree to the relevance of the external layer while substantial percentage of experts have agreed to the relevance the other layers. For example, 100% of the experts agreed to developer layer, 89% have voted their support for initiation layer, 82% voted fo r user layer while 82% also voted fo r maintenance layer. This research therefore infers from the results of initial survey on relevance of external layer (56%) on Table 7.3 that more efforts need to be channeled toward looking beyond the open source development within the developer/user phenomenon. The climatic environment in which the open source development is being initiated is of high importance. For instance, there is the need to ascertain that the environmental factors, such as government policies, political instability and availability of infrastructures which could affect the initiation of an open source project of high user satisfaction goals are 'stabilized'. However, at this point, the environment refers to the geographical location where the open source project is being initiated and this is considered the 'domicile terrene for an initiated open source project to flourish' in thesis. For example, Ubuntu is an ethical concept of African origin by Mark Shuttleworth while Fedora originated from Warren Togami in Hawaii. Details on Ubuntu and Fedora Linux distributions could be obtained from (AI Housani et at., 2009; Cortada, 2002; Payette and Lagoze, 2009). 203 In Raymond (1999) the description of the open source development such as Linux was likened to a 'Bazaar' while that of commercial software development was likened to a "Cathedral". Based on the 56% expert support obtained on Table 7.3, it could also be inferred that high in the determinant of the relevance of external layer is the identification of the software market populace that would continue to fledge support for open source development phenomenon on a large scale; otherwise the relevance of the 'Bazaar ' may be hijacked by the dominant 'Cathedral ' (see list of acronyms on page viii). The remaining rounds of the Delphi validation cut across all layers of the open onion as only one round of Delphi survey is not enough to conclude that the external layer is totally irrelevant. Therefore, the Delphi round-2 validation survey, Section 7 .4, covers all the five layers of the proposed open onion model including the external layer validation. 7.3.3.Round-2 Results (11 Respondents) This round validates each of the five layers of the open onion model. It is conducted in three parts (Parts A, B and C). In Part A, the instrument used was that the essentiality and relevance of each of the proposed layers (initiation, developer, maintenance, user and external layers of the open onion.) was inquired. Part B identifies and examines the various parameters and attributes which need to be considered in each layer of the open onion model. The result is shown in Table 7.4 below. Basically there are 3 options, Yes (if this attribute should be considered), No (if this attribute should not be considered) and can't say (if undecided about inclusion/rejection of this attribute) while in Part C, the respondents were allowed a freedom to express other attributes which they considered necessary for each layer of an open source project that have not been considered in the previous sections of the survey. 204 Table 7.4 Delphi Round-2 Result for Project Initiation Layer Open Onion Instruments (Attributes and Yes No Can't Layers Characteristics) (out of Say 11) Project Initiation Project Properties such as: Layer Project name/ Topic e.g. CMS, operating 7 4 system or ERP Project Url: Accessibility to project for 9 2 ease of contribution License type e.g. GPL, MPL 10 1 Programming Language Support e.g. Java 1 l Domain audience e.g. end user 7 4 Project initiators' Profile: Educational background of open source 3 8 project initiator Prime occupation of open source project 4 7 initiator. No of open source development 4 7 contributed to by initiator Position held in those projects' community 4 7 Leadership skill of the project initiator and 8 3 ability to learn from others Ability to build support for the project 11 And ability to avoid fatal errors such as 11 unclear goals, difficultyin understanding people, underestimating people, fo cusing on code only and fa ilure to build a community 205 All the Delphi open onion validation participants (1 1 experts) have agree to the fact that ability to build support fo r the project being initiated as well as ability to avoid fatal errors are highly required fo llowed by project initiator's leadership skill with inherent ability to learn from others. Detailed analysis of Delphi round- ! initiation layer is provided in Section 7.3.4. (i). Table 7.5 shows that the developer layer validation was performed by soliciting the requirements for developer contributions as well as developer attractions towards an open source project; based on the previously proposed open onion layers' parameters on Table 4.13. It was observed from the experts' opinion that previous programming skills and softwaretesting skills are highly supported by 10 out of the 11 experts who participated in this round. Project publicity, clear communication channels as well as programming language support are also considered highly essential based on the results on Table 7.5. Detailed analysis of Delphi round-2 developer layer is presented in Section 7.3.4 (ii). Table 7.5 Delphi Round-2 Result for developer layer Developer Requirement for developer contribution Yes No Can't Layer Say Project publicity and Task list 9 2 Clear communication channel 9 2 Previous programming experience 10 1 Software Testing Skills 10 1 Open source Developer attraction Programming Language Support 8 2 1 Operating System support 6 4 I License type 7 3 1 Topics Covered 7 3 1 206 Maintenance layer was validated on Table 7.6. The respondents were requested to tick the answers of their choice on the relevance of development of maintenance plan as well as the maintenance layer parameters earlier proposed on Table 4. 13. A very large portion of the validation questions were positively responded to in the maintenance layer. For example, I 0 out of 11 Delphi experts agree on the opinion that open source maintainers do develop and test codes, commit codes and these 10 experts support that programming language, operating system support and bug open are the watch processes which are highly relevant to this layer. Analysis of the detailed result of maintenance layer validation is presented in Section 7.3.4 (iii). Table 7.6 Delphi Round-2 Result for maintenance layer Maintenan Development of maintenance Plan Yes No Can't ce Layer Say Develop and test codes 10 1 Problem discovery 9 2 Identify optimal solution 8 3 Present code changes fo r review 9 2 Discover new functions required 9 2 Document code changes to repository 8 3 Commit code 10 1 Maintenance Layer Parameters Project administrators 8 3 Programming Language 10 l Operating System support 10 l Percentage of bug open 10 1 Percentage of CVS commits 9 2 207 At user layer, Table 7. 7, it was observed that an open source user would like to join open source community, make contributions and download the open source software based on the responses from the 1 0 Delphi open onion validation experts who took part in the Delphi round-2. Detailed analysis of the results obtained from the user layer validation is presented in Section 7 . 3 .4 (iv). Table 7.7 Delphi Round-2 Result for user layer User Layer User characteristics Yes No Can't Say Surfs the internet for open source project 9 2 Join open source community fo rum 9 2 Make contributions to open source projects 10 1 (e.g. post bugs and sends features requests) :--... 1' . \ r;> > . � �- ., . Downloads and uses the software 10 1 ' . '\ .. �y . ' User Layer parameters \ - 1'�( ; 1Ff-': .·' ;· I) User Interface 8 2 1 \\.f k, - Domain Audience 8 2 1 - �. � ll -I Topics Covered 8 2 1 Natural Language support 8 2 I License types 6 4 1 Validation results at external layer are presented on Table 7.8. Following the low level of relevance attached to the external layer in the Delphi round- 1 as shown on Table 7.3 which shows a very low (56%) result as compared to the other layers, the results for Delphi round-2 on the external layer has revealed that only the license type and download volume should be considered necessary while the experts' opinion shows that Natural language support, No of fo rums and Forum messages are 208 of no relevance at the external layer as shown on Table 7.8. Analysis of the Delphi round-2 external layer resultsis presented in Section 7.3.4 (v). Table 7.8 Delphi Round-2 Result for external layer External layer External layer characteristics Yes No Can't Say Surfs the internet for open source project 6 2 3 Joins open source community forum 6 I 4 Does not join open source community forum I 7 3 Downloads source codes 6 2 3 Make contributions to open source projects 5 2 4 (e.g. post bugs and sends features requests) Does not make contributions to the open 4 4 3 source project External Layer parameters Download volume 7 1 3 Topics covered 5 4 2 License types 8 2 1 Natural language support 3 2 6 No of forurns 3 5 3 Forum messages 3 5 3 Project age 5 3 3 7.3.4.Analysis of Delphi Round-2 Results In this section, the percentage "YES" responses to various elicited questions are of high importance. Discussion on the level of consensus reach by the totality of the Delphi open onion validation experts is captured with percentages of responses to varying degree of questions in the Delphi round-2. This section details the analysis of 209 validation results across each of the five layers of the open onion process model. The instrument is designed such that fo r each layer, survey is conducted for the proposed properties/profileof the layer as well as the validation of the parameters associated with the layer. Results of part con the open ended question reveal that: (i) Initiation layer Delphi round-2 results show that fo r open onion initiation layer (Table 7.9), proj ect programming language support takes the highest 100% vote fo llowed by the consideration for the project license type (91 %) and 82% suggested that project accessibility to the public fo r ease of contribution is fundamental to initiation of an open source project. The least factor within this range is the project topics covered (61 %) which may imply that irrespective of the topics covered, the right way to initiate a project is not influenced by the type of topics being covered by the project. The convergence of opinion of the expe1ts on the project initiators' profile shows support 100% vote fo r the initiator's ability to build support for the project and 100% consensus on the initiator's ability to avoid fatal errors such as unclear goals, difficulty in understanding people, underestimating people, fo cusing on code only and failure to build a community. However, the project initiators' leadership skill and ability to learn from others shows high support of 71% from the Delphi open onion validation experts. Invariably, other components of the project initiator's profile being survey have received very negligible vote. For example, educational background of open source project initiator (27%), the prime occupation of open source project initiator (36%), No of open source developments initially contributed to by initiator (36%) and the position held in those projects' community (36%). Further discussion on the implications of these results is presented in Section 8.5. 210 Developer Layer Table 7. 10 shows that analysis of Delphi round-2 on the developer layer of the open onion model. Consensus of experts show support fo r the developer contributions' requirement in terms of open source developers possessing software testing skills (91 %) and having previous programming experiences (91 %). Interestingly, open source developers are said to reckon with proj ects whose project publicity is prominent (82%) and whose developer communication channels are clear and easy to use (82%) as shown on table 7.1 0. The open omon developer layer parameters being validated programming language, topics covered operating systems and license types. Consensus of 80% of experts show support fo r relevance of programming language which is being supported by the proj ect while a substantial vote of 70% of experts show support fo r License types and topics covered by the proj ect. Interestingly, only 60% show support fo r operating system to which the project support. 211 Table 7.9 Analysis of Delphi Round-2 (open onion initiation layer) Yes Open Onion Instruments (Attributes and Can't YES %Yes No Layers Characteristics) (out of Say Vote responses 11) Project Project Properties such as the Initiation parameters below: Layer Project name/ Topic e.g. CMS, 7 4 711 1 64% operating system or ERP Project Uri: Accessibility to project 9 2 9/ 11 82% fo r ease of contribution License type e.g. GPL, MPL 10 l 10/1 1 91% Programming Language Support e.g. II l 100% Java Domain audience e.g. end user 7 4 7/11 64% Project initiators' Profile: Educational background of open 3 R 311 1 27% source project initiator Prime occupation of open source 4 7 4/1 1 36% project initiator. No of open source development 4 7 411 I 36% contributed to by initiator Position held in those projects' 4 7 4/11 36% community Leadership skill of the project 8 3 811 1 73% initiator and ability to learn from others Ability to build support for the II NA 11/1 1 100% project And ability to avoid fatal errors such 11 NA 11/I I 100% as unclear goals, difficulty in understanding people, underestimating people, fo cusing on code only and fa ilure to build a community 212 Table 7.10 Analysis of Delphi Round-2 (open onion developer layer) Yes 0/o Open Onion Instruments (Attributes and Can't YES Yes No Layers Characteristics) (out Say Vote respo of 11) nses Developer Requirement for developer Layer contribution Project publicity and Task list 9 2 9/1 1 82% Clear communication charmel 9 2 9/ 11 82% Previous programming 10 I lOII I 91% experience Software Testing Skills 10 I 10/1 1 91% Open source Developer parameters Programming Language Support 8 2 I 4/5 80% Operating System support 6 4 I 3/5 60% License type 7 3 I 7/10 70% Topics Covered 7 3 I 7110 70% This shows that contribution of open source developer to an open source project is not usually influenced by the type of operating system being supported by such a project. Further discussion on the implication of the developer layer results is presented in Section 8.5. The open onion developer layer parameters being validated programming language, topics covered operating systems and license types. Consensus of 80% of experts show support for relevance of programming language which is being supported by the project while a substantial vote of 70% of experts show support fo r License types and topics covered by the project. Interestingly, only 60% show support fo r operating system to which the project support. 213 Maintenance Layer Delphi round-2 validation analysis of the open onion maintenance layer is presented in this section. Table 7.11 shows a summary of the analysed results. Survey on the necessity to develop maintenance plan was first conducted prior to the validation of maintenance layer parameters. Result shows that high level of activities being performed at maintenance layer is to develop and test codes ( 100% consensus of experts on this particular point) and 91% consensus on code commit as evident from the Table 7.11 However, 82% of experts agree to the fact that other essential activities being performed at maintenance layer are problem discovery, presentation of code changes for review as well as discovery new functions while 71% of experts agree that identification of optimal solution and documenting code changes to repository essential to the maintenance of the open source development project. On the maintenance layer parameters, 91% of the experts come to terms with the fact that programming language, operating system support and percentage of bug open essential parameters that need to be considered at this layer. However, 82% of experts say that percentage of cvs commit activity is a watch word at the maintenance layer while 73% of experts agree to the fact that consideration of number of proj ect administrators is indeed essential in validating maintenance layer activities of open source development as shown on Table 7.11. 214 Table 7.11 Analysis of Delphi Round-2 (open onion maintenance layer) Open Yes %Yes Instruments (Attributes Can't YES Onion No response and Characteristics) (out of Say Vote Layers 11) s Maintenan Development of ce Layer maintenance Plan Develop and test codes lO NA 1 1 100% Problem discovery 9 2 9/11 82% Identifyoptimal solution 8 3 8/11 73% Present code changes for 9 2 9/ 11 82% review Discover new functions 9 2 9/11 82% required Document code changes to 8 3 8/11 73% repository Commit code 10 1 10/1 1 91% Maintenance Layer Parameters No of Project 8 3 8/l l 73% administrators Programming Language 10 1 l0/1 1 91% Operating System support 10 I 10/11 91% Percentage ofbug open 10 I 10/1 1 91% Percentage ofCVS 9 2 9/11 82% commits 215 User Layer The validation results for the user layer of the open onion process model are discussed in this part of the thesis. Table 7.12 shows the summary of the analysis of experts' consensus on the user layer characteristics as well as user layer parameters. Table 7.12 Analysis of Delphi Round-2 (open onion user layer) Open Yes %Yes Instruments (Attributes Can't YES Onion (out No respon and Characteristics) Say Vote Layers of 11) ses User User characteristics Layer Surfs the internet for open 9 2 9/ 11 82% source project Join open source community 9 2 9/1 1 82% fo rum Make contributions to open 10 1 1 100% source projects (e.g. post bugs and sends fe atures requests) Downloads and uses the 10 1 10/1 1 91% software User Layer parameters User Interface 8 2 1 4/5 80% Domain Audience 8 2 1 4/5 80% Topics Covered 8 2 1 4/5 80% Natural Language support 8 2 1 4/5 80% License types 6 4 1 3/5 60% 216 Result shows that 100% of experts' consensus point at open source users being characterised by their ability to make contributions to open source projects (such as post bugs or request for more features). However, 91% of experts say that an open source user would like to download and use the open source software (not necessarily working with the source codes). Interesting results (82% experts' consensus) also show that most open source users do get the open source projects by surfing the internet specifically to get the software or by joining an open source community fo rum in order to gain access to the software (and some ad-on whose access might not be grated to none members of the forum). On the user layer parameters, quite a high consensus is reached (81% of experts) on the necessity to include such parameters as user interfa ce, domain audience, topics covered and natural language support in the essential parameters of consideration at the open source user layer. However, only 60% of experts consider license types necessary at the user layer parameter validation. External Layer Open omon external layer parameters were being validated by first identifying the expert opinion on the possible characteristics that could be attributed to the external layer of a given open source project and next was the open onion external layer parameter validation. Table 7.13 fe atures the responses to the Appendix G (No 2) on externallayer validation subsection. Result shows that the mostly observed characteristic at external layer was the prominence of growth of the open source project community fo rum. 86% of the experts are of the opinion that external people would like to join an open source _ community fo rum. 75% of experts agree that at external layer the external "community" surfs the internet fo r open source project and download source codes (for reasons beyond the scope of this research - possibly fo r personal use and reuse, 217 for modifications suitable for commercial reasons or fo r purpose of improving the source codes). Table 7.13 Analysis of Delphi Round-2 (open onion external layer) Open Yes %Yes Instruments (Attributes Can't YES Onion No respon and Characteristics) (out Say Vote Layers of 11) ses External External layer layer characteristics Surfs the internet for open 6 2 3 3/4 75% source proj ect Joins open source community 6 I 4 617 86% forum Downloads source codes 6 2 3 3/4 75% Make contributions to open 5 2 4 517 71% source projects (e.g. post bugs and sends fe atures requests) External Layer parameters Download volume 7 1 3 7/8 88% Topics covered 5 4 2 5/9 56% License types 8 2 1 4/5 80% Natural language support 3 2 6 3/5 60% No of forums 3 5 3 3/8 38% Forum messages 3 5 3 3/8 38% Project age 5 3 3 5/8 63% 218 However 71% of the experts' opinion tends towards an indication that people the external layer would make contributions to open source projects (e.g. post bugs and sends fe atures requests). The open onion external layer parameters were also validated as evident from Table 7.9. Results showed that the most relevant parameters are download volume (88% of experts' consensus) and license type (80%). 7.3.5.Delphi Round-3: Open Source User Satisfaction Survey There were 11 respondents during Delphi round-3 validation survey. Based on the responses of the Delphi round-2, a survey of the open onion user satisfaction metrics were specifically embarked upon in the Delphi round-3 validation phase. Table 7.14 shows the results of the analysis of the Delphi round-3 questionnaire as attached on Appendix G (No 3 ). Results on Table 7.13 shows that download volume is an essential parameter at the external layer. However, as evident fo r Table 7 .14, user satisfaction within open source development tends to increase with projects with fewer bugs open and high bug closed. Results also indicate that open source user satisfaction is indeed not dependent on project age. 219 Table 7.14 Delphi Round-3: User Satisfaction Survey User Satisfaction Analysis Yes % SIN lnstrument Vote Yes Project age Users are likely to be more satisfiedwith projects existing for at least 1 3/11 27% 5years Users are likely to be more satisfied with projects existing for 2 NA > 1 0years Users are likely to be more satisfiedwith projects existing for 3 NA >15years Users satisfaction with open source projects does not depend on 4 9/11 82% project age Development status Users are more satisfied with projects in their alpha/beta status by 5 NA contributing Users are more satisfied with projects with stable/unstable status by 6 4/ 11 36% contributing Users are more satisfied with projects in their mature status by 7 1/1 1 9% contributing Users are more satisfied with projects in any development status by 8 4/11 36% contributing Users satisfaction does not depend on project maturity in terms of 9 4/ 11 36% development status Download volume Users' satisfaction of open source project can be measured by 7/1 1 36% download volume. Users' satisfaction ofopen source project cannot be measured by 10 7/1 1 64% download volume. Project Forums and forum messages are performance indicators of user satisfaction in open source development project User satisfaction gets higher with projects having fe west bug open 11 10/1 1 91% and high bug closed User satisfaction gets higher for projects with high bug open and low 12 1/1 1 9% bug closed 220 7.3.6.Analysis of Delphi Round-3 Results Negligible is the importance attached to project age as a metric to measure open source user satisfaction. There is consensus of opinion on the same level of importance (low importance level) attached to project status. Only 36% of experts agree that users are more satisfied with projects with stable/unstable status by contributing, 36% also agree that users are more satisfied with projects in any development status by contributing and equaily 36% agree that users satisfaction does not depend on project maturity in terms of development status. This shows clearly that the user satisfaction of open source project does not depend on project maturity (development status attained by the project). Results with individual parameter evaluation shows high importance of download volume (88% of experts agree) at the external users of open source project. Open source user satisfaction definitely gets higher (91% of experts agree) for projects with fewest bug open and high bug closed as shown on Table 7.14. The download volume as a measure of user satisfaction was also validated. Though not as high as the results obtained at external layer validation (Table 7.13), 36% of experts are of the opinion that users' satisfaction of open source proj ect cannot be measured by download volume as observed on Table 7 .14. Interestingly, quite a number of researchers have identified download volume as a yardstick for project popularity (Crowston et al., 2003; Lee et al., 2009). In this research, project use is measured from download volume. It is a clear fact that not all downloaded projects are used. However, in Lee et al. (2009) it was reported that the user satisfaction is having significant effect on the project-use, where use is measured based on project publicity. In Stewart and Ammeter (2002), project popularity was based on the number of people who subscribe to the project as well as hits to the Website; this is considered synonymous to the tracking the download volume which was used this research. 22 1 Therefore, the popularity of open source project was obtained from the validation at external layer (Table 7. 13) of the proposed open onion model in which it shows the relevance of high download volume in practical terms at external layer. Based on these results, this research is convinced that download volume is still a relevant parameter to measure user satisfaction together with high percentage bug closed (meaning low percentage bug open) as supported by 91% of the Delphi experts opinion as supported by evidence on Table 7 .14. Detailed discussions on the Delphi round-3 validation is reported in Section 8.5 7 .3.7. Delphi Round-4 (11 Respondents) In this round, an open ended question was asked on the assessment of the experts on the open onion model, as a way of getting their consensus on the suitability and usability of the model as well as gather feedbacks on the shortcomings of the model. Results show that quite interesting and encouraging comments were gathered from the Delphi experts on the open onion validation. The expert keys were used as identifying names since the survey did not get their consent on disclosure of their identity to the public. Table 7.15 features the experts' key identities and their Delphi round-4 responses which are reported as captured from the expet1s' submission obtained from the Delphi round-4 survey questionnaire as attached on Appendix G (No 4). Expert key and affiliation Delphi round-4 validation comments are presented as fo llows: 222 Table 7.15: Delphi round-4 Experts' Responses DelphiOOEVLElO:(F-Secure Antivirus Malaysia) "Good" DelphiOOEVYJtl (Multimedia University, Malaysia) "I like this model" DelphiOOEVNK12 (Redboot Solutions, Malaysia) "Clear indication of processes and participation layers" DelphiOOEVJH2: (Carnegie Mellon University, Pittsburgh) "The open onion Layers are a good description motif to talk about levels of engagement and roles within open source projects. It is also a good idea to separate measures for understanding each different type of role. However it seems a stretch to me to say that Forurn_messages is relevant to the external layer but not the developer layer; what if developers use fo rums to talk to each other? How can one know that in general, when projects have such different practices? It also seems strange to me to me that each measure only appears once; for example I don't see how downloads volume (adj usted for number of releases) would not be relevant to roles other than Users; some developers are motivated by download numbers, and it's definitely. relevant for the recruitment of new developers. I think this model should be tempered with an acknowledgement of its limits DelphiOOEVAQT4 (MIMOS Berhad, Malaysia) "The OPEN ONION model development is a good choice as it segregates responsibilities and eases management in different types of software projects. It can be used by the open source community to manage projects and can be beneficial fo r long term projects. It is an interesting approach and might solve the problem of overlapping responsibilities and interference into other domains by some members in the project. 223 DelphiOOEVMEGS (MediaMix Asia Sdn Bhd, Kuala Lumpur, Malaysia) ..Open onion model maps the onion layers to real life situations very closely. Though when I first read the title I was wondering "what a name?!", but after participating in all three rounds, I can say that It does actually match reality and yes, it makes sense. I have a small comment on the user layer, it mentions the License as one of the parameters, However, I strongly believe that "normal users" do not know and do not actually care about licensing types, what comes to their minds when talking about open source "if they know what is open source" is that it's FREE. Overall, the survey was unique, systematic, and informative DelphiOOEVEY6 (Novell Software, Malaysia) "There must be a benevolent dictator to direct the affairs and boldly take responsibility for success/failure of the project. This model assumes funding is a non-issue; money must come from someone /somewhere! Please do not neglect funding in future research!" DelphiOOEVNS7 (Century Software, Malaysia) Successful floss projects tend to have two things: A dictator and an open page for open issue tracker system. Dictator within the open source project is highly necessary" DelphiOOEVTH8: (Fireworks Solutions, Malaysia) "Quite an interesting model, I haven't seen any other model similar to this" DelphiOOEVMI9: (INIGO Consulting, Malaysia) Layer A, 8, D and E do apply more to floss projects. However, the maintenance layer will need improvement on the group of people categorized under it. Release coordinator and maintainers are more in the leadership of developer layer. Bug fixers are also usually the people in developer layer themselves DelphiOOEVMM13 (Android Expert, Commonsware, USA) "Is there an onion model? Possibly. I disagree with the division and sequence of the layers." 224 7 .3.8. Analysis of Delphi Round-4 Results Eleven respondents took part in the Delphi round-4 (final open omon validation round) open onion validation. Interesting comments were obtained from the Delphi round-4 open ended question requesting fo r experts' comments on the open onion process model. Consensus of the experts has pointed at the open onion model being a good model such as in responses from DelphiOOEVJH2 and DelphiOOEVAQT4. Of particular importance was the consensus on the fact that the open onion process model indicates clear segregation of layers and processes (DelphiOOEV AQT4 and DelphiOOEVNK 12); the issue of high level of uniqueness of the open onion model was also mentioned by DelphiOOEVTH8 and DelphiOOEVMEG51; while the Delphi round-4 result also clearly shows that open onion process model could help in solving the problems of overlapping responsibilities as well as interference (by some open source domain experts) into other domains by some members within the open source development project (DelphiOOEVAQT4). The open onion process model was described (DelphiOOEVJH2) with an indication that the layers are a good description motif on the levels of engagement and roles within open source projects; while it was observed that the open onion has provided good idea in separating measures fo r understanding different type of roles. The consensus on the sensibility level of open onion process model shows that the open onion model maps the onion layers to real life situations very closely adding that the model makes sense (DelphiOOEVMEG5). Detailed discussion on the Delphi round-4 is presented in Section 7.4 CHAPTER S RESEARCH FINDINGS This research establishes that open source development is indeed onion structured. After extensive literature review, this research observed that the use of onion in describing the process of open source development was frequent in literature. Majorly, open source onion descriptions are prominent in literatures such as Crowston et al. (2004), Herraiz et al. (2006), Antikainen et al. (2007) and Kumiyo et al. (2002). Results obtained from the open source onion literature reviews reveals that the understanding of what activities goes on within each layer of the open source onion models were not clarified. It was also observed that inability to understand the details of the open source development activities would hamper the open source in two ways according to Raymond (1999); it will be difficult to think systematically to improve the open source process and it also becomes difficult to teach the open source process to others. This research has improved the understanding of open source development and it has made it clearer, based on segregation of overlapping open source development activities into layers, how to teach the open source development process. This was achieved by various phases which were embarked upon in this research. First, case studies were selected from ten highly ranked open source development projects on SourceForge and activity data were extracted for each of the case studies. Based on the analysis of the case studies, the proposed open onion model was evolved. Evolution of the open onion model was presented in Chapter 5 and various diagrams were used in describing each of the layers of the model. The 226 use of diagrams in analysis and design of a system is highly imperative as suggested by Jungpil and J inwoo ( 1999). Detailed findings on Case Studies are discussed in Section 8.4 of this Chapter Extensive statistical evaluation of the open onion model was carried out based on the case studies activity details which were earlier extracted from SourceForge repository. The activities were regrouped by segregating possible relevant parameters across each layer of the open onion model as presented on Table 4.13. The open onion model was statistically evaluated based on the proposed parameters (the parameters were later subjected to Delphi 's validation). Statistical evaluation was performed on the activity data obtained from the l 0 highly ranked projects case studies obtained from SourceForge and verified with the results obtained from the analysis of case studies from 1104 Flossmole projects as presented in Chapter 6. The detailed findings on statistical evaluation are discussed in Section 8.3 of this Chapter. It is highly imperative to mention very important infetTed principle. The Pareto principle of 80/20 rule is prominent in the open source development community settings. This was observed from the results obtained from the case studies activity details on SourceForge as presented on Table 4.14 as discussed in Section 8.1. Delphi's open onion validation has also revealed valuable results which are discussed in details in Section 8.5 8.1. The Pareto principle in Open onion This research establishes that the overall open source development efforts are not far from the Pareto principle of 1935. Borrowing from the concept of Pareto law as applied by other researches on software development such as Anderson and Runeson (2007); Fenton and Ohlsson (2000); Gittens et al. (2005); Hongyu (2008); Iqbal and Rizwan (2009) and Ling-Ling et al. (2009), the open onion reveals the 227 evidence of the phenomenon of Pareto principle on the overall open source development structure. A critical analysis of the case studies, as presented in the summary on Table 4. 14, shows that very fe w but vital people (The core - project initiator /administrators/ owners) of 19% actually controls and oversees the affairs that are carried out by the many (maintenance, developers, users and external layers) of about 81%. This is closely at par with the 80/20 rule of Pareto principle. This research therefore concludes that 80% of open source project members are actually controlled by 20% of the core members. 8.2. Open Source User satisfaction metrics The statistical SQA in open source application has led to the intuitive motivation towards the development of open source user satisfaction metrics. This research assumes and states that the open source user satisfaction is the major metric for measuring "Open Source Quality". The open source user satisfaction metric which was presented in Definition 5.1, was validated at external layer of Delphi round-2 validation in Section 7.3.4 and Delphi round-3 user satisfaction validation, Section 7.3.5. Based on the analysis of the Delphi experts' opinion, the open source user satisfaction metrics depend on two parameters: Download volume and high percentage bug closed. Experts vote 88% support for download volume at external layer on Table 7.13 while there is 91% vote of support for high percentage (%) bug closed on Delphi round-4 validation ofTable 7.14. This research therefore concludes that high download volumes together with high % bug closed are the relevant user satisfaction metrics within the open source development projects. This validates the proposed user satisfaction equation of Definition 5.1 in Chapter 5 as recapped below: 228 Open Source User Satisfaction =High Download Vo lume + High Percentage of Bug Closed 8.3. Statistical Evaluation Findings The statistical results gathered were based on the experiment with SourceForge case studies and that of Flossmole projects (2004-2009) are presented in this section. Section 8.3.1 presents the results fo r SourceForge and Section 8.3.2 presents the Flossmole results. 8.3.1.Results from SourceForge Case Studies The ten SourceForge projects under study were evaluated statistically. Result shows that user interface has a negative correlation with domain audience with a high confidence level of 95.9% and the topics-covered has a significantly positive effect on domain audience at a higher confidence level of 96.3%. Domain audience has impact on the project ranking and License type has effect on the project ranking as well. Topics covered have significant effect on domain audience, meaning that the more the topics which are covered, the higher the expected audience resulting in higher project community building. Based on the results obtained from statistical evaluation, it implies that the parameters being investigated are indeed essential. In particular it was observed that some of the parameters are more influential than the others. For example, at initiation layer, result shows that a good enough open source project should address at least 4 domain audiences because the more the domain audiences being supported, the lower the project rank as observed from Table 6.2 and Table 6.3 respectively. It was also observed that such projects need not support more than two prominent programming languages (Table 6.2) such as Java and C++ (Table 4.23). At developer layer it was 229 observed that an average developer is highly particular about the license for which a project of interest is subscribed as shown on the developer/license relationship on Table 6.5. Interestingly, it was observed that the user interface type does affect the download volumes as shown on Table 6.14 where high download volume of 202,377,656.75 is observed for web based user interface as against 13,788,136.67 of Win 32 user interface. At the external layer, it was observed that projects which have reached mature development status are downloaded by about 183% more than projects which are still in their stable release versions as shown on Table 6.17. 8.3.2. Results from Flossmole Projects In order to strengthen the results which was presented in Section 8.3.1, Flossmole project data from 1996-2009 was statistically analysed. The result reveals that 41% of open source projects thrive on Web Environment fo llowed by 15% on Microsoft Windows's environment. After categorizing Unix Admin, Tester, and Developers as Professional coders (Programmers), it shows that 65% of Open source project developments are usually targeted at professional coders while the remaining 35% consist of Document Writer, Graphic/Other Designer, Support Manager and the Undefined are categorized as Unskilled Programmers. However, the result reveals that those classifiedas Professional coders (Programmers) consist of 58% Developer, 2% UNIXAdminis trators and I% Tester. The developers who are classified as Amateur or Unskilled Programmers consist of 19% Project Manager, 16% Undefined, 3% Doc Writer and l% Support Manager. Graphic/Other Designer class are very insignificant with approximately 0.1 %. The result reveals that Production/Stable has 55%, Beta 22%, Alpha 12%, Planning has 5% while Pre-Alpha and Mature both have 3% each. The result shows that only 42% have reached stable released version status while the remaining 58% have not reached stable released version status. This shows that 62.7% of the domain 230 audiences are actually software developers while 17.6% are system administrators and only 19.7% are end-users and others. 8.4. Case Studies Findings In the analysis of the case studies as shown in the details on Table 4. 14, it is revealed that some highly ranked open source projects exhibit the characteristics of all five layers of the proposed open onion model while some other highly ranked projects exhibit only the first fo ur layers characteristics. This is fo llowed from the evidence that it is always possible to find a combination of layers a - layer d with or without out the prominence of the layer e That is, all active open source projects exhibit the characteristics of first fo ur layers of the open onion model but not all exhibit the sth layer characteristics. In this research, the volume of downloads is one of the major metrics fo r measuring the software user satisfaction and also a performance indicator fo r the quality acceptability levels of such software; however the interesting result shows that MinGNU for windows, which has the highest number of downloads of over 20.74 million as well as ScummVM with over 6.7million downloads actually exist without the external layer. These projects (MinGNU and Scumm VM) are shielded from having external fo rums. Although both of these projects have mailing lists which were the major medium of collaboration among the developers, fo rums are vital performance indicators fo r existence of the external layers. As evident from the proj ect details on Table 4.1 0, the MinGNU project has no external fo rum which resulted into not having any fo rum messages. Table 4.7 also shows clearly that ScummVM exists, as a well-ranked open source project (RankS), without any external fo rum and therefore has no posted fo rum messages. This also supports the evidence that sometimes it is difficult to measure open source user satisfaction based on download volume alone 23 1 as shown on Table 7. 14 in which 64% of the experts voted their support for not using download volume alone to measure user satisfaction in open source. On the initiation layer, all open source proj ects would be initiated and administered (core developers/project owners) by about 20% of the overall open source development team. This means that the initiation layer (of Core developers) has its prominence across all active open source projects. This supports the evidence that project initiation layer is mandatory fo r all open source projects. All the projects m the case study also exhibit the developer layer characteristics. Showing and confirming the grandness of the developers who work tirelessly to achieve the success of their 'project at heart '. Referring to Table 4. 14, the large number of developers shows that all open source projects have larger number of developers (about 80% of the overall project development team). working with the project owners and administrators (20% of the core administrator). Therefore, the developer layer is indispensable in an active open source development project. Maintenance layer activities are measured partly by the CVS activities. Results shows that CVS commit activities observed were only 5.95% of the total activities submitted that are committed to the project's CVS at a given point in time. This provides an explanation to the fa ct that it is very tough to get a particular piece of code committed to an active open source project. This therefore provides room for competition and robustness of the software and this intricacy improves the quality of such a software project. However, the existence of the maintenance layer validates and supports the high level of relevance attached to maintenance layers across all the projects under study. Without any doubt, the user layer is necessary as it is an indicator for project acceptance and user satisfaction level. Therefore it is highly prominent across all the projects under study. When the download of a given project is relatively low, then it implies that such a project is not popular. This means that users are not satisfied with 232 the software and this in turn implies that the software is of 'Low Quality'. For the case studies, all the projects have remarkable number of downloads with the highest download of over 20.7 millions of MinGNU and minimum downloads of approximately 338 thousand for SW Test Automation framework. However, analysis of user level satisfaction based on age of open source project reveals that Notepad++ tops the list of relative downloads/age as shown on Table 4.14. User layer existence signifies the importance of the software downloads across open source projects. Interestingly, not all the open source proj ects have external fo rums which is a significant pointer at the existence of the external layer as evident on Table 4.14. This shows that some open source projects are shielded from the external fo ra. As earlier discussed that most researches concludes that the open source development exhibits the onion structure as suggested by Crowston et al. (2004); Crowston and Howison, 2006) and as cited by researches such as (Herraiz et al. (2006); (Kumiyo et al. (2002) and the Linux onion model (Antikainen et al. (2007), this implies that it is possible to notice that active open source project activities are having either all the five layers (initiation, developer, maintenance, user and external layers) or are having only fo ur layers (initiation, developer, maintenance and user layers) both of which are observed during the course of thesis research . Since this rule of projects having fo ur or five layers of the open onion model holds for l 0 active and highly ranked open source projects on SourceForge and most of the unit parametric analysis of Flossmole and SourceForge agree, as shown on Table 6.34, this research therefore generalizes the rule to hold fo r large open source project data such as Flossmole across heterogeneous fo rges. 233 8.5. Delphi's validation findings This research has established that the open source project development is indeed onion-structured. This section discusses the findings on the open onion model validation. The validation was done using Delphi's approach in fo ur rounds. In Delphi round- !, l 00% of the experts' opinion is converged on the agreement that to the onion model phenomenon in open source is ideal. The five layered segregation of the open onion was also agreed upon. At least 82% agreed to layers a, b, c and d as shown on Table 7.3 while only 56% agree to the relevance of the external layer. This result could be explained based on the greater fluidity attached to the open source development environment (Lerner and Tirole, 2002). In open source development environment, external contributors may decide to transfer more of their eff01ts (such as feature request and bug reporting) to a new project environment as there is no firm specific or human capital limits to bond them from shiftingtheir efforts to a new work environment. Secondly, with open source development, there is need fo r increased user involvement by having many developers concurrently involved in the open source project development process, rather than having a commercial software development team within a company (Feller and Fitzgerald, 2002). Since there is no concrete involvement of users at external layer to the active development of open source project, then the convergence of opinion on the relevance of external layer to the overall open onion model is supported. On the Delphi round-2 validation phase, there is strong convergence of experts' opinion at initiation layer on the high relevance of programming language support and project (url) accessibility to project publicity and support. I 00% voted yes fo r the ability of project initiator to build support fo r the project and ability to avoid fatal errors as shown on Table 7.9. It is interesting to note that there is convergence of experts' opinion on the fact that academic qualification does not affect efficiency of being an open source project initiator. 234 Despite the fact that a further analysis of the experts' qualifications (Appendix H i) shows that most of the Delphi open source validation experts used are from computer science background (at least 8 of the experts have computer science, MIS and IT related background), they are of the opinion that academic background is of negligible importance at project initiation layer. This is in line with the fa ct that most of experts used in this survey have been involved in open source development for over 4 years as captured in Appendix F and further analysed in Appendix H ii and it shows that they are highly acquainted with the prominent academic qualifications of other members of open source developer fmums with whom they had collaborated. There is therefore a convergence of opinion that academic qualifications of open source project initiators do not affect the resulting output of such a project as shown clearly on Table 7.9 Virtually all parameters and validation instruments within the developer layer, maintenance layer and user layers are supported as shown on Table 7.1 0, Table 7.11 and Table 7. 12 respectively. However, at external layer (Table 7.1 3), result shows support for every parameter except the natural language support and relevance of fo rum messages at this layer. This still goes in line with the low level of relevance of the external environment to the overall open source development as shown on 7.3 of the Delphi round-! validation. Result of Delphi round-3 validation shows 91% support for the user satisfaction getting high with projects having fewest bug open and high bug closed on Table 7.14 and 36% support fo r user satisfaction being measured with download volume. Based on earlier result on Table 7.13, this research infers that both high download volume and the parameter on high bug closed with low bug open are essential to open source user satisfaction metrics. This shows that the user satisfaction equation of Definition5. 1. The final round of the Delphi validation points at the fact that the open onion model is unique, it separates possible unclear roles, it segregates responsibilities which means it can be used to solve the problem of overlapping responsibilities and 235 that the open onion model is interesting. However there are some comments on the limitations of the model. The areas, which were not considered by the open onion model, that were highlighted as essential components of the open source development process are 1. The acknowledgement of a benevolent dictator, which goes beyond being the project initiator or maintenance, who could always take a stand and whose decision is .final on project development issues and 2. The issue of fu nding is said to be very essential. This is either by voluntary donation or by fu ll fu nding fr om other companies who fledge support fo r the project. While the experts opinion is well appreciated and the specified Delphi rounds have been exhausted (Delphi round-4), the two additional components stated above would be considered in future research on the open onion model. 8.6. Findings on Hypotheses i. Hypothesis 1 (Project Initiation Layer) The Hypothesis I was supported based on the results obtained from the case studies. All open source projects have to be initiated by someone (or a group of some people). The projects need be posted on a website or be registered on open source development platform(s) as discussed in case study findings of Section 8.4; which means that an open source project must be web based. 236 ii. Hypothesis 2 (Developer Layer) Hypothesis 2 which states that the developerse ar highly influenced by programming languages, topics covered and license types. Based on the parameters associated with developer layer as shown in Table 4. 13, the developer layer was statistically evaluated. Result shows that programming languages do not necessarily affect the developer motivation. Table 4.23 concretely reveals that the mostly adopted programming language is Java. This invariably implies that open source developers are usually Java friendly. Therefore, this part of the hypothesis is not supported since programming language does not affect open source developer motivation. On the other hand Developers are highly motivated towards projects which are licensed under GPL as shown on Table 6.5 as against projects with other licenses. iii. Hypothesis 3 (Programming Language vs. Bug Open) Hypothesis 3 states that percentage bug open is highly influence by the programming language, operating systems and number of project administrators. This hypothesis is only slightly supported. Whilethe evidence on Table 6.11 reveals a slight support fo r the Hypothesis 3 in terms of a slight correlation between percentage bug open and programming language support, the combined evidences on Table 6. 10 and Table 6. 11 shows that Hypothesis 3 is generally not supported since programming language does not quantitatively affect the operating system and project administrators. 237 iv. Hypothesis 4 (topics covered vs. domain audience) Hypothesis 4 states that the topics covered are influenced by the domam audience and users are highly influenced by natural language support. This hypothesis is supported by the evidences from statistical analysis presented on Table 6.2 1 in which the topics covered have a positive effect on the domain audience. Table 6.20 also concretely provides support for the second part of this hypothesis in which it clearly shows that natural language supports do in fact, positively affect the open source project fo ra messages. This research therefore shows support for Hypothesis 4. v. Hypothesis 5 (projects age vs. project forum size) Hypothesis 5 is also supported by this research. Table 6.24 shows that proj ect age has a significantlynegative effect on the number of fo ra while Table 6.25 reveals that projects within the age brackets of 7 to 10 years tend to gain more download volumes as against projects whose ages fall below 7 years. This also provides support for the higher project rank which grows with the project age as presented on Table 6. 19. This research therefore provides support for Hypothesis 5. CHAPTER 9 CONCLUSIONS The entry point into this research was the undisputed quest for producing high quality software cheaply and within a reasonable shortest timeframe. This has actually motivated towards further investigation of open source projects in this research. In this Chapter, the overall research activities were summarized, achievements of the research objectives were revealed and the contributions were highlighted. 9.1.Research Summary The comprehensive literature analysis revealed that open source projects, although conceptually the same, do have varying characteristics. some such as Apache are 'fully open' from the initiation till the release status is accomplished while others such as Mysql do not do their development openly since the project is done by staff of the Sun Microsystems. Attempts to have unifying characteristic properties common to the various open source projects have led to quite a number of conceptualized discussions on open source onion models such as Crowston (2003) and Antikainen (2007). Traditional software process models such as Waterfall, Spiral and RAD models were reviewed in order to compare them with the existing open source development processes such as Linux model, Apache and Mozilla development 239 models. Result shows a wide disparity in the traditional software process models and open source model. For example in the rigidity associate with waterfall model and the excessive iterations in the spiral model reveals that they are both not suitable for open source development. The RAD is slightly flexible by releasing prototypes or part of the evolving software (before completion) fo r testing purposes; it is however not suitable fo r open source development since the completed software application is released (often) in open source development model in order to achieve rigorous testing. The details of the case studies were earlier discussed in Chapter 4 together with the activity data which were tracked for the identified parameters within the project details. The case studies was used to evolve the open onion model and the output generated from the case studies in the project summary Table 4. 14 serves as the input into the open onion development in Chapter 5 and statistical experimental evaluation phases of Chapter 6. The results from the experimental evaluation reveals that open onion model could be statistically anlysed with data from homogenous forge such as SourceForge as against its experimental analysis performed on data from multiple heterogeneous fo rges such as Flossmole which contained 10 different data sources as shown on Table 6.26. The open omon model was validated across the layers in fo ur rounds of Delphi. Along with the layered validation of the open onion, validation details were extracted for open onion success tree as well as open source user satisfaction metrics. Result shows that it is highly fundamental for a successful open source project to be handled with a project initiator who possess the ability to learn from others, ability to avoid fatal errors, who has developed leadership and communication skills, and ability to build support for the project. The validation of the success characteristics were inherently performed in the Delphi Round-2 validation for project initiation layer on Table 7.4 under the initiator's characteristics and profile. 240 The outcome of this research therefore significantly provides open source policy makers, developers and open source government adopters with some appropriate guidelines towards understanding the phases within open source development project (initiation, developers, maintenance, users and external) and consequently improving the quality of open source development projects. 9 .2. Contributions Open onion model is a layered approach to open source development. This approach has the tendency to improve the open source development "quality" based on its findings as follows: 9.2.1. The 5-layered Open Onion Model One major contribution of this research is the presentation of open source using open onion model that greatly improves the hitherto inadequate understanding of the various key components of the open source development. According to Raymond (1999), Open source has evolved without any theory to explain why the practice works. The Open onion Model produces an improved understanding of open source activities at each layer of the development stages. Diagrammatical approach was adopted to represent each of the open onion layers; making it possible to visualize each stage in the open source development as an onion layer. Thus making it easier to explain and show how the open source development method works in a simplified maner. The modeling across the layers of the open onion is presented in Chapter 5. 24 1 9.2.2. Open Source Success Tree Open source development is usually described based on case studies; for example in (Mockus et al., 2002). However, Aberdour (2007) shows that it is still very difficult to understand why successfulopen source projects attain high quality. This research provides explanation through the development and validation of open source success tree as well as open source user satisfaction metrics. The open source success tree which was developed in Section 5.5 and validated as presented in Table 7.9 shows that the most important elements of open source project success (especially at initiation layer) are the ability to build support fo r the project (100%), ability to avoid fatal errors (100%) and ability to possess leadership skill (73%). These are unanimously attested to by the open onion validation experts as shown in Table 7.9. 9.2.3.Statistical Quantitative Improvement It is interesting to observe that organisations that want to invest in open source would want to know the estimated amount of required resource to invest in order to achieve necessary deliverables (Jai, 2005). This research points at some of the estimated amount of resources, in terms of the required number of domain audience, expected user interfaces, required topics to be covered and License types as presented on Table 4. 14, which are necessary for a successful open source development project of such high quality ranking. This was achieved through the use of statistical method of quantifying software development process activities since statistical approach to software quality managements is encouraged by Pressman (Roger, 200 l ). In addition, the identification of correlations between the open onion laer parameters largely improves the understanding of the interedependencies among the proj ect activity entities. 242 9.2.4.0pen Source User Satisfaction Metrics The third research objective is to develop open source user satisfaction metrics; this was achieved and a resulting definition fo r Open Source User Satisfaction equation was developed and presented in Section 5.5.1 of this research. While appreciating that 'human' are very difficult to satisfy, the development and validation of open source user satisfaction equation clearly reveals the necessary open source metrics being considered for open source users to be satisfied. The user satisfaction metrics which was developed is as fo llows: Op en source user satisfaction = high download volume + high % bug closed Interestingly, the Delphi round-2 (external layer validation) and Delphi round-3 (user satisfaction validation) showed support for the proposed user satisfaction equation as stated in the equeatiun above. The result however reveals that download volume alone such as in Table 7.13 is not a sufficient parameter to measure user satisfaction as shown in Table 7 .14. However, this research concludes that when high download volume is combined with high % (percentage) of bug closed, the user satisfaction result is better achieved. 9.2.5. Validation of Open Onion Model Based on literature reviews, the previous concepts of open source onion were prominently not subjected to any fo rm of validation as stated by Crowston et al. (2004) where it states: "the onion structure of the open source development teams has good fa ce validity but needs to be extensively tested". 243 This implies that, as at the time of thesis writing, validation of the onion model of open source is a research issue. This is one of the aspects in which open onion model has significantly improved and tremendously contributed to the open source development process. Validation of the open-onion models reveal that indeed open source development is onion structured. Despite the fact that the validation results have been discussed in preceding chapter, it is highly essential to briefly mention some of the interesting responses obtained in the concluding round of the Delphi open onion validation. There is convergence of opinion of the experts on the high level of credibility attached to the open onion model development. The open onion is generally said to be a good model that has segregated the developer duties in order to ensure that overlapping responsibilities are avoided. The open onion model is also said to be a unique model as presented in Section 7.3.7. The various analyses of case studies and have revealed some interesting results. The prominence of Pareto principles of 80/20 was obsereved and some of the research hypotheses were supported by the findings of this research. 9.2.6. Pareto Principles in Open Source Development The analysis of case studies has revealed that very fe w but key people (The core - project initiator /administrators/ project owners) of about 20% actually control and oversee the affairs being out by the many (maintenance, developers, users and external layers) of about 80% of the overall project contributors. The results show support for the application of Pareto principle of 80/20 in open source development as discussed in earlier in Section 8.1. 244 9.3. Future Work There are still some research 1ssues that would need to be addressed in future research. Specifically a further validation could be carried out on other aspects of open source development model as discussed as the fo llows: );> Metrics which were not considered in this research are suggested fo r future studies. For instance, the consideration of the necessity associated with having a benevolent dictator for an open source project team, pros and corns may need to be furtherevaluated. );> The issue of funding and economic viability of open source development model was not considered and would need to be looked into and be researched further. REFERENCES Aberdour, M. (2007) Achieving Quality in Open-Source Software. Software, IEEE 24(1), 58-64. Adempiere, P. (2009) Al Housani, B., Mutrib, B., & Jaradi, H. (2009) The Linux review - Ubuntu desktop edition - version 8.10. Paper presented at the Current Trends in Information Technology (CTIT), 2009 International Conference on the. Andersson, C., and Runeson, P. (2007) A Replicated Quantitative Analysis of Fault Distributions in Complex Software Systems. Software Engineering, IEEE Transactions on 33(5), 273-286. Antikainen, M., Aaltonen, T., & Vaisanen, J. (2007) The role of trust m OSS communities - Case Linux Kernel community. In Open Source Development, Adoption and Innovation (pp. 223-228). Apache 2.0 (2004), The Apache Software Foundation. http://www.apache.org/licenses/ , accessed online on 15th October, 2009 ApacheFoundation. (2004) Apache HTTP Server Proj ect Guidelines and Voting Rules. Apache Foundation. http://httpd .apa che.org/dev/gu idelines.html, Accessed online 2ih January, 2010. 246 Apache-incubate. (2008) Apache Incubation process, Apache-incubator: http: //incubator.apa che.org/, Accessed online 2i11 January, 20 I 0 Apress. (2007) Introducing the Versatile ZK Components. In ZK™ (pp. 29-54): A press. Arun, P. G., and Paul, C. G. (1994) Onion: a methodology fo r developing data dominant systems from building blocks, Proceedings of the conference on TR!-Ada '94. Baltimore, Maryland, United States: ACM. Ashley, B., and Hyunju, K. (2007) A survey on open source software licenses: student paper. J Comput. Small Coli. 22(4), 205-2 1 1. Balmer, M. (2009) IVT BibTeX-LaTeX workshop. Transport Planning Systems, Arbeitsbericht, xyz, IVT, ETH Z\iirich, Z\iirich. Banker, K. D., and Kauffman, R. J. (1992) Reuse and Productivity in Integrated Computer-Aided Software Engineering: An Empirical Study. SSRN eLibrary. Barahona, G. J. M. (2000) A briefhistory of open source: IT Conecta. Barnes, T., Durek T., Gaffney J., A. Pyster (1987) A fr amework and economic fo undation fo r software reuse. Paper presented at the Proceedings, Workshop on Software Reuse and Maintainability. Basili, V. R. ( 1990) Viewing maintenance as reuse-oriented software development. IEEE Software 7(1), 19-25. Basili, V. R. (2007) Measuring Software Systems. In Software Measurement (pp. 301-328). 247 Benyon, D. (1995) Wh ither the life cy cle ? Paper presented at the lEE Colloquium on Integrating HCI in the Lifecycle. Berlecon Research, (2002) FLOSS III: Basics of Open Source Software Markets and Business Models Berlecon Research Bing, L., and Shufen, L. (2008) A Model Driven Domain Engineering Method. Paper presented at the Third International Conference on Pervasive Computing and Applications, 2008. ICPCA 2008. Bitzer, J., Schrettl, W., and Schroder, P. J. H. (2007) Intrinsic motivation in open source software development. Jo urnal of Comparative Economics 35(1), 160-169. Blunt Jackson, L. (2002) Writing apache modules. Dr. Dobb's Journal 27(9), 42-50. Boehm, B. (1986) A spiral model of software development and enhancement. SJGSOFT Softw. Eng. No tes 11(4), 14-24. Boehm, B. (1988) A Spiral Model of Software Development and Enhancement. IEEE Computer 21(5), 61-72. Boehm, B. (1996) Anchoring the softwareprocess. Software, IEEE 13(4), 73-82. Boehm, B. (1999) Making RAD work for your project. Computer 32(3), 113-1 14, 117. Boehm, B. W., and Ross, R. (1989) Theory-W software proj ect management principles and examples. Software Engineering, IEEE Transactions on 15(7), 902-916. 248 Boehm, B., and Basili, V. R. (2000) Gaining intellectual control of software development. IEEE Computer (Software), 33(5), 27-33. Boehm, B., and Bose, P. ( 1994) A collaborative sp iral software process model based on Th eory W Paper presented at the Software Process; Proceedings, Third International Conference on 'Applying the Software Process' 1994. Booch, A. W. B. a. G. (2002) Reusing Open-Source Software and Practices: The Impact of Open-Source on Commercial Vendors;. Sp ringer- Ve rlag Berlin Heidelberg 2002. Bomfreund, M. (2005) OpenSource law, Op en source legal issues (creative commons ed.): Creative Commons license. Bouillon, P., and Krinke, J. (2004) Us ing Eclipse in distant teaching of software engineering. Paper presented at the Proceedings of the 2004 OOPSLA workshop on t:dipsetechnology eXchange. Bourque, P., Robert, F., Lavoie, J. M., Lee, A., Trudel, S., and Lethbridge, T. C. (2002) Guide to the Software Engineering Body of Knowledge (SWEBOK) and the Software Engineering Education Knowledge (SEEK) - a preliminary mapping. Paper presented at the Software Technology and Engineering Practice, 2002. STEP 2002. Proceedings. lOth International Workshop. Caliber (Writer) (January 2006) Ccaliber (Co-ordination Action for Libre Software Engineering for Open Development Platforms fo r software and services):. In E. C. I. S. a. Media (Producer), Software Technologies: [email protected]. Carlson, D. (2005) Eclipse Distilled: Addison-Wesley 249 Cavano, J. P., and McCall, J. A. (1978) A fr amework fo r the measurement of software quality. Paper presented at the Proceedings of the software quality assurance workshop on Functional and performance issues. Charles, W. K. (1992) Software reuse. A CM Comput. Surv. 24(2), 131-183. Chen, H., and Cheng, R. (2007) What Is the ZK Ajax Framework? In ZK™Ajax Without JavaScript™ Framework (pp. 3-8). Cioch, F. A., Brabbs, J., and Kanter, S. (1994) Using the spiral model to assess, select and integrate softwaredevelopment tools, Washington, DC, USA. Cortada, J. W. (2002) Researching the history of software from the 1960s. Annals of the History of Computing, IEEE 24( 1 ) , 72-79. Crowston, K., & Howison, J. (2003) The social structure of open source software development teams. Paper presented at the OASIS 2003 Workshop (IFIP 8.2 WG). Crowston, K., & Howison, J. (2006) Assessing the health of open source communities. COMPUTER-IEEE COMPUTER SOCIETY- 39(5), 89-89. Crowston, K., and Howison, J. (2003) The social structure of open source software development teams. Paper presented at the OASIS 2003 Workshop (IFIP 8.2 WG). Crowston, K., and Howison, J. (2006a) Assessing the health of open source communities. COMPUTER-IEEE COMPUTER SOCIETY- 39(5), 89-89. Crowston, K., and Howison, J. (2006b) Hierarchy and centralization in free and open source software team communications. Knowledge, Technology and Policy 18(4), 65-85-65-85. 250 Crowston, K., Annabi, H., & Howison, J. (2003) Defining open source software project success. Paper presented at the Proceedings of the 24th international conference on information systems (icis 2003). Crowston, K., Annabi, H., Howison, J., and Masango, C. (2004) Ef ectivef work practices fo r software engineering: fr ee/fibre open source software development. Paper presented at the Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research. Dag, I. K. S., Tore, D., and Magne, J. (2007) The Future of Empirical Methods in Software Engineering Research, 2007 Future of Software Engineering: IEEE Computer Society. Dahlander, L., and Magnusson, M. (2008) How do Firms Make Use of Open Source Communities? Long Range Planning 41(6), 629-649. Daile, J. M., David, P. A., Beslt:n, M., and Steinmueller, W. E. (2008) Empirical issues in open source software. Information Economics and Policy 20(4), 301-304-301-304. Daile, J. M., den Besten, M., and Canini, L. Users vs. Developers: Defect Detection and Resolution in Mozilla's Firefox. Daile, J.-M., den Besten, M., and Galia, F. (2008) The allocation of collaborative efforts in open-source software. Information Economics and Policy 20(4), 316-322. De Sousa Jr, S. F., Balieiro, M. A., Dos R. Costa, J. M., & DeSouza, C. R. B. (2009) Multiple Social Networks Analysis of FLOSS Projects using Sargas. Paper presented at the System Sciences, 2009. HICSS '09. 42nd Hawaii International Conference on. 251 DeKoenigsberg, G. (2008) How Successfu l Op en Source Projects Wo rk, and How and Why to Introduce Students to the Op en Source Wo rld. Paper presented at the Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference. Demarco, T. ( 1999) Management can make Quality (Im) possible, Cutter . T Summit. Boston: April 1999. den Besten, M., Daile, J.-M., and Galia, F. (2008) The allocation of collaborative efforts in open-source software. Information Economics and Policy 20( 4), 316-322. Determann, L., Pixley, S., and Shapiro, G. (2007) Managing commercial risks in open source software licensing. Jo urnal of Intellectual Property Law Practice 2(1 1), 770-776. Devanbu, P. T. (2008) Reverse Engineering the Bazaar: Collaboration and Communication in Open Source Development. Paper presented at the Reverse Engineering, 2008. WCRE '08. 15th Working Conference on. Dinh-Trong, T. T., and Bieman, J. M. (2005) The FreeBSB project: A replication case study of open source development. IEEE Transactions on Software Engineering 31(6), 48 1 -494. Dinh-Trong, T., and Bieman, J. M. (2004) Open source software development: a case study of FreeBSD. Paper presented at the Software Metrics, 2004. Proceedings. 1Oth International Symposium on. Dominic Chwan yee Foo, Z. A. M., Murugan Selvan and Michael Lynn McGuire. (2005) Integrated Process Simulation and Process Synthesis. Chemical Engineering Process ( CEP) magazine.. 252 Donaldson, S. E., and Siegel, S. G. (2007) Enriching Your Project Planning: Tying Risk Assessment to Resource Estimation. IT Professional 9(5), 20-27. Erik, B., and Michael, P. (200 1) Open-source documentation: in search of user driven, just-in-time writing, Proceedings of the 19th annual international conference on Computer documentation. Sante Fe, New Mexico, USA: ACM. Etienne Suvasa. (2002) FreeSoftware, FreeSociety: Selected Essays of Richard M Stallman (First ed.): Free Software Foundation, Inc. Eunha, K., Jongchae, N., and Seokmoon, R. (2009) Developing a Test Automation Framework for Agile Development and Testing. In Agile Processes in Software Engineering and Extreme Programming (pp. 8-12). Feitelson, D. G., Heller, G. Z., and Schach, S. R. (2006) Anempiri cally-based criterion fo r <.ktermining the success of an open-source project, Sydney, Australia. Feller, J., & Fitzgerald, B. (2002) Understanding open source software development. Inf Res. 7(2), 21 1. ISSN: 210-201-73496-73496. Fenton, N. E., and Ohlsson, N. (2000) Quantitative analysis of faults and failures in a complex software system. Software Engineering, IEEE Transactions on 26(8), 797-8 14. Ferenc, R., Siket, 1., and Gyimothy, T. (2004) Extracting fa cts fr om open source software, Chicago, IL, United states. Fichman, R., and Kemerer, C. ( 1997) Object Technology and Reuse: Lessons from Early Adopters. IEEE (Software). 253 Fielding, R. T. (2005) Software architecture in an open source world, Saint Louis, MO, United states. Fitzgerald, B., Hissam, S. A., and Lakhani, K. R. (2005) Perspectives on Free and Open Source Software. In F. Joseph (Ed.): MIT Press, Cambridge, Massachusetts London, England. Fogel, K. (2005) Producing open source software: how to run a successful free software project: O'Reilly Media, Inc. Fredberg, T. (2009) Organising Customers: Learning from Big Brother. Long Range Planning 42(3), 320-340. Fuggetta, A. (2003) Open source software--an evaluation. Jo urnal of Sy stems and Software 66( 1), 77-90. - Fukuhara, T., Murayama, T., and Nishida, T. (2006) IC-portal: An Integrated Communication Support Sy stem fo r Understanding a Social Problem. Paper presented at The Second International Workshop on Intelligent Media Technology for Communicative Intelligence. Fulop, L. J., Gyovai, T., and Ferenc, R. (2006) Evaluating C++ design pattern miner tools. Paper presented at the Sixth IEEE International Workshop on Source Code Analysis and Manipulation, 2006. SCAM'06. Gao, Y., and Madey, G. (2007) Towards understanding: a study of the SourceForge.net community using modeling and simulation Paper presented at The Spring Simulation Multiconference Gardinali, P. A. (2003) Op en source: Digital communities and the new economy of inormation.f Unpublished Ph.D., University of California, Santa Barbara, United States - California. 254 Garfinkel, S. (2008) Android calling. Technology Review I 11 (2). Gargiulo, P., Momati, S., Contino, U., and Tajoh, Z. (2005) PLEIADI, a portal solution fo r scholarly literature. Paper presented at the From Author to Reader: Challenges fo r the Digital Content Chain: Proceedings of the 9th ICCC International Conference on Electronic Publishing. Georg, V. K., and Eric, V. H. (2003) Special issue on open source software development. Research Policy 32(7), 1 149-1 157. George. (1997) Research Topics in Software Composition. Paper presented at the Languages et Modeles a Objects Nancy. Ghosh R., P., V. V. (2000) Orbiten Free SoftwareSurvey. First Monday 5(7). Ghosh, R. A. (2002) Free/Libre and Open Source Software: Survey and Study FLOSS Workshop on Advancing the Research Agenda on Free I Open Source Software. Brussels European Commission. Gill, N. S., and Grover, P. S. (2003) Component-based measurement: few useful guidelines. ACM SJGSOFT Software Engineering Notes 28(6), 4-4. Gittens, M., Yong, K., and Godwin, D. (2005) The vital fe w versus the trivial many: exa mining the Pareto principle fo r software. Paper presented at the Computer Software and Applications Conference, 2005. COMPSAC 2005. 29th Annual International. Glass, R. L. (1998) Defining quality intuitively. Software, IEEE 15(3), 103-104, 107. Glass, R. L. (1998) Definingquality intuitively. Software, IEEE 15(3), 103-104, 107 . 255 Goldman, R., and. R. P. G. (2005) Innovation Happens Elsewhere Op en Source as Business Strategy: Morgan Kaufmann Publishers, Elsevier. Goldschlag, D., Reed, M., Syverson, P., Gabber, E., Gibbons, P. B., Krista!, D. M., et a!. (1999) Onion routing for anonymous and private internet connections. Communications of the ACM 42(2), 39-47. Grad, B. (2002) A personal recollection: IBM's unbundling of software and services. Annals of the History of Computing, IEEE 24(1), 64-71. Grand, J., Thornton, F., Yarusso, A., Baer, R. H., Joe, G., Frank, T., et al. (2004) Index. In Game Console Hacking (pp. 541-558). Burlington: Syngress. Gregor, K., and Erik, H. (200 l) Aspect-oriented programming, Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering. Vienna, Austria: ACM. Gruhn, V. (2002) Process-Centered Software Engineering Environments, A Brief History and Future Challenges. Annals of Software Engineering 14( 1 ), 363- 382. Gurbani, V. K., Garvert, A., and Herbsleb, J. D. (2006) A case study of a corporate open source development model, Shanghai, China. Haigh-Hutchinson, M. (2009) Camera scripting. In Real-Time Cameras (pp. 179- 212). Boston: Morgan Kaufmann. Hansen, W. (1999) Deployment Descriptions in a World ofCOTS and Open Source. In System Configuration Management (pp. 795-795). 256 Hars, A., and Ou, S. (2002) Working for free? Motivations for participating in open source projects. InternationalJo urnal of Electronic Commerce 6(3), 25-39- 25-39. Helmer, 0., & Heimer-Hirschberg, 0. (1983) Looking forward: a guide to futures research: Sage Publications, Inc. Henley, M., and Kemp, R. (2008) Open Source Software: An introduction. Computer Law and Security Report 24( 1), 77-85. Herraiz, 1., Gregorio, R., Juan, J., Amor, Te, filo, R., et al. (2006) The processes of joining in global distributed software projects, Proceedings of the 2006 international workshop on Global software development fo r the practitioner. Shanghai, China: ACM. Hertel, G., Niedner, S., and Herrmann, S. (2003) Motivation of software developers in Open Source projects: an Internet-based survey of contributors to the Linux kernel. Research Policy 32(7), 1 159-1 177- 1 159-1 177. Herwig, M., and Kris, V. (2005) The use of open source software platforms by Independent Software Vendors: issues and opportunities, Proceedings of the fifth workshop on Op en source software engineering. St. Louis, Missouri: ACM. Hinds, D. (2008) Social Network Structure as a critical success condition fo r open source software project communities. Florida International University. Hongyu, Z. (2008) On the Distribution of Software Faults. Software Engineering, IEEE Transactions on 34(2), 301-302. Hsieh, T.-h. (2009) Effe cts of Iriformed Strategies fo r Learning Intergrated into Xoop fo r The High Grade Students ' Reading Comprehension, Mo tivation, and 257 Metacognition. Unpublished Master's Thesis, Graduate Institite of Educational Technology, National Pingtung University of Education (NPUE) Humphrey, W. S. (2002) Software unbundling: a personal perspective. Annals of the History of Computing, IEEE 24( 1), 59-63. IEEE and Open Group. (2004 Edition) The Open Group Base Specifications. In The IEEE and The Open Group (Ed.), IEEE Std 1003 (Vol. IEEE Std 1003): The IEEE and The Open Group. IEEE STD 1517. (2004) IEEE 1517 Standard for Information Technology - Software Life Cycle Processes on Reuse Processes. In IEEE (Ed.), 1517 (pp. 1 - 43): IEEE. Iqbal, M., and Rizwan, M. (2009) Application of 80120 rule in software engineering Waterfa ll Model. Paper presented at the Information and Communication Technologies, 2009. ICICT '09. International Conference on. ISO/IEC 12207. (2002) Software Engineering: Software life cycle processes. In ISO/IEC (Ed.), ISOIIEC 12207. Isoda, S. (1995) Experiences of a software reuse project. Jo urnal of Sys tems and Software 30(3), 171-186. J. E. Gaffney, Jr. (1981) Metrics in software quality assurance, Proceedings of the ACM '81 conference: ACM. Jack, H. (2001) Linuxworkshop session, Albuquerque, NM, United states. 258 Jai, A. (2005) The need fo r effort estimation models for open source software projects, Proceedings of the fifth workshop on Op en source software engineering. St. Louis, Missouri: ACM. James, W. H., and Chester, R. 0. (199 1) Software Reuse: Guidelines and Methods: Perseus Publishing. Jensen, C., and Scacchi, W. (2007) Role Migration and Advancement Processes in OSSD Projects: A Comparative Case Study. Paper presented at the Software Engineering, 2007. ICSE 2007. 29th International Conference. Jiang, J. J., Klein, G., and Discenza, R. (2002) Perception differences of software success: provider and user views of system metrics. Jo urnal of Systems and Software 63(1), 17-27. Jin Xu, S. C., and Madey, G. (2006) Application of Social Network Analysis to the Study of Open Source Software. In P. J. H. S. Jurgen Bitzer (Ed.), The Economics of Op en Source Software Development (pp. 247 - 270): Elsevier B.V. Jin, X., Yongqin, G., Scott, C., and Gregory, M. (2005) A Topological Analysis of the Open Souce Software Development Community, Proceedings of the Proceedings of the 38th Annual Ha waii International Conference on Sy stem Sciences - Vo lume 07: IEEE Computer Society. Jing Y., and Jiang, W. (2008) Review on fr ee and open source software. Paper presented at the Service Operations and Logistics, and Informatics, 2008. IEEE/SOLI 2008. IEEE International Conference. lipping, M. J., Calka, C., O'Neill, B., and Padilla, C. R. (2007) Teaching students java bytecode using !ego mindstorms robots. Paper presented at the 259 Proceedings of the 38th SIGCSE technical symposium on Computer science education. Joan, F., Aaron, J., and Paul, S. (2007) Probabilistic analysis of onion routing in a black-box model, Proceedings of the 2007 ACM workshop on Privacy in electronic society. Alexandria, Virginia, USA: ACM. Johnson, M. K., and Troan, E. W. (2005) Linux Application Development: Addison Wesley. Jonathan, E. C., and Alexander, L. W. (1999) Software process validation: quantitatively measuring the correspondence of a process to a model. ACM Trans. Soft w. Eng. Methodol. 8(2), 147-176. Jorrit, N. H., Herbert, B., Ben, G., Philip, H., and Andrew, S. T. (2006) MINIX 3: a highly reliable, self-repairing operating system. SlOOPS Op er. Syst. Rev. 40(3), 80-89. Julian Satchell, N. P. (200 l) Analysis of Impact of Open Source Software: QinetiQ 2001. Jungpil, H., and Jinwoo, K. (1999) Why are some diagrams easier to work with? Effects of diagrammatic representation on the cognitive intergration process of systems analysis and design. ACM Trans. Comput.-Hum. Interact. 6(3), 181-213. Kai, K., Pree, W., Bosch, J., and Hedin, G. (1999) Designing Reusable Object oriented Architectures Challenges, Methods and Tools. Paper presented at the Technology of Object-Oriented Languages and Systems, 1999. Proceedings of. 260 Kane, A., and Band, A. (2009) Modular Software Architectures. Accessed on l" April, 2010 http:llwww.ece.gatech.edu/a cademic/courses/ece4007/09springlece4007l03/ lm2/trpl .pd[ Kmma, S., and Aj ay, V. (1999) A qualitative model fo r barriers to software reuse adoption. Paper presented at the In Proceedings of the International Conference on Information Systems, 20th international Conference on information Systems, , December 12 - 15, Charlotte, North Carolina, United States. Katsamakas, E., and Georgantzas, N. (2007) Why Most Op en Source Development Projects Do Not Succeed? Paper presented at the Emerging Trends in FLOSS Research and Development, 2007. FLOSS '07. First International Workshop on. Kavanagh, P. (2004) Open Source Software: Definitions and History. In Op en Source Software (pp. 1-17). Burlington: Digital Press. Kellner, M. J. (1988) Software process modeling at SEI. Paper presented at the Software Maintenance, 1988., Proceedings of the Conference on. Khalaf, S. a. J., and Al-Jedaiah, M. N. (2008) Software quality and assurance in waterfall model and XP - A comparative study. WSEA S Transactions on Computers 7(12), 1968-1 976. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.-M., et al. (1997) Aspect-oriented programming. In ECOOP'97 - Object-Oriented Programming (pp. 220-242). Kitchenham, B., Pickard, L., and Pfleeger, S. L. ( 1995) Case studies fo r method and tool evaluation. Software, IEEE 1 2(4), 52-62. 26 1 Knight, J., and Dunn, M. (1998) Software quality through domain-driven certification. Annals of Software Engineering 5, 293-3 15. Koch, S., and Neumann, C. (2008) Exploring the effects of process characteristics on product quality in open source software development. Jo urnal of Database Ma nagement 19(2), 31-57. Koji, Y., Eunyoung, C., Carlos, 1., & Khai, N. T. (2009) Understanding how and why open source contributors use diagrams in the development of Ubuntu, Proceedings of the 27th international conference on Human factors in computing systems. Boston, MA, USA: ACM. Koponen T., H. V. (2004, June 2004) Evaluation Framework fo r Op en Source Software. Paper presented at the International Multi Conference m Computer Science and Computer Engineering, Las Vegas, Nevada. Krishnamurthy, S. (2003) A managerial overview of open source software. Business Horizons 46(5), 47-56. Krzysztof, D., and Sebastian, G. (2005) Open Source --Ideology or Methodology?, Proceeding of the 2005 conference on Software Engineering: Evolution and Emerging Technologies: lOS Press. Kumar, S. (2006 ) Enforcing the GNU GPL. Jo urnal of Law, Technology and Policy. Kumiyo, N., Yasuhiro, Y., Yoshiyuki, N., Kouichi, K., and Yunwen, Y. (2002) Evolution patterns of open-source software systems and communities, Proceedings of the International Wo rkshop on Principles of Software Evolution. Orlando, Florida: ACM. Kung-Kiu, L., and Zheng, W. (2007) Software Component Models. Software Engineering, IEEE Transactions on 33(1 0), 709-724. 262 Lakhani, K. R., and von Hippe!, E. (2003) How open source software works: "free" user-to-user assistance. Research Policy 32(6), 923-943. Lakhani, K., and Wolf, R. G. (2003) Why hackers do what they do: Understanding motivation and effort in free/open source software projects. Laurindo, B., and Moraes, d. 0. (2006) Managing Conflicts in IT Projects in Brazilian Companies. Paper presented at the Technology Management for the Global Future, 2006. PICMET 2006. Lee, B. (2004) Eclipse Project CDT (C/C++) Plugin Tutorial. Department of Computer Science, University of Ma nitoba, Winnipeg, Manitoba, Canada February 20. Lee, S.-Y. T., Kim, H.-W., & Gupta, S. (2009) Measuring open source software success. Omega 37(2), 426-438. Lennerholt, C., Lings, B., and Lundell, B. (2008) Architectural issues in opening up the advantages of open source in product development companies, Turku, Finland. Lerner,J . , and Tirole, J. (2000) The simple economics of open source. Lerner, J ., and Tirole, J. (2002) Some simple economics of open source. The journal of industrial economics 50(2), 197-234-197-234. Lerner, J., and Tirole, J. (2005) The Scope of Open Source Licensing. J. Law Econ. Organ. 21(1 ), 20-56. Lin, L. (2008) Impact of user skills and network effects on the competition between open source and proprietary software. Electronic Commerce Research and Applications 7( 1 ), 68-81. 263 Lind, R. K., and Vairavan, K. ( 1989) An experimental investigation of software metrics and their relationship to software development effort. Software Engineering, IEEE Transactions on 15(5), 649-653. Ling-Ling, W., Luesukprasert, L., and Lee, L. (2009) Research and the Long Ta il: A Large-Scale Citation Analysis. Paper presented at the System Sciences, 2009. HICSS '09. 42nd Hawaii International Conference. Lohkamp, B., Emsley, P., and Cowtan, K. (2005) Coot news. CCP4 Newsletter 42. Madey, G., Gao, Y., Freeh, V., Tynan, R., and Hoffman, C. (2003) Agent-Based Modeling and Simulation of collaborative Social Ne tworks . . . Paper presented at the Americas Conference on Information Systems, AMCIS 2003. Mahboob, A., and Ikram, N. (2007) How to Overcome the Challenges to Large Scale Adoption of Open Source Software and Systems in Pakistan Business and Industrial Environment. Malik Ahmad Yar, K., and Darryl, V. (2008) Peeling the 802. 11 onion: separating congestion from physical per, Proceedings of the third A CM international workshop on Wireless network testbeds, experimental evaluation and characterization. San Francisco, California, USA: ACM. McClure, C. (200 l) Software Reuse: A Standards-Based Guide: Wiley-IEEE computer society press. McCracken D.D, M. A. J. (1982) Life-Cycle Concept Considered Harmful. ACM Software Engineering Notes, 29-32. Meijler, D., and Nierstrasz, 0. (1995) Beyond O�jects: Components. Paper presented at the Languages et Modeles a Objects, A Napoli (Ed.). 264 Michingan, S. (2009) Michigan Student Data System (MSDS) I XML Validation Guide, Michigan Student Data Sy stem (MSDS) I XML Va lidation Guide (Fall 2009 ed., pp. 21): Center fo r Educational Performance and Information (CEPI). Millington, I., and Funge, J. (2009) Game AI. In Artificial Intelligence fo r Games (Second Edition) (pp. 19-35). Boston: Morgan Kaufmann. Misra, S. C., Kumar, V., & Kumar, U. (2009) Identifying some important success factors in adopting agile software development practices. Journal of Systems and Software 82(1 1), 1869- 1 890. Mockus, A. (2007) Large-Scale Code Reuse in Op en Source Software. Paper presented at the Emerging Trends in FLOSS Research and Development, 2007. First International Workshop on FLOSS '07. Mockus, A., Fielding, R. T., and Herbsleb, J. (2000) Case study of open source software development: the Apache server, Limerick, Ireland. Mockus, A., Fielding, R. T., and Herbsleb, J. D. (2002) Two case studies of open source software development: Apache and Mozilla. A CM Transactions on Software Engineering and Me thodology 11(3), 309-346. Moore, J. (2008) ISO 12207 and Related Software Life-Cycle Standards;. In T. M. Corporation (Ed.), ISO 12207. Moreno-Ger, P., Sierra, J. L., Martinez-Ortiz, 1., and Femfmdez-Manj6n, B. (2007) A documental approach to adventure game development. Science of Computer Programming 67( 1 ), 3-3 1. Moshe, B., and Karl, F. (2003) Advanced CYS. In Open Source Development with CVS (3rd ed., pp. 125-170): Paraglyph Press. 265 Mozilla (2004) The Firefox web browser, Thunderbird and Mozilla Suite. www .mozilla.org Muller-Bim, C., Lehmann, J., and Jeschke, S. (2009) A Composite Calculation fo r Author Activity in Wikis: Accuracy Needed. Paper presented at the Web Intelligence and Intelligent Agent Technologies, 2009. WI-IAT '09. IEEE/WIC/ACM International Joint Conferences. Murray, T. (1971) Delphi and its potential impact on information systems, Proceedings of the November 16-18, 1971, fall joint computer conference. Las Vegas, Nevada: ACM. Mustonen, M. (2003) Copyleft--the economics of Linux and other open source software. Information Economics and Policy 15( l ), 99-121. Nandigam, J., Gudivada, V. N., and Hamou-Lhadj, A. (2008) Learning software engineering principles using open source software. Paper presented at the Frontiers in Education 38th Annual Conference, 2008. FIE 2008. Netcraft, A. W. S. S. A. o. t. S. (2008) Apache market Share (August 2008 Web Server Survey): NetcraftWeb Server Survey. Nierstrasz, D. M. a. 0. (1995, October 1995) Beyond Objects: Components. Paper presented at the Languages et Modeles a Objects, Nancy. Oon., R. D. (2010) Open Source ERP from ADempiere top world SourceForge project (First ed.): Pearson Education. Oostendorp, N. (2009) Using Networks to Visualize and Understand Participation on SourceForge.net. Unpublished Network Theory and Application, project. 266 Openbravo. (2009) Openbravo project page on SourceForge.net. Accessed on-line on 16111 November, 2009 at http:// sourceforge.net/pr ojects/openbravo/ OpenGroup. (2004) IEEE Standard fo r Information Technology - Portable Operating System Interface (POSIX). Rationale (Informative). IEEE Std 1003.1, 2004 Edition. Th e Op en Group Technical Standard. Base Sp ecifications, Issue 6. Includes IEEE Std 1003. 1-2001, IEEE Std 1003. 1-2001/Cor 1-2002 and IEEE Std 1003.1-2001/Cor 2-2004. Rati, 0_ 1. Orsila, H., Geldenhuys, J ., Ruokonen, A., and Hammouda, I. (2009) Trust issues in open source software development, Strand, Cape Town, South africa. Ortega, M., Perez, M., and Rojas, T. (2003) Construction of a Systemic Quality Model for Evaluating a Software Product. Software Quality Journal 1(3),1 219-242. Osterloh, M., and Rota, S. (2007) Open source software development--Just another case of collective invention? Research Policy 36(2), !57 -171. Otso, K. (2008) Free/Open Source Software Development: Results and Research Methods UNIVERSITY OF HELSINKI, HELSINKI. Otte, T., Moreton, R., and Knoell, H. D. (2008) Applied Quality Assurance Methods under the Op en Source Development Model. Paper presented at the Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International. Parekh, N. (2005) Spiral Model - A New Approach Towards Software Development. 267 Paul, F. S., David, M. G., and Michael, G. R. (1997) Anonymous Connections and Onion Routing, Proceedings of the 1997 IEEE Sy mposium on Security and Privacy: IEEE Computer Society. Paulson, J. W., Succi, G., and Eberlein, A. (2004) An empirical study of open-source and closed-source software products. IEEE Transactions on Software Engineering 30(4), 246-256. Payette, S., & Lagoze, C. (2009) Flexible and Extensible Digital Object and Repository Architecture (FEDORA). In Research and Advanced Technology fo r Digital Libraries (Vol. 1513, pp. 517-5 17): Springer Berlin I Heidelberg. Peeling, N., and Satchell, J. (2001) Analysis of the Impact of Open Source Software (No. QINETIQ/KI/SEB/CR010223): QinetiQ2001. Petersen, J.-U. (2003) Native-Compiled PLISQL m Windows With the Freeware Compiler MinGW. Polancic, G., Horvat, R. V., and Rozman, T. (2004) Comparative assessment of open source software using easy accessible data, Cavtat, Croatia. Poulin, J. S. (I995) Populating software repositories: incentives and domain specific software. Journal of Sy stems and Software 30(3), 187-199. Pressman, and Scott. (2005) Software Engineering: A Practitioner's Approach (Sixth, International ed.): McGraw-Hill Education. Punter, T., Krikhaar, R. L., & Brit, R. J. (2009) Software engineering technology innovation - Turning research results into industrial success. Journal of Systems and Software 82(6), 993-1003. 268 Qureshi, R. J. M., and Hussain, S. A. (2008) An adaptive software development process model. Advances in Engineering Software 39(8), 654-658. Rafal, K., Tomasz, A., and Kenneth De, J. (2005) Evolutionary computation and structural design: A survey of the state-of-the-art. Comput. Struct. 83(23-24), 1943-1 978. Rajdeep, G., Gary, L. L., & Girish, M. (2006) Location, Location, Location: How Network Embeddedness Affects Project Success in Open Source Systems. Manage. Sci. 52(7), I 043-1056. Rajdeep, G., Gary, L. L., and Girish, M. (2006) Location, Location, Location: How Network Embeddedness Affects Project Success in Open Source Systems. Manage. Sci. 52(7), 1043-1 056. Raman, R., and Richard, F. P. (2008) Process-centered review of object oriented software development methodologies. ACM Comput. Surv. 40(1), l-89. Rankin, C. (2002) The software testing automation framework. IBM Sy stems Journa/ 41(1), 126-139. Rapley, K. (1995) RAD or TR AD or both? The fu ture of software development. Paper presented at the Will Tickit and ISO 9000 Survive Rapid Application Development?, lEE Colloquium on. Rastic, J., Gros, S., and Glavinic, V. (2007) LUSCA-Test Framework fo r Network Applications. Paper presented at the 30th Jubilee International Convention MIPRO 2007. Raymond, E. S. (1999) Homesteading the Noosphere In The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (pp. 65- 1 1 2.). Cambridge, MA: O'Reilly. 269 Raymond, E. S. ( 1999) The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary Cambridge, MA. Raymond, E. S. ( 1999) The Revenge of the Hackers, Op en Sources: Vo ices fr om the Op en Source Revolution (lst edition, ed.): O'Relly. Raymond, E. S. (200 1) The Magic Cauldron. In The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (pp. 1 13-143). Cambridge, MA.: O'Reilly. Reilly, J. P., and Carmel, E. (1995) Does RAD live up to the hype? Software, IEEE 12(5), 24-26. Rhodes-Ousley., M., Roberta., B., and Strassberg., K. (November l 0, 2003) Network Security, The complete reference, , . In (Vol. ): McGraw-Hill. Richard, M. S. (2000) Us ing and Porting the GNU Compiler Collection (Softcover ed.): Free Software Foundation. Rigby, P. C., German, D. M., and Storey, M.-A. (2008) Open source software peer review practices: A case study of the apache server, Leipzig, Germany. Rizwan Jameel Qureshi, M., and Hussain, S. A. (2008) An adaptive software development process model. Advances in Engineering Software 39(8), 654- 658. Robert K. Yin , S. R. (2009) Case Study Research: Design and Methods, Fourth Edition, Applied Social Research Methods Volume 5, Sage Publications Incorporated (2008) 240 pages, ISBN: 978 1412960991. Australasian Emergency Nursing Jo urnal 12(2), 59-60. 270 Robles, G., Gonzalez-Barahona, J. M., and Herraiz, I. (2009) Evolution of the core team of developers in fibre software projects. Paper presented at the MSR '09. 6th IEEE International Working Conference on Mining Software Repositories, 2009. Roger S., P. (200 1) Software Engineering. In Software Engineering: A Practitioner's Approach (5th ed., pp. 207-210): McGraw-Hill Rosen, L. (2004) Op en source licensing: Software fr eedom and intellectual property law: Prentice Hall PTR Upper Saddle River, NJ, USA. Royce, W. W. (1987) Managing the development of large software systems: concepts and techniques, Proceedings of the 9th international conference on Software Engineering. Monterey, California, United States: IEEE Computer Society Press. Saiedian, H., and McClanahan, L. ( 1996) Frameworks fo r quality software process: SEI Capability Maturity Model versus ISO 9000. Software Quality Journal 5( 1), l-23. Sakaguchi, M., and Mazalov, V. V. (2004) A non-zero-sum no-information best choice game. Mathematical Methods of Operations Research 60(3), 437-451. Sarkinen, J. (2007) An open source(d) controller, Rome, Italy. Sauer, R. M. (2007) Why develop open-source software? The role of non-pecuniary benefits, monetary rewards, and open-source licence type. Oxf Rev. Econ. Policy 23(4), 605-6 19. Scharff, E. D. (2002) Op en source: A conceptual fr amework fo r collaborative artifact and knowledge construction. Unpublished Ph.D., University of Colorado at Boulder, United States -- Colorado. 271 Schattkowsky, T. (2008) Model-based Development of Embedded Systems: Executable Models vs. Code Generation. Relation 10( 1.25), 124- 124. Schmelich, V., and Alt, R. (2008) Functional Analysis o.f Open Source ERP Sys tems: An Exploratory Analysis: Inst. f\iir Wirtschafts informatik. Schneberger, S. L. (1997) Distributed computing environments: Effe cts on software maintenance difficulty. Journal of Sy stems and Software 3 7(2), 101 - 1 1 6. Scotto, M., Sillitti, A., and Succi, G. (2007) An empirical analysis of the Open Source development process based on mining of source code repositories. International Jo urnal of Software Engineering and Knowledge Engineering 17(2), 23 1-247. SEIRAND. (2008) Intoduction to ZK: A Direct RIA Development Framework, Webinair: SEIRAND Institute Accessed Online at http: //www.zkoss.org/support/training/webinar/zkintro.dsp, 18th November, 2009. Sener, G. a. U. (2006) Adventure Lantern: News. Adventure Lantern, 154. August, 2006 Siegel, D. S., and Wright, M. (2007) Intellectual property: the assessment. Oxfo rd Review on Economic Policy 23(4), 529-540. SourceForge. (2009) About SourceForge.net repository: SourceForge, Accessed online 18th November 2009. Spaulding, T. J. (2009) How can virtual communities create value for business? Electronic Commerce Research and Applications In Press, Corrected Proof 272 Stallman, R. (1984) The GNU project, Free Software Fo undation: Free Software Foundation. Stallman, R. (2006) The Free Software Movement and the GNU/Linux Op erating Sys tem. Paper presented at the Software Maintenance, 2006. ICSM '06. 22nd IEEE International Conference. Staringer, W. (1994) Constructing applications from reusable components. Software, IEEE 11(5), 61-68. Stavrinoudis, D., Xenos, M., Peppas, P., and Christodoulakis, D. (2005) Early Estimation of Users' Perception of Software Quality. Software Quality Journal 13(2), 155-175. Stewart, K., & Ammeter, T. (2002) An Exploratory Study of Factors Influencing the Level of Vitality and Popularity of Open Source Projects. Paper presented at the International Conference on Information Systems (TCIS), . Subramaniam, C., Sen, R., & Nelson, M. L. (2009) Determinants of open source software project success: A longitudinal study. Decision Support Systems 46(2), 576-585. Terry, W. (1995) From programming environments to environments fo r designing. Commun. ACM 38(6), 65-74. Timo, K., and Virpi, H. (2005) Open source software maintenance process framework, Proceedings of the fifth workshop on Op en source software engineering. St. Louis, Missouri: ACM. Tsirakidis, P., Kobler, F., & Krcmar, H. (2009) Identification of Success and Failure Factors of Two Agile Software Development Teams in an Open Source 273 Organization. Paper presented at the Global Software Engineering, 2009. ICGSE 2009. Fourth IEEE International Conference on. Tsoi, H. L. ( 1998) A framework for Management Software Project Development. ACM 1998. Ueda, M. (2005) Licenses of Op en Source Software and their Economic Va lues. Paper presented at the Applications and the Internet Workshops, 2005. Saint Workshops 2005. The 2005 Symposium. Valimaki, M., and Oksanen, V. (2005) The impact of free and open source licensing on operating system software markets. Telematics and Informatics, Elsevier 22(1-2), 97-110. Vreugdenhil, B. (2009) The Influence of Social Network Structure on the chance of success of Open Source Software Communities. RSM Erasmus University, Netherlands, Rotterdam. Wahyudin, D., and Tj oa, A. M. (2007) Event-Based Monitoring of Op en Source Software Projects. Paper presented at the Availability, Reliability and Security, 2007. ARES 2007. The Second International Conference. Walker, R. (1998) Software project management: a unified framework: Addison Wesley Longman Publishing Co., Inc. Warren, P. J. (2001) An empirical study on the growth of open source and commercial software products. Unpublished M.Sc., University of Calgary (Canada), Canada. Warren, P. J., Giancarlo, S., and Armin, E. (2004) An empirical study of open-source and closed-source software products. IEEE Transactions on Software Engineering 30(4), 246-256. 274 Wiegand, J. (1993) Cooperative development of Linux, Philadelphia, PA, USA. Wikipedia. (2009) Android Opeating System. Accessed online on 20th November, 2009. http://en.wikipedia.org/ wiki/Android %28operating system%29#cite n ote-AndroidAnnouncement-2 Wilson, D. N., and Hall, T. ( 1998) Perceptions of software quality: a pilot study. Software Quality Jo urnal 7(1 ), 67-7 5. Wolfgang, Z., Stefan, H., and Thomas, G. (2005) Software quality development and assurance in RUP, MSF and XP: a comparative study, Proceedings of the third workshop on Software quality. St. Louis, Missouri: ACM. Xie, X., Poshyvanyk, D., and Marcus, A. (2005) Support fo r Static Concept Location with sv3D. Paper presented at the 3rd IEEE International Workshop on Visualizing Software forUnderstanding and Analysis, 2005. VISSOFT 2005. Xiong, C. J., Li, Y. F., Xie, M., Ng, S. H., and Goh, T. N. (2009) A model of open source software maintenance activities. Paper presented at the Industrial Engineering and Engineering Management, 2009. IEEM 2009. IEEE International Conference. Yoshifumi, M., and Tatsuaki, 0. (2008) Anonymous return route information fo r onion based mix-nets, Proceedings of the workshop on Applications of private and anonymous communications. Istanbul, Turkey: ACM. Yu, L., Schach, S. R., Chen, K., Heller, G. Z., and Offutt, J. (2006) Maintainability of the kernels of open-source operating systems: A comparison of Linux with FreeBSD, NetBSD, and OpenBSD. Jo urnal of Systems and Software 79(6), 807-815. 275 Yunwen, Y., and Kishida, K. (2003) To ward an understanding of the motivation of open source software developers. Paper presented at the Software Engineering, 2003. Proceedings. 25th International Conference. Zain, M. Y. (2009) Minimizing the Problems of Enterprise Resource Planning (ERP) Implementation for Small to Medium Cigarette Company Through Framework fo r Applications of Systems Thinking (FAST). Media lnformatika 6( 1 ). Zelkowitz, E., Johnson, M. C., and Lu, Y.-H. (2006) Quantitative analysis of programs: Comparing open-source software with student projects, Chicago, IL, United states. Zhang, S., and Yao, Z. (2007) The Relation of CMM and Software Lifecycle Model. Paper presented at the Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, 2007. SNPD 2007. Eighth ACIS International Conference. Zhao, L., and Elbaum, S. (2003) Quality assurance under the open source development model. Jo urnalof Systems and Software 66( 1), 65-75. Zheng, X., Zeng, D., Li, H., and Wang, F. (2008) Analyzing open-source software systems as complex networks. Physica A: Statistical Mechanics and its Applications 387(24), 6190-6200. Zhou, Y., Shen, X., and Fan, L. (2007) The social and economic factors within ICT development in China: A case study of linux development in China, Shanghai, China. Zoltai, J. (2000) The Software Development Life Cycle (SDLC) For Small To Medium Database Applications, Software Engineering - Concepts and Applications (Vol. 1.0, pp. 280). Zubeck, J. C. (1997) Implementing reuse with RAD tools' native objects. Computer 30( 1 0), 60-65 . APPENDICES APPENDIX A: INTERNATIONAL PUBLICATIONS 1 . The List of Conference Papers are as fo llows: 1. Showole Aminat, Shamsul Sahibuddin and Ali Selamat, Open Source Integration into Business Strategies: A Review. Proceedings of the In ternationalBusiness Information Management Conference (1Oth IBIMA), lSI Thomson Scientific Index, 30 Jun-2 July, 2008, Kuala Lumpur, Malaysia. 11. Showole Aminat, Suhaimi Ibrahim and Shamsul Sahibuddin, Industrial Application Development with Open Source Approach., Third International Conference on Software Engineering Advances (ICSEA '08), IEEE Computer Society, 26-3 1 October, 2008, Malta. 111. Showole Aminat, Shamsul Sahibuddin and Suhaimi Ibrahim, Prospects of Open Source Adoption in Education Prospects in Nigeria. Proceedings of the International Conference of the In ternational Jo urnal o[ Arts and Science (JJAS'2008), 3-5 December, 2008, Germany. iv. Showole Aminat, Shamsul Sahibuddin and Suhaimi Ibrahim, Making the First Move Towards Open Source Development. Proceedings of the International Business Information Management Conference (14111 IBIMA), lSI Thomson 277 Scientific Index, 23-24, June 2010, Turkey ISBN :978-0-9821489-3-8). (Accepted fo r Publication) v. Showole Aminat, Shamsul Sahibuddin and Suhaimi Ibrahim, Towards Open Source Interoperability, Proceedings of Postgraduate Annual Research (PARS '08), Faculty of Computer Science and Information Systems, Universiti Teknologi Malaysia, 30th June - 3rd July, 2008, Johor Bahru, Malaysia. VI. Showole, A., and Longe, H. 0. D. Open Source Software Quality Assurance Process. In Conference Proceedings, 20th Annual Na tional Conference, Nigeria Computing Society Nigeria. Vol. 17 pp 172-182, 13th June - 16th June 2006, Y ola, Nigeria. 2. The List of International Journal Papers are as fo llows: vii. Showole Aminat, Ali Selamat, and Shamsul Sahibuddin Open Source Integration into Business Strategies: A Review. In ternational Jo urnal of Communications of IBIMA . Volume 2, number 17, Communications of the IBIMA, 2008, pages 122- 128. ISSN:l 943-7765, USA viii. Showole Aminat, Ali Selamat, and Shamsul Sahibuddin Making The First Move Towards Open Source Development. International Jo urnal of Communications of IBIMA . ISSN: 1943-7765 USA (Accepted fo r Publication). 278 APPENDIX 8: OPEN ONION CODING AND ANALYSIS No: 1: Topics Covered Rank Topics covered 1 code generators Project Point-of-sale Accountin ERP CRM Management g 2 Software Enterprise AJAX Development. 3 Object oriented ERP Accounting 4 Software text editor Development 5 Interpreter game/ entertainment 6 Version Control File management 7 Quality Assurance Build tool 8 build tools code generators compilers debuggers interpret ers 9 Software Dynamic content site Development management 10 Testing Framework NO: 2 User Interface coding User Interface coding user interface Code web based 1 Java I Java swing 2 win 32 3 Command line 4 Eclipse 5 xwindow sys (x 11), win 32, PDA, 6 Cocoa(MacOS X), SOL 279 NO: 3 Rank Table Snapshot Rank table snapshot (number in parentheses represents rank for designated statistics type) Track Last Foru Down loa Logo Release er ML Rank Score Site Hits cvs SVN GIT Logi Ill Project ds Hits Age Entri Posts Posts 11 es 113, Projec 4,109 26,444 0 301 31 I 268 0 105 428 0 tX (282) (312) (10,386) (3) days day (4) (0) (12) I 39,830,902 (38) (0) No: 4 Programming Languages Support Expanded Case Studies Rank Prog_Lang Support I Java Java PLISQ Openbarvo ERP script L 2 Groovy Java Java Python Ruby ZK-Simply Ajax and Mohile Scrpt Adempiere ERP 3 Java Notepad Plus 4 C++ ScummVM 5 C++ WinMerge 6 C++ Eclipse Checkstyle Plug-in 7 Java MinGW-Minimalist GNU for 8 Ada c C++ Fortran Java Pascal Windows XOOPS Web Application Platform 9 JavaScript PhP 10 c C++ Java Perl Pyth Tel SW Test Automation Framework on 280 NO: 5 Regression Analysis (Topics covered and User Interface) Model Summary Adjusted R Std. Error of Model R R Square Square the Estimate 3 I .506 .256 . 1 63 1.280 a. Predictors: (Constant), Topics Covered Coefficientsa U nstandardized Standardized Coefficients Coefficients Model 8 Std. Error Beta t Sig. 1 (Constant) 3 . 700 . 991 3.733 .006 TopicsCovd -.500 .302 -.506 -1.658 .136 a. Dependent Vanable: usennterface Regression equation: y (user interface) = -0.5(x: topics covered) + 3.7 Y = -0.5(x) + 3.7 281 NO: 6 Regression Analysis (user interface and operating systems) Model Summary Adjusted R Std. Error of Model R R Square Square the Estimate 1 .61 13 .373 .295 1.175 a. Predictors: (Constant), OpSys Coefficients3 U nstandardized Standardized Coefficients Coefficients Model B Std. Error Beta t Sig. 1 (Constant) 1.585 .466 3.398 .009 OpSys .205 .094 .611 2.181 .061 a. Dependent Variable: userinterfa ce y (user interface) = 0.2 (x : operating systems) + 1.6 y=0.2x+1.6 282 No: 7: Domain Audience Property File (from Flossmole) Intended Audience Analysis Flossmole Frequency of l42 Cumulative projects Percent Valid Percent Percent Valid End Users/Desktop 20 14.1 14.1 14.1 Developers 89 62.7 62.7 76.8 System Administrators 25 17.6 17.6 94.4 Others 8 5.6 5.6 100.0 Total 142 100.0 100.0 No: 8: Operating system Analysis Flossmole Operating system Analysis Flossmole Valid Cumulative Frequency Percent Percent Percent Valid Linux 14 12.7 12.7 12.7 MacOS 1 .9 .9 1 3.6 Microsoft 10 9. 1 9. 1 22.7 OS Independent 73 66.4 66.4 89. 1 POSIX 3 2.7 2.7 91.8 SunOS/Solaris 1 .9 .9 100.0 Windows NT/2000 8 7.3 7.3 Total ll0 100.0 100.0 283 APPENDIX C: OSS ADOPTION IN MALAYSIA State Goverrunent M yN D 0 MySp MySf t My No Agencies D I A w c E 0 G G w WkS MyM I Johor 9 22 4 0 0 0 1 0 0 0 I 0 2 Kedah 9 10 5 0 0 1 5 0 I I I 0 3 Kelantan 8 8 7 3 2 6 3 2 0 2 1 I 4 Melaka 3 7 2 I 0 0 3 0 1 0 0 1 Negeri 5 Sembilan 2 4 1 I 0 0 0 1 0 0 0 0 6 Pahang 24 28 25 4 0 3 12 3 21 2I 3 I 7 Perak 15 55 8 I 0 0 11 0 0 0 0 0 8 Perl is 5 27 5 0 0 0 2 1 I 0 0 0 Pulau 9 Pinang 8 23 10 I 0 0 6 0 0 0 0 I 10 Sabah 102 24 8 I 0 I 52 I 0 0 2 0 11 Sarawak 46 16 7 1 1 I 37 0 0 0 0 0 12 Selangor 13 16 11 I 0 I 5 I 1 I 1 0 13 Terengganu 16 19 II 3 I 5 6 6 4 I 3 I Key Key MySurfGuard and other equivalent D Desktop Solution MyS fG OSS Solutions MyNetWatch and other equivalent OSS I Infrastructure Solutions MyNtW Solutions MyWorkSpace and other equivalent A Af>I>_lication Solutions I\1y_WkS OSS Solutions Workload MyMeeting and other equivalent OSS w Consolidation MyM Solutions High Performance c Computing/Clustering I This denotes adoption of OSS DE Distributed Enterprise 0 This denotes zero ado_E_tion of OSS 00 OpenOffice.org F Favourable MySpamGuard and A Adverse other equivalent oss MySpG Solutions Abs Absolute 284 APPENDIX D: OPENBRAVO ERP SAMPLE REPOSITORIES LIST Example of ··last commie on a repository ts given below (open bravo, 2009) Name Description Contact Last change mam Main Openbra vo ERP Release Management Ill minutes ago development pi Pre-Integration Openbravo Release Management 52 minutes ago ERP development APP.ENDIX E: ANALYSIS OF FLOSSMOLE PROJECT N 1 : Project environment description Project environment description Cumulative Frequency Percent Valid Percent J>ercent Valid 006 �1.1 H.I H.I Console (Text Based) 3 .2 .2 )2.3 Gnome 2 2 2.5 KDE I I 2.6 No lnpuUOutput (Daemon) 6 6 �3.2 Other Environment 3 .2 .2 �4.4 Web Environment 0 �.6 �.6 �8.0 Win32 (MS Windows) 4 .3 .3 �9.3 XII Applications 7 7 00.0 Total I04 00.0 00.0 285 N 2: Intended Audience description lntended Audience description Cumulative Frequency Percent Valid Percent Percent !Valid 962 87.I 87.1 87.I Developers 89 8.I 8.I 95.2 End Users/Desktop 20 1.8 1.8 97.0 Other Audience 8 .7 .7 97.7 System 25 2.3 Administrators 2.3 100.0 Total 1104 100.0 100.0 N 3 : License Description License description Cumulative Frequency Percent Valid Percent Percent Valid 1003 90.9 90.9 90.9 Artistic License 1 .I .1 90.9 BSD License 8 .7 .7 91.7 Eclipse Public License 2 .2 .2 91.8 (EPL) GNU General Public 7 .6 92.5 License (GPL) .6 GNU Lesser General 81 7.3 99.8 Public License (LGPL) 7.3 OSI Approved 1 .I .I 99.9 Other/Proprietary 1 .1 .1 100.0 License Total 1104 100.0 100.0 286 N 4 : Operating System Description Opeating system description Cumulative Frequency Percent Valid Percent Percent Valid 993 89.9 89.9 89.9 Linux 15 1.4 1.4 91.3 MacOS I .I .I 91.4 Microsoft 3 .3 .3 91.7 OS Independent 73 6.6 6.6 98.3 POSIX 3 .3 .3 98.6 SunOS/Solaris I .I .I 98.6 Windows 5 .5 .5 99.1 Windows 95/98/2000 I .I .I 99.2 Windows CE I .I .I 99.3 Windows NT/2000 8 .7 .7 100.0 Total 1104 100.0 100.0 N 5 : Project Topics Description Project Topics Description Valid Cumulative Frequency Percent Percent Percent Valid 965 87.4 87.4 87.4 Benchmark 6 .5 .5 88.0 Boot I .I .I 88.0 Build Tools 6 .5 .5 88.6 CGI Tools/Libraries I .I .I 88.7 Code Generators 6 .5 .5 89.2 Communications 4 .4 .4 89.6 Compilers I .I .I 89.7 287 COREA 2 .2 .2 89.9 Database 14 1.3 1.3 91.1 Database Engines/Servers 3 .3 .3 91.4 Debuggers I .I .I 91.5 Dynamic Content 8 .7 . 7 92.2 Education l .I .I 92.3 Email I .I .I 92.4 File Transfer Protocol I .I .I 92.5 (FTP) Financial I .I .I 92.6 Front-Ends I .I .I 92.7 Graprucs 2 .2 .2 92.8 HTTP Servers 3 .3 .3 93. 1 Indexing/Search I .I .I 93.2 Intemet II l.O 1.0 94.2 Intemet Phone I .I .l 94.3 Log Analysis l .I .1 94.4 Logging 3 .3 .3 94.7 Networking 4 .4 .4 95.0 Object Brokering 2 .2 .2 95.2 Office/Business 4 .4 .4 95.6 Operating System 1 .I .1 95.7 Kemels Other/Nonlisted Topic 4 .4 .4 96.0 Packaging I .I .I 96.1 Security I .I .1 96.2 Simulation I .I .l 96.3 Site Management 3 .3 .3 96.6 Software 29 2.6 2.6 99.2 Development Software Distribution 3 .3 .3 99.5 Systems 3 .3 .3 99.7 Administration Vector-Based l .I .I 99.8 Visualization 2 .2 .2 100.0 Total 1104 100.0 100.0 288 N 6: Development Status development status Cumulative Frequency Percent Valid Percent Percent Valid 1014 91.8 91.8 91.8 Alpha 11 1.0 1.0 92.8 Beta 20 1.8 1.8 94.7 Mature 3 .3 .3 94.9 Planning 4 .4 .4 95.3 Pre-Alpha 3 .3 .3 95.6 Production/Stable 49 4.4 4.4 100.0 Total 1104 100.0 100.0 N 7 : Programming language Programming language Cumulative Frequency Percent Valid Percent Percent Valid 993 89.9 89.9 89.9 Assembly 1 .1 .1 90.0 c 8 .7 .7 90.8 C++ 4 .4 .4 91.1 Erlang 1 .1 .1 91.2 Java 85 7.7 7.7 98.9 Objective C 1 .1 .1 99.0 Other 3 .3 .3 99.3 Perl 4 .4 .4 99.6 PHP 1 .1 .1 99.7 PL/SQL 2 .2 .2 99.9 Python 1 .1 .1 100.0 Total 1104 100.0 100.0 289 N 8 : Operating Systems Description Opeating system description Cumulative Frequency Percent Valid Percent Percent Valid 993 89.9 89.9 89.9 Linux 15 1.4 1.4 91.3 MacOS 1 .1 .1 91.4 Microsoft 3 .3 .3 91.7 OS Independent 73 6.6 6.6 98.3 PO SIX 3 .3 .3 98.6 SunOS/Solaris 1 .1 .1 98.6 Windows 5 .5 .5 99.1 Windows 95/98/2000 1 .1 .1 99.2 Windows CE 1 .1 .I 99.3 Windows NT/2000 8 .7 .7 100.0 Total 1104 100.0 100.0 290 N 9 : proj_unixname Valid acceleo 31 2.8 2.8 2.8 activexml 20 1.8 1.8 4.6 apollon 3 .3 .3 4.9 asm 4 .4 .4 5.3 aspire 19 1.7 1.7 7.0 azuki 3 .3 .3 7.2 barracudamvc 7 .6 .6 7.9 been 12 1.1 1.1 9.0 bonita 15 1.4 1.4 10.3 bpmadmin 14 1.3 1.3 Il.6 byline 13 1.2 1.2 I2.8 cardamom 2 .2 .2 13.0 carol 27 2.4 2.4 15.4 celtix 27 2.4 2.4 I7.8 clif I7 1.5 1.5 19.4 crni 12 l.l 1.1 20.5 deployment 5 .5 .5 20.9 director 4 .4 .4 21.3 dods 5 .5 .5 21.7 dotnetj 2 .2 .2 21.9 dragon 5 .5 .5 22.4 dream II 1.0 1.0 23.4 dryverl 2 .2 .2 23.6 dysoweb 4 .4 .4 23.9 eaf 3 .3 .3 24.2 easybeans 30 2.7 2.7 26.9 easywsdl 11 1.0 1.0 27.9 eclipse-update 7 .6 .6 28.5 edemos 3 .3 .3 28.8 enhydra 5 .5 .5 29.3 epaf I .1 .1 29.3 exoplatform 42 3.8 3.8 33.2 fe derid 11 1.0 1.0 34.1 fo o 5 .5 .5 34.6 fractal 34 3.I 3.1 37.7 frascati 9 .8 .8 38.5 gasp 7 .6 .6 39.I gotm 5 .5 .5 39.6 OX l 1 �6.1 291 octopus 4 .4 .4 68.7 odis 4 .4 .4 69.0 ofccharts 1 .1 .1 69.1 oncept 2 .2 .2 69.3 opalval 5 .5 .5 69.7 openediint 2 .2 .2 69.9 openmobileis 1 .1 .1 70.0 ops 5 .5 .5 70.5 orchestra 19 1.7 1.7 72.2 orientwareccm 1 .I .1 72.3 oscar 2 .2 .2 72.5 oslcv3 12 1.1 1.1 73.6 oyster 3 .3 .3 73.8 pa.Je 5 .5 .5 74.3 pargres 9 .8 .8 75.1 perseus 7 .6 .6 75.7 petals 41 3.7 3.7 79.4 pkuas 2 .2 .2 79.6 polyorb 4 .4 .4 80.0 rfid 3 .3 .3 80.3 rubbos 3 .3 .3 80.5 rub is 3 .3 .3 80.8 s4allsdk 3 .3 .3 81.1 salome-tmf 13 1.2 1.2 82.2 scarbo 6 .5 .5 82.8 shark 7 .6 .6 83.4 siteadmin 27 2.4 2.4 85.9 snapper 2 .2 .2 86.1 soda 1 .1 .l 86.1 sofa 15 1.4 1.4 87.5 spagic 7 .6 .6 88.1 spago 7 .6 .6 88.8 spago4q 5 .5 .5 89.2 spagobi 12 1.1 1.1 90.3 speedo 8 .7 .7 91.0 starwebservice l .1 .l 91.1 stock-online l .l .1 91.2 surf 4 .4 .4 91.6 think 49 4.4 4.4 96.0 292 howl 7 .6 .6 40.2 interldap 9 .8 .8 41.0 introspector 1 .l .1 41.1 ishmael 7 .6 .6 41.8 istx 1 .I .I 41.8 ivy 6 .5 .5 42.4 j2ws 1 .I .1 42.5 jac 3 .3 .3 42.8 jasmine 26 2.4 2.4 45.1 jass 4 .4 .4 45.5 javaservice I .1 .I 45.6 jawe 5 .5 .5 46.0 jeffree 2 .2 .2 46.2 jmimetypelib 1 .I .I 46.3 jnetcontrol 1 .1 .I 46.4 jonas-doc 44 4.0 4.0 50.4 jonathan 9 .8 .8 51.2 Joram 6 .5 .5 51.7 jorm 7 .6 .6 52.4 jotm 12 1.1 1.1 53.4 jsurvey 2 .2 .2 53.6 jwtgen 4 .4 .4 54.0 kelly 4 .4 .4 54.3 kelp 5 .5 .5 54.8 kilim 7 .6 .6 55.4 kilim2 2 .2 .2 55.6 lemonldap 5 .5 .5 56.1 lewys 15 1.4 1.4 57.4 lomboz 9 .8 .8 58.2 mass1v 3 .3 .3 58.5 maven 56 5.1 5.1 63.6 medor 11 1.0 1.0 64.6 mesh I .1 .1 64.7 mobilitools 1 .1 .1 64.8 modfact 13 1.2 1.2 65.9 monolog 9 .8 .8 66.8 navilis 1 .1 .1 66.8 newsadmin 5 .5 .5 67.3 noah 2 .2 .2 67.5 objectweb-zh 8 .7 .7 68.2 ocelot 1 .1 .1 68.3 293 ubistar 1 .1 .1 96.2 wcms I .1 .1 96.3 wsunit I .I .I 96.4 xm.lc 7 .6 6 97.0 xplus 3 .3 .3 97.3 xquare 3 .3 .3 97.6 xservice 15 1.4 1.4 98.9 xwiki 9 .8 .8 99.7 zeus 3 .3 .3 100.0 Total 1104 100.0 100.0 N 10 : Project Topics Description Project Topics Description Valid Cumulative l " · Build Tools 6 4.3 4.3 9.4 CGI Tools/Libraries 1 .7 .7 10.1 Code Generators 6 4.3 4.3 14.4 Communications 4 2.9 2.9 17.3 Compilers 1 .7 .7 18.0 CORBA 2 1.4 1.4 19.4 Database 14 10.1 1 10.1 29.5 Database Engines/Servers 3 2.2 2.2 31.7 Debuggers 1 .7 .7 32.4 Dynamic Content •.. 8 5.8 5.8 38.1 Education 1 .7 .7 38.8 Email 1 .7 .7 39.6 File Transfer Protocol (FTP) 1 .7 .7 40.3 Financial 1 .7 .7 41.0 Front-Ends 1 .7 .7 41.7 Graphics 2 1.4 1.4 43.2 HTTP Servers 3 2.2 2.2 45.3 Indexing/Search 1 .7 .7 46.0 Internet 11 7.9 7.9 54.0 Internet Phone 1 .7 .7 54.7 Log Analysis ,, 1 •' .7 .7 55.4 Logging 3 2.2 2.2 57.6 294 60.4 61.9 64.7 65.5 68.3 69.1 69.8 Simulation 1 .7 .7 70.5 Site 3 2.2 2.2 72.7 29 20.9 20.9 93.5 Software Distribution 3 2.2 2.2 95.7 Systems Administration 3 2.2 2.2 97.8 1 .7 .7 98.6 Visualization 2 1.4 1.4 100.0 Total 139 100.0 100.0 N 11: Open Source Project Count (Flossmole Project) count proj_name count proj_name count proJ_name count proJ_name 1. activex 2. Jac 3. ops 4. foo 5. apollon 6. jasmine 7. orchest 8. fractal 9. asm 10. Jass 11. orientw 12. frascat 13. aspire 14. Javaser 15. oscar 16. gasp 17. azuki 18. Jawe 19. os1cv3 20. gotm 21. barracu 22. jeffree 23. petals 24. howl 25. been 26. jmimety 27. pkuas 28. interld 29. bonita 30. jnetcon 31. polyorb 32. introsp 33. bpmadmi 34. jonas-d 35. rfid 36. ishmael 37. byline 38. jonatha 39. rubbos 40. istx 41. cardamo 42. JOram 43. rub is 44. oyster 45. carol 46. JOrm 47. s4allsd 48. objectw 49. celtix 50. jotm 51. salome- 52. ocelot 53. clif 54. JSurvey 55. scarbo 56. octopus 57. cmi 58. jwtgen 59. shark 60. odis 61. deploym 62. kelly 63. siteadm 64. ofcchar 295 65. directo 66. kelp 67. snapper 68. oncepi 69. dods 70. kilim 71. soda 72. opal val 73 dotnetj 74. kilim2 75. sofa 76. openedi 77. dragon 78. lemonld 79. spagtc 80. openmob 81. dream 82. lewys 83. spago 84. IVY 85. dryverl 86. lomboz 87. spago4q 88. wsunit 89. dysoweb 90. masstv 91. spagobi 92. xmlc 93. eaf 94. maven 95. speedo 96. xplus 97. easybea 98. medor 99. starweb 100. xquare 101. easywsd 102. mesh 103. stock-o 104. xservtc 105. eclipse 106. mobilit 107. surf 108. xwiki 109. edemos 110. mod fact 111. think 112. zeus 113. enhydra 114. mono log 115. tox 116. pargres 117. epaf 118. navilis 119. ubistar 120. perseus 121. exoplat 122. newsadm 123. wcms 124. paJe 125. fe derid 126. noah 127. j2ws 296 APPENDIX F LIST OF EXPERTS FOR OPEN ONION MODEL VALIDATION Expert Key Years. Affiliation DelphioOEVIHl 6 Universidad ALFONSO, Spain DelphiOOEVJH2 - Carnegie Mellon Univ. Pittsburgh Delphi00EVMN3 8 Amun Honeypot developer on Sourceforge, Malaysia DelphiOOEVAQT4 7 Open source Researcher, MIMOS Berhad, Malaysia DelphiOOEVMEGS 4 Open Source Developer & Web Director, Media Mix Asia Sdn Bhd. DelphiOOEVEY6 8 Open Source Developer, Novell Software, Malaysia Delphi00EVNS7 5 Open Source Developer, Century Software, Malaysia DelphiOOEVTH8 About 1 Open Source Developer, Fireworks year Solutions, Malaysia DelphiOOEVMI9 4 Open Source Developer, INIGO Consulting, Malaysia DelphiOOEVLElO About I Open Source Developer, F-Secure year (Antivirus) Malaysia. DelPhiOOEVYJll 2 Lecturer (Open Source) Multimedia University, Malaysia Delphi00EVNK12 10 Redboot Solutions, Malaysia DelphiOOEVMM13 9 Android Expert, Commonsware, USA DelphiOOEVAZ14 7 Open source Php Developer, PPTM (K), Bahagian Pengurusan Maklumat,Malaysia *Number of years of mvo veme11t 111 ope11 sourcetle vpm e11t pro;ects Survey Conducted By: Supervised By: Aminat Showole Professor Dr. Shamsul Sahibuddin ---·- PhD Computer Science Candidate Dean, AlS FSKSM, UTM UTM 297 APPENDIX G DELPHI VALIDATION ROUNDS Appendix G (No 1) UNIVERSITIUTM TEKNOLOGI MALAYSIA Open Onion Model Validation Delphi Round 2 Open Source Expert Profiling Questionnaire Presented by: Aminat Showole Supervised by: Prof. Dr. Shamsul Sahibuddin 1h 26 July, 2010 298 Survey Highlights This survey's primary purpose is to validate a proposed "open onion model" of open source development process. Literature Review It is interesting to note that the open source development is usually described with onion. Paradigm examples are Crowston's Onion (Crowston & Howison, 2003), Kumiyo's Onion (Kumiyo et al., 2002), Antikainen's Linux Onion (Antikainen et al., 2007) and Herraiz's Onion (Herraiz et al., 2006). However, the onion layers within the fo ur previous onions under study could be generalized and possibly merged together. By doing this, the open onion model emerged. Table below show the evolution of the proposed "open onion model" Onion layers I I Proposed "open Crowston Kumiyo Antikainen Herraiz onion" model Most Core Project Linus Tovald/ Core Project Initiation Internal Developer Leader/Core Lieutenant Developer Layer members Developer Co- Active/Peripher Coders/ Developer Developer Layer developer al Developers Jenitars Maintainers Release Active Maintainers Bug fixers Maintainers Layer Coordinator Developers - User Active Users Readers Testers Mailing list User Layer Most Passive Passive Users Readers Plain Users External Layer External Users 299 Q 1: open source onion structure Would you agree with us that the open source development process is indeed onion structured? Yes definitely Yes, to some extent No Research Questions: );> What Characteristics of Open Source projects have made them synonymous to Onions? );> How well can each layer of the Onion be modeled? );> To what extent could the Open Source Onions be validated? );> What parameters are determinant factors of open source user satisfaction? Target Audience Profiling Questionnaire Q2: Self Assessment [n this section, we seek to identifyour target audience by providing the opportunity for you to candidly and confidentially rate yourself. However, it suffices to note that our criteria fo r "Open Source expert" is someone who has some of the qualities below: Open Source Expe rt Corner Your open source activities Please Indicate below has been involved in Open source development project(s) Written academic literatures on open source with an in-depth understanding of how the open source development works Conducted academic research(es) on open source Teaches open source at institutions of higher teaming And any other relevant skills for an expert apply (Please specify) 300 Ope n Source Professional Corner Your open source activities 1 Please Indicate below Academic Background (E.g Computing, accounting, engineering) Open source projects contributed(please name some) Member of open source project community (please mention the projects which you have contributed) How long have you been working with open source (please indicate by years) How do you believe open source process development should be that you think it is presently not? Do you teach the open source approach to others How long have you been involved in any form of open source activities (e.g teaching, writing books on open source, open source projects development, and other activities) Q3: Any other comments about your open source achievements: Q4: Expert Opinion Required Could you indicate your availability to validate the open onion model? Mark "X" to indicate your option. Available Not available 301 Validation Phases (3 iterations) 1. Complete this questlonnatre and return (First Phase) 2. Open Source Delphi Expert key would be attached to the second questionnaire mainly on the validation across layers of the onion model (Second Phase) 3. The third round validates the user satisfaction metrics (Third phase) 3. Round up with few more questions (Fourth Phase) QS: Would you be willing to participate in the three rounds of the Delphi open source validation for the open onion model? Mark "X" to indicate your option. Only this round I Yes but 2 rounds All the 3 rounds Rewards Open Source Delphi Expert Appreciation Lettere would be provided to you as a token to appreciate your efforts and time. Thank you fo r taking this survey, we will surely get back to you. 302 Appendix G (No 2) VALIDATION OF OPEN ONION MODEL INSTRUMENT(Round 2) Questionnaire on Validation of OPEN ONION MODEL OF OPEN SOURCE DEVELOPMENT DELPHI OPEN SOURCE EXPERT KEY NUMBER (ESSENTIAL FIELD): ---- (Please provide us with your Delphi Expe rt Key number that has been provided to you in the e-mail) INTRODUCTION Objective of the Questionnaire: To validate our open onion model; which has been evolved to support open source development approach. The evolution of our model was based on 3 methods, first was an extensive literature review on open source, and finallywas the use of case studies. The open onion model has evolved to have five layers of open source development community. The questionnaire is broadly divided into five parts (Al to AS): Validation across the Layers of the Open Onion In this section we propose five layers of constructs along with their attributes to be considered as the actual industry practice of open source development. These five layers constructs are project initiation layer, Developer layer, Maintenance Layer, user layer and external layer. These 5-layered constructs have been evolved by us on the basis on our extensive literature review, case studies (sourceforge and Flossmole). Before finalizing, this open onion layers development (parameters comprising each of them) need to be validated by you in this section. Please fe elfr ee to request fu rther clarifications on any of the parameters considered under this survey where necessary 303 SURVEY A: Validation across the Layers of the Open Onion model The five layers and their respective parameters suggested by us fo r developmg quality open source proj ect needs to be validated by you. We look fo rward to and would greatly appreciate any comments, suggestions, presumptions or conditions fo r choosing or rejecting a particular parameter. You may feel free to write more than the space provided for your comments A.l: Project Initiation Layer As the process (�( so/t11•are development changes ji-om conventional to open source approach attributes and clwracreristics �/ an open source development project becomes more challenging especialfy to the organisations wanting to adopt open source software projects and hence \Fe propose that open source project initiation has IIlllCh impact on the quality associated 1vith the resulting open source project. Th e project initiation phase characteristics are defined hy the following attributes: Project registration, project initiator 's skill (define milestones, select pr�ject development platform or reposifOIJ', start build a community, develop pr�ject management process and create sofhmre architecture of the project) am/ reputation (p revious experience in term:; uf contribution to other previous open source development projects) In this research, open source project initiation phase is characterised by the initial steps that need to be taken by the project initiator (i.e project owner or core person) as well as the publicly declared detailed characteristics of the project. 1. Do you think "project initiation layer" of an open source development project need to be considered as an essential factor in determining the resulting user acceptance or success of an open source development process? (Please choose only ONE answer and delete others) ()Yes ()No () Can't Say 2. List reasons fo r considering or rejecting the importance of"Project initiation" phase in the development of open source process. 304 3. Do you think the fo llowing attributes actually influence "project initiation layer·· activities? You ma: "rite · 1· under the column indicating : our choice. Attributes of Project Yes( if this attribute should be No (if this Can't say (if [nitiation Layer considered) attribute should undecided about characteristics not be inclusion/rejecti considered) on of this attribute) 3.1 Project Properties such as: Project name/ Topic e.g CMS, operating system or ERP Project Uri: Accessibility to project fo r ease of contribution License type e.g GPL, MPL Programming Language Support e.g Java And Domain audience e.g end user, developers or industry 3.2 Project initiators' Profile: Educational background of open source project initiator Prime occupation of open source project initiator. No of open source development contributed to by initiator Position held in those projects' community Leadership skill of the project initiator and ability to learn from others Ability to build support for the project And ability to avoid fatal errors such as unclear goals, difficulty in understanding people, underestimating people, fo cusing on code only and fa ilure to build a community 305 4. Kindly suggest any other attribute(s) under "Project Initiation layer" that need to be considered in an open source development process: 4.1 ______ 4.2.______4 .3______5. Please provide justification for your agreement (or otherwise) on inclusion of attributes of "Project initiation Layer" which was chosen by you in the above two questions of no. 3 and 4? A.2: Developer Layer /11 this study, "'Developer Layer " is the second layer in the open onions model which is characterised by a spec!fic hierarchy a./people contributing to the open source prc?ject. The deFelopers are ustw/(v considered as those contributing codes to tlte project as well as other technical details. The details within this layer are captured by some suggested possible motivations o.f developers and some of the attributes that have been jor modeled fo r this layer are Programming Languages, Op erating Sy stem support, License typ es and Topics Covered have been taken into consideration in the development a./ the open onion model. 6. Do you think "Developer Layer Activities" needs to be modeled as pat1 of the open source development process? (Choose only ONE box ami delete others) ()Yes ()No () Can't Say 7. List reasons fo r considering or rejecting "Developer Layer Activities" in the development of open source project. 8. Do you think fo llowing attributes completely describe "Developer Layer Activities" adequately? You may write ·I' under the column indicating your choice. Attributes Of Developer Yes( this attribute No (this attribute Can't say Layer Activities should be considered) should not be (undecided considered) about inclusion/rejec tion of this attribute) 8.l.Requirement for developer contribution Project publicity and Task list Clear conununication channel 306 experience Software Testing Skills 8.2. Open source Developer attraction Programming Language Support Operating System support License type Topics Covered 9. Any other attribute(s) under "Developer Layer Activities" need to be considered in developing an open source process: 9. 1.______ 9.2.______ 9.3.______ 10. Provide justificationfor your agreement (or otherwise) about inclusion of attributes of Developer Layer Activities in above two questions no. 8 and 9? A.3: Maintenance Layer Th e third layer of the open onion model i::> the maintenance layer. At this layer, open source maintenance activities are tracked with respect to their relevant parameters within the open source development community. To attain rhe maintenance hierarchy, the open source developer should haFe pe1jormed excellently well as a de veloper befbre being ·rewarded ' by graduating to the maintenance level. The '·Maintenance Layer " activities details that were captured under rhe open onion model are number of project administrators, Programming Languages, Operating systems support, bug open and CVS commits I I. Do you think "Maintenance Layer activities" be considered relevant within the open source development process? (Choose only ONE box and delete others) ( ) Yes ( ) No ( ) Can't Say 307 12. List reasons for considering or rejecting "Maintenance Layer'' in the development of an open source process. 13. Do the following attributes describe "Maintenance Layer" adequately? You may write ·1' under the column indicating your choice. Attributes of Maintenance Layer Yes (if this No (if this Can't say (if attribute attribute undecided should be should not about considered). be inclusion/rejec considered tion of this ). attribute) 3.1 Development ofmaintenance Plan Develop and test codes Problem discovery Identify optimal solution Present code changes for review Discover new functions required Document code changes to repository Commit code 3.2 Maintenance Layer Parameters Project administrators Programming Language Operating System support Percentage of bug open Percentage of CVS commits 14. Any other attribute(s) under Maintenance Layer that need to be considered w the development of open source process: 14 .1______14 .2______4 1 .3______ 15. Provide justification for your agreement (or otherwise) about inclusion of attributes of maintenance layer in above two questions no. 13 and 14? 308 A.4: User Layer The developers and users of open sow·ce are sometimes said /o be the same. This research lui\· idenli/ied !he clislinclin• (ealun:s ht'f\l'{:en 1he111 In rhi\ rnearch !he den·lojJt n al't.. ·egamed a.\ 1hf:. pr�Jf:..sstonal sli.t!led programmers who contnbuted ''ehementzv to the tec:hnical development of the project especially in terms of coding. The user on the other hand does not have to be a skilled programmer ll'ho contrilmtes to the prqject developmenl, however, a user(ski!/ed or unskilled) helps in bug reports, contribute to the user (o rum discussions especially in terms q( posting fo rum requests and getting updates from the projects 'forum messages concerning common issues on the project. 16. Do you think the "User Layer activities" be considered important within the open source development process? (Choose only ONE box and delete others) ( ) Yes ( ) No ( ) Can't Say 17. List reasons for considering or rejecting "User layer activities" within the open source development process. 18. Do following attributes describe "User layer activities" adequately? You may write · I· under the column indicating your choice. Attributes Of User layer Yes( if this No (if this Can't say (if attribute should be attribute should undecided about considered) not be considered) inclusion/rejection of this attribute) 18.I User characteristics Surfs the internet for open source project Join open source community forum Make contributions to open source projects (e.g post bugs & sends fe atures requests) Downloads and uses the software 18.2 User Layer parameters User Interfa ce Domain Audience Topics Covered Natural Language support License types 309 1 9. Should there be any other attribute(s) for "User Layer Characteristics'" that need to be considered in open source development process? Please specifybelow: 1 9.1 ______19.2 ______ 19.3______ 20. Provide justification for your agreement (or otherwise) about attributes of"User Layer Characteristics" in above two questions no. 18 and 19? 21. Any other parameters required to be considered necessary at the User Layer of an open source development process 20 1 . ______ 20.2______ 20.3______ 22. Justifications or assumptions fo r addition of new parameters at the User layer of the open source development process: 23. Any Other Comments/Suggestions fo r the User layer activities: A.S: External Layer TY1e external layer is characterised by the possible uses of open source projects outside the open source deFe!opment process. Va rious organisations/individuals that get hold of the source codes of open source proje cts, adapt it to its organi=ational/indil•idual needs whereby evolving new high quality sojill'are cheaper and fclster. Such organisation/indil'idual may decide not to release the new resulting so.fi ware "open ., in which case the new software becomes a guided asset of such organisation/indil•idual. 24. Do you think "External Layer characteristics" need to be clearly specified within the open source development process in order to determine how the software/source codes should be used by external parties? (Choose only ONE box and delete others). ( ) Yes ( ) No ( ) Can't Say 310 25. Do fo llowing attributes describe "External layer activities" adequately? You may write · l' under the column indicating your choice. Attributes Of External layer Yes( ifthis No (if this Can't say (if (a user at this layer would do attribute should attribute should undecided about some or all of the following be considered) not be considered) inclusion/rejection of activities) this attribute) 25 .I External layer characteristics Surfs the internet for open source project Joins open source community fo rum Does not join open source community forum Downloads source codes Make contributions to open source projects (e.g post bugs & sends fe atures requests) Does not make contributions to the open source project 25.2 External Layer parameters Download volume Topics covered License types Natural language support No of forums Forum messages Project age 26. Should there be any other attribute(s) for "External Layer Characteristics" that need to be considered in open source development process? Please specify below: 26.1 ______ 26.2______ 26.3______ 27. Provide justification for your agreement (or otherwise) about attributes of "External Layer Characteristics" in above two questions no. 25 and 26? 311 28. Any other parameters required to be considered necessary at the External Layer of an open source development process 28.1 ______ 28.2______3 28. ______ 29. Justifications or assumptions for addition of new parameters at the external layer of the open source development process: 30. Any Other Comments/Suggestions for the External layer activities: Th ank you fo r taking our survey. We value your inputs and willget back to you shortly. Appendix G (No 3) VALIDATION OF OPEN ONION MODEL INSTRUMENT (Round 3) Questionnaire on Validation of OPEN ONION MODEL OF OPEN SOURCE DEVELOPMENT _ DELPID OPEN SOURCE EXPERT KEYNUMBER (ESSENTIAL FIELD):__ (Please provide us with your Delph i Expert Key number that has been provided to you in the e-mail) Part-8: Validation of Open Source User Satisfaction Metrics Secondly, Open source user satisfaction metrics was developed which basically points at project download volume and % bug closed as detemlinant factors. The user satisvaction metrics was based on analysis of the open source case studies as described earlier, which shows that projects with high download volumes are usually associated with less bugs open meaning that they have high % of bug closed. This section seeks your inputs on the open source user satisfaction criteria. 312 Part-B: Open Source User Satisfaction Metrics What factors would you suggest that contribute to the user satisfaction of a gtven open source project? Please mark .. x· as appropriate inthe boxes. Project age Users are likely to be more satisfied with projects existing for at least 5years Users are likely to be more satisfied with projects existing fo r>l Oyears Users are likely to be more satisfied with projects existing for > 15years Users satisfaction with open source projects does not depend on proj ect age Development status Users are more satisfied with projects in their alpha/beta status by contributing Users are more satisfied with projects with Stable/unstable status by contributing Users are more satisfied with projects in their mature status by contributing Users are more satisfied with projects in any development status by contributing Users satisfaction does not depend on proj ect maturity in tenns of development status Dow11load volume Users' satisfaction of open source project can be measured by download volume. Users' satisfaction of open source project cannot be measured by download volume. Project Forums am/fo rum messages are performance indicators of user satisfaction in open source development project User satisfaction gets higher with projects having fe west bug open and high bug closed User satisfaction gets higher for projects with high bug open and low bug closed Users ' satisfaction all(/acceptance of opm source project can be measured by other metrics (please sp ecify below): Thank you fo r taking our survey. We value your inputs and will get back to you shortly. 313 Appendix G (No 4) DELPID OPEN ONION VALIDATION FINAL ROUND-THANK YOU Delph i Ope n Source Expe rt Key: There are two sections in this final round. Section 1 provides a general overview of the open onion model and you only need to go through with no comments. Section 2 seeks your general comments on the open onion model validation. This wraps up the fi nal validation round. Thank you for your time. SECTION 1: GENERAL OVERVIEW & DESCRIPTION OF THE LAYERS Project This is the root of the project. This is the initiation phase. The open Layer a initiation source project initiator is the person who started the project and layer eventually, does not necessarily have to be the core maintainer(s). This is the developer's layer. These are the people that are very much interested in the particular open source project and are actually working Developer Layer b according to the available policy documentations and guidelines to layer maintain top-level quality of such projects. However, their contributions are subject to ratification by maintenance layer c This is the maintenance layer. .The maintainers are those people who are Maintenance responsible for the acceptance and rejection of submissions. They match Layer c layer the submissions to the overall objective of the project and determine the suitability of adding such contribution to the existing overall efforts. This is for the users. These set of people are not necessarily programmers, but they want to have a hands-on experience in order to Layer d User layer understand the utilities of the resulting end-product. They are therefore considered very important in the development as their contributions also help in the successful implementation of the project. Various organisations that actually get hold of the raw codes of open source projects and adapt it to suite their organisational needs whereby External evolving new high quality software cheaper and faster. Such Layer e layer organisations may not necessarily release the new resulting software 'open'. The new package therefore becomes a guided asset of such organisation. 314 OPEN ONION VALIDATION PARAMETERS Layers Description I Relevant Parameters -L� -·------ • Proj_name, Project_Uri, Project Age, a Initiation Layer • Domain audience, Prog_lang support, License types ...... ,_. , I b Developer Prog. Lang, OS, License types, Topics Layer . Covered 1--" I , proj_admin, Prog lang, Os support Maintenance c I•• Percentage of bug open, Percentage of Layer Ii I cvs commits • Domain Audience, User Interface, Topics d User Layer Covered I Natural Language support, License , . • Downloads volume, Topics covered, External License type e Layer • Natural Language Support, No_of fo rums, Forum_messages, Project_age, '"·-·-·----'---" SECTION 2: What can you comment on the OPEN ONION MODEL Development? Th ank you fo r taking our survey. We value your inputs and will get back to you shortly. 315 APPENDIX H DELPHI EXPERT'S BACKGROUND (i) Acdemic qualifications of Delphi open onion validation experts Academic Compute MI I Engineerin Mathematic Business undisclose Backgroun r science s T g s Administratio d d n Experts' 6 l 1 2 1 1 2 count (ii) Years of cognate experience with open source development Years of experience Less than 4 years 4 to 12 years Unspecified with open source development Expe11s' count 3 10 2