James Bottomley: Succession Planning: Is It time to Throw Linus Under a Bus?

September 10, 2018

Related Material:

  1. CHANGE OF PLAN: Maintainer Summit will be in Edinburgh.
  2. On the scalability of Linus.
  3. Guido van Rossum resigns as Python leader.
  4. The wisdom of Linus Torvalds.
  5. community management/subsystem governance.
  6. USA Social Security Actuarial Life Table.

I am sure that you all can supply a great many more.

Additional Participants: Daniel Vetter, David Woodhouse, Geert Uytterhoeven, Jens Axboe, Jiri Kosina, John W. Linville, Laurent Pinchart, Linus Torvalds, Mauro Carvalho Chehab, Olof Johansson, and Thomas Gleixner.

James kicked this topic off as only James could do:

Since our fearless leader apparently can't even remember the dates of the only conference he goes to, perhaps now might be a good time to talk about how we'd run an orderly succession process (purely theoretically, of course ...)

I think a vote amongst the Maintainer Summit attendees might be the way to elect a new leader, but others probably have different ideas.

Jiri Kosina asked for reassurance that Linus would not actually be thrown under a bus. [ Ed. note: “Throw him under a bus” is an idiom indicating that the person in question be deposed or removed from his position rather than being physically thrown under a bus, but that is English for you! ] Jens Axboe warned of the dangers of hastiness, and suggested establishing a timeline. John W. Linville agreed on the timeline, noting that it took months for him to coordinate an orderly withdrawal from wireless maintainership. Linus Torvalds nevertheless got fully into the spirit of this thread:

I literally suggested that this is why it would be best to do it without me in Vancouver.

Because what better opportunity for a palace coup than when the old dictator is off gallivanting? It's very traditional.

After a paragraph that seemed designed to make Jiri even more nervous, James called out the benefits of having Linus round to annoint the successor(s). Linus responded to the nervousness-inducing paragraph with “This has taken a dark turn”, then pointed out that he himself had raised this question at the 2017 Maintainers Summit, but failed to get any reaction. This led him to suspect that the discussion would go better in his absence. James continued the dark repartee, and then suggested a with-Linus meeting in Edinburgh followed by a without-Linus meeting in Vancouver. James also suggested that two people, elected by the maintainer summit invitees, hve push rights to Linus's tree, working according to rules established by Linus. If this experiment failed, another experiment could be devised in 2019. Olof suggested another experiment, namely offloading merging of non-controversial fixes during the non-merge window.

Daniel Vetter asked why a single leader, assertion that group maintainership works. James replied that this would be a good discussion topic, noting that not all that many Linus-kernel subsystems actually practice group maintainership. Geert Uytterhoeven noted that the ARM-SoC subsystem has a functioning triumvirate. Olof Johansson (who was once and still might be a member of the triumvirate) pointed out that both group and single-person maintainership can be dysfunctional, but that group maintainership makes it easier to deal with a bad-choice maintainer. Olof also noted that x86 maintainership uses the group-maintainership model.

Linus agreed that group maintainership has mostly worked well, but argued that the most important attribute of a good group is mutual trust. Olof agreed that trust within the maintainership group is important, but emphasized the importance of outside optics, giving arm-soc as an example.

Mauro Carvalho Chehab asked how many developers it takes to replace Linus, wisely declining to supply an answer. (For his part, John shuddered at the thought of finding enough fools to backfill Linus.) Mauro also called out a problem in the media drivers that required the presence of a lead developer to resolve, albeit painfully. Mauro also argued for the greater resilience of geographically separated maintainers, later suggesting that they be forbidden to ever meet at the same location. Jens seemed reassured by the general feeling that replacing Linus was not a short-term month-long project

Daniel pointed out a number of things required to make group maintainership work:

  1. Clearly documented merge criteria, enforced by automation where possible.
  2. Require mandatory review, no exceptions.
  3. Massive CI with in-depth testing before committing is even considered.
  4. Code of conduct that allows banning people who “who don't get it and cant work together in a group”.
  5. Pay attention to and learn from experience in other open-source projects.

Laurent Pinchart also held forth on the advantages of group maintainership, but also favors a relatively small group, certainly fewer than 20 maintainers. Laurent also pointed out that group maintainership does not necessarily imply that all developers are maintainers: Maintainership must be earned. Laurent agreed that group maintainership is not a panacea, just a better way.

Linus reassured everyone that he was happy to continue in his role indefinitely, but argued that there should be real proposals prepared beforehand, as opposed to a random and pointless discussion “Because I can think of more productive things to do in Edinburgh, and most of them involve drinking.” David Woodhouse suggested hill-climbing as an alternative to drinking [ but thankfully did not suggest that your editor do the driving ], to which Linus responded “Y'all don't need a dictator, you need a baby-sitter.”