A post sparked Hacker News spouting of noise and smoke. It looks like “just fork it.” phrase in #FOSS culture provokes heat. So worth a second look, for some it’s the purest expression of freedom, to others, it’s a conversation-stopper that quietly protects power. What’s striking isn’t that one side is right and the other wrong, it’s that people are too often talking about entirely different things, while using overlapping words, thus the smoke and heat in the linked discussion above.
It’s worth a little time to look at this issue. The pro-fork view is about permissionless agency. From the classic #Geekproblem perspective, “just fork it” is not an insult or a dismissal, it’s a reminder of where power actually lies. The arguments, often bad-tempered, go like this: Open source removes the need for permission, maintainers are not obligated to implement anyone else’s ideas, if you want something different, you can do the work yourself, forks are non-hostile, temporary, and often merge back.
In this view, forking is not fragmentation, it’s pressure relief, to protects maintainers from entitlement, unpaid labour demands, and endless arguments over direction. It’s also what makes #FOSS resilient: even if a maintainer disappears or a project takes a turn you dislike, the code remains usable.
For libraries, tools, and infrastructure components, this works remarkably well. Many developers maintain private forks, carry patches for clients, or experiment freely without any intention of creating a new community. No drama, no schism, no ideology “mess”, just work. From this “native” angle, criticism of “just fork it” sounds like a demand for obligation where none exists.
The counterpoint is that forks aren’t free in social systems, the critique isn’t only about forking code, everyone agrees that’s normal, healthy, and foundational. The tension is when “just fork it” is applied to social platforms, protocols, and shared infrastructure, systems where the software is only a small part of the project.
Running a fork as a new public project isn’t only technical work, it needs: attracting users, building trust, maintaining governance, handling conflict, sustaining moderation and care and thus carrying long-term responsibility. This is where the phrase starts to feel different, in these contexts, “just fork it” is heard not as empowerment, but as exit over engagement, a way to avoid dealing with governance failures, power asymmetries, or unresolved social conflicts inside an existing social project.
From a social #OMN perspective, this isn’t neutral, forking risks: splitting attention, duplicating effort, losing shared history, weakening already fragile commons. Forking may preserve freedom, but it can still destroy value. Forks vs schisms is maybe a way to look at this:
- forks – technical divergence
- schisms – social rupture
You can fork without a schism, but every schism requires a fork. Many arguments talk past each other on this, because one side is defending the right to fork, while the other is warning about the cost of schisms. These are related, but not identical. Power, ownership, and stewardship, are fault lines about how people understand authority.
- One view holds that open source projects are a #feudalistic kingship – benevolent or not – and contributors knowingly accept this. Maintainers owe nothing, forking is the safety valve.
- The opposing view sees projects as commons built from collective labour where maintainers are stewards rather than owners, carrying responsibilities that go beyond “my repo, my rules.”
Neither position is imaginary, both exist in the wild. The conflict arises when a project quietly shifts from one model to the other without naming it.
Why this matters for OMN-style projects, they are explicitly social, federated, and historical, they depend on: continuity, shared narrative, visible governance, memory. In this context, common sense “just fork it” instincts unintentionally reinforce the problems #4open paths are meant to solve: fragmentation, invisibility of power, and loss of collective learning.
That doesn’t mean maintainers owe endless emotional labour It does mean that governance and mediation matter as much as code, and can’t be solved by technical exits alone. Two truths at once, the debate becomes clearer if we hold these two truths together:
- No one owes you unpaid labour, forking is a legitimate, necessary protection for maintainers.
- Social infrastructure is not just software, treating forks as cost-free exits erodes shared commons over time.
When people argue past each other, it’s usually because they’re defending one truth while denying the other. This creates mess, social mess. So to compost this mess, we need to understand better where this leaves us, “Just fork it” is neither a delusion nor a universal solution, it is:
- healthy in libraries and tools
- essential as a last resort
- dangerous as a reflex
- corrosive when used to silence governance questions
The real work – the hard, unglamorous part – is knowing which situation you’re in, and being honest about the social costs of the choices you make. That’s not a technical problem, it’s a cultural one, best not to be a prat about this.
This matters because we have social problems created by tech intolerances, #blocking culture. The #dotcons industry’s ability to pull the ladder up behind itself should not be underestimated.
We’ve created digital systems so complex, fragile, and professionally gated that an entire generation is being locked out of owning and understanding their own tools. Communities and people should be able to run their own services, control their own data, and participate meaningfully in digital culture, but few can, because we made everything unnecessarily controlled and complicated.
This wasn’t an accident, it’s a part of the #eekproblem, complexity concentrates power, it creates dependency on experts, platforms, and the corporations that have been quietly erasing the possibility of autonomy. What once required curiosity and modest effort now demands specialist knowledge, constant updates, and institutional backing. The result is a widening gap between those who can build and control systems, and those who are forced to rent/beg access to them.
This is why #KISS simplicity matters, why documentation matters and most importantly why social tooling matters as much as code. And why the #openweb was always about people, not only protocols. When we ignore this, we don’t just lose users, we lose a generation’s ability to imagine, agency, and collective control in the first place.
It’s a real mess we need to compost.
One thought on “Power, the social cost we keep talking past in #FOSS”