Maintainerless Debian?

A maintainer of a package within the Debian project cannot be circumvented by forking — unless one wishes to fork the entire distribution, an enterprise which tends not to end well. So, when maintainer problems arise, they must be solved in some other way. A recent problem of this type, involving the GNU GLOBAL package, came to a head in October, and is still, as of this writing, unresolved. The slow progress of this case, which played out for years before being referred to Debian's technical committee (TC) in October, has led longtime Debian contributor Ian Jackson to start pushing for changes.

Jackson noted that the Debian constitution only provides one practical method for the removal of a nonperforming maintainer: the technical committee. But, he said, the committee has never, in the entire history of the Debian project, actually forced a maintainer out of their position. That, he said, indicates a problem:

Jackson expressed mystification as to why the TC — an institution he designed and served on for years — has proved unable to deal with maintainership problems. He went on to propose a couple of methods for improving the situation.

Making it easier to depose maintainers

His first proposal was to create a new mechanism, separate from the technical committee, to handle maintainership disputes. After an initial mediation step failed, a "jury" of ten randomly chosen Debian developers would hear the arguments and, with a majority vote, decide whether the package should be given to a new maintainer or not. The jury idea comes from a desire to get away from an appointed panel like the TC; as prominent members of the project, committee members, he said, are more likely to side with maintainers than with those who are complaining about them.

He quickly moved away from this idea, though, toward a scheme that, he hoped, would make it easier for the TC to make maintainership decisions. He posted a draft for a general resolution that would, if adopted, offer "advice" to the TC. That advice says that, in disputes over a package, the maintainer's position should be given no more weight than that of any other project contributor. Each opinion should be considered on its own merits, regardless of the "authority" of the person expressing any given opinion.

This draft resolution has not been all that well received. It was simultaneously seen as a no-op resolution that made no changes to how the TC was supposed to operate and a statement of a lack of confidence in the current committee's judgment. Two TC members (Philip Hands and Didier Raboud) said that they would be likely to resign from the committee if the resolution were to pass. Those TC members also seemed to feel that, by pursuing this initiative at this time, Jackson was trying to force the committee's hand in the GLOBAL dispute. As of this writing the discussion is ongoing, but it seems unlikely that Jackson's proposal will make it to a vote in anything resembling its current form.

No more maintainers?

Back at the beginning, Jackson proposed another option, seemingly as an exercise in extremes: abolish the concept of package maintainership entirely. He quickly dismissed that option, saying that it would lead to developers being "expected to play core wars in the archive" when they disagree over changes to a package. But some other developers took the idea more seriously.

Former project leader Stefano Zacchiroli remarked that abolishing maintainership was "the obviously right solution". The maintainer model, he said, gets in the way of effective collaborative development and should be done away with. He proposed moving to a "weak code ownership" model (without describing how that would work) along with tools that would make it easier to integrate changes made by multiple developers.

Russ Allbery agreed that the maintainership model is a part of the problem, partly because involuntary changes in maintainership will be, by their nature, confrontational events. Rather than codify how those changes should be done, he said, it would be better to just weaken the notion of maintainership in general. Again, though, he didn't get into the details of how a weaker maintainer model might work.

Jackson disagreed with this conclusion; he does not believe that things can work well in the absence of a maintainer who can make decisions. Others felt the same way; Adam Borowski suggested that, as a thought experiment, one could consider what would happen if the init-system choice were open to modification by any interested party. Rather than abolish the maintainer role, Jackson said, it would be better to just make maintainership changes easier and more routine. Some developers clearly see some appeal in the no-maintainer idea, though. Lars Wirzenius suggested the creation of a list that maintainers could join if they were amenable to having their packages taken over if they weren't keeping up with them. That list was subsequently created by Laura Arjona Reina and now had a handful of names on it.

Jackson, meanwhile, has moved on to a new idea: require group maintainership for all packages. The worst problems, he said, have always involved single-maintainer packages. If a formal team does not exist for a Debian package, then, perhaps, the entire project should be seen as the team and empowered to make changes. Like some other projects (the kernel, for example), Debian has encouraged more group maintainership of packages, but has not required it. Perhaps strengthening that encouragement is all the change that is really needed.

The Debian maintainer model has endured since the beginning of the project with few changes. It is too early to tell but, just maybe, this discussion will lead to larger changes in how Debian packages are maintained, with a subsequent reduction in maintainer-related problems. One should remember that this is Debian, though, so there is certain to be a fair amount of further discussion to get through first.