4  Deliberate Closure

ending on your own terms

4.1 When

  • (Weitzel and Jonsson 1989) describes a five-stage model of organisational decline:
    • Blindness: warning signs go unrecognised
    • Inaction: signs are seen but nothing changes
    • Faulty action: the wrong remedies are tried
    • Crisis: resources are depleted and options close off
    • Dissolution
  • The sunk cost fallacy keeps projects alive past their useful life
  • The moment when shutdown becomes undeniable is rarely the moment it became inevitable: the warning signs were there earlier (Whetten 1980)
    • Recognizing which stage a project is in determines which interventions are still available
  • Clinicians systematically fail patients by focusing on what medicine can do rather than asking what the patient actually wants (Gawande 2014)
    • Project closure conversations often fail in the same way
  • The conditions for shutdown should already be written down in the project’s advance directive
  • If they are not, the first step is to write down who decides and under what conditions
    • Distinguish between who must be consulted and who has a veto
  • Discussions with team members, funders, institutional sponsors, and users should:
    • Establish a shared understanding of the situation
    • Make each party’s values and priorities explicit
    • Negotiate a plan that meets those goals rather than being what is technically easiest
  • Focus on:
    • The least bad outcome for each stakeholder
    • What trade-offs they are willing to make
Note

One special case is patterns in the dynamics of corporate scandals (Palazzo and Hoffrage 2025). Recognizing them early can give people warning that projects are going to fail.

rigid ideology
toxic leadership
manipulative language 		corrupting goals
destructive incentives
ambiguous rules 		perceived unfairness
dangerous groups
slippery slope

4.2 Honest Enough

  • Framing matters
    • “Putting into hibernation” provokes less hostility than “termination” and keeps the door open for revival
    • If it is the truth and credible
    • It’s possible to be one without the other
  • “Tell people what you know, as soon as you know it” is easy to say but hard to do
    • Information gaps cause more anxiety than difficult truths
    • Conflicting verbal and written instructions cause lasting harm
    • On the other hand, you often don’t know what’s happening
    • And constantly-changing pronouncements raise the temperature as well
  • Remember that this project is probably not the sole relationship you have with others
    • (Wruck 1990) found that indirect costs of financial distress (lost contributors, cancelled collaborations, management distraction) are substantially larger than direct costs such as legal fees or asset sales
    • Indirect costs arise because distress signals inability to fulfil commitments, triggering defensive behaviour that accelerates decline
    • An information vacuum does more damage than an honest announcement would have

4.3 Beginning

  • Don’t start by announcing shutdown
    • Announce that you are stopping work and invite known successors to take over
    • Do not accept successors you don’t already know (supply chain attack risk)
  • Give users real deadlines and enough time to act
    • Two to six months between announcement and shutdown is enough
  • Use the project’s announcement channels and others, not just the repository README or project home page
    • The latter reach core project members, not the wider circle
  • Tell people reasons (as much as you can), timelines, and what will happen to assets

4.4 Middle

  • Update the project home page to list:
    • Key achievements
    • Current state (working, broken, incomplete)
    • Where code, data, and results are (going to be) archived
    • Next steps or alternatives for users
  • Don’t bother with:
    • User-facing tutorials
    • Exhaustive dependency documentation
    • Adding additional tests as if you were doing a new release
    • Bug triage

4.5 End

  • If possible, have someone outside the project run structured exit interviews to find out what should survive rather than what went wrong
  • Hold a wake for the project (i.e., a combination group retrospective and memorial)
    • What went well, what didn’t, and what stories people will remember
Note

(Chochinov et al. 2005; Chochinov 2012) advocates dignity therapy as a brief, structured intervention for people near the end of life. The central technique is a guided life-review interview in which the person reflects on what has mattered most, what they are proud of, and what they most want future generations to know and remember. A similar structured exit interview or retrospective at the end of a project is more than a conventional “lessons learned” report because it is personal, narrative, and explicitly oriented toward what should survive rather than what went wrong.

4.6 Exercises

4.6.1 Audit Your Dependencies

Read Dumb Ways for an Open Source Project to Die, then think about the projects you depend on. Which of them do you believe are already in one of these states? How would you find out?

4.6.2 Write a Shutdown Notice

  1. Draft a short announcement (3-5 bullet points) for your project. Explain the reasons for closure, give a concrete timeline, tell people what will happen to the data and the website, and point users to alternatives or successors.
  2. Swap and identify one thing the other notice does well and one thing it could improve.

4.6.3 Last Known State

Draft a one-page “last known state” document for your project:

  1. What does this project do (i.e., what problem does it solve)?
  2. What is currently working?
  3. What is broken or incomplete?
  4. Where does the data or code live, and how would someone get it?
  5. What are the most important things a successor would need to know?

Compare drafts: what did others ask about that you had not thought to include?