The 'Just Fork It' Mantra in FOSS: A Social Problem Masquerading as Technical Freedom

The phrase "just fork it" echoes through FOSS communities like a mantra of empowerment. Technically, it's accurate: you can take Mastodon's source code, create a fork, and build something different. Don't like the governance? Fork. Disagree with the branding? Fork. Have a better implementation? Fork. The license permits it, the tools enable it, and the culture celebrates it.

But this technical truth masks a social reality: forking code is cheap; sustaining a living project is not. The "just fork it" narrative quietly ignores that software is only a small component of what makes a project work. The hard parts are social: building user trust, establishing shared norms, governance structures, maintenance pipelines, conflict resolution, and long-term stewardship. When people invoke "just fork it," they're often advocating for social avoidance rather than engagement—removing themselves from the problem instead of working through it.

From the perspective of the Open Media Network (#OMN), forking is sometimes necessary, but it's rarely the optimal path. Most forks don't fail because the code is bad; they fail because the social surface area becomes untrusted or unmanageable. The result is entropy, not resilience: dozens of half-maintained projects, duplicated effort, incompatible implementations, and communities too small to support themselves. Each fork splits attention, energy, documentation, user bases, and developer time. Even when forks remain technically compatible, they often become socially isolated, creating lost value, lost history, and lost trust.

The "just fork it" slogan also obscures power dynamics. It presents itself as anti-authority, but in practice, it often protects informal power structures. Core teams remain untouched, governance questions are avoided, and structural problems persist. Users, moderators, and small contributors are effectively told to leave and rebuild everything from scratch. This isn't openness—it's abdication.

There's a healthier, though less glamorous, path: starting conversations that include people you disagree with. This is slower than forking, but it's how shared infrastructure survives. Contribution isn't about submission 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, incremental steps often beat heroic exits. The myth of the heroic fork mirrors the wider #geekproblem—the belief that technical control can replace social process. Real change usually comes from boring work: partial wins, awkward compromises, long conversations, and incremental shifts, not dramatic exits.

Forks do have a place in FOSS. They're 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 freedom and becomes a 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 recognizing it for what it often is: a refusal to do the harder social work in FOSS.