Welcome

Dear Reader,

When I started this job 15 years ago, Debian was a really big deal. The whole Linux community paid attention to Debian elections, and this magazine even had a regular monthly column devoted to Debian affairs. It would not be an exaggeration to reveal that I even knew a guy who had the Debian spiral tattooed on his neck.

Over the years, though, the Debian project has faded from the foreground, with Arch Linux filling the über-geek niche and enterprise variants from Red Hat and others capturing the greater share of media attention.

But if you're really tuned in to Linux, you'll know that Debian is still really important. Dozens of the best known Linux variants grab the Debian codebase and adapt it to their needs, including cult favorites like Knoppix and CrunchBang, security and privacy distros like Kali Linux and Tails, and game distros like SteamOS. The Raspbian Linux running on your Raspberry Pi is based on Debian. All flavors of Ubuntu are based on Debian, and by extension, all distros based on Ubuntu, such as Linux Mint, Zorin OS, and elementary OS are based on Debian code.

The Debian project was back in the headlines this month, when Debian developer and maintainer Michael Stapelberg revealed in a blog post that he is "winding down" his contributions to the project. With over a thousand Debian contributors, the loss of one package maintainer (even a prominent one) is not necessarily big news. The real news is Stapelberg's detailed critique of Debian development methods, which scored a Slashdot link and has already generated lots of comments from columnists like me.

Although it is neither possible nor necessary for me to recount his entire discussion (which you will find at his blog [1]), I will touch on a few of the highlights. The general theme is that Debian development methods are antiquated, and the decentralized nature of the Debian development process creates headaches for developers. Stapelberg's detailed commentary is organized by topic:

• Change process: He writes, "While it is great to have a lint tool (for quick, local/offline feedback), it is even better to not require a lint tool at all. The team conducting the change (e.g., the C++ team introduces a new hardening flag for all packages) should be able to do their work transparent to me."
• Fragmented workflow and infrastructure: "Debian generally seems to prefer decentralized approaches over centralized ones…non-standard hosting options are used rarely enough to not justify their cost, but frequently enough to be a huge pain when trying to automate changes to packages."
• Package Uploads: Package uploads occur through a system of batch jobs. Stapelberg claims that, depending on timing, you might wait for over seven hours before your package is actually installable.
• Bug tracker: The Debbugs bug tracker was created in 1994 and lacks some important features available with contemporary tools.
• Email archive: Stapelberg laments that Debian still doesn't have a conveniently browsable threaded archive of mailing list discussions.
• Machine readability: According to Stapelberg, "While it is obviously possible to deal with Debian packages programmatically, the experience is far from pleasant."

The problems of aging code are well known to all software developers. Left to its own minimum energy state, a codebase is an artifact of the time in which it was envisioned. The tools and methods used to build the code become an integral part of the product. In some respects, the decentralized nature of a project like Debian forces a kind of continuous evolution, which tends to attenuate some of the aging effects. But, as Stapelberg points out, the decentralization causes other issues, especially for a very large project. The current trend in software development is automation, which puts the emphasis on uniformity and centralization – traits that are de-emphasized in a vast, decentralized project.

The problems outlined in Stapelberg's blog post seem to call for decisive action from a committee or individual empowered to impose uniformity and standardization in a culture where these traits have no history. The question is whether a community project like Debian could muster the unity and strong leadership needed for big and decisive changes. Of course, it is fair to say that Stapelberg's critique is just the opinion of one contributor; many Debian developers might not agree with him. Perhaps more importantly, some developers who agree with him about the headaches of Debian development still might not want to change Debian culture, which has always been based on principle rather than on considerations of efficiency and business.

Whether or not the Debian developers decide to address the issues raised in Michael Stapelberg's critique, I hope his blog post starts a fair, open, and honest discussion about what they really want and what kind of development environment would serve them best. Linux distributions come and go, but Debian really is a big deal – just as it was 15 years ago.