Governance, Assets, and Permissions

start with the easy stuff

• Deliberate closure first: less traumatic, and the practices are good project hygiene anyway

Governance

• Every team needs explicit decision-making rules (e.g., BDFL or Martha's Rules)
• Rules must include suffrage: who can veto, not just who is consulted
• Few projects have a GOVERNANCE.md file; fewer still include shutdown criteria
• The Apache Software Foundation's attic process is a documented model:
  • At least three active respondents required to keep a project viable

• Governance discussions forced under stress are far harder than those done in advance: cognitive load and interpersonal conflict make clear-headed decision-making much harder
• In medicine, an advance directive specifies what care a patient wants if they become unable to speak for themselves
• So write an advance directive for the project while it is still healthy [Towey2026]:
  • Conditions for shutdown
  • Who has authority to make the call
  • What assets must be preserved
  • What obligations must be honoured
• A closure plan that sits in a drawer and has never been tested is a fantasy document [Clarke1999]
  • Organizations routinely produce plans that reassure regulators and funders but bear no relationship to what would actually happen under stress
  • A HANDOVER.md written in an afternoon that no one outside the core team has read
  • Ideally, walk through the closure plan periodically to check that each step is actually executable with the people available
  • But the word "ideally" is doing a lot of work in that sentence

Coupling and Cascading Failure

• Project infrastructure is often tightly coupled in ways that only become visible during shutdown [Perrow1999]
  • Failures in tightly-coupled systems are not aberrations but predictable outcomes of the system's design
• [Singer2023] shows that organisations often invoke individual explanations to deflect systemic accountability
  • "The driver wasn't paying attention" rather than "the dashboard was too complicated"
• An account that pays for ten services, or a single personal login that controls a domain, means that an unexpected departure can cascade into complete loss of access
• Handing over a GitHub organization and a domain name is not the same as handing over governance obligations or data privacy commitments
• Treat any single point of control that cannot survive 48-hour unavailability as a bug
• And treat every handover as an explicit asset transfer, not a transfer of "the project" as a whole [Marks2022]
  • An asset transfer moves selected assets and obligations; the original legal entity persists or is wound down separately
  • An entity transfer moves the entire legal entity including unknown liabilities
  • Being explicit about what is and is not transferred protects both the outgoing team and the incoming maintainers
• As noted in the introduction, there are legal obligations and restrictions around many of these
  • Do not assume the law is comprehensible or sensible

Permissions

• Use dedicated organizational accounts rather than personal ones as soon as multiple people have privileged access
• Keep a findable list of privileged actions and the accounts that can perform them
• Use a password manager for all organizational credentials

Exercises