A few weeks ago I was having a discussion with a friend over whether distribution maintainers are adding any value to Free Software development or not. I thought that the answer would make a good blog post to be shared with the public, particularly since I have experience on both sides of this particular divide, although not recently.
First of all, I need to take out of the door one big caveat: I have ranted about the irrelevancy of distributions today. My concern with that is less about the role of maintainers, but rather about the amount of significant diversity that distributions have unleashed on the world, and the resistance to organize for common standards outside a few selected areas.
What is obvious to users, is that a packager creates the, well, packages for a certain software in a distribution. The concept of “package” is a bit vague in by itself, because you don’t get the same experience between binary distributions like Debian or SuSE as you do for Gentoo or Arch Linux: there are no “packages” generated for the latter two, as much as the installation scripts.
But is there really that much to do, beside building the software and listing the dependencies? Well, yes. The main job of a distribution maintainer is to make sure that the software integrates correctly with the other packages in the distribution. This involves not just making sure that all of the paths are correct, and that the package can build, run, and possibly test correctly with the packages that are available in the distribution: not just libraries, but also any connected tool and build tool.
Back in the days, there was also a lot more to integrate with the init system: every distribution or thereabout had a different idea of how init systems should be done, so whenever a software would be coming with their own init script, it would be most likely thrown out to be replaced by whatever the maintainer wrote. This is one of the places where I believe systemd made a significant difference, and in my opinion a positive one, though I really wish instead of being done as a “my way or the highway” kind of deal, this would have been a collaboration to define a protocol for daemons. I’m ready to bet that if we did it that way, OpenRC and systemd could have shared the same unit format protocol, and kept evolving matching featuresets. After all, systemd user units are not much different from my proposed OpenRC user services.
Most importantly, distribution maintainers should be the first line of support for most users. I think the best relationship I ever had was with projects that kept me involved to reply to support requests from Gentoo users, such as Amarok. I think this is infinitely more sustainable than complaining about the existence of distribution packagers in the first place, and allows real upstream issues, or compatibility across different projects, to be more easily identified.
There is also the role of early canaries. Because systems are different in different metrics, distributions are often attempting new combinations that have not been attempted before. Gentoo has been fairly close to many upstreams in term of development velocity, and the Tinderbox in particular has found many upstream issues for FFmpeg and a number of media libraries. It also often showed defects due to changes in build tools, or new features that might have been too experimental for other distributions to attempt at using early.
I’m not sure if in the ideal world we would have more or less diversity. I have argued before that software biodiversity is good but also that the diversity in Linux distributions has condemned them to disappear in much the same way as alternative personal computer implementations disappeared. Indeed you can think of most distributions as different IBM PC clone manufacturers. And nowadays, it doesn’t really matter which ones you get, they are all about the same. even with all their differences in aesthetics or choices.
Monocultures are bad. Software whose assumptions are never challenged is at risk of breaking when progress requires it to change. But not being able to change components at will does not make for great computing.
The role of distribution maintainers is to make sure that the difference between packages, and the difference between distributions, are smoothed down enough to allow the users to feel comfortable with using a system, without having to learn how different developers think they should be using their software. Kind of an opposite character to DJB.
I miss my distribution work. But as I said before, it was the kind of work that never paid the bills, and that was more frustrating than rewarding, particularly when death threats flown by.
