Tool adoption behaviour in the Debian project

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.

At 15 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.

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.

A framework of the salient influences to adoption decisions among Debian package maintainers helps everyone figure out what is necessary to enter competing ideas into the field, and prevents 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.