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, small contributors – are quietly told to leave and rebuild everything from scratch.

That’s not openness, that’s abdication, it’s a prat move that we need to compost. In social terms, it’s the equivalent of saying: “If you don’t like society, go start your own civilisation.” Contribution is not about submission. There is a healthier, but, less glamorous path – start conversations that include people you disagree with, yes, this is slower than forking. It’s also how shared infrastructure survives.

What we need to talk more about is that contribution is not about obedience to maintainers. It’s about stewardship of commons. That means staying in the mess, mediating conflict, and resisting the urge to walk away every time something feels wrong. Forking skips the hardest step: collective sense-making.

Small steps beat heroic exits, the myth of the heroic fork mirrors the wider #geekproblem: the belief that technical control can replace social process. Change usually comes from boring work, partial wins, awkward compromises, long conversations, incremental shifts, not from dramatic exits. Yes, forks in #FOSS have a place, but not as a default. Forking does matter. It’s an escape hatch. A pressure valve. A last resort when projects become irredeemably captured or hostile. But when “just fork it” becomes the first response instead of the last, it stops being a freedom and becomes #geekproblem pathology.

From a social #OMN standpoint, the goal isn’t endless new projects. It’s shared infrastructure that can be argued with, adapted, and cared for over time. Open source gives us the right to fork, open culture asks us when not to. If we want something better than endless reinvention and burnout, we need to stop treating “just fork it” as wisdom – and start treating it as what it often is: a refusal to do the harder social work in #FOSS

And as ever please don’t be a prat about this, thanks.