Background & motivation

I have been involved with the Debian Project for over a decade. At first, it was only a hobby; then, teaching Debian to others 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. To date, I am still an active and prominent contributor.

The Debian Project is a highly successful project, run entirely by over 2'000 volunteers, and possibly the largest FLOSS [software which is to grant the right of users to study, change, and improve its design through the availability of its source code.] project [AmEAL2005]. 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.

Despite these successes, the project is currently stagnating — this is not to say that the project is failing! Rather, its processes are not as effective as they could be. As I started to become more and more involved with the project, I ran against walls and fell into holes that had started to appear over time. As one of the oldest Linux-related projects, it is starting to show that some of the project's processes did not scale to meet the tremendous growth the project has enjoyed since its inception in 1993. 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. Similarly, day-to-day tasks, including package maintenance, consist of a dozen of tedious and thus error-prone tasks, which are anything but integrated.

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 with tools geared towards distributed cooperation, if consistently used.

Some efforts in this direction already exist, but they are not being adopted by the Debian community as readily as they should be. Because the Debian Project is made up entirely of volunteers [an individual who enters into, or offers for, any service of his own free will.], noone can be told what to do or how to approach their tasks. Instead, Debian contributors prefer to choose their own methods [a systematic way of achieving a goal; often implies the use of tools [a means to facilitate a given operation.].], 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 and not be able to assess whether the effort will pay off.

It is the combination of the participants' volunteer nature and the implications of open source software that distinguish my research from other studies on method adoption in the domain of information systems. To my knowledge, no work exists on the Debian workflow, or method diffusion [the process of spreading ideas, concepts, technology, or products.]/adoption [acceptance with approval, usually following a period of scrutiny.] within FLOSS projects at large.

References