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.
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.
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.
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.
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.
You're replying to a comment that says, "rarely see good faith engagements being immediately shut down with 'just fork it'"
They do seem to be clearly contradicting your point
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.)
Spot on. I almost never see "just fork it" brought up in a context that acknowledges what that would actually take. It mostly shows up as a way of shutting down discussion, and often has a flavor of victim-blaming to me.
“Victim blaming” is an odd phrase here. Could you clarify what you mean?
As background, when power is misused, you'll often find somebody immediately showing up to explain why it was the fault of the person harmed. In the US, for example, this happens basically any time a cop kills somebody. In analyzing the situation, the agency of the person with power is minimized or ignored; the agency of the person harmed is maximized.
Open-source project are often run as little fiefdoms. Power is concentrated; checks and balances are minimal or nonexistent. Note that I'm not saying that this is bad or good; that's just how it is.
The "just fork it" style of response that the article is addressing, which I don't ever think I've seen in an issue but often see here on HN as a response to some complaint about a project. It's not part of a careful analysis about the costs and benefits of forking. There's also little or no attempt to understand who a project's audience and community is, or the value of the complaint in that context. It's a drive-by response to shut-down a complaint in a way that treats the complain as illegitimate, suggesting that person is wrong for wanting something different from what's on offer.
Does that help?
I wish I could "just fork" most social problems. As FLOSS developers, we have the great luxury of being able to fork, and all we lose is the community, other people's considerations for our preferences. But for social problems, the people are the point, so "forking" alone wouldn't accomplish anything, not to mention physical limitations that make forking e.g. a country impossible.
Forking is not the only solution. You can offer 1 billion dollars to each member of the core team to implement your pet feature and it will be implemented. Guido would add braces, Linus would use the backslash, ...
The important point lost in many of these anti-fork posts is that forks usually aren't hostile, and "just fork it" isn't usually a dismissal of people's input - rather, it's an invitation to do the work and to stop looking for permission. Which is really the core value of open source - no need for permission, "just do it". Forks also don't generally split communities because forks live within the community (and good community leaders foster the tolerance of forks).
As an example, I have a fork going of someone else's open source project which I made to meet my client's needs. I've got an email thread going with the project owner, it's all very friendly, and one day the fork might merge back in again (probably in parts). I think this is how most forks work, with the exceptions making big headlines partly because they're juicy gossip but mostly because they are exactly that - exceptions.
Maintainers have the freedom to choose whether to accept an idea or not. Users have the freedom to fork or not.
It's just cancellation on a global scale.
This isn’t really what the article is about. Doing a temporary fork for your own needs is equivalent to maintaining some personal patches.
The article is talking about running a forked project as an active fork that other people are using. That comes with the social overhead and community complications.
a project owner have the right to be dismissive about anything regarding their own project. This is why "just fork it" is both dismissive, but also power.
If you are simply asking a project owner to do somethings you wanted (often for free, i might add), then why shouldn't they be dismissive?
If you have an idea for said project that the owner is dismissive about, then you fork it - prove that the idea is good.
"Where can I send some cash for your hard work" or "here is a very well thought out patch to a long standing bug, with minimal impact" are much rarer than "Here's my very complex edge use case that I need to support ASAP, I think it's quite shameful you don't support this already must not take you more than 5 minutes, come on people do it already my clients are waiting and I'm stuck waiting for your lazy asses".
This. You can't even issue a Git pull/merge request without technically forking the project first! It's super common.
> The important point lost in many of these anti-fork posts is that forks usually aren't hostile, and "just fork it" isn't usually a dismissal of people's input
In my experience, forking a semi-active project can often be viewed as hostile by the maintainers. Some of those maintainers may turn it into a holy war where they try to throw their weight around to push back on the fork. I’ve seen claims of “trying to stealing our project” to mobilizing users of their Discord to warn people to avoid the fork across Reddit and other social media.
It doesn’t always go that way, as you experienced with the project you forked. The situation you described is about as non-threatening as it gets, though, because you forked for a single client and you don’t want to become a maintainer of a new project.
A fork doesn't require a schism, but a schism does seem to require a fork.
Yes, one or two persons can't maintain a fork of a giant project for long.
But when you have a project with enough problems that there are thoughts of forking it, whether those are technical problems or social problems, and when that problem is big enough that enough people are thinking about forking it, you already have a new community.
Isn't that a situation where forking happens as "a last resort when projects become irredeemably captured or hostile" as the article writes?
I think you're the one who missed the point and haven't digested this blog post properly.
The author claims forking is impractical except when it's a last resort.
My point is that it's not needed except when the need also creates the community.
That is exactly the point. But it makes sense if you look at it from the other side. When you put in the effort to maintain a project, there have to be boundaries to the social interactions, and when those are reached, "just fork it" is a pressure valve to protect the ones who put in the effort to maintain projects.
Many people think they know how something should be done better, but as a community, we have to protect the ones who are not just talking, but actually maintaining.
Is it good that the article has inspired mostly "the author is wrong" comments, more so than even the usual for HN?
> This isn’t resilience, it’s entropy
> That’s not openness, that’s abdication
> Just fork it” hides power, it doesn’t challenge it
> is not about obedience to maintainers. It’s about stewardship of commons.
> the goal isn’t endless new projects. It’s shared infrastructure
It's Not A Blog Post — It's Moralizing Slop
i would think humans would start writing in a way that doesn't scream ai generated writing by now, or perhaps the internet is truly dead
For example, 3 months ago developers of GZDoom didn't like where it heads, so forked it to UZDoom (vide https://github.com/ZDoom/gzdoom/issues/3395 and https://www.techspot.com/news/109864-gzdoom-developers-split...).
The core part is if you can find enough contributors (from the original repo, or new ones) to make it viable.
It won't be long at all before this becomes a huge amount of work for a relatively small divergence of the code. But we could build tools that would make it much less awful!
The article is also quite wrong, because there are already multiple forks of the original Mastodon code base, which have communities that adopted them. Not at the same magnitude as mastodon.social, but not negligible either.
> The result is lost value, lost history, and lost trust – rinse, repeat, move on.
I hate, hate, hate when someone that's on the side of building things proscribes what the people that actually do build should spend their effort on. I don't see Mr. Campbell building communities, fostering cooperation and gathering funds so that people can better work together instead of apart on things.
This kind of article is an empty, preachy, hot take which misses the point that open source is about communities of builders, not about communities of users, and is uselessly antagonistic against a whole category of people for basically no reward.
And that implication at the bottom that forking, as opposed to "collaboration", is close to fascism is a level of being so far up their ass that gets my humors up and my blood boiling.
When the possibility of forking exist there's at least a chance someone (or you yourself) takes over maintenance. Even if it's just basic 'port it to newer systems' stuff.
Was not. It's much easier now, with LLMs. E.g. I can easily maintain a fork of a Gnome component instead of dealing with the convoluted motivation of the pricks ruling the project and not willing to merge features because of no reason (e.g. "we won't add tray icon to our app because tray icons are deprecated in gnome. So what there is no alternative, we don't want it" or "no, we won't accept a PR improving mouse navigation because our keyboard navigation is broken and noone wants to fix it").
Of course it only works for some kinds of changes, and not total structural or cultural revision, but still it seems to be a part of many of the most vibrant open source projects.
I mean, we can engage with the ideas, there was intentionality in prompting the AI for this output, after all.
But it is interesting how after you see a bit of AI written text, it becomes super recognizable as afterwards.
jqpabc123•1h ago
These inherent problems are not new or unique or unexpected --- they have all been faced by similar *community* constructs in the past.
The biggest impediments to success are some of the most fundamental, unavoidable characteristics of human nature. And the last ditch effort at maintaining similar systems has often involved forced labor.