Engaging with the Open Source Community (Part One)

Abstract
THE OPEN SOURCE community-based software development model provides industry, government, and academia with significant opportunities to leverage IT investments and increase organizational effectiveness and efficiency by using and continually improving high quality Open Source software. The Open Source community ecosystem provides important software, services and support components that span virtually all commercial markets as well as governmental and educational domains. While Linux, Apache, and SendMail are well known examples of Open Source software, these solutions constitute only a very small fraction of the Open Source software available. Open Source software solutions exist for virtually all types of business applications. Open Source solutions integrating these and other business functions into powerful applications like ERP and CRM suites are also available. Additionally, Open Source software exists for a variety of vertical markets and is being widely used. These solutions, as well as many more, are available at various levels of functionality, stability, and both commercial and non- commercial support. There are many advantages to the adoption of Open Source software. The extent to which a given enterprise benefits from these advantages depends in large measure upon how it engages with the Open Source community. Part I briefly outlines the benefits of Open Source software and development processes. Part II will describe the rationale for, and benefits of, engaging with the Open Source community, as well as suggest a high level process for deciding to deploy Open Source and how to engage with the community.

What is Open Source Software?
Open Source software is characterized by its licenses, such that any user who modifies the software and then redistributes it either must or may make available to those who receive it the source code that defines the software and their modifications. A number of Open Source software licenses exist in a continuum of legal rights and obligations ranging from the Berkeley Software Distribution (BSD) license, which permits but does not require providing source code, to the General Public License (GPL), which mandates source code availability for all users.

Open Source software has the following characteristics, some of which are not usually found in legacy commercial software:

• Control resides with the user
• Highly stable
• Proven security
• End-User input to evolving functionality
• Excellent quality
• Highly flexible
• No or reduced License Fees
• No vendor lock-in
• Self-determined upgrade path
• Can run on less expensive hardware
• Very cost-effective
• Freedom of vendor choice
• Fast development cycles
• Ongoing evolution.

Open Source software can meet the software requirements of mainstream enterprises including financial services, retail, manufacturing, distribution, transportation, healthcare, entertainment, academia and all branches of government.

What is the Open Source Community?
In the broadest sense, the Open Source community includes everyone who uses Open Source software, worldwide. However, many users of Open Source software are passive consumers, that is, they never ask questions on mailing lists, participate in online discussions, post bug reports, fix software problems, or develop and contribute software source code. For the purposes of this discussion, we will use the following definition: the Open Source community consists of those who participate in developing and improving Open Source software.

The term "Open Source community" sounds rather monolithic, doesn't it? Actually, that's not the case at all. Instead, "Open Source community" is a term that refers to a great number of separate and individual groups of self-selected Open Source software contributors and involved users organized for self interests.

Self-Organizing
An individual Open Source community is characterized as a loose association of people who have a common interest in developing and using a particular piece of software. These people are typically geographically dispersed, communicating via email and various Open Source development tools in order to collaborate on the software that they are jointly developing, testing, using, and improving. Each loosely organized group -- an Open Source community of developers and users -- designs, codes, tests, documents, reviews, and uses all parts of the software being developed. Decisions are typically made by consensus,[1] with leadership exercised by those recognized as more committed, knowledgeable, and competent by the rest of the community. Such communities can have as few as two or as many as several thousand individuals contributing to the overall software development lifecycle -- the more, the merrier.

Gift Economies
Those who contribute to an Open Source community typically are not compensated monetarily within the community for their work. Members join the community because they have an intellectual interest in the software or because they have an association with some other organization that is interested in or actively using the software. Many Open Source community members are paid for their work directly by those enterprises that employ them, and their contributions to the community are simply made in the course of their normal employment. Intangible status and rewards within an Open Source community invariably come as a result of contributing significantly to the software developed by the community. In this way, Open Source communities function as "Gift Economies" with the most recognition given to those individuals who contribute most substantially and consistently to the project success and progress.

Self-Selection
Members of the Open Source community typically choose for themselves what piece(s) of programming or other development tasks they will work on. Typically one or more senior members of the community will organize a prioritized list of things that need to be done, but it is up to the individual members to choose their own self-assignments. It is considered good form to work on tasks from the prioritized list; consequently the recognition is greater for those who cooperate with the agreed-upon priorities. Most Open Source communities are fairly cooperative, but members are free to contribute however they wish.

Members of an Open Source community can take different roles, depending on their interests and skills. There is typically a cadre of core developers who write the most formidable constructs and algorithms. A larger peripheral group of less committed developers often exists that contributes interfaces, subroutines, device drivers, and the like. Some members may focus their efforts on functional or performance testing, while others might write documentation. Perhaps the largest group is involved users who contribute bug reports and feature requests. Everyone involved is free to make comments, argue for one approach over another, and generally discuss the direction and technical details of the software under construction. Peer recognition, honest and direct criticism, and the weight of one's own reputation among other members of the community combine to make these Open Source communities self-regulating.

Meritocracy
Because the members of Open Source communities are usually geographically dispersed, communicate almost exclusively by email and other Internet enabled electronic means, and typically haven't ever met each other face-to-face, the socio-economic hierarchies of the physical world don't apply in cyberspace.[2]

Thus, corporate position, economic status, and formal education don't interfere with the meritocracy of Open Source communities. The factors that matter in Open Source development projects are raw coding talent, incisive logic, hard work, and attention to detail. Most programming members of Open Source communities collegially compete with each other through their ideas, arguments, and especially their functioning software submissions. Concepts and solutions that are clearly superior win out through the consensus of critical, multi-level peer review and rigorous testing in a wide variety of different software and platform environments. Over time, those developers who consistently devise more elegant, complete, and better performing solutions gain well deserved peer recognition, stature within the project, and more responsibility in their own assignments as well as for reviewing the work of others. Since a very talented software developer can be substantially more productive and efficient than the average developer, this might have a lot to do with why Open Source communities can be more effective than proprietary software corporations and most independent in-house software development organizations.

Therefore, any teenager with a personal computer and an Internet connection can compete - on a level playing field - with seasoned systems development professionals in academia and industry. If she can write a more elegant widget implementation subroutine, or better grasp the Zen of task scheduling or virtual memory management, they should accept her patch, and the project will be that much better for it.

The dispersed, Internet connected nature of Open Source communities also fosters another characteristic of Open Source development: vigorous criticism. It's well known that email communications often lack the tact of personal interactions. Woe unto any Open Source developer who submits a badly formatted and gratuitously complicated, spaghetti-code module or patch to a programming gatekeeper on an Open Source project. Such an unwise would-be contributor is likely to get a rigorous emailed whipping that they won't soon forget! Corporate programming managers cannot get away with such enthusiastic correction of subordinates in modern office environments with strictly enforced human resource policies. But Open Source contributors are all volunteers, so they either work up to the standards of their peers, or drop out, and someone more able takes their place. Open Source communities are very capable of enforcing high standards among their contributors, either quickly training or losing any poor performers.

Fast Development
Most Open Source communities tend to evolve and improve major software products on much faster cycles than commercial software development organizations. A new release of IBM's MVS or AIX, HP's HP-UX, Sun's Solaris, or Microsoft's latest flagship PC operating system is produced about every three to five years. In contrast, a new and significantly improved release of the Open Source Linux production kernel is produced every 18 to 24 months. Similarly blistering paces of software development have been observed with the Apache web-server as well as the KDE and Gnome desktop environments for Linux. It is simply the case that commercial software development processes can't match the pace of Open Source.

Quality Ensurance
Open Source communities typically follow a philosophy of "release early, release often" with daily build releases of the software within the community not uncommon. External releases are made on a schedule dictated by the relative maturity, level of bug-free quality, and functional stability of the software. Members of the community continually review the current build level of the software as well as designs, testing scaffolds, test results, documentation and other information contributed within the community.

Another piece of Open Source philosophy is characterized as "many eyes make all bugs shallow." The continual review process used by Open Source communities produces a "many eyes" effect of massively parallel peer review that has been demonstrated to produce very high quality oversight of the software development process and products. Constant, repetitive peer review, coupled with a release schedule tied to objective software quality rather than marketing deadlines, consistently results in Open Source software quality orders of magnitude higher than that of commercial releases of similar software.[3]

Open Source software is constructed primarily by those who want to use it, so they don't release it until they're satisfied that it's usable by the majority of the user community involved, that is, when it's done.[4]

Triumph of the Commons
Software produced by an Open Source community is released under one of a number of Open Source licenses. The common elements of these licenses are that: (a) no license fees are charged and (b) all source code defining the software is made available without charge to users of the software.

In the cautionary tale known as "The Tragedy of the Commons," individual herd owners each attempt to maximize their individual returns from use of a common grazing land. As each herder grazes more beasts, the Commons quickly becomes overgrazed and falls into ruin. Open Source communities turn this story on its head, resulting in much greater returns for everyone involved than they could ever gain separately.

Each member of an Open Source community contributes as much as they can afford in terms of time and effort, and they all gain the benefits of everyone's combined contributions equally in the software results. This powerful force multiplier of Open Source communities is seen as "The Triumph of the Commons." µ

The authors are management consultants with the Olliance Group, an Open Source strategy-consulting firm offering a comprehensive portfolio of education, business strategy, and technology planning services.

[1] The mode of consensus practiced within Open Source communities that facilitates decision-making is based upon objective criteria. The maturity of a software product is perceived in the resolution of serious bug reports and dwindling of minor ones. A software release is proposed, and lack of vocal objections is taken as general assent.

[2] A famous New Yorker cartoon illustrates this perfectly. It shows a dog sitting in front of a personal computer with his paws on the keyboard. The caption is: "On the Internet, no one knows you're a dog."

[3] Published studies conducted by Reasoning, Inc. have established just such software quality differentials between Open Source software and proprietary commercial software, specifically regarding several TCP/IP implementations.

[4] Commercial software organizations usually have "Quality Assurance" departments that typically oversee internal conformance with a set of rather ponderous and expensive software development lifecycle procedures. But "to assure" means to encourage confidence, not necessarily to guarantee anything about completeness, correctness, accuracy, ease-of-use, security, stability, reliability, or performance. "Quality Assurance" in commercial software development can be a show of due diligence to satisfy corporate legal departments rather than actual focusing on producing software quality. In contrast, "to ensure" means to make certain, so it's appropriate and borne out by actual results to say that the rapid collaborative developmental practices of the Open Source communities result in effective Quality Ensurance. µ

Copyright (C) 2003 Olliance Group, LLC, All Rights Reserved