CHAPTER 3 A THEORETICAL FRAMEWORK OF OPEN SOURCE...
Transcript of CHAPTER 3 A THEORETICAL FRAMEWORK OF OPEN SOURCE...
38
CHAPTER 3
A THEORETICAL FRAMEWORK OF OPEN SOURCE
SOFTWARE DEVELOPMENT
3.1 INTRODUCTION
OSSD process is different when compared to the traditional
proprietary software development. The traditional software process
propositions were not developed with OSSD in mind and thus cannot be
readily applied or tailored to OSSD. OSSD needs its own specific software
process model.
This chapter provides an insight into OSSD process, related core
phases, their evolution and conceptual aspects of development for proper
understanding of the nature of the present study.
In 1970, less than one per cent of the public could describe what
computer software meant (Pressman 2004). Unlike other human inventions,
software is a logical element rather than a physical entity. Therefore, in the
early days of computers, there was no concept of charging money for selling
software. It was an entity, packaged with the computer hardware and all the
source code was freely available. As the use of computers became more
pervasive, software became commercialized (Feller and Fitzgerald 2002). In
order to preserve the commercial value of software, companies started to
deliver software as a black box, where the user could only access the output
features, but the internal structure of the software or the source code was
39
hidden from the user. Protecting the source code is a tool commercial
software development companies use to keep control over the life cycle.
Thus, the end user of commercial software has no visibility or control over the
source code. If a fault occurs, it has to be reported back to the manufacturer or
the maintenance service provider and only authorized parties can locate and
remove faults. This also holds for upgrading the software to adapt to new
requirements. This type of software development is referred to as Closed
Source Software (CSS). As a reaction to the mass commercialization of
software, some programmers felt the need for upholding the concept of
freedom of sharing software.
In 1981, Richard Stallman founded the Free Software Foundation
(http://www.fsf.org/fsf/fsf.html). People of similar interests and ideology
started to develop software, which was available to users free of cost and with
full access to the source code. The software structure was no longer a black
box, but was an open artifact, available to be used, upgraded, maintained or
changed. The GNU Project was launched in 1985 to develop a complete
Unix-like operating system, which is free software: the GNU1 system.
Variants of the GNU operating system, which use the kernel Linux, are now
widely used; though these systems are often referred to as “Linux”, these are
more accurately called GNU/Linux systems (Wu and Ling 2001). Linux was
started in 1991 as a personal project of a Finnish graduate student, Linux
Torvaldas. He posted his code on the Internet and invited people to use it and
find bugs. Over the period of time, Linux has grown to become one of the
most popular operating systems being used (Godfrey and Tu 2001; Kerstetter
et al 2003). In 1976, Bill Gates in his “Open letter to hobbyists”, predicted
that free sharing of software would prevent the writing of good code.
However, Linux prevailed over such predictions and has become one of the
most successful open source projects. Linux, with its interesting development
phenomenon is currently competing well with its commercially developed
40
counterparts. Estimates reveal 8000 person years of effort went into the
development of Linux Red Hat 7.1 (Wheeler 2003). It would cost over 1.08
billion dollars, had it been developed commercially. Eric Raymond in 1999
wrote an article titled “Cathedral and the Bazar” (Feller and Fitzgerald 2002;
Raymond 2003). In the article, he argued that the OSS development method
was a credible competitor to CSS projects. He identified the characteristics of
OSS development that enabled it to maintain a superior quality despite being
a non-commercial endeavour. That paper gained much fame and attention and
the OSS phenomenon became a topic of discussion in the research
community. The OSS paradigm has led to the development of some very
successful software by a community of contributors who share the source
code for free (Kerstetter et al 2003). In recent years, there has been a focus on
OSS projects and several streams of research have emerged in these areas.
However much of the work has been either focused on case studies of
large-scale development projects (Aoki et al 2001; German 2004; Kerstetter
et al 2003; Markus et al 2000; Scacchi 2004; Wheeler 2003). Some have
looked into issues like participation in OSS projects (Bergquist and Ljungberg
2001; Crowston and Scozzi 2002).
Open source software is typically developed by online volunteer
communities of programmers and is available to the public for download, use,
modification and upgrades (Feller and Fitzgerald 2002). Most OSS products
are free or have a nominal charge associated with them. While CSS projects
are struggling to meet costs, user requirements and schedule, OSS projects are
becoming more and more popular. According to internet reports, 80% of the
web servers use Apache, an OSS web server. Many small and medium scale
OSS projects are also finding their way into corporate use. Organizations
claim to have saved millions by switching to OSS solutions. Amazon’s switch
to Linux has reportedly saved them over 7 million dollars. IBM has launched
over 30 of its projects in the OSS community. This interest in OSS projects is
41
not just because of their free availability, but also because of their high quality
and ability to fulfill user requirements (Lerner and Tirole 2002).
The increase in the use of OSS projects demands a deeper
understanding of the OSS development and maintenance process.
Procurement of the software is not the only cost associated with the use of a
software system. Software systems usually have a high operational cost
(Banker et al 1998; Kemerer 1995). Thus, before an organization makes a
decision to use new software, there is the need for considerable evaluation of
the product. The maintenance costs of a software system can be very high, if
frequent changes are made to it. If the adoption of the new system fails, there
could be additional financial losses in terms of loss of data, loss of time, and
loss of technical expertise. The OSS teams also need to be able to have more
control over the evolution of their projects. Some companies like, IBM, have
launched their projects in the OSS domain and have assigned staff to OSS
development. Therefore, for OSS developers, there is a need for research to
determine what factors would affect the long-term lifecycle outcomes of their
projects.
The open source software development approach has enhanced
multi operational potential and technology transparency. It also enables the
volunteer communities to access a vast array of resources and source codes
which speed up the software development and release processes. Software
development is not lagging behind adoption of new methodologies; and
during last three decades, a large number of different approaches to software
development have been evolved and few have been used widely by OSS
developers.
Generally, the OSS development methodologies are treated
primarily as a necessary tool to provide a symbolic status in the volunteer
activities. While these methodologies are considered as too mechanistic,
42
arguments have been advanced by researchers that it is possible for traditional
methods to merely hypothesize ideal development approaches. However, on
the other hand the industrial software developers have become skeptical about
new approaches to OSSD which are difficult to grasp and thus, remain
unused.
There are several similarities in the volunteer activities of software
development methods even though they have their own peculiarities. For
instance, the combination of the invention of the bulletin board system and
the old method of software development to share source code freely among
developers of volunteer community intensified and expanded their activities.
Over the years, with the expansion of communication over the
internet in the post-‘90s, OSSD process inspired the growth of software
development methods and there has been a paradigm shift in software
industry and these offer innovative ways to evolve new software projects.
Also, this has aroused growing interest along with ample research efforts and
discussions concerning the possibilities of the OSS projects for the whole
software producing industry. This feature has increased significantly after
several success projects like Linux, Apache server and the Send-Mail mail
handler.
3.2 DEFINING OPEN SOURCE SOFTWARE
Since 2000s, OSSD has made an extensive impact on Information
and Communication Technology (ICT) industry and it has changed the
method of software development and deployment in several fields.
It is not easy to define the term ‘open source software’ with few
words, due to the existence of many categories and variants of OSS projects
access methods. Therefore, it is necessary to first understand the meaning of
43
OSS in terms of source code made available to volunteers. Source code
implies a set of instructions written in a computer language in the form of
computer software for specific application usage. When such computer
software is available freely to access by computer users with the liberty to
modify the source code of the computer software, it is known as open source.
In other words, a well-managed open source software project will accept any
improvements in the form of updates, which modifies the program to solve
someone else’s slightly different problem. Releasing new versions of the
software with the new features ensures that everyone benefits from these
changes. In a broader perspective, open source software is developed in a
collaborative manner and most of the developers are volunteers. Although this
collaborative method of development has created a substantial amount of
software, the software development procedure is often described as
unstructured and unorganized.
Open source software is software whose source code is also
published and made available to the public and it enables anyone to copy,
modify and redistribute the source code without any royalties or fees.
Initially, the term ‘Open Source’ was introduced by Eric Raymond (1998).
Open source doesn't merely mean access only to the source code. The
distribution terms of open-source software have to comply with the following
criteria:
• The software must be freely distributable.
• The source code must be included in the distribution or there
is a well-publicized method of obtaining the source code.
• Derived works and modifications are to be allowed.
• The license must not be specific to a product, not restrict other
software and be technology-neutral.
44
These features show that the OSS phenomenon deserves rigorous
exploration and investigation. For the purpose of the present study, OSS is
defined as “a type of software whose source code is released by the impact of
multiple factors and to be made available to volunteers to enable them to
modify with focus on quality and redistribute without any constraints”
3.3 EVOLUTION OF OPEN SOURCE SOFTWARE
While OSS emerged rapidly in late 1990s, the concept of sharing
ideas on software source code can be traced back to several decades
(Levy 1984). In 1960s, when IBM and others commercialized computer sales,
software and source code was freely shared among computer users. In late
1960s, the situation dramatically changed after the “unbundling” of IBM
copyright software, and in mid-1970s it was usual to find proprietary
software, in the sense that users were not allowed to redistribute it, that source
code was not available, and that users could not modify the programs.
The origin of present OSS movement is traced back to late 1970s
and early 1980s. Two different volunteer groups have emerged as the primers
of the open source software Movement. Richard Stallman launched the GNU
Project and the Free Software Foundation. The ultimate goal of the GNU
Project was to build a free operating system. The Computer Science Research
Group (CSRG) of the University of California was improving the Unix
system, and building lots of applications which quickly become Berkeley
Software Distribution (BSD) “BSD Unix”. These efforts were funded mainly
by DARPA contracts, and a dense network of Unix hackers around the world
helped to debug, maintain and improve the system. During many time that
software was not redistributed outside the community of holders of a Unix
AT&T license. But in the late 1980s, it was finally distributed under the
“BSD license”, one of the first open source licenses.
45
During later years, in 1980s and early 1990s, the development of
open source software continued in relatively isolated volunteer groups.
Internet helped to coordinate transnational efforts, and to build up strong user
communities. Gradually, many of the open source software already developed
were integrated, merging the developed source code of many of these
volunteer groups. Subsequently, complete environments could be built on top
of Linux using open source software.
Further, the late 1990s witnessed the rapid growth of open source
software development. Open source systems based on GNU/Linux or BSD
gained popular public acceptance, and have become real alternative software
to proprietary software systems.
Given the major influences and positive impacts of OSS projects,
there is an increasing interest in understanding and utilizing the process
underlying in OSS development activities in terms of OSSPM.
The above observations and projects justify the importance being
given to the role and use of open source software development and it can be
extended to Government sector, education and Information Technology (IT)
industry.
3.4 OSS IN INDIA
In a developing country like India, especially, in Government
sectors, the costs associated with licensing fees of proprietary software and
the requirements of such software are not meeting the individual needs.
Former Hon’ble Indian President Abdul Kalam (2004) emphasized the need
for introducing “open source software in defense”. Recognizing its
importance, he called upon the engineers to develop and implement OSS
since the technical know-how is fully available in the OSSD process. Even in
46
other countries like Norway, an open source operating system like Linux has
been given a winning support by Government authorities. Similarly, the
National Resource Centre for Free/Open Source Software (NRCFOSS)
project funded by the Department of Information Technology (DIT),
Government of India, promotes OSS in India, Phase-I (2005) was carried out
by C-DAC and KBC Research Centre of Anna University initiated OSS
Project to develop and promote the Indian version of Linux distribution
named Bharat Operating System Software (BOSS). Phase-II (2009) has
commenced as a multi-institutional project of DIT involving
C-DAC, Anna University and IIT.
Hence, there has been a growing degree of interest in using open
source software applications especially, due to the advantages like
cost-cutting and skill development among ‘open source software developers’.
IT industry is already providing multiple advantages to academic
institutions through implementing open source software and such advantages
include absence of user restrictions, reduced cost, and vendor lock-in. And
also it is consistent with traditional academic values of openness and
coordination. The greatest benefit from the OSS community for educators is
to provide a technical, social, and legal framework which is capable of
harnessing IT to improve the learning skills and for developing ‘open source
software’. These virtual communities are composed of individual developers,
end-users as well as very large organizations worldwide. Programming of
source code can evolve through such virtual community coordination. Thus,
open source software has been receiving greater attention during the last few
years. This research study focuses on the release management, a part of
software development process in OSSPM.
47
3.5 OSSD PARADIGM
Software development is the process that is carried out before it is
launched as an operational system. In traditional software development, the
activities during this phase include requirements and system specification,
initial design, software coding and testing. There are various methodologies
available for carrying out software development e.g. Waterfall, Spiral, Agile
and Rapid Application Development etc. These methodologies specify issues
like team formation, task assignment, milestone definition and cost and
scheduling of the project (Pressman 2004). The failure rate of software
development projects is very high. The 90% syndrome in software
development projects implies that the majority of software development
projects fail to meet the expected time and cost schedules (Abdel-Hamid
1988; Brooks 1995). This failure affects the overall system costs and
performance. Much of software engineering research has been focused on
identifying the causes of software project failure. The community has been
long in search of a silver bullet that would help overcome this great challenge
(Brooks 1995). Once software code is complete and has been tested; it is
ready to be operational and to be used by the customer. However, the nature
of software is such that it undergoes change throughout its life. Any change
made to the software product after its development has been completed, is
called software maintenance (Pressman 2004; Zelkowitz et al 1979). Software
maintenance may include activities like fault correction, improvement of
performance or adaptation to changes in the operational environment
(Pressman 2004).
The OSS paradigm suggests the source code to be freely available
for modifications and redistribution without any charges. Feller and Fitzgerald
(2000) identified the following significant features of OSS development:
48
a) Technological: the need for robust code, faster development
cycles, higher standards of quality, reliability, stability, m ore
open standards and platforms.
b) Economical: the corporate need for shared cost and shared
risk.
c) Socio-political: scratching a developer’s “personal itch”, peer
reputation, desire for “meaningful” work, and community
oriented idealism.
Many of the well-known OSS development projects are focused on
development tools or other platforms that are used by professionals who have
often participated in the development effort themselves. OSS is not a
compilation of well-defined and published software development practices
constituting a well-expressed method.
The OSSD development differs from the other software
development modes in logical, economical, and team structural aspects, it
does in many ways follow the same lines of thought and practices as other
active methods of software development. The OSSD process begins with
early and frequent software releases and at the same time it lacks many of the
traditional mechanisms used for coordinating software development with
plans, schedules and defined processes. Generally, any OSSD project consists
of the following visible phases:
a) Problem discovery
b) Finding volunteers
c) Solution identification
49
d) Code development and testing
e) Code change review
f) Code commit and documentation
g) Release management.
Schematically, the above aspects can be viewed as follows.
Figure 3.1 Open source software development phases (Iterative method of software development)
OSSD
Problem Discovery
FindingVolunteers
SolutionIdentification
CodeDevelopment
&Testing
CodeChangeReview
CodeCommit
and Document
ReleaseManagement
50
Figure 3.2 Open source software development life cycle
Mockus et al (2000) also depicted the OSS software development
methods with the above stages, the interest lies in how this process is
managed, as can be seen in how the OSS development method is
characterized by the following statements:
a) the systems are built by potentially large numbers of
volunteers;
b) work is not assigned and people themselves choose the task
they are interested in;
c) there exists no explicit system in level design;
d) there is no project plan, schedule or list of deliverables;
51
e) the system is augmented with small increments; and
f) programs are tested frequently.
The process of OSSD is organized as a massive parallel
development and debugging effort. This includes loosely-centralized,
cooperative and free of charge contributions from individual developers.
However, there are also indications that the approaches towards OSSD is
changing. The OSSD process does not include any predefined formal
documentation norms or approaches.
3.6 ANALYZING THE ROLES AND RESPONSIBILITIES OF
DEVELOPERS
Many of the prior studies on open source have focused on the
motivations of developers (Hann et al 2004; Wan et al 2004). People were
curious about why OSS developers are willing to spend so much time and
effort on something they are not paid for. In addition, as the open source
software became more and more popular to the general public, some
researchers started to examine the motivations of organizations to adopt the
open source software (Lerner and Tirole 2002; Kogut and Metiu 2001;
Dedrick and West 2003).
The OSS development process and activities are quite active.
However, there is a need for some form of structure or else it would never
have been able to witness such enormous growth in the past years. Longtime
volunteer developers and established organizations have started to show
interest in OSS. Among these, for example: notably are IBM, Apple, Oracle,
and Intel Corporation. In this perspective, in larger OSS projects, the
developer communities have taken the role of coordinating, mediating and
acting in project management activities.
52
The emergence of the repository sites are another new phenomenon
like Fresh meat and Source Forge, which have established development
websites with a large repository of Open Source code and applications
available over the Internet for developers and computer users. The OSSD
effort structure involves several levels of volunteer participation in their
development activities:
a) Project leaders who have the overall responsibility for the
project and who usually have written the initial code
b) Voluntary developers who create and submit code for the
project. These can be further specified as:
o Senior members or core developers with broader overall
authority
o Peripheral developers producing and submitting code
changes
o Occasional contributors
o Maintainers and credited developers
c) Other individuals who, in the course of using the software,
perform testing identify bugs and deliver software problem
reports
d) Posters who participate frequently in newsgroups and
discussions, but do no coding.
3.6.1 The OSSD Process
It is continuous in nature, as software development is evolving
endlessly. Even though large number of volunteers may be participating in the
53
OSSD projects, usually there is only a small group of developers performing
the main development activities of the work. Some of the main aspects in the
OSS approach include the division of developer, co-ordination mechanism
among them, distribution of decision-making responsibility, and informal
structure of the projects. Researches characterize the OSS development
activities in the following terms:
a) OSS systems are built by potentially large numbers of
volunteers.
b) Work is not assigned; people undertake the work they choose
to undertake.
c) There is no explicit system-level design, or even detailed
design.
d) There is no project plan, schedule, or list of deliverables.
To work successfully, the geographically dispersed volunteers and
small groups of developers need to have well-functioning and open
communication channels between each other, especially, as the developers do
not usually meet face-to-face.
3.7 STRUCTURE, COMPOSITION, AND ROLES OF
VOLUNTEERS
In OSS projects, there is no substantial difference between
developers and end-users. All end-users involved in OSSD activities are
potential developers and depending on one’s involvement and contribution,
anyone can assume any role. OSS communities virtually have a hierarchical
structure with loosely coupled membership.
54
Many researchers have suggested a hierarchical or onion-like
model structure to describe individuals’ positions and roles in OSS
communities. According to the Onion model shown in Figure 3.3, OSS
communities consist of successive layers of member types and roles.
Figure 3.3 Onion Model (Source: Crowston et al 2004)
The Onion-pyramid model is advocated in the context of
organizational structure of OSS communities as shown in Figure 3.4.
3.7.1 Core Team
At the center of the community is the core team composed of core
and active software developers, and a project leader. These individuals have
been involved in the project for a long time and are perceived to be aware of
the functions and structure of the OSS project. The core team is usually small,
who contribute most of the source code and active software developers
regularly contribute new features and bug fixes. They are the one who act as a
driving forces behind the project.
55
Figure 3.4 Onion-pyramid model (Source: Crowston et al 2004)
3.7.2 Contributors
Next to the core team is a group of co-developers of OSS
volunteers community who occasionally submit patches (e.g. bug fixes),
contribute new functionalities or features which are reviewed and checked in
by core developers. This group has more members in a successful community
or project.
Active-Users: Active users are those who make a significant
or sporadic contribution to the OSS community. They may not
access and contribute code but are active users of the software
and are, therefore, best positioned as bug hunters and fixers.
They download and use the latest released products and try to
understand how the software works.
Passive Users: These passive end-users just download and use
the software. Most the members of the OSS community are
passive members. While this group does not directly
contribute to the project development activities, they play an
56
essential role in the community and their very presence
motivate other community members to whom a large
population of users is the utmost reward and flattery of their
hard work.
3.7.3 Changing Roles
The developers’ community is capable of producing quality source
code and can open its doors to others who are perceived to be less hacker-like.
The existing developers’ community is capable of lowering barriers for
potential developers and new computer users. Describing community
structures in terms of onion circles does not limit members advancing from
one layer or role to another. Individuals create a sustainable community by
increasing their involvement through a process of role efficacy, which varies
from one project to another. Through sustained contribution, active users are
recognized and gradually move from one role to another. Passive users, on the
other hand, may also become active users and might, in due course, become
developers or co-developers. A few contributing co-developers will
eventually join the small team of core developers. Essential project activities
such as reviewing, approving, and committing code to the project’s source
tree are mostly done by the trusted core and co-developers. Developers who
may have earned sufficient credits with the core team may also contribute to
essential project activities.
The OSS development process is sustainable because successful
projects evolve along with their communities. The growth rate at which a
given project’s community evolves is directly proportional to the positive
contributions made to it by the OSS community. Such contributions not only
change the role and the degree of influence of the individuals in the
community, but also evolve the whole community and act as sources of
evolution of the OSSD system.
57
Software maintenance claims a large proportion of the lifecycle
costs of a software system and is a large component of the Information
Systems (IS) budgets of organizations. According to estimates, software
maintenance consumes more than 80% of the lifecycle costs of software
systems (Erlikh 2000; Moad 1990). From the point of view of organizational
resources, IS departments spend 50-80% of their budgets on software
maintenance (Dekleva 1992; Huff 1990). Therefore, there is a considerable
interest in the improvement and control of the process of software
maintenance. Many of the problems of software maintenance are a result of
software development and design inadequacies (Schneidewind 1999;
Swanson and Beath 1997). Therefore while studying the operational
maintenance of software, it is critical to have a deeper understanding of
software development (Banker and Slaughter 1995).
3.8 CHARACTERISTICS OF RELEASE MANAGEMENT IN
OSSPM
The OSSD success factor is a key issue relevant to the OSSD
process. Crowston et al (2003) conducted research to identify the success
factors of OSSD. In their study, some conceptual factors such as user,
product, process, developers, use, and recognition were identified and shown
to be success factors of OSSD projects. They also stated that the OSSD
process is not a one-off event as CSSD usually is, but rather an on-going
activity that involves continuously updating and releasing new versions of the
software. Another study (Chin and Cooke 2004) found that intrinsic and
extrinsic motivational factors, project coordination, project characteristics,
and group trust of members in the OSS community affect the member’s job
satisfaction, and ultimately the OSS project’s success.
Through a case study of an OSSD project, Jensen and Scacchi
(2004) identified three issues of OSSD: collaboration, leadership and control,
58
and conflict resolutions of intra-community and inter-community. Clearly, the
researchers of information system are becoming more and more aware that
social factors play a more important role in OSSD than they do in CSSD. The
membership of an OSSD project is open (i.e., people can freely join or leave
projects at any time). This leads to some particular phenomena in OSSD. The
Ising theory describes basic patterns in dynamic interactions among physical
objects or economic agents. One study (Oh and Jeon 2004) applied the “Ising
and Herding Model” in marketing research to study membership dynamics
and network stability. It found that OSSD projects inherently bear the
characteristics of herded exits by its participants, which may be the leading
susceptibility and vulnerability of OSSD projects. Another study on open
membership applied social network theory to OSSD (Madey et al 2002) and
identified the “band-wagon” effect (i.e., the “rich get richer” phenomenon) in
OSSD. The initial success of an OSSD project induces more success down the
road because good developers prefer joining successful projects. Therefore, it
is crucial for an OSSD project to achieve a critical mass shortly after it is
launched. Ulhoi (2004) viewed OSSD as a process of innovations. He used
“private model of agency” and “collective model of agency”, to represent the
concept of closed source and open source software “innovation”.
Open source innovation, or the collective model of agency, features
1) non-proprietary and collectively owned knowledge 2) psycho-social
motives 3) social control mechanisms 4) low cost of participation
5) cooperation between innovators 6) free-riders are not considered a problem
7) the value of knowledge increases with wide consumption and 8) market
flexibility. Ulhoi’s view of the OSSD process emphasized the social effects
involved in OSSD. This study of OSSD from the economics perspective
brought us fresh insights into OSSD. Several studies in the Information
System area have investigated the issues related to the OSSD process in
particular.
59
According to Berglund and Priestley (2001), the nature of the
open-source development (process) is typically (among other characteristics)
“robust, public, just- in-time, user-driven, global, community oriented,
critical-mass dependent, non-directional in its growth, developed from the
bottom up, and change-prone”. Their research, though focused particularly on
the OSSD documentation process, has raised some issues that can be
generalized to the OSSD process, such as user control/driven, social structure
of the community, and live and face-to-face communication forum. Mockus
et al (2002)’s research is a more comprehensive effort in identifying factors
related to the OSSD process. They used computer aided quantitative research
methods to analyze and compare the electronic archives of Apache and
Mozilla with several other commercial projects. According to their research,
these factors are found to be related to the OSSD process: 1) the size of the
community 2) the work distribution among the community 3) problem
reporting 4) code ownership 5) defect density and 6) time to resolve reported
problems. Based on these constructs, they proposed some hypotheses about
the OSSD process. Among the previous studies in OSSD, Wu and Ling
(2001, P.34) is possibly the only one that proposed a framework of the OSSD
phases starting with the launcher’s “personal itch” and ending with the
official version release. However, this framework of OSSD phases is too
generic to serve as an effective OSSD process model.
At present, most of the software developers concentrated their
efforts on the large OSS tools and internet based OSS project activities. The
OSS development method itself does not bring forth any special application
domains nor does it set any limits for the size of the software, as long as the
suggested development projects comply with the elements that the OSS
development methods are founded on as described above.
60
Future trends also rely on taking advantage of global developer
collaboration, while OSSD efforts are continuously producing raw material
that can later be harnessed to commercial exploitation (O’Reilly 1999). As for
as OSSD paradigm is concerned, it may be viewed as a structure using the
software applications with back-office infrastructural support systems
involving a huge number of volunteers. The OSS development process itself
can be implemented with different specific software development methods,
although these methods must comply with and allow for the characteristics of
the OSS paradigm. Thus the process can have open aspects, but on the other
hand, the development process itself can be slowed down resulting from
several reasons, e.g., lack of interested and skillful developers, and conflicting
views. The geographically dispersed volunteers community could benefit
from analyzing the pros and cons of the different OSS methods and adopting
the appropriate approaches in their specific requirement of software
development.
In fact, release management in OSS projects implies managing the
process of developing, integrating and distributing the final stage of the
software for end-users’ usage. Here, an explanation of process of release
management is presented. The explanation also provides a checklist that can
be useful when making a release.
In open source software project development, the software is
released early and frequently and therefore, it is essential to have a
well-defined release process in place for creating such releases, than it is for
most other activities in software development. This is necessary to ensure that
all related issues are addressed and quality of the product during release is
ensured for acceptance by end-users. This does not mean that a release must
be complete or that it must be bug-free in practice. In other words, it simply
61
means that the status of each release is systematically documented to meet the
expectation of the end-users.
Specifically, a number of roles are involved in the release
management process. At the earlier stage of the project level, it is possible
that such roles will be carried out by individual developer. At the maturity
stage of the project, the release process is separated out and delegated to
different team members of the developer community. The release
management process consists of the following roles:
a) Architect (Developers): the person responsible for identifying,
creating and implementing the release process
b) Manager: the person coordinating the release process
c) Facilitator: the liaison between all stakeholders in a release
The major steps in the release management process needs an
analytical understanding, as it is the most significant phase in the OSSD life
cycle. When the project is at the stage of creation of a release, it is essential to
ensure compatibility of the source codes. The project source code depends on
some external functionality, each of which has its own software development
approach.
The role of architect is confined to identifying, creating and
implementing to integrate the release process of the source code. The role of
the manager is to co-ordinate the activity to check and redistribute the source
code among developers. The facilitator acts as a communicator between the
developer and the end-users.
The scope and planning of the OSS project is determined the
project manager and in the process, he needs to allow participation of the
committed developers and end-users. The end-users also have an important
62
role to play in testing the prospective release process and adopting the release
once it has been made final. To achieve this objective, all communication
about the scope and planning of the release activities needs to be made
accessible to end-users. As the release manager oversees the overall activities,
its controlled by the facilitator of the OSS project.
3.9 MAINTENANCE OF RELEASE THROUGH VERSION
CONTROL PROCESS
Each release phase needs identification and this can be through
version control process by numbering the different release phases. Such
numbers are not fully arbitrary but are used according to a specific scheme
that gives additional information about the released projects. Many schemes
can be considered for allocating version numbers in software releases
activities. In few OSS projects, postfixes can be used by identifying the
version number to indicate the stability of the source code. Using a version
control system in release management activity is crucial for maintenance of a
released product. It allows the OSS project to build further by having the
released product as a main version. Thus, the evolution of project phases
continues on the release in a separate phase without interfering with the main
development activities.
In each stage of release process, communication with the OSS
community is of prime importance, especially, in the period just before the
release of a product. In view of the geographically distributed nature of open
source software projects, communication is the key tool for ensuring the
developers commitment of source codes towards release activities. Once the
source code has been committed by the developer, the architect is responsible
for generating the release of the project and assigning the version number for
the released project. In practice, implementation a ‘code freeze’ method is a
desired preference while the architect is working on the release activities.
63
Also, it is the facilitator's responsibility to inform the OSS community that the
release of a project was completed and is available for end-users.
Towards the final release, critical bugs or errors found in the source
code have to be fixed before the final release is generated. This process
involves fixing a patch to the released product and creating a new release of
project with a different version number. This process is repeated until no
more critical errors are found during release activities.
Then the newly released product is made available to end-users
through the OSS project's distribution channels in the form of release
repository in a common server. Such channels have to be capable of handling
the anticipated demand for the released product. For this function, the
facilitator’s role is significant.
In many OSS projects, usually resistance in early release is
experienced, saying that the source codes are incomplete and needs to be
fine-tuned or it has not been fully tested. Releasing of incomplete source code
is not encouraged by the developers. This aspect has a bearing on best
practices in release activities.
Release is often described as ‘Release early, release often’ activity
in OSSD. The main reason includes:
a) encouraging early and frequent feedback;
b) providing easy access to the latest and greatest features;
c) building developer confidence;
d) showing genuine project activity; and
e) facilitating a manageable upgrade path for end-users
64
‘Release early, release often’ is a crucial element in developing and
releasing a sustainable OSS project. Sometimes, end-users become
contributors and make the project stable. The emphasis is on the real status of
the release which draws attention of end-users towards known bugs in release
activities. This aspect influences the success of open source software projects.
The success of OSS projects is sufficiently proved in few case
studies and one such case study related to a OSSD project is – ‘Apache
Cocoon’.
3.10 COMMUNICATIONS IN VIRTUAL ENVIRONMENTS
A definitive feature of OSSD is its virtual development
environment. Admittedly, CSSD projects can also sometime work in virtual
development environments. However, OSSD is entirely accomplished in the
virtual environment and totally subjected to the virtual community’s norms.
Recently, there have been extensive studies on online virtual communities.
The practices of these virtual communities are also called computer mediated
communications, or electronic network of practice (Wasko and Faraj 2005). It
was defined as “self-organizing, open activity system focused on a shared
practice that exists primarily through computer mediated communication”
(Wasko and Faraj 2005). The online virtual communities have these
characteristics: “Virtual” members are in scattered physical locations; Peer-to-
peer, decentralized structure (Kwok and Gao 2004): there is no “leader” in the
normal sense; Anonymous members: members usually use online nicknames
instead of their real identifications, although it is becoming less so in the
OSSD community. Open membership and voluntary contribution:
membership is open and free to the public; members voluntarily contribute
knowledge to the communities.
65
Asynchronous communication mode (Nah et al 2002): in most of
the online virtual communities, one cannot get immediate feedback. The most
important function of the virtual community is communication. The fast
developing technology is more or less helping virtual communities catch up
with their physical counterparts in terms of effective communication (Etzioni
and Etzioni 1999).
Quality knowledge sharing in virtual community is difficult to
maintain according to Wasko and Faraj (2005). Since, the membership is
open and voluntary, knowledge seekers have no control over who will
respond to their inquiries and the quality of the responses. Another obstacle to
quality knowledge sharing in virtual communities is that contributors have no
idea whether those they helped will ever return the favour (Wasko and Faraj
2005). In addition, leadership in a virtual community is also different from
that of traditional community. Many leaders in the virtual environments
agreed that they have to build some level of personal relationships with the
virtual team members before initiating working relationships with them
(Pauleen 2003). In the virtual environment, the steps and strategies of
building relationship between a leader and team members are also unique.
Due to its virtual nature, the OSSD community is subject to the above specific
environmental limitations/requirements as well. Several researchers in OSSD
stressed the importance of virtual community functions for the success of an
OSSD project.
Surprisingly, despite the reality of thin communication media in
virtual communities, the open source movement has been very successful. In
retrospect, the reason behind this phenomenon is that there are some
advantages of a virtual environment that actually benefit OSSD. Furthermore,
computer-mediated communication is inherently impersonal and favors
task-oriented and focused exchanges (Hiltz and Turoff 1993). The
66
asynchronous communication in written form allows more time for reflection
before sending out a message. As a result, a virtual community tends to foster
rational decision making. Emotional or authoritative factors seldom become
obstacles to rational decision making in a virtual community (Yamauchi et. al.
2000). Based on the study of Wasko and Faraj (2005), gaining professional
reputation is the leading reason why an individual virtual community
participant contributes knowledge. Therefore, the OSSD project community,
as a relatively stable, professional virtual community, should provide more
motivation to its participants to share quality knowledge than other virtual
communities with more volatile members. To build an OSSD process model
that can effectively guide OSSD practice, we have to first look at the factors
affecting OSSD. Even though the nature of OSSD has been revealed
somewhat by these studies, it remains largely uncharted (Berglund and
Priestley 2001).
3.11 MAIN FACTORS OF OSS RELEASE MANAGEMENT
In recent years, in India, the economic benefits of OSS are
increasingly realized from the introduction of open source software
development technologies. In this context, many institutions have extensively
initiated measures to promote the open source software development and
learning infrastructures with the participation of students and faculty with an
objective of utilizing the open source software in their work place. This new
trend of rapid growth of open source software development and major impact
of the new and innovative software project management strategy has raised
many questions related to open source software development (Feller et al
2005; Von Krogh and Von Hippel 2003). The existing method of Open
Source Software development highly influences the release management
process; and it is considered as the main area of research approach in terms of
quality improvement in open source software project management. This has
67
aroused the interest of researchers in a variety of release approaches
necessitating interdisciplinary research studies.
Release management in OSS is an area which is either largely
unexplored or very few researches have been carried out. The concept of OSS
is characterized by a highly iterative development model in which new
development releases are made available very frequently following the motto
“release early, release often” (Raymond 1999). The aim of this approach is to
gather feedback early and it allows the volunteer community to influence the
direction of a project.
Generally, there are a couple of issues related to the OSS projects
which become more crucial when the project is set for creating a release
process. So far, the open source software release process was mainly confined
to time based release approach (Michlmayr 2007) or feature based release
approach. But either time or feature based approach is not the only optimum
release approach to identify the quality of the OSS. This has been perceived
as a major gap. Therefore, in the present research, for effective
implementation of the release management process and as a measure to bridge
the above said gap, evolving an innovative release approach is considered as
significant.
Thus, this study on release management approach is an attempt to
integrate four areas of project management relevant to OSSPM, viz, (a)
Human Resource Management (b) Communication Management (c) Quality
management and (d) Time Management. A detailed description of these four
areas is given below.
3.11.1 Human Resource Factor in OSS Release Management
As the OSS volunteer communities (human resource) are
geographically wide spread and are involved in different teams for various
68
types of projects, it reflects lack of uniformity in the development of OSS
projects. Their practices in OSS projects impact the activity of the evolution
of release management process. The concept of “virtual community” suggests
that there is a need to develop effective collaboration among the volunteers
with high levels of interdependency and integration in release activities.
Furthermore, the mode of varied and distributed collaborators is evidenced in
a global software release process as the OSS projects increasingly pertain to a
multisite, multicultural and globally-distributed trend in OSSPM.
Generally, the OSS volunteer community movement provides
inspiration for an affordable and reliable solution to many OSS projects and
contributes to the availability of high quality software to end-users. Bridging
the gap in geographical distribution of volunteers and in establishing
uniformity in the release activity, motivation in terms of social and economic
benefits and uniform participation in OSS projects plays a key role.
Usually, individuals feel motivated when they participate in OSS
projects which evolve an open source virtual community work. The element
of motivation for volunteers in OSS projects includes two broad factors:
(a) internal factors (intrinsic motivation and OSS community identity) and
(b) external factors (expected future rewards, fulfillment of personal needs).
The internal factors of motivation among OSS volunteers relate to
enhancement of their programming competency levels and attaining a sense
of fulfillment and self-satisfaction, arising from participation in release
management activity. The intrinsic motivators not only aim at increasing the
welfare among volunteers, but also promote community identity to work
collectively with a common approach to release management process in OSS
projects. The external factors of motivation among OSS volunteers relate to
obtaining future returns by securing support to post-release products and
services with focus on quality approach.
69
The influence of both internal as well as external motivators is
realized in terms of the degree of role efficacy among volunteers, resulting in
the collective team effort to set and achieve a common goal of release
management process. Thus, the human factors in release management process
rely on:
(a) Implications of multi-teaming for collective work performance
among volunteers.
(b) Kind of motives in eliciting job role performance among
volunteers.
(c) Kinds of work involving motivational gains by allowing
volunteers to choose their own simple tasks and at the same
time collaborating in various OSS projects of complexity.
The benefits accrue while coordinating with effective
communication management among volunteers and subsequently resulting in
team work among OSS developers. This strengthens the nature of work
among volunteers community for developing quality oriented OSS projects.
3.11.2 Communication Factor in OSS Release Management
Lack of face-to-face contact among the OSS community volunteers
leads to lack of uniformity and coordination in release management process
and activities. This gap needs to be bridged through effective electronic mode
of communication. Effective communication narrows down the geographical
distance and integrates volunteers to deal with conformity and changeability
in release schedule and varied approaches to quality of release management
process. Also, the rate of failures in OSS projects gets reduced.
70
The volunteer’s community is the main driver behind OSS
phenomenon in release process, although the OSS projects differ amongst
themselves in terms of their size and levels of their participation in release
approach and communication. This necessitates suitable and measurable
communication strategies in OSS to contribute knowledge sharing and
collective innovation.
Communication process in OSS is an important element as it
provides developers to have access to the source code for developing release
activities with smooth physical distribution system. Certain characteristics of
communication between developers and users (volunteer community) may
lead to richer discussions, better flow of ideas, efficient code development,
faster bug finding as well as fixing, boosting testing function, leading to
efficient OSS project release evolution. This has positive quality impact of
release process for stable releases. The process of communication,
interactivity and contribution in OSS release activities are emphasized. Since,
the communication gap and chaotic contribution may lead to deterioration in
the activities of OSS volunteer community.
Effective interaction between developers leads to release of quality
products by using the mechanism of feedback and thus, it helps in the
reinforcement of information exchange during release activities as part of
OSSD process. Information exchange among volunteers builds collaborative
efforts of large number of distributed developers, with diverse interest in OSS
projects. In contrast, most OSS projects fail due to lack of communication
over a period of time after product release.
The complexities which arise in such distributed collaborations due
to ineffective communication, which affect the quality of released product,
require analysis of quality approaches towards release management.
71
3.11.3 Quality Factor in OSS Release Management
The OSS project which needs to release a product has to be
analyzed in terms of quality dimensions conforming to the requirements of
user community. Quality in release management implies a well-designed, well
coded, well tested, error free software product. There are varied approaches to
bring together different quality attributes; and one such approach applicable to
release management of OSSPM is ISO 9126 model evolved by the
International Organization for Standardization, 1991. The ISO 9126 model is
a hierarchical approach which includes the aspects of functionality,
reliability and efficiency.
Functionality are a set of attributes that relate to the existing
functions and specified properties of OSS projects. The functions are those
that satisfy the needs of Volunteer community, viz. suitability, accuracy,
security and compliance.
Suitability: Attribute of software that relates to the presence
and appropriateness of a set of functions for specified tasks of
release process in OSS.
Accuracy: Attributes of software that bare on the provision of
right or agreed results or effects of activities of volunteer
community.
Security: Attributes of software that relate to its ability to
prevent unauthorized access to source code among developers
of volunteer community
Compliance: Attributes of software that adhere to application
related standards of user requirement of volunteer community
72
Reliability is a set of attributes that relate to the capability of OSS
projects to maintain its level of performance under stated conditions for a
stated period of time. The attributes include:
Maturity: Attributes of software that relate to the frequency
of failure by faults in the software release.
Fault tolerance: Attributes of software that relate to its
ability to maintain a specified level of performance in cases of
software faults or of infringement of its specified interface in
release process.
Recoverability: Attributes of software that relate to the
capability to re-establish the software level of performance
and recovering of the data which are affected in case of a
failure and on the time and effort by the volunteer community.
Efficiency is a set of attributes that relate to the relationship
between the level of performance of the OSS projects and the quantum of
resources deployed during release activities. The attributes include:
Resource utilization: Attributes of software that relate to the
quantum of volunteer resources used and the duration of such
use in performing the OSS project release activities.
Time factor: Attributes of software that relate to volunteer
response and releasing time of OSS projects.
Further, OSS Project Quality Management includes the processes
required to ensure that the project will timely satisfy the expectation of
volunteer community. It includes all activities of the overall release
management function that determine the responsibilities of a product by
73
means such as quality planning, quality control, and quality assurance within
the OSS quality management processes.
While the aspect of Quality Planning identifies which quality
standards are relevant to the OSS project and determines how to satisfy them,
the Quality Assurance evaluates the overall OSS project performance on a
regular basis to provide confidence to volunteer community that the project
will satisfy their expectations. Quality Control is a measure to monitor the
OSS projects to determine if they comply with relevant quality standards and
identifying ways to eliminate the defects causing unsatisfactory performance.
Thus, these processes interact with each other and may involve
effort from one or more individuals or groups of volunteers based on their
needs. Quality initiatives in release management undertaken by the volunteer
community can improve the quality of the OSS product in OSSPM.
3.11.4 Time Factor in OSS Release Management
In OSS release management, time is an influential factor in project
release phases. Implementation of a project release schedule does not rely
merely on time based release approach. Effectively, the time schedule is a
means which allows volunteer contributors to perform their routine task with
active communication among them. By using time as the orientation, a release
schedule can be constructed by developers as an overall planning tool of the
release activities. If there were no release schedule, it would be difficult for
OSS developers to complete their development activities and adhere to release
deadlines.
Dependency information between different release activities among
volunteers can be included in the release schedule and deadlines can be met.
The release schedule may motivate further the OSS developers and enhance
74
their efficiency by creating a tight feedback mechanism with users. It also
provides accessibility by the volunteers to the contributions of OSS
developers.
OSS release management has its significance in delivering a
production time and to benefit the end user volunteer community. In this
context, the time factor is all about doing the right task, at the right time, in
the most effective way leading to effective resource management. To know
about the kind of nature of release process activities have been completed and
the percentage of completion is critical to understanding the release progress.
To manage the release activity, knowing who is doing what, when and where,
what their skills and strengths are critical if the right volunteer developer is to
be allocated to each activity. This approach to time management ensures that
from the initial stage of the OSS project, the development process is on the
right path to be released on time. It also benefits the volunteer developer who
works remotely in OSSPM which allows for integration of the release
activity. The time management strategy promotes better planning for quality
improvement of the OSS projects.
Thus, the above four factors which influence the release
management activities are to be considered in OSSPM. In this context, the
significance of this research is explained in the following sections.
3.12 CONCLUSION
The analysis of the process of OSSD indicates that traditional plan-
driven software development methodology is not extensively used in practice.
It has been argued that the traditional methodologies are too mechanistic to be
used in detail. Consequently, the OSS developers have become skeptical
about certain approaches to release management that are difficult to adopt.
OSSD methods bring about a paradigm shift in the field of software
development activities and place emphasis to volunteers’, interaction and
75
collaboration. Often, the issue arises as to ‘what makes a development method
active’?
As far as distribution of OSS releases is concerned, it is significant
in the sense that it enables end-users to try out the project more easily and
hence increases the chance of getting new volunteer contributors. Therefore,
as the practice of releasing early may involve few complications, such
complications need to be identified and solved in the future release for
stability of the project.
The conclusion is that when software development activities are
incremental (small software releases, with rapid cycles), co-operative
(customer and developers working constantly together with close
communication), straightforward (the method itself is easy to learn and to
modify, well documented), and adaptive (able to make last moment changes),
there is a high degree of impact on the rapid growth of OSSD approaches
among software developers.
This research identifies the relevant factors in the OSSD release
process and develops a comprehensive OSSD release process model based on
them. The study in OSSD reveals that social factors play an important role in
OSSD. The traditional software process models are very engineering-oriented
and give inadequate attention to human and social issues. Therefore, they do
not fit in with OSSD. Unlike these traditional software process models, this
research focuses not only on engineering, but also on the social aspects of this
unique software development practice.
In this chapter, a theoretical discussion of OSSD in relation to
release management activities has been presented. In the next chapter, the
detailed results and discussion based on the analysis and interpretation of data
are gathered.