Background & motivation

The Debian Swirl: "@"

I have been involved with the Debian Project for over a decade. At first, it was only a hobby; then teaching Debian to others and planning Debian deployments became my main source of income. Along the way, my fascination with the project kept building up and I documented what made Debian so special in my book The Debian System. I am an active and prominent contributor to date.

The Debian Project is a highly successful project, run entirely by over 2'000 volunteers, and possibly the largest FLOSS project. It produces several computer operating systems the most popular of which (Debian GNU/Linux) provides over 20'000 software packages for eleven different hardware architectures. Furthermore, the Debian System is the basis for around 150 derivative distributions, such as the popular Ubuntu distribution, and large-scale, localised installations, including Guadalinex and Limux.

Project growth and scalability

At 16 years of age, it is evident that some of the project's processes did not scale to meet the tremendous growth we've seen over the years. Endeavours, such as library transitions, currently require dozens of contributors to work hand in hand, and often stall because of bottlenecks or lack of coordination. Day-to-day tasks consist of tedious and thus error-prone tasks, which are anything but integrated: keeping track of patches, triaging bugs, follow policy changes, and work with upstream and derivatives, to name just a few…

Looking at the way these processes are currently handled, it seems strange that contributors of a system as technically sound and universally applicable as Debian are still doing by hand what the computer should be doing for them. Tasks like the aforementioned could be streamlined and optimised to avoid redundancy and points of failure due to brittle integration. For instance, a bug report should only be marked as done as soon as but only when the patch fixing the issue has been signed off and appears in the repository.

Inertia and progress

Some efforts in this direction already exist, but they are not being adopted as readily as they should be. Because the Debian Project is made up entirely of volunteers, noone can be told what to do or how to approach their tasks. Instead, Debian contributors prefer to choose their own methods, based on criteria which range from technical benefits to ideology, from pragmatism to sheer stubbornness. In addition, once settled, a developer is often unwilling to change his/her methods at a later point in time, or may only be able to do so through considerable additional effort without the ability to assess whether the effort will pay off.

For coordinators, integrators, or tool designers, no guidelines exist that could help them frame these criteria and properly cater to everyone in the target group. Instead, everyone is on their own when trying to spread a new tool or technique. This impedes upon progress: some ideas may be good, but never manage to convince more than a handful, who fail to communicate them to the majority, because they do not understand others' decision behaviours. As a result, those ideas cannot rise to become competitors with existing methods, people will have no reason to change, and progress is halted.

Competition drives progress

Knowledge of the salient influences to adoption decisions among Debian package maintainers would help everyone figure out what is necessary to enter competing ideas into the field, and would prevent stagnation due to unsuccessful "marketing". With healthy competition, only the best tools and techniques will emerge as winners. And because competition drives progress, the project should be able to scale better as a result.

If you are interested in how I go about achieving my objectives, please have a look at my research approach.

Table of contents

Please cite this web page as follows: Krafft, Martin F. "Background & motivation." Process evolution in large open-source projects:. 14 Jun 2011. Martin Krafft, University of Limerick. <>. Last accessed: [DATE ACCESSED].

This page was last modified Tue Nov 2 12:45:31 2010.

Site design and content are copyright © 2005–9 Martin F. Krafft. Please see the imprint.
I shall not be held liable for offending content in pages linking to or linked from site, nor do I endorse their content unless I stated otherwise.

This webpage wouldn't be possible without Debian, Python, rest2web, Apache, and other excellent pieces of Free Software.

Valid XHTML 1.0 Strict Valid CSS