3 reading summary

Open_Source_A_Multidisciplinary_Approach_----_Chapter_3_The_Organization_of_the_Open_Source_Community_.pdf

Home >History homework help >3 reading summary

Chapter 3

The Organization of the Open Source Community

In 1976, when he was 21, in "Open Letter to Hobbyists" Bill Gates wrote: "Who can afford to do professional work for nothing? What hobbyist can put their three man-years into programming, finding all bugs, documenting his product, and distribute for free?"29 In this letter he claimed that the ethic of free-of-charge software was wrong and that there was a commercial market for software. He was right that there was a market for software, but 24 years later a young university student in Finland disagreed that the ethic of free software was wrong. In an on-line message, Linus Torvalds, then 22, publicized his creation LINUX by writing an online message in which he stated: "This is a program for hackers by a hacker. I've enjoyed doing it, and somebody might enjoy looking at it and even modifying it for their own needs."30 The result was the creation of an international community of hackers who voluntarily dedicate their free time to developing open source software. Hackers are people whose hobby and passion is figuring out computer problems. They should not be confused with crackers, who are people that use their computer skills to commit illegitimate and/or illegal actions, i.e. break computer security systems, create viruses, etc. Since Torvald's first message the community has grown exponentially and produced many high quality, technologically advanced products.

How is this possible? How does this community work? This chapter deals with the open source community. First we will identify the key players in the community and describe the relationships existing between them. Then we will take a look at the demographics of the software developers in particular. We will also consider what motivates

Muffatto, Moreno. Open Source : A Multidisciplinary Approach, Imperial College Press, 2006. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/scad-ebooks/detail.action?docID=1679623. Created from scad-ebooks on 2020-04-16 19:16:33.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

50 Open Source: A Multidisciplinary Approach

individuals, organizations and society to keep the community alive and functioning. After having considered "who" the community is, we will focus on "how" the community works. We will do this through an analysis of the main characteristics of the organization of the open source community, (open participation and bottom-up organization) and of the open source software development process (fast development and parallel development).

3.1 "Who" is the Open Source Community?

Open source products are developed within a community made up of a heterogeneous group of independent players who interact but are driven by different interests and motivations.31 This community, though seemingly chaotic, actually has specific organizational characteristics.

Some authors refer to the open source community using the metaphor of a bazaar since it expresses the idea of the frenzy and chaos with which the activities in the community are carried out.32 The open source community has also been seen as an immense "magic cauldron" of ideas to which volunteers contribute on a continuous basis.33 Anyone can draw from this cauldron to suit his/her needs without having to contribute money or knowledge.

The community of players meets online and creates a dynamic virtual team, i.e. a team characterized by the constant coming and going of players who contact each other via virtual meetings such as forums and mailing lists. These meeting points make it possible to diffuse concepts, ideas and strategies to the whole community without dispersing or slowing down the flow of information and decisions. What is interesting about this community is that this virtual team is made up not only of software developers, but of other players as well.

By observing numerous open source projects, it is possible to identify five categories of players involved in the community: users, prosumers, leader teams, companies and non-commercial/public institutions. These five categories and the relationships that exist between them are shown in Figure 3.1.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 51

P r o s ume rs

Autonomously develop codes and solve technical problems.

Instructions """1

L e a d e r Teams

Launch projects and develop initial code. Keep projects on track.

Use software and provide feedback.

V i r t u a l Teams

Meeting point to exchange: • ideas • information • codes

I n s t i t u t i o n s

Stimulate research, innovation and competition. Check standards.

Package and

C o m p a n i e s

Share their own code, collaborate and provide support and consulting.

.4- f *°£ an^ niformatio_n^xchanges_-

Figure 3.1 - Structure of the open source community.

Depending on what they do, players can take on one or more of the following three roles: customer, actor or decision-maker.34 Before describing each category and the various roles that players can take on, let's look at a brief definition of each role.

Customers Customers neither take part in the community nor finance product development. Their relationship with the open source community is limited to using open source products and exploiting the community to meet their own needs.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

52 Open Source: A Multidisciplinary Approach

Actors The words itself, "actor", highlights the "active" role these agents play, i.e. actors actively participate in product development. Their participation involves not only analyzing products and identifying and correcting any errors or incongruities (re-actor) but also producing new code and adding on new features (pro-actor). Anyone who provides technical support or finances a project is also part of this category. Decision-makers These players influence the direction a project takes during the development, diffusion and distribution stages of a product.

Now, let's take a look at who makes up each category of players and which of the three roles these players can take on.

Users. This category is made up of all the people who use open source products but do not directly participate in their development because they do not have the ability, time and/or resources to do so. Users are of fundamental importance to the community as they carry out the timely and exhaustive process of observing and testing products and produce feedback for the software developers.

The main role of users is as customers of open source software products. They use products to satisfy their personal needs, which may be both professional and personal in nature. Users are also often defined using the term "free riders" since they use the fruit of the community's work without directly contributing to development. Nonetheless, the presence of free riding is not looked down upon within the community because free riders are actually indirectly involved in product development. The feedback users provide is considered to be a significant and integral part of the development process. Feedback can contain both criticism of existing features and ideas for new ones. Furthermore, since users use the software in real situations, they can assess the overall quality of the products. This assessment implicitly leads to product selection and thus influences the evolution of open source software products. This is why we can say that users can have some of the characteristics of actors and decision-makers in the development process.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 53

Prosumers. Prosumers (producer and consumer) are software developers who actively participate in product development to meet their own needs, for the pure pleasure of developing products, and, in many cases, with the hope of improving their own professional prospects. This group is the nucleus of open source software development. It is generally made up of people who come from different walks of life and use their free time to work on the development of a code. These people might be students or software developers/ professionals with very different cultural backgrounds and professional needs.

The main role of prosumers is as actors. The voluntary work of these agents provides the main contributions to product development. The role of actor can have two different connotations. In the first case, reaction, the agent's responsibility is to correct errors and imperfections in the code {re-actor). In this case, prosumers help stabilize products so that they can actually be used by customers. The second behavior is related to production. In this case, prosumers are involved in the research and implementation of new features and consequently contribute to the creation of new code (pro-actor). Nonetheless, the word itself "prosumer", made by putting the words producer and consumer together, shows the twofold nature of these agents. In fact, in addition to being actors in the development of codes, they are often the first ones to use open source products, i.e. customers. Finally, prosumers can make proposals and thus influence the direction the development of a product goes in. In other words, they have a significant role in the management of development processes as well and are, in this sense, decision-makers.

Leader Teams. This category is made up of software developers and is a sort of elite group chosen by the community based on merit. This group of people is given the authority and responsibility of managing projects. A leader team is made up of a tight circle of prosumers who have participated in the definition and development of open source products from the beginning of the projects.

The main role of the leader teams is as decision-makers. Leaders dedicate much of their time to planning, managing and checking the product development processes and often do not participate in programming. They guide the development process of a project and are

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

54 Open Source: A Multidisciplinary Approach

responsible for project management. The leader teams have to try and resolve any disputes regarding the project. They are responsible for motivating development efforts and integrating the various contributions received. Finally, since the leaders are made up of prosumers, they continue to carry out the role of actor and customer, even if to a lesser degree.

Companies. This category is made up of the companies that are interested in the open source community and its products. They interact with the open source community by using open source software, financing product development, and/or participating in the development of software. Therefore, they can either influence the development process and evolution of products or simply support the community.

Companies can have one or more of the three roles. Many companies have chosen to use open source products for their own production and management processes and have thus helped diffuse these products. By using these products, they act as customers, and by diffusing them they act as decision-makers. Other companies get more involved by having their personnel directly participate in the development of open source software. In this case, they have a role as actors in the community. The different ways companies can and are interacting with the open source community are dealt with in Chapter 6.

Institutions. This category of players is essentially made up of universities and governments. Some universities have created the cultural environment in which many open source products have been developed. Some important products, such as Linux, were created thanks to the technical support, and sometimes financial support, of universities. Recently, governments have also shown interest in open source products first by carrying out studies and then, sometimes, by promoting the use of open source software in their own structures.

Universities can take on all three roles. They are among the main users of open source products and as such are customers. Many professors and students are also involved in researching and developing open standards and open source products, and are, therefore, actors.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 55

Finally, some universities are even decision-makers in that they support the community and products through specific investments.

So far, governments have mostly taken on the role of customers, though they could potentially play an important role as decision-makers as well. As we will see in Chapter 7, many governments are considering adopting OSS or have already started doing so. If they actually do start implementing OSS on a large scale, this decision could influence the software choices the public makes.

Table 3.1 sums up the different characteristics taken on by agents depending on the role they play.35

Table 3.1 - Roles of the players in the open source community. (Adaptation from Feller & Fitzgerald, 2002)

Users

Prosumers

Leader Teams

Companies

Institutions

Customer

Use of OSS for personal or professional reasons.

Use of OSS within the OSS development process.

Internal use of open source products.

Actor

Feedback to the community produced from actual use.

Re-actor: stabilization of software. Pro-actor: addition of new features.

Product design. Integration of contributions.

Partial contribution to OSS development.

Involvement in the research and development of OSS (universities) and open standards (governments).

Decision-maker

OSS quality assessment.

Influence on the direction development takes.

Project management.

Product diffusion and, sometimes, distribution.

Specific investments in support of the community.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

56 Open Source: A Multidisciplinary Approach

3.2 Demographics

We have just seen that the open source community is made up of a variety of stakeholders who, in different ways, support the community. This is a concept of community in a broad sense, but there is no doubt that the heart of the community is the development community. Prosumers are the most active players in the development community. Who are these people that dedicate a significant amount of their free time to developing open source software? In order to answer these questions we can look at the results of studies carried out by the Technical University of Berlin (TUB, 2001), the International Institute of Infonomics at the University of Maastricht (FLOSS, 2002) and The Boston Consulting Group in cooperation with the Open Source Development Network (BCG/OSDN, 2002).

Men or women? All three surveys confirm that the participation in the open source community is overwhelming male, about 98%.

How old are they? More than 70% were aged between 22 and 27 at the time of the study and are thus members of what is now commonly called Generation X, i.e. the generation of people born in the late 1960s and 1970s. (The term comes from Douglas Coupland's 1991 book Generation X: Tales For An Accelerated Culture?) The second largest group, about 16% of the total, consists of people born between 1945 and 1964, followed by members of the so-called Generation Y, i.e. people born in the 1980s.

What degrees do they have? The majority of open source software developers have a university (Bachelor's or Master's) degree, about a fifth have just a high school degree and fewer than 10% have a PhD. The members of this community do not seem to give significant importance to very high levels of education, i.e. post-graduate work.

What is their professional background? About 60% are IT professionals, e.g. programmer, software engineer, IT manager, and the second largest group is made up of people in academia (ca. 30%), two-thirds of whom are students.

Where do they come from/Where do they live? Over 80% live in North America and Europe. However, the data regarding the distribution of these people by nationality differs significantly in the three surveys

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 57

considered: while the FLOSS study found 70% are from Europe and only 14% from North America, the BCG/OSDN survey and TUB study found a more equal distribution in North America and Europe.

How much time do they spend on developing OSS? The data from all three studies reveals that even though some professionals are now paid to work on OSS, participation in OSS projects continues to be mainly a hobby. From a third to a half spend less than 5 hours a week on OSS, about a third spend from 6 to 20 hours a week, about a tenth spend from 21 to 40 and only 5% spend more than 40 hours a week.

How many projects do they contribute to at the same time? According to the BCG/OSDN survey, 30% work on 1 project, 28% on 2 projects, 22% on 3 projects and 18% on 4 or more projects. The FLOSS survey reported similar percentages. Both surveys had respondents who were not currently working on an OSS project but who had in the past. About 80% of the developers work on at most 3 projects and the distribution from 1 project to 3 projects is relatively even.

How might these demographics change 10 or 20 years from now? Is it plausible to think that a community of young graduate males who dedicate their spare time to developing free software is sustainable? At present there is no reason to believe it is not. It is possible and reasonable to imagine that new generations, born in the Information Age, will continue to show an interest in open source software development. What might change is the geographical distribution. Developing countries, such as India and China, have a large population of potential contributors. The age distribution might change as well.

3.3 The Motivating Factors of Individuals and Organizations

The question Bill Gates asked in 1976 continues to be one of the most frequently asked questions when speaking about the open source community: who can afford to do professional work for nothing? In other words, what drives and motivates software developers, companies and organizations to invest their resources in activities which do not produce immediate profits?

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

58 Open Source: A Multidisciplinary Approach

In order to answer these questions, we must distinguish between individual software developers, organizations and society as a whole. Although these are all heterogenous groups, it is possible to identify motivating factors that the players in each group have in common. Open source can offer individuals, organizations and society benefits that motivate these groups to directly or indirectly participate in or support the community.

3.3.1 Motivations for individuals

As we have just seen, the majority of the software developers in the open source community are IT professionals or IT students who receive no financial compensation for their contributions. Furthermore, though the average amount of time they spend per week on open source projects is 5 hours, some spend up to 40 hours or more per week. So the question we pose here is what moves these people to dedicate their time, most often free time, to participating in this community. We will consider a well-known distinction between two types of motivation: "intrinsic motivation, which refers to doing something because it is inherently interesting or enjoyable, and extrinsic motivation, which refers to doing something because it leads to a separable outcome".36 We will look at the extrinsic motivations first as they tend to be the more evident and 'tangible'.

Surveys have shown that one of the most important reasons respondents give for participating in an open source project is to improve their own technical knowledge base. Learning and improving one's performance tend to be ranked among the top reported reasons for contributing to open source projects.37 Another high-ranking motivating factor is the so-called scratching an itch phenomenon, i.e. people participate in a project to solve a particular technical problem or satisfy specific technical needs. Furthermore, these people can exploit the contributions that the community can offer, such as independent peer review and feedback from the community regarding the quality of the work carried out. The so-called "Linus's Law", from Linus Torvalds, states that "given enough eyeballs, all the bugs are shallow", i.e. with a

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 59

given number of users any problem can quickly be identified and pointed out.

The knowledge individuals gain by participating in projects or solving problems can lead to other extrinsic motivations which are more economic in nature. The fact that the source code is open increases the visibility of each individual's contribution. Therefore, not only is each programmer that much more responsible for his own contribution, but the fact that other programmers have access to it can improve one's own reputation within the community. The main motivating factor for software developers, from an economic point of view, is, in fact, to have their abilities recognized by the community (peer recognition) in order to increase their value as professionals in the job market. An improvement in reputation can lead to job offers and promotion, future career benefits and even paid consulting opportunities. The benefits gained by improving one's reputation can justify what voluntary participation costs software developers in terms of time, money and opportunities lost.38

It is worth pointing out, however, that economic motivations seem to be much less important than increased knowledge or improved reputation motivations. In the BCG survey, 93% of respondents mentions "increased knowledge base" as an important benefit of participating in the open source community, 50% "improved reputation", and 33% "new job offers". In the FLOSS study, about 75% responded that one of the reasons to join the community was to "learn and develop new skills" while only 4% cited "make money" as one of these reasons.

The intrinsic motivations seem to be just as, if not more, important as the extrinsic motivations for the software developers in the open source community. This explains and justifies the fact that so many professionals keep the community thriving even without financial compensation for the work they do. Linus Torvalds, the initiator of one of the most successful open source software projects (Linux), was not primarily motivated by reputation concerns, but rather by a desire to participate in a community he identified with. 9 In fact, surveys have shown that "self-determination", i.e. the feeling of accomplishment, competence, enjoyment and effectiveness, and enjoyment-based intrinsic motivation, i.e. the sense of creativity and intellectual stimulation

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

60 Open Source: A Multidisciplinary Approach

experienced when working on an open source software project, are mentioned as two of the most important reasons for participating in the open source community.40 These intrinsic motivating factors can be either personal or social in nature. For example, the second most important benefit of participating in an open source software project cited in the BCG/OSDN survey was "personal sense of accomplishment for contribution" and in the FLOSS survey about 60% answered "share knowledge and skills" as the reason they joined or continue to participate in the community.

Many open source software developers find working on open source software projects intellectually stimulating and participate for the pure creative satisfaction of doing so. The creation of a code can be considered a form of artistic production similar to musical composition or painting, where gratification and intellectual satisfaction play a fundamental role.41 Paul Graham, author of Hackers & Painters, a book that examines the world of hackers and what motivates them, stated:

When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work - that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge. Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I've known, hackers and painters are among the most alike. What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things42

What Graham is describing here is what Raymond has called the joy of hacking. It is "...the pure artistic satisfaction of designing beautiful software and making it work. Hackers all experience this kind of satisfaction and thrive on it".43 Furthermore, the very way in which the community is organized creates an environment where people can

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 61

express their creativity, have fun and feel a sense of accomplishment. Developers have the freedom to experiment in writing code and to choose the projects they are most interested in or that best suit their abilities.

In this context, it is not surprising that many members are also motivated by a belief that free and unlimited access to information must be guaranteed. They consider software to be a knowledge product and therefore a common good. Consequently, software should be freed from the restrictions imposed by copyright. They refuse to accept closed codes and above all the presence of monopolies. It is interesting to note that the results of the FLOSS study indicate that this sense of disapproval of proprietary software and monopolies increases once people have joined the open source community.

The factors that motivate software developers to participate in the open source community are summarized in Table 3.2.

Table 3.2 - Motivations for individuals' involvement in open source software projects.

Extrinsic Motivations for Individuals

Technical

Improve one's own technical knowledge base.

Solve technical problems and satisfy personal needs related to software {scratching an itch).

Exploit peer-review to improve a software product.

Economic

Improved reputation {signaling incentives).

Job offers/promotion and future career benefits.

Paid consulting opportunities.

Intrinsic Motivations for Individuals

Personal

Personal sense of accomplishment for one's own contribution.

Work on intellectually stimulating projects.

Pure creative satisfaction (joy of hacking).

Social

Sense of belonging to a community that fosters cooperation.

Share knowledge and skills {Gift culture and economy).

Oppose proprietary software and monopolies.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

62 Open Source: A Multidisciplinary Approach

In a community where a significant proportion of the members participate for the joy of hacking, for intellectual stimulation or personal satisfaction, sharing and diffusing the results of one's own work become important. This philosophy is the basis on which a the open source community is built: gift economy.44 In a gift economy, a person's social status depends more on how much he/she is willing and able to contribute and share information than how much he/she is able to have exclusive property of information.45 As Raymond writes, "In gift cultures, social status is determined not by what you control but by what you give away." (italics in original)46

3.3.2 Motivations for organizations

Companies and institutions also have important reasons for investing their time and money in observing the open source community, using open source software products, and/or participating in the development of open source software products. All of the motivating factors for commercial organizations that we will discuss can be considered extrinsic as they provide either indirect or direct benefits.

First of all, for companies the community is a sort of reservoir of a high-quality work force which is already productive. Companies can limit training costs by hiring people in the community who have already acquired skills and knowledge in a given area (alumni effect).

Open source products are usually high-quality technologically advanced products. Companies take advantage of the increased quality of these software products by choosing to use them. At the same time, the availability of source codes allows companies to increase the quality of the open source software they are using within their organization by modifying software products to suit their needs. These modifications would be impossible to carry out internally on products protected by copyright.

Some companies directly participate in the development of software in collaboration with the open source community. To be involved in development, the company must make technological and human resources available. This commitment, and the relative costs, must have an economic return which can obviously not come from sales. One

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 63

motivating factor is the possibility this collaboration offers for limiting research and development costs. In fact, the effort required for these activities can be shared among the members of the entire development community. Though the results obtained in cooperation cannot be claimed by any single company, companies can exploit the results to the benefit of their own product quality and internal processes. A final motivating factor is that participating in open source software projects can help improve company image. This helps break the company image away from the profit making aspect and give customers the impression that the company is interested in improving quality and doing something useful for society.

3.3.3 Motivations for society

There are reasons why even society as a whole might support the open source community and benefit from the development of open source software products. Companies and institutions can benefit from the work of the open source community to contribute to the development of open standards and high-quality products even when there are other dominant proprietary products. Promoting open standards which are not the property of any single company can stimulate competition and lead to higher product quality, reliability and stability to the benefit of all members of society. Open source software is, therefore, also an effective means by which to oppose monopolies. Proprietary software, and in particular the dominant software of monopolies, is in complete contradiction with the belief that software should be available to everyone at a low cost. Open source products could also be used to limit the so-called digital divide, i.e. the technological gap between industrialized and developing countries. These products could be distributed in countries where a significant public debt and slow development make it difficult to invest in technology.

Table 3.3 summarizes the factors that motivate organizations and society to support and/or be involved in the open source community.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

64 Open Source: A Multidisciplinary Approach

Table 3.3 - Motivations for the involvement of organizations and society in the open source community.

Motivations for organizations

Find competent technical personnel.

Increase software quality.

Take advantage of the open source community for research and development.

Improve company image.

Motivations for society

Exploit open standards to stimulate competition, lower costs and improve quality.

Oppose the power of monopolies.

Have access to low-cost software.

Limit the digital divide.

3.4 Organization of the Open Source Community

One might think that a community of program developers with different technical motivations would lead to an uncontrollable and chaotic situation. Nonetheless, this is not the case. Clearly then, the community is organized in some way. Although we might be stretching it to speak of the organizational "structure" of the open source community, we can identify characteristics that define how the community and development processes are organized.47 From the organizational point of view, two distinctive characteristics are open participation and decentralized decision-making power. From the point of view of processes, two other characteristics are fast development and parallel development. These characteristics have come into being as the community has grown and evolved. We could even say that they have become rules that help avoid the generation of negative phenomena and guarantee stability and continuity over time and the quality of the results obtained.

Each of the characteristics has advantages and drawbacks. We will see what these are and how the open source community has found ways to limit the negative effects of the drawbacks (Figure 3.2).

Open participation is the premise for the other three characteristics, i.e. bottom-up organization, fast development and parallel development. Open participation makes it possible to explore different alternatives and

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 65

O p e n P a r t i c i p a t i o n

Benefit: Exploration of alternatives

and flexibility Problem:

Lack of incentives to participate Solution:

Frequent releases

I \ F a s t Development

Benefit: Continuous product evolution

Problem: Lack of exploitation of

existing features Solution:

Double development path

B o t t o m - u p O r g a n i z a t i o n

Benefit: Increase in information flows

Problem: Code forking

Solution: Efficient use of the decision

making power

P a r a l l e l Development

Benefit: Simultaneous exploration of

alternatives Problem:

Software incompatibility and project complexity

Solution: Modular design

Figure 3.2 - Characteristics of the organization and development process in the open source community.

make strategies flexible. However, this makes it impossible to define precise deadlines in the development process. The non-specificity of objectives could lead to a lack of incentives for developers and little motivation to speed up development and make a strong commitment to it. The community overcomes this problem by creating numerous and frequent releases of the code to stimulate developers to actively contribute.48

Fast development and frequent releases create a continuous evolution of products. The advantage of continuously modifying and releasing products makes it possible to maintain technologically avant- garde products. However, innovation does not always guarantee total product reliability and stability, at least not until products have been sufficiently and thoroughly checked. This could discourage people from

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

66 Open Source: A Multidisciplinary Approach

using these products because there is no reason for a user to use recent versions of a product when the community cannot guarantee the quality of the product.

To reach a compromise between exploring new solutions and exploiting existing ones, leader teams often use two different paths of development. The first one, called the stable path, is made up of products which have been proved to be stable and guaranteed compatible over time with future versions of the same products. The second one, called the development path, is made up of the most recent versions of products which have not been sufficiently checked and tested, and which are, therefore, still just the fruit of research and innovation. The stable path offers users reliable and tested products and the development path gives developers the possibility to work on developing innovative products. Figure 3.3 illustrates the two development paths.

The double path of development also allows the community to distribute technical and human resources better. In fact, different activities are organized in the two paths. The stable path is characterized by a process in which codes are stabilized through testing. On the contrary, the development path focuses on activities dealing with

/Ji'i rliipiih-m I'IIIII

Kosciiirli ;iml ilowlnpiiK'Hl nl m-u Ivatnrvs - / \plMillion

Release of innovative but m I Requests to develop potentially unstable products [§j 1 new features

Open Source Community

Release of stable s U Integration of new code products | J l _ in the stable versions

Miiblt' 1'iith

( oik' \l.il>ili/;ilimi- I'vploiUlimi

Figure 3.3 - The two development paths used in open source projects.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 67

the research and development of new features. The creation of the two paths makes it possible to improve the distribution of the responsibilities and the organization of the activities. Nevertheless, stability and innovative research must always be carefully balanced. Therefore, the two paths must periodically be integrated with each other. This happens in an explicit way when new features and a new code are transferred from the development path to the stable path. This integration happens in an implicit way when feedback from the products in the stable path indicates new features that the development path should work on.

Parallel development is another advantage of open participation. The community has a theoretically unlimited number of volunteer developers at its disposal and can therefore allow them to work on different alternatives at the same time. This makes it possible to find the best solution in the shortest time possible. The disadvantage, however, is that contributions developed by different programmers at the same time may overlap, interfere and/or be incompatible making it difficult to manage development projects.

When software is produced in the traditional way, excessive parallelism is considered to be a waste of resources and a factor that increases the complexity of the development process. The well-known Brooks's Law states that as the number of software developers increases, there is a proportional increase in the amount of code produced but that there is also an increase in the complexity of the project proportional to the square of the number of software developers.49 This complexity leads to higher communication and management costs and a greater possibility of making errors.

Brooks's Law is still widely accepted by companies, software developers and academics. Nonetheless, some large open source projects (e.g. the Linux and Apache projects) seem to demonstrate that the negative effects of Brooks's Law can at least be limited by using certain strategies. One such strategy is to divide relatively large/complicated products into more simple, mono-functional parts. In this way resources are used more efficiently and any interferences between single contributions are more easily solved. Modular product planning reduces the negative effects of Brooks's Law in that these effects can be traced

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

68 Open Source: A Multidisciplinary Approach

to smaller portions of the code and more easily dealt with. The leader teams are responsible for the modularity of open source products. In fact, they plan products and guide the development of the interface protocol to be used for communication between the various modules. Modularity also means that additions, modifications and imperfections present in one module do not have negative effects on the whole code, but rather are limited to that one module.

Another strategy is to exploit the possibilities offered by the Internet to reduce communication and organization costs. Thanks to the connectivity offered by the Internet, software developers do not have to meet in a physical place to discuss and exchange ideas and codes. In particular, the community uses specific tools, such as the Current Versioning System (CVS), discussion forums and mailing lists, to manage parallelism. The CVS is basically a database containing the various contributions to the project, each of which is identified by a different name and date. This tool can help software developers eliminate the interferences and obstacles that cooperation naturally creates. The CVS is also useful in the debugging process because it makes it possible to track the development sequence and identify the exact point in the sequence where the defects are. A bug database makes it easier to identify and solve problems. When a new problem arises, programmers can quickly look for similar problems in the bug database to see what solutions have already been used. Together with discussion forums, the CVS is also used to archive all of the comments and questions that arise in the community during the development of projects.

A project mailing list should not be considered less important. Developers depend on mailing lists to stay in touch with one another and remain up to date on the evolution of projects. Furthermore, new entries can read the archived messages of a given mailing list to get familiarized with a project and become productive right away.

Bottom-up organization with no strict top-down planning is the third characteristic generated by open participation. This type of organization means that projects can be more flexible and have greater freedom to evolve. However, the negative side of flexible organization is code forking, i.e. a situation that occurs when independent development

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

The Organization of the Open Source Community 69

paths of a code dedicated to reaching the same goals fork off in different directions.50

Code forking can only be accepted if it leads to different features or the same product and cannot be accepted if it leads to the dispersion of contributions, incompatibility of versions and lack of communication between development teams. When peer review is not carried out, the positive effects of collaboration are reduced in terms of product quality, speed, and stability.

The consequences of code forking can be very serious. The loss of collaboration between the members of the community outweigh the positive effects of parallel development. If the community divides up into many subgroups, it could lose the number of programmers and users needed to maintain the fast speed of the product development process, or even worse, the community could implode. The community often loses interest in projects that are subject to code forking. This loss provokes the gradual but unstoppable process of developers distancing themselves from a project that is destined to eventually die. In fact, software developers will want to look elsewhere for a project which can offer the reputation and recognition that a project which risks failing because of code forking cannot.

Fortunately, the code forking phenomenon is very rare in the open source community. When code forking does happen, the community turns to its leader teams to help avoid project failure. Leaders must carefully listen to the opinions of the different members of the project and reach a consensus on the future of the project. They can make suggestions and indicate which direction the development processes should take. They also have to demonstrate the feasibility of projects and try to maintain software developers' interest in the project.

One way to help avoid code forking in large scale projects is to create a management structure made up of team leaders responsible for different parts of a project. By distributing authority among different teams, not only are their managerial responsibilities reduced, but their responsibilities are specific to one given module. In this way, it is easier to respond quickly to needs and to control better the development process. It is important to remember that the power of the leaders comes from the credibility and trust the community places

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .

70 Open Source: A Multidisciplinary Approach

in them. Credibility and trust mostly come from the value and importance of the contributions leaders have made. The leaders can maintain their position only so long as their decisions remain transparent and impartial and so long as they are able to demonstrate technical expertise.

Strong leadership, therefore, reduces the risk of code forking. In fact, any possible "rebel" factions would have to look for other leaders capable of attracting a large enough part of the community to work on a new project. An attempt like this is often made in vain in particular when the project has, as is the case with Linux, a recognized and indisputable leader.

The community also has two other strategies to protect itself from behaviours that can harm the community. Flaming and shunning are the reaction strategies the community can use against anyone, be he/she a leader or programmer, who threatens to break the social rules of the community. Flaming is the public condemnation of the guilty party. Shunning, on the other hand, isolates the "hijacker", i.e. refuses to cooperate with the guilty party. In other words, the guilty party is forced out of the open source development community.

To sum up, the community tries to avoid code forking and any other negative behaviours by whatever means necessary since it sees this phenomenon as a risk to the survival of its projects and to the community itself.

In this chapter we have seen who makes up the open source community and how it works. Although it might be possible to consider the way in which open source software is developed to be a new model for software development, open source software is currently only a small part of all of the software developed. The proprietary model for software development is much more widely used and will most likely continue to be so in the future. Therefore, it is worth comparing these two different ways of developing software in order to understand their respective strengths and weaknesses. Can the so-called open source model become a new and superior software development model? In the next chapter, we will try to answer this question by taking a look at the evolution of software development models and then comparing them with the open source model.

C o p yr

ig h t ©

2 0 0 6 . Im

p e ri a l C

o lle

g e P

re ss

. A

ll ri g h ts

r e se

rv e d .