Comment by growse
6 hours ago
The subtext here is that there's a difference between someone saying "I don't like this community, I'm going to make my own" and "I don't like this community, I'm going to change it".
Building communities is hard. It's not obvious why someone who wants a community on their terms gets to piggyback on an existing community rather than putting the effort in to make their own.
The point of "just fork it" is that if your ideas are popular, then sustainability shouldn't be a problem.
Every community is the sum of its members. Each person who joins changes it, at least a bit. And each of those members is changing and growing.
When community members have different needs, forking should be a last resort. It's expensive, and it's wasteful unless two different groups have irreconcilable needs. It should only ever be suggested as a last resort, after other options have been exhausted.
However, it's often used as a first resort to shut down criticism and to protect existing power structures. The person who speaks up is, as here, treated as an outsider and an exploiter.
I rarely see good faith engagements being immediately shut down with "just fork it" (you'd never accept issues / MRs!). Instead it's usually used as a last resort when the "exploiter" doesn't get their way and starts whining about it.
If a change is proposed that's completely counter to a community's stated values, then I guess "fork it" is a more appropriate immediate response, because it's hard to see how such a clash could be resolved without fundamental change.
Edit
> Every community is the sum of its members
A community is much more than the sum of it's members.
> Instead it's usually used as a last resort when the "exploiter" doesn't get their way
I am not saying the phrase can't be used legitimately. Like the article's author, I just think it's often used in a way that isn't. Perhaps we're sampling from different areas of open-source culture, but when I think specifically of HN, I think just-fork-it style responses of the kind that the author is criticizing are common.
> A community is much more than the sum of it's members.
Sure, I agree with that. But you write it as if it's in contradiction with my point, which I'm not seeing.
2 replies →
I imagine with coding agents, maintaining private forks (reapplying patches on upgrade) will be a lot easier. Though, a plugin architecture would be better, where feasible.
If there there's a big enough community swapping patches that upstream isn't accepting for some reason, that's when a public fork becomes reasonable. (This is the Apache web server's origin story.)
The problem with that premise is that often, projects can be having trouble with sustainability already, so even if you're getting 90% of the people in your fork, that might still be too few.
If 90% of the contributions are by 10 people, if the project is large enough, losing one of them is going to be an enormous additional tax on people unless you can get an additional one to step up.