39
i AN ONION PROCESS MODEL TO SUPPORT OPEN SOURCE DEVELOPMENT AMINAT ABIOLA SHOWOLE UNIVERSITI TEKNOLOGI MALAYSIA
i
AN ONION PROCESS MODEL TO SUPPORT
OPEN SOURCE DEVELOPMENT
AMINAT ABIOLA SHOWOLE
UNIVERSITI TEKNOLOGI MALAYSIA
i
ii
i
ii
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 Information Systems
Universiti Teknologi Malaysia
JANUARY 2011
ii
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: Aminat Abiola Showole
Date: 31ST January, 2011
iii
To
My late father, Alhaji G.S. Alamutu
My sweet mother Alhaja Safiat Atoke Alamutu,
My beloved Children Mubarak, Teslim, Hikmat & Yusrah
My darling husband and best friend, Abdul Wasiu Showole
iv
ACKNOWLEDGEMENT
All Praises belong to Allah (SWT) for making it possible for 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 Abuja, Nigeria, to both whom
I am very grateful.
My deepest appreciation goes to my principal supervisor Professor Dr. Hj.
Shamsul Sahibuddin, for 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 forge 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
faculty of computer science and information system (FSKSM), UTM; and in
particular, Associate Prof. Dr. Ali Selamat for 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
issues.
v
My appreciation goes to my family friends particularly, Abd-Gafar and
Kifayah Fahm and the entire Nigerian communities in Malaysia, for 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 foundation in mathematics and statistics. Engineer Bayo
Adeola is a fantastic brother to me, Dr A.K. Ojo 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, Alhaji ‘Ganiu S.
Alamutu and my mother Alhaja Safiat A. Alamutu for 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
of blessed 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 four
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 1104 open source software
projects details. The support for Pareto (80/20) principle in open source shows that
80% of project 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% for 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.
vii
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 pernah 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
sebenarnya 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
100% 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.
viii
TABLE OF CONTENTS
CHAPTER TITLE PAGE
DECLARATION ii
ACKNOWLEDGEMENT iv
ABSTRACT vi
ABSTRAK vii
TABLE OF CONTENTS viii
LIST OF TABLES xiv
LIST OF FIGURES xviii
LIST OF DEFINITIONS xxi
LIST OF ACRONYMS xxii
LIST OF APPENDICES xxiv
1 INTRODUCTION 1
1.1. Problem Background 1
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 of Research 14
ix
1.6. Significance of Research 16
1.7. Thesis Organization 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 Ajax 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 101
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
xi
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. Verification with Flossmole Project 176
6.7.1. Open Source Projects Distribution on Flossmole 179
xii
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-1: 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-1 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 (11 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
xiii
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. Delphi’s validation findings 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-Project 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 ScummVM project details 91
4.8 WinMerge project details 95
4.9 Eclipse Checkstyle Plug-in activity 97
4.10 MinGW-Minimalist GNU for 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 frequency analysis 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 AVG for Initiation layer Table 152
6.3 Correlations Matrix for 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.11 Correlation for Maintenance Layer for 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 for User Layer 165
6.16 External Layer Data 167
6.17 Project Maturity Vs Downloads 168
6.18 Natural Language Correlations for External Layer 168
6.19 Project Age Correlations for External Layer 169
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
xvii
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 1: 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 for 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
xviii
LIST OF FIGURES
FIGURE NO TITLE PAGE
2.1 Market Share for 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 Tjoa, 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 colors 89
4.8 Scripts on ScummVM 92
4.9 WinMerge File compare window 94
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 Project 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 of User Layer 140
5.10 Open Source Adoption and Implementation in Malaysia 142
5.11 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
xxii
LIST OF ACRONYMS
ACRONYM TITLE
RANK Open source project rank on SourceForge
DA Domain audience
UI No of User Interface
TC Topics Covered
DS Development Status
ND No of Developers
NA No of Admin
%CD % Core admin/ developers
OS Operating system support
NF No of Forums
LT License Types
PL Programming Language
NL Natural Lang. Support
ML No of Mailing List
%BO % of bug open total bug
YR Year registered
xxiii
DD Download volume
FM No of forum messages
%CC % of CVS commit to the total submissions
FR No of feature 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
1
1. Introduction
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 followed by, significance of the
research. The final part spells out the thesis organization.
1.1. Problem Background
Today, software developments are faced with steadily increasing
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
1.1.1. Conventional Software Development Paradigms
The pursuit of technologies for building systems faster, 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 for 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 al., 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 is 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, OO 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
difficult to identify.
Another short coming 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 projects 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 for
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 for
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-solving process of locating relevant components. This explains
why the it is difficult to agree with the abstract of Gill and Grover (2003) where in,
after identifying the urgency for 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 format.
6
Notable academic research activities have been conducted in the field of open
source. It was observed from Madey et al.(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 focused 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 focused 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 software quality.
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 software crisis.
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 fundamental questions for research on principles by which productive
open source work can best be organized since the open source community is mostly
comprised of ‘volunteer’ developers, with differing styles and agendas, who develop
and debug the codes in parallel (Georg and Eric, 2003).
The success of several open source software systems 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 software on the
Internet, Emacs is 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 software crisis 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 modify source 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 software is software whose source code is openly
published, and is usually available at no charge, and which is often developed 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
functionality quickly and because they can mitigate development cost through code
reuse.
9
It is therefore not surprising to note that many firms and governments have
adopted open-source software, since this enables these organizations to reduce costs.
However, economists have found it difficult to 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
successful form of large-scale software reuse. Open-source software offers the most
impressive range of reusable assets for any software project. Open-source software is
available for virtually all activities, runs on every platform, and can be used in almost
every business domain for which software is written (Booch, 2002).
1.1.3. Issues in Open Source Software Development
Numerous issues could be identified within the context of the open source
development model. Paradigm examples of such issues are empirical issues Dalle et
al (2008), problems associated with uses of open source by some software vendors as
discussed in Herwig and Kris (2005), architectural issues in Lennerholt et al. (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 software investors do not fully understand
the open source model, its profitability model is still developing and therefore
unpredictable (Satchell, 2001). Most of the problems with some software that fail the
market acceptability is that the development could not have been funded
continuously until the software attains a high level of quality to be readily accepted
by the community. Some proprietary software (e.g. Microsoft Windows NT) has
been continuously supported by the resource and management committee of the
particular software product 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) maintains their interest, the project (software development) keeps on
going. Also, the ability for users to acquire complete software without 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 difficult to
explain or show the method to anyone else (Raymond, 1999).
Most often, open source development is described based on case studies
(Mockus et al., 2002) and (Gurbani et al., 2006). This is because open source
development does not follow a strict software development methodology unlike the
traditional software development which follows strictly, some software models such
as the water fall and Spiral. However, the necessity to map software development
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
software process 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, successful open source software (OSS) developments are quite
different from one another. For example, Apache allows for volunteers to take part in
all activities while in Mysql, development is done internally within 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 further in
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.
