Home > Articles > Programming > C/C++

  • Print
  • + Share This
From the author of

The Importance of Open-Source

Open-source development processes have emerged as an effective approach5 to reduce development cycle time and decrease design, implementation, and quality assurance costs for certain types of software, particularly systems infrastructure software such as operating systems, compilers, and language-processing tools, editors, and middleware. This section describes the reasons why successful open-source development projects work, from both an end user and software process perspective. We base this discussion on our many years of experience researching, devising, and employing open-source development processes and middleware toolkits, such as ACE, JAWS, and TAO.

From an end user perspective, successful open-source projects work for the following reasons:

  • Reduced software acquisition costs. Open-source software is often distributed without development or run time license fees, though many open-source companies do charge for technical support. This pricing model is particularly attractive to application developers working in highly commoditized markets, where profits are driven to marginal cost. Moreover, open-source projects typically use low-cost, widely accessible distribution channels such as the Internet so that users can access source code, examples, regression tests, and development information cheaply and easily.

  • Enhanced diversity and scale. Well-written and well-configured open-source software can be ported rapidly to a variety of heterogeneous operating system and compiler platforms. In addition, since the source is available, end users have the freedom to modify and adapt their source base readily to fix bugs quickly or to respond to new market opportunities with greater agility. Indeed, many new ports of ACE originated in the ACE user community rather than its core development group. Since ACE is distributed with an open-source model, its range of platforms could therefore expand more quickly and inexpensively than if the code hadn't been available to its users.

  • Simplified collaboration. Open-source promotes the sharing of programs and ideas among members of user communities who have similar needs, but who also may have diverse technology acquisition and funding strategies. This cross-fertilization can lead to new insights and breakthroughs that would not have occurred as easily without these collaborations. For example, due to input and code contributions from the ACE community, ACE's logging service component has evolved from a self-contained client/server arrangement into one that can take advantage of both UNIX syslog and the Windows Event Log for better enterprise integration.

From a software process perspective, successful open-source projects work for the following reasons:

  • Scalable division of labor. Open-source projects work by exploiting a loophole in Brooks Law6 that states, "Adding developers to a late project makes it later." The logic underlying this law is that software development productivity generally doesn't scale up as the number of developers increases. The culprit is the rapid increase in human communication and coordination costs as project size grows. A team of 10 good developers can therefore often produce much higher quality software with less effort and expense than a team of 1,000 developers.

    In contrast, software debugging and QA productivity can scale up as the number of developers helping to debug the software increases. This is particularly true in open-source development projects, where the user community engages in very large scale distributed testing. For example, ACE's users are autonomous and therefore don't need the level of coordination and communication that a conventional development team requires. Although ACE has an extensive set of regression tests, its large user community brings many other privately developed applications to bear on each new release, effectively multiplying the regression test suite many times over. In the testing/debugging arena, a team of 1,000 testers will usually find many more bugs than will a team of 10 testers. Due to this multiplied testing effect, the errors in open-source software such as ACE are often identified quickly. The errors are also addressed quickly due to a key advantage of open-source development—short feedback loops (discussed in the following item).

  • Short feedback loops. The short feedback loops between the core developers and the users is another reason for the success of well-organized open-source projects. In ACE, for instance, it's often only a matter of minutes or hours from the point at which a bug is reported from a user to the point at which an official patch is supplied to fix it. Since many ACE users are also highly talented developers, users who encounter bugs often fix them directly and then contribute the fixed source code. Even if they can't provide immediate fixes, they can often provide concise test cases that allow the core ACE developers to isolate and resolve problems quickly.

    Short feedback loops in the ACE development process are also facilitated by the use of powerful Internet-enabled software configuration management tools, such as the GNU Concurrent Versioning System (CVS), the CVSup and viewCVS web interfaces to CVS, and the Bugzilla issue-tracking database. These tools allow ACE users to synchronize in real time with updates supplied to and from the core ACE developers. User efforts greatly magnify the debugging and computing resources available to the ACE project, which in turn helps improve its software quality.

  • Effective leverage of user community expertise and computing resources. In today's time-to-market-driven economy, fewer software providers can afford long QA cycles. As a result, nearly everyone who uses a computer—particularly software application developers—is a beta tester of software that was shipped before its defects were removed. In traditional closed-source/binary-only software deployment models, premature release cycles yield frustrated users. These users have little recourse when problems arise with software they purchased from vendors, and thus little incentive to help improve closed-source products. By contrast, open-source development processes leverage the expertise and resources in their communities, thereby allowing core developers and users to collaborate to improve software quality. Due to the short feedback loops described above, open-source users are rewarded by rapid fixes after bugs are identified.

    Particularly important to multiplatform software such as ACE is the diversity of computing platforms that are tested simultaneously by the user community. In addition to the multiplication of test cases and scenarios mentioned above, the open-source nature of ACE leverages an enormous combination of hardware platforms, operating system versions, and compiler releases. The combination of expertise and computing resources has helped to make ACE successful across a wide range of platforms.

  • Inverted stratification. In many organizations, testers are perceived to have less status than software developers. The open-source development model inverts this stratification. In many cases, for instance, testers in the ACE user community are also excellent software application developers. These tester/developers can use their considerable debugging skills when they encounter occasional problems with the ACE open-source software base. The open-source model makes it possible to employ the talents of these gifted developers, who would rarely be satisfied with playing the role of a tester in traditional software organizations. In many open-source projects, such as ACE, the names of users who contribute fixes, ideas, and features are recorded in ChangeLog and THANKS files. Prolific contributors therefore achieve a level of international recognition in the community, which itself can be highly rewarding.

Traditional closed-source software development and QA processes rarely achieve the benefits outlined above as rapidly or as cost-effectively as open-source processes.

  • + Share This
  • 🔖 Save To Your Account