FOSS "Just Fork It" Delusion

Summary

One of the most repeated mantras in #FOSS culture goes something like this: “If you don’t like it, just fork it.” On the surface, this sounds empowering. And technically, it is true. The beauty of open source is that you can take the Mastodon source code, fork it, and do whatever you want with it. Don’t like how it’s run? Do something different. Don’t like the branding? Change it. Got a better idea? Implement it. But socially, this mantra is misleading, forking is easy, sustaining is hard. Forking code is cheap, sustaining a living project is not. What “just fork it” quietly ignores is that software is only a small part of what makes a project work. The hard parts are social: users, trust, shared norms, governance, maintenance, conflict resolution and long-term care. When people say “just fork it,” they usually mean “remove yourself from the social problem rather than engaging with it.” That’s not empowerment – it’s fragmentation at best and prat behaver at worst. From an #OMN point of view, sometimes this is needed, but its rare as it is mostly value destruction. Fragmentation isn’t neutrality, every fork splits attention, energy, documentation, user bases, and developer time. Most forks don’t die because the code is bad; they die because the social surface area is untrusted or unmanageable. We end up with: dozens of half-maintained projects, duplicated effort, incompatible implementations, project communities too small to support themselves. This isn’t resilience, it’s entropy, not in a good way. And worse, most of these forks are isolated socially, even when they are technically compatible. The result is lost value, lost history, and lost trust – rinse, repeat, move on. “Just fork it” hides power, it doesn’t challenge it. The slogan pretends to be anti-authority, but in practice it is used to protect informal power. Core teams stay untouched, governance questions are avoided, structural problems remain unresolved. The people most affected – users, moderators, sma...