The peaceful transfer of power in open source projects

Original Article ↗ Hacker News Discussion ↗

Article’s Focus and Tone

  • Some see the piece as lightweight praise for Mastodon’s transition: “here’s someone who did succession and governance decently; nice example.”
  • Others think it’s mostly a veiled attack on certain BDFL-style projects (e.g., Rails/WordPress) and their leaders’ behavior, with charged “Mad King” rhetoric that invites political framing more than constructive discussion.
  • Critics argue the real issue raised is bad governance, not succession, and that tying it to one founder’s voluntary exit is a red herring.

Governance vs. Succession

  • One camp: the praise is about how Mastodon’s founder stepped back—moving key assets to a nonprofit and avoiding a new BDFL—creating a formal model to replace poor governance.
  • Skeptics point out there was no prior succession plan; the plan only appeared once the founder wanted out, so it’s not obviously praiseworthy as a proactive model.
  • Some highlight “undead king” risk when founders stay on as advisors and might still exert informal power.

Forking vs. Formal Structures

  • Many argue OSS is unlike a state: stakes are lower, exit costs are low, and “dictators and forks are good.” If you dislike governance, you can fork; that is the replacement model.
  • Counterargument: for large, central projects, network effects make forks costly and fragment documentation, contributors, and users; “too big to fork” is not absolute but is real friction.
  • Debian’s constitution and corporate-style entities (boards, co-ops, nonprofits) are cited as examples of planned, peaceful power transfer; others note these bring their own drama.

Maintainer Rights, Community, and Entitlement

  • Strong view from many maintainers: they don’t “govern” users, owe only what the license says, and are free to ignore demands; people making entitled, unpaid demands are a major burnout risk.
  • Opposing view: successful OSS is more than code+license; publishing in the open implicitly creates a community and some social expectations, especially when many contributors are involved.
  • Proposed middle ground: maintainers should at least be transparent about governance and their intentions; contributors can then decide whether to invest, fork, or walk away.

Economics, Scale, and Examples

  • Several note that for most small projects the article is mis-aimed: there isn’t even a pool of willing co-maintainers; succession talk feels like “banging the wrong drum.”
  • For very large projects (Linux, WordPress, Ruby ecosystem), leadership decisions have real economic impact. Some fear corporate capture; others think market forces and distro behavior will prevent catastrophic failure.
  • Personal anecdotes show both successful and failed handoffs; picking successors is hard, and sometimes walking away entirely works better than clinging on as BDFL.