The Source of Open Source

This chapter is from the book

Succeeding with Open Source

Learn More Buy

This chapter is from the book

This chapter is from the book 

Succeeding with Open Source

Learn More Buy

Who Uses Open Source?

The short answer is "everyone." If you've searched with Google, purchased books from Amazon, or placed a call with MCI, you've used open source. Each of these organizations uses open source as part of its core computing infrastructure.

The somewhat longer answer is that many organizations currently use, are actively experimenting with, or are thinking about using open source. To date, users of open source have mostly been early adopters; pragmatic IT organizations are now beginning to consider open source, mostly for the reasons outlined earlier. A detailed discussion of how these early adopters and pragmatic organizations use IT is contained in Chapter 4, "The Open Source Maturity Model."

The even longer answer is that open source is used by the product's user community. This might seem redundant, but the term community (or user community) is one you will hear repeatedly in discussions about open source. One of the key differences between commercial software and open source is captured in this phrase. To understand it, you need to consider the relationship between developer and user.

With commercial software, there is practically no interaction between software developers and the people who actually use the product. Most companies seek to shield their developers from users to enable them to focus full time on banging out the code needed for the next release.

In contrast, on open source projects, there is a great deal of interaction between developers and product users. In fact, one might say that there is a very intense relationship among all individuals involved with the product—whether developers or users. E-mails fly back and forth among the development team and product users. Feedback is sought and freely given. Without romanticizing community, it's critical to understand it and recognize how you can interact with it and take advantage of it. It's worth a discussion about community to see how it impacts how you will use open source. The place to begin community lies with the development team and how they work. After that, we can explore how the user community affects and is affected by open source.

Created by Volunteers, Not Employees

Open source developers are typically IT professionals who donate their work on a voluntary basis (this is not universally true, as will be discussed in Chapter 2, "Open Source Business Models." By and large, however, most participants in an open source product are there by choice on an unpaid basis. In contrast, commercial software is written by paid employees.

The fact that open source is written by volunteers affects how open source product teams form and work. Because individuals participate based on their interest in the product, open source management practices are very different from those in commercial software companies.

Anyone who has worked in a voluntary organization will recognize the key differences between the two types of organizations. People volunteer for personal reasons, so getting individuals to work on something that doesn't interest them is fruitless. They won't do it—they just drift away. Volunteers must be emotionally engaged to work on a task and "managing" a volunteer is chiefly an exercise in figuring out a good way to motivate him or her. The role of a manager in an open source project involves lots of emotional stroking and personal interaction, which takes time and forfeits urgency. It can all seem very touchy-feely: There is no such thing as a well-disciplined voluntary organization.

On the other hand, one might argue that the motivation of paid employees is less than complete. Just because an employer offers a paycheck doesn't mean that an employee is strongly motivated. Employees can accept their pay but disdain their tasks. Anyone who has spent time as a manager knows that some employees find it impossible to be enthusiastic about their work. If they're not enthusiastic, they deliver minimal effort. They might actually deliberately hinder their team's progress if they're unhappy enough. Therefore, it's important not to overstate the power that an employer has because it supports its employees' living standards.

There are tremendous benefits to having volunteers write open source software, however. Volunteers bring real passion to what they do. Again, anyone who has worked in a voluntary organization has seen the tremendous effort expended by participants. The inefficiencies in managing open source projects are balanced by the enthusiasm the engineers bring to the tasks they select. Great products are achieved by passion; it might not be missing in software written for pay, but it surely cannot be missing in software written for free.

Because they are voluntary groups, open source development teams work together in a decentralized fashion with little hierarchy. The project leader is usually the individual who originated the project; he or she must manage by consensus with a "lead by example" approach. The project leader is responsible for developing a common understanding of what functionality the upcoming product release will contain, encouraging new developers to join the project, helping developers select a portion of the project to work on, and arbitrating any conflicts that arise between team members.

In summary, egalitarian groups working together as volunteers create open source products. These groups operate with all the glories and frustrations that accompany any voluntary organization.

Development Practices

Open source projects tend to make early releases available for use by the user community and quickly refresh the releases as the product is modified. It's not unusual for new versions of a product under development to be released every few days. This practice is described as "release early and often." The open source community believes that this practice leads to higher-quality products.

The reasons for this belief are straightforward. Developers create and test code based on their assumptions about how it will be used. However, actual users use (and misuse) the product in ways that no developer could possibly have imagined. This use or misuse exercises unexpected code paths and stresses the code in unforeseen ways. By making the product widely available, a large pool of users quickly performs this product exercising and more quickly improves the product's quality.

Because the source code for the product is available, a second factor comes into play. As the epigram "two heads are better than one" illustrates, additional perspectives about problems lead to better solutions. As many of the people using (or misusing) the product access the source code to create fixes that they then submit to the core development team, the overall solution created as a blend of the different fixes will be of higher quality than any one fix possibly could be. Certainly the use of a large pool of developers beyond the central team enables a broader perspective to be brought to bear on the source code. The benefit of having many people working on the source code is summarized in the open source shibboleth "many eyes make all bugs shallow." A side benefit of having many people looking at the source is that the code is reviewed for adherence to coding standards; fragile or inflexible code can also be improved as a result of these reviews. Generally speaking, code reviews are considered to be a very positive quality practice in software engineering.

A third factor that affects open source development practices is that large numbers of real users work with the product and offer feedback directly to the development team. This feedback enables the team to learn what features the product really needs to include to be more useful. By contrast, commercial product companies often suffer from what is known as feature creep, focusing on delivering more features in a race to outshine competitors rather than on what product users really need. There is no pithy catchphrase to express this open source practice, but the direct involvement of end users is believed to lead to more useful products.

A Philosophy of Community

The practice of frequent releases to gather user feedback highlights one of the most important aspects of the open source world: the community. The size and activity level of the community carries significant implications for organizations considering a product. Community pervades discussions of open source, and is discussed throughout this book. More particularly, the size and activity level of the community directly affects the maturity of the product. This book extensively addresses all the ways that the user community impacts the maturity of an open source product, and how you or your organization can use the user community to assess the product's maturity.

What is an open source community? It is all the product developers, any users who are interested in participating, and any other individuals who care to be involved with a product. Essentially, it is a freewheeling organization of everyone who is interested in a particular product for whatever reason. There are no formal requirements for joining and no formal rules for participation.

However, lack of formality does not mean that there are no standards for participation or behavior. Very strong unwritten rules govern all community interactions. A community member is expected to interact respectfully, make reasoned arguments about why a particular course of action is right, and, above all, to contribute to as well as take advantage of the community.

Open source product communities are very powerful and offer tremendous benefits:

• As described earlier, the interaction between developers and users makes for a more useful product. The product is better for having more people determining its direction and improving its stability via usage.

• The community offers a real resource to draw on for expertise in the product. It is very common for members of the community to help one another figure out problems or to suggest potential solutions for product usage.

There are some drawbacks, however:

• Because of the need for consensus and the large community size, the pace of work and decision making can seem very slow. There really isn't any way around this, but it usually doesn't cause an enormous problem. In any case, if you feel strongly about something, there is always source access to more quickly make changes that you feel are time sensitive.

• Despite the strong informal rules of participation, immature behavior sometimes (rarely, really) occurs. This can take the form of namecalling, but the more common form is one-upmanship based on technical opinion—the "it is obvious to anyone who really understands how objects interact that it should . . ." sort of thing.

• Occasionally, the community will engage in protracted discussions about off-topic subjects. Depending on your temperament, these discussions might be charming, mildly distracting, or irritatingly time wasting. I tend to the latter point of view, but have learned to grit my teeth because of the community benefits.

One unique aspect of an open source community is that it is essentially anonymous and extremely decentralized. Nearly all interaction is done via e-mail and Web forums. It is common for members of the development team to have never met, but to have worked together quite closely to create a high-quality product. Many members of a product community will cooperate to solve a problem successfully, all while being scattered literally around the world.

Can Community Work?

Many IT managers are initially reluctant to use a product that relies so heavily on an informal community organization. They feel open source communities that lack hierarchical leadership and a formal governance structure must be inefficient and chaotic. It's easy to understand this reaction, because so much of corporate and governmental life revolves around hierarchies and formal rules of behavior.

At bottom, this reaction is based on a fear that community means no one is truly responsible for the product—that there is no one to turn to about a specific problem or an urgent need. There is a comforting sense that a commercial provider offers a responsible point of contact, sometimes charmingly referred to as "one throat to choke." On the other hand, having a commercial provider standing behind a product is no guarantee of responsible behavior. The software industry has witnessed many instances of companies abruptly declaring products "no longer supported" or defining them as having reached their "end of life plan." Another perspective on "one throat to choke" is "single point of failure," which is usually considered a bad thing.

However, there is a precedent for a technology successfully delivered by an informally structured organization. It is one that every reader of this book likely uses each day: the Internet. Despite its lack of formal hierarchy, use of the informal request for comment (RFC) standards mechanism, and reliance on personal reputation for leadership, the Internet has succeeded brilliantly. It is unlikely that a single commercial entity could have created what this informal organization has brought about. Many observers even argue that the lack of formal structure and regulations for the Internet have enabled it to evolve more quickly and be more useful than would otherwise have been possible.

Many discussions about open source denigrate the commercial software world and describe open source methods as far superior and perhaps even better morally. The informal community is portrayed as delivering much better products that will eventually send commercial software to its deserved burial in the elephant's graveyard. My own view is that there are many powerful benefits available from using open source and the community is one of those benefits. I don't believe that commercial software is going to disappear by any means; however, I do believe that open source software will become an important part of every IT organization's infrastructure and that taking advantage of the community is vital to success with open source. Open source succeeds brilliantly at delivering software, and the community is an important part of that success.