On the Xtreme in Open-Source Software Development
Recently, software developers have been offered a plethora of remedies that seek to address inherent inadequacies in and observed problems with traditional software development methodologies. More often than not, however, these come bundled with their own variants of said inadequacies and problems. As a result, at least as far as software developers are concerned, these remedies basically replace an old devil with a new one.
Not all of the remedies fall into this category, however. One particular approach that has seen some well-deserved success is Xtreme programming. Xtreme programming (XP), with due credit to its founding fathers, bases its processes and practices on elements of simple and sound common sense. XP focuses on the things that matter in the development of software. Whole volumes are available on XP that discuss what really matters in software development, and we don't dwell on it here because this article is not about XP. This article is about open-source software development. Given the ideal of better software that remains the guiding principle of the open-source world, open source inevitably crosses paths with XP, in philosophy and in practice. In the rest of this piece, we examine some Xtreme influences on open-source software development--what they are and what they can be.
XP recognizes that the single most important factor in software development is the customer. Most key practices in XP revolve around communication with the customer, listening to his requirements and responding to his feedback. XP even advises that you have a representative of the customer available at the development site throughout the development life cycle. Open-source projects have a quirky and largely unintentional similarity to this approach. Open-source projects, almost without exception, take birth as tools to serve some personal need of the developer, who eventually comes to believe the tool may benefit the rest of mankind and publishes it. Others then try it, improve it, hack it, rewrite it or supplement it to address some missing feature or fix a bug. So, at least in the beginning stages of the development, the developers are the customers. Can there be a more idyllic arrangement? And when the package actually is released to the community, rich feedback in terms of reviews, bug reports, usage experiences and comparisons show up on the ubiquitous mailing lists. All in all, the customer factor in open-source development is handled in a manner that even XP can learn from.
Most conventional software development methodologies work on a single release schedule. The development life cycle spans years and essentially is a black box from the point-of-view of the customer, who has to step out of the way and await the day the developers transform his requirements into usable software. This approach offers no scope for change, for feedback from the customer on what is being churned out in the development process or for a cut-and-run.
For customers who need some degree of control over the development process, XP often is the answer. XP proposes an incremental release schedule that incorporates a finite subset of product features (sorted by business value) in each release. Customers feed requirement changes as well as their comments on the current release into a system that adopts these into the release cycle. More importantly, each release is thoroughly tested and the customer is assured of flawless execution within the scope of the limited feature set. Iterative development of this sort is the norm in open-source development. In fact, the open-source SDLC has been referred to disparagingly as release-first.
To be fair, some of this criticism is deserved. Open source-package releases often are buggy and full of untested code, thanks to authors who have come to depend on bug-reports and feedback from users to such an extent that they do not perform elementary sanity-checks on their code before publishing it. To be fair some more, to the developers this time, it must be mentioned that such releases are tagged appropriately and advertised as unstable. However, that's no excuse. One lesson that open-source developers can pick up from XP is to ensure that any release that goes out of the stable is thoroughly tested in scenarios the developers are familiar with. Feedback from the field then can be relied on for scenarios untestable in the development setup or those that have been overlooked.
In the same vein, XP assures its customers of strict adherence to a pre-planned release schedule. Although the scope of each release may vary in consultation with the customer, the deadlines remain immovable. On the contrary, the release schedule for open-source projects is, to say the least, haphazard. Planning is sometimes based on a TO-DO list but more often is governed by essential bug fixes and the triviality factor of feature additions. Because most development endeavors in the open-source world happen in the off-hours, when the developers are not at their regular day jobs, we sometimes see releases that follow each other by scarcely a day only to be followed by lulls that may span years. Exceptions to this are large projects with roadmaps that sketch the broad outline for a release schedule.
- Transitioning to Python 3
- Red Hat OpenStack Platform
- Tech Tip: Really Simple HTTP Server with Python
- Stepping into Science
- Linux Journal December 2016
- CORSAIR's Carbide Air 740
- The Tiny Internet Project, Part II
- Radio Free Linux
- A Better Raspberry Pi Streaming Solution
- FutureVault Inc.'s FutureVault