Let's Recommon IT

Two Keyholders

No shared system should depend on one person.

Thread:
Liberatory tech
Level:
collective-choice, in the governance column
File:
wiki/patterns/two-keyholders.md

draft

explained in Who holds root? An IAD analysis of a shared server

Two Keyholders Sketch in perspective: a long wall with one hatched door in it. At the door, a mannequin turns a key in the lock. From the right, a second mannequin walks up holding its own key out, ready to use it. The wall and door are the shared system from the pattern's context: something a group depends on, with one way in. The door is admin access, the focus. Each key is full access, and each figure is a keyholder. Two keys for one door is the first half of the solution: at least two people can get in, without needing each other. The second figure arriving with its own key out, about to take a turn, is the second half: both keyholders use their access regularly. The consequence is that the door still opens whichever of them is away. The metaphor: admin access as the key to a shared building, with a second key cut and carried, not left in a drawer.
Fig. 1

No shared system should depend on one person.

Context

A server, service, or network that more than one person depends on, run by volunteers.

Problem

When one person holds all the admin access, the system depends on that person. If they burn out, move, get sick, or fall out with the group, nobody else can get in to fix it, and the single admin ends up deciding everything by default.

Forces

  • Most community tech starts with one enthusiastic person who sets it up, so access starts out concentrated.
  • Rules about positions (who holds which role, and how many people hold it) are part of what makes an institution last (Understanding Institutional Diversity).
  • Single-maintainer projects put the whole load on one person (Working in Public).
  • The lone admin’s work is rarely seen until it stops (Re-enchanting the World).

Solution

Therefore, give at least two people full admin access to every shared system, and make sure both of them use it regularly.

Actions

  • Write down where credentials and recovery information live, and make sure both keyholders can reach them without the other’s help.
  • Have the second keyholder do routine tasks now and then (updates, restarts), so they can step in when needed.
  • Treat two as the minimum, not the ideal.

Consequences

  • Positive: the system survives one person leaving or burning out, and decisions stop defaulting to one admin.
  • Negative: more people with full access means more trust is needed and more ways for credentials to leak. Keyholders have to coordinate so they don’t undo each other’s work.

Mark up this page on GitHub