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.