Welcome!

Linux Authors: Pat Romanski, Gary Kaiser, Liz McMillan, Elizabeth White, Michael Thompson

Related Topics: Linux

Linux: Article

The OSS Development Life Cycle

Part 4 of 4

This is an excerpt from Chapter 6 of Understanding Open Source Software Development by Joseph Feller and Brian Fitzgerald, published by Addison-Wesley. ISBN 0201734966. No part of this excerpt may be reproduced, in any form or by any means without the prior written permission of the publisher. (c) 2002 Addison-Wesley

The traditional software development life cycle (SDLC) is premised on a set of stages, which, in their most generic form, include:

  • Planning
  • Analysis
  • Design
  • Implementation
However, the OSS development life cycle is quite different. First, the planning, analysis, and design phases are largely conducted by the initial project founder, and are not part of the general OSS development life cycle. Getting design issues right is perhaps even more critical in OSS than in conventional development. Certain criteria in relation to modularity of the code are critical. For example, modules must be loosely coupled, thereby allowing distributed development in the first place. Less important, but still highly desirable for achieving an efficient development model, is that modules be highly cohesive and address a single well-defined purpose. However, design decisions are generally made in advance, before the larger pool of developers start to contribute, and are generally based on well-established design patterns. This allows developers to collaborate without having to undergo the detailed requirements analysis or design phases of the traditional life cycle. In the absence of conventional project management, the importance of "having a tail-light to follow" (Bezroukov, 1999b) is a very useful coordinating principle, as it allows a multitude of developers to contribute. This also helps to explain why many OSS products are horizontal infrastructure-type products, as these are ones in which the requirements are pretty well understood. In vertical domains, developer knowledge of the application domain has been found to be critical, but it is unlikely that the pool of potential developers would be as high in such domains.

Thus, the OSS development life cycle is located primarily within the implementation phase of the traditional SDLC. Several researchers have investigated the life cycle underpinning OSS. Bollinger et al. (1999) suggest that it follows a very intensive spiral model (Boehm, 1988), albeit without any real risk assessment. Mockus et al. (2000) have derived a life cycle for OSS from their study of the Apache Project, and Jorgensen (2001) has investigated the life cycle in the FreeBSD Project. Both have come up with models that are largely compatible, but Jorgensen's is more detailed. He identifies the following main phases in the OSS development life cycle:

Code

  • Review
  • Pre-commit test
  • Development release
  • Parallel debugging
  • Production release

    Code
    This is the sine qua non activity. However, many potential OSS contributors may fear taking the initial step of submitting their code for review by the supremely talented OSS "code-gods" (Asklund and Bendix, 2001; Bergquist and Ljungberg, 2001), a fear that is quite warranted when you consider the views of a FreeBSD developer reported by Jorgensen (2001):

    The way you get commit privileges is by first making enough code contributions&This implies the code you've been submitting is of sufficiently impressive quality that no one objects and says, "Yuck, no, don't give him commit privileges. He writes ugly code."

    Thus, the knowledge that talented and respected peers will be reviewing the code is a real incentive to improve the quality of the code being submitted in the first place.

    Review
    As already mentioned, truly independent peer review is one of the central strengths of the OSS process. However, Jorgensen found that eliciting feedback was not always easy. "Heavyweights" with a proven reputation will get a lot of feedback, but it can be quite difficult to get attention as a newbie - another classic "Catch-22" situation. Also, somewhat paradoxically, the simpler the code, the more feedback you gets. However, complex code would invariably benefit more from feedback. Also, it's more difficult to get feedback on design issues.

    Precommit Test
    Given the vulnerability of the OSS development model, it's critical that committers test each contribution carefully to avoid breaking the build, another common norm in the OSS community. Since there is no convenient help-line or telephone support for those installing the eventual product, it can be an adventure completing an actual OSS product installation. Sanders (1998) quotes the "tech-savvy" Ellen Ullman's description of her installation of Linux as "an exhilarating succession of problem-solving challenges." Given this problematic installation context, it is imperative that installation proceeds as smoothly as possible without unnecessary noise, and thus rogue modules that could jeopardize this must be prevented.

    Interestingly, testing is very much a personal process. There is no requirement that test scenarios be rigorously planned and written down in advance. However, the negative implications of allowing a faulty contribution through are such that the testing process is taken very seriously indeed. As mentioned earlier, the delegation of testing to the user community - or partial delegation, as is the case with Mozilla and GNOME - is one of the strengths of OSS (Schmidt and Porter, 2001).

    Development Release
    If the committer deems the module ready, it can be incorporated in the development release. This is the key payoff for many developers as they get the reward of seeing their code implemented quickly in the product. Jorgensen (2001) cites a developer who captures it quite graphically:

    There is a tremendous satisfaction to the "see bug, fix bug, see bug fix get incorporated so that the fix helps others" cycle.

    Parallel Debugging
    The advantages of global parallel debugging were discussed above. Again, as in testing, there is typically no formal plan for debugging. Rather the numbers of potential debuggers is where the power of the debugging arises - Linus's Law. If bugs are found, they can be fixed and resubmitted as per the life cycle described above, or problem reports may be created and submitted. This can also be a way of initiating your contributions to OSS. For example, the database of outstanding problem reports could be examined, and if there are some outstanding that catch your interest or are within your capability, then these can be worked on. Thus, can you begin a career in OSS.

    Production Release
    Contributions eventually become part of the production release. They are merged into the stable production branch. This is accomplished in different ways in different projects. FreeBSD maintains stable production and current development branches, and contributions that are eventually found suitable are merged into the latest stable production branch, and, in the case of a bug fix, to any previous production branches to which it might be relevant. Linux maintains its stable production and development versions in different directories, and uses release numbers to identify production (even numbers) and development (odd numbers) versions.

    Conclusion
    We have argued that the generic OSS development process is characterized by the practice of parallel, rather than linear, collaboration among developers, which leads to increases in both speed and quality; by the participation of large, globally distributed communities of developers who participate in a truly independent peer review process; by prompt feedback (e.g., bug reports) and prompt recognition (e.g., integration of bug fixes); by the participation of talented and motivated developers and extremely active users; and by rapid, incremental release schedules. We also examined the well-stocked toolkit of OSS, including configuration management tools like CVS, as well as editors, build tools, documentation extractors, and the like. Finally, we argued that the OSS process is governed by an elaborate system of taboos and social mores that take the place of formal project management, and that the OSS process follows a distinctly different development life cycle to traditional proprietary software.

  • More Stories By Joseph Feller

    Joseph Feller is a lecturer with the Business Information Systems Group,
    University College Cork, Ireland. His research on Open Source Software is
    published in several prominent conference proceedings and he is the author
    of Customer Friendly: Design Guidelines for eCommerce. He also edits the
    monthly professional journal, Inside XML Solutions.

    More Stories By Brian Fitzgerald

    Brian Fitzgerald is the Frederick A Krehbiel II Professor of Innovation in Global Business and Technology at the University of Limerick, Ireland. He is Associate Editor for two leading international journals in the IS field, The Information Systems Journal, and Data Base. His publications include five books and more than 50 papers, published in leading international conferences and journals. Having worked in the industry prior to taking up an academic position, he has more than 20 years of experience in the IS field.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.