I think the wisdom of "just fork it" is that in a project the power lies with the people who do the work (yes, that power is often rented out in exchange for a pay cheque), and in an open source project you have the right to do that work without kowtowing to the authority of other people who did the work before you ("just fork it").
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.
Yes exactly. I've forked many a library to meet my own needs. Usually temporary, but not always. The fact that I can do this when I have to means I can use basically any library. The submitted post is written from the perspective of some kind of social network project. People saying "just fork it" in that perspective are clearly missing the bigger picture, hence the post. And the author of that post, didn't acknowledge that FOSS is much more varied than their particular project.
> Yes exactly. I've forked many a library to meet my own needs. Usually temporary,
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.
There's absolutely a far right fediverse. Though they're mostly (back) on Twitter for obvious reasons.
Not sure why this split would be a problem? It's a very Big Social Media idea that everyone should use the same thing and expose themselves / be exposed to everything.
is this a common problem? are software maintainers in the east sufficiently committed to racial superiority that they can't work with people in the west?
If almost everybody thinks you're so insufferable that they don't want to interact with you, chances are, you are.
This has been a function of societies for as long as societies have existed, and addressing it requires honest reflection. In this case: "why is there such a huge overlap between people competent and willing to host federated social media servers, and people who don't want to be around me?"
Unfortunately there is a pervasive attitude amongst a certain personality type, that if someone criticizes them, then that someone must be wrong, and must be fought, no matter what. It's common enough to have ICD-10 diagnosis codes for it: Narcissistic Personality Disorder and/or Oppositional Defiant Disorder.
This is why I rarely try to change people's minds anymore unless they appear receptive to it: there's a good chance an overactive amygdala will see it as an attack and just make more work for me, wasting my time. It's easier to just talk to them about something else, or if they're being unnecessarily rude to people: not talk to them.
You might reflect upon your own short comment history (or your username) and judge for yourself what proportion is polite & respectful vs. rude & belligerent, and consequently whether the average person would want to try having a nice conversation with you.
> If almost everybody thinks you're so insufferable that they don't want to interact with you, chances are, you are.
Or they disagree with your views so intensely that they want you silenced.
That's what happened with https://spinster.xyz defederation. A group of male administrators of other Fediverse instances took umbrage at the women-centered, feminist discussion there and between them defederated hundreds of servers away from Spinster.
This was on top of misogynistic attacks and attempts to deplatform. Some unfortunately successful, like the removal of the Spinster app from the Google Play Store and F-Droid.
the propensity for fediverse admins to act like tiny dictators is extremely worrying. i haven't seen a good solution to this sort of thing honestly. ultimately it also means that you have to walk on eggshells and force yourself into an impossible shape lest you offend someone's very special interest that you didn't even know you were lightly brushing up against (for example, you say "clanker" and therefore the owner of some instance immediately and without asking thinks you are against cyborgs, and they identify as a cyborg, therefore you are a bigot, and you get banned without warning and all your friendships are gone - didn't happen to me, but i've seen it happen to someone else). one of the worst things about this is that you can't have a really strong disagreement with people who are popular on some instance because social inner circles form very easily on tiny instances, and all of them are tiny, especially compared to non-federated, centralized networks where brushing up against inner circles that have connections to admins is much much less likely.
> Or they disagree with your views so intensely that they want you silenced. That's what happened with https://spinster.xyz defederation.
You're referring to an instance in which nobody was silenced, and all that happened was that some people chose not to interact with other people. That's totally okay! You don't have to interact with folks you think are insufferable.
> This was on top of misogynistic attacks
Unfortunately, most social networks are full of misogynists, racists, etc. As the size of the network grows, the probability of it including a jerk approaches 100%. In fact, this is one of the reasons someone might choose to run their own network in which they don't have to associate with said jerks. Based on a cursory search of your example, it looks like a lot of folks felt that spinster.xyz wasn't worth voluntarily associating with, perhaps because there was a high proportions of jerks.
> you have the right to do that work without kowtowing to the authority of other people who did the work before you ("just fork it").
> 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.
in 30+ years of software development i've never heard "just fork it" or "you're welcome to fork it" used as an encouragement and i've heard it as a dismissal countless times. the article is spot on, and your interpretation of the described real-life situation is a rosy-tinted hypothetical at best.
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.
i disagree with that stance. an open source project is made up of contributions by dozens, maybe thousands of people, and they almost always only contributed to that one specific repository under that one specific person's control due to game theoretical processes that are mostly random, such as first-mover advantage, schelling points, etc. the collective effort of those people usually far outweighs what the controlling person usually contributed to ostensibly earn this sort of privilege. if talking about a FOSS repository, that person cannot be correctly described as "the owner" of that work, as the work is owned by the public, i.e. anyone who is provided access to the code. the person you are describing is merely the current maintainer of the project and the fact that most of the work they are maintaining is not theirs, but comes from the public, and is meant for the public, immediately puts a burden of responsibility on them of acting in a way that is much better than "a project owner have the right to be dismissive about anything regarding their own project" - a mode of operation which, if you pull in all the considerations i presented here, sounds childish. a much better way is to talk about this like you would about an old watch: you are merely maintaining it for future generations. that puts you in a more humble and less combative mindset.
It's dismissive because most of the requests open source developers get need to be dismissed.
"Where can I send some cash for your hard work" is 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".
It would be, if it were true. I'm not going to cast the entirety of a very large community in a single light, but there are great deal of people in the open source community who are afraid of money, or more specifically, that someone else might be making some, especially using open source code that they didn't personally hand write.
Another symptom is most projects don't have an easy way to donate money to them.
see, that's the problem, you immediately jump to a combative stance + assume the current maintainer is always right, which is exactly how the situations i presented happen in the first place
There's software where the continued existence of a diligent community around that project is necessary (web browsers, OS drivers, security-critical software...), but there's also software where I don't need any of that and I'm grateful for the chance to ignore any community around it and keep using the software anyway. Sometimes ideas just aren't compatible, and that's fine, forking allows us to part amicably.
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.
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.
> But you write it as if it's in contradiction with my point, which I'm not seeing.
My point was that a community is members + values + practices + other stuff. In the case where one member who wants to upend the values and practices of an existing community, "just fork it" is an entirely reasonable response.
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.
Hard disagree... sorta. Or rather, I think the author is just looking at it the wrong way.
Most of the time when I see (or give) a "just fork it" response, it's a dismissal of an entitled user who believes that they are owed unpaid labor from a maintainer.
If you're working at some big company and are using open source software, and need a new feature or bug fixed RIGHT NOW, sometimes your best bet is to make an internal fork, implement it yourself, submit it upstream, and continue to maintain your fork until it's accepted upstream and there's a new public release.
I've done this several times in the past, and it's been fine. Sure, it's work to maintain a private fork, but it's usually a hell of a lot less work than implementing all the same functionality from scratch. And I'm getting paid to do that work, so it's fine.
Yes, sometimes "just fork it" is a response given to a random user who doesn't know much about software, is frustrated, and just wants to go about their day. It sucks for them to get a response like that, but really what it is is a brusque education in how the sausage is made.
I think the most rare "just fork it" is due to actual disagreements over project direction from peers. I think this particular case is what this article is really about, but, honestly, it barely warrants discussion. Yes, it's hard to build and sustain a community around a fork. That's life. A maintainer telling you "just fork it" in this instance is implicitly reminding you of this fact, and to consider the implications of striking out in your own. You may choose to do so anyway, and that is the beauty of open source.
I don't really understand these sort of articles. If something is closed source and the original owners quit or decide they move to a subscription model or whatever then you're just screwed no matter what.
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").
Seems like the author's only talking about the extreme end of the spectrum. Not every fork is attempting to replace the forked project. There are so many other lesser degrees.
You can fork something just for a fun or experimentation. You could have a use case that the project doesn't handle and you aren't ready or interested in contributing that solution (especially if you only need this for a one-off scenario or a short-lived project).
This could also apply to needs that your client or company has, but it's out of scope for the original project, so you make a private fork that you and your team maintain internally. It could be that you DO actually make this public (either initially or eventually) so other people who have the same need can benefit and possibly contribute.
It could even be that, over time, the amount of users of your fork convince the upstream project that there is a need for this use case. Maybe they decide to handle it themselves or maybe your fork merges back in with the upstream. Sometimes projects just can't say yes to certain things because they wouldn't want to/be able to implement, maintain and support it. Seeing that you and others maintain a fork for a non-trivial amount of time can establish the credibility that there is indeed someone who will maintain this.
> forking is easy, sustaining is hard. Forking code is cheap, sustaining a living project is not.
This what I wish people would remember before they complain that some feature they can barely verbalize isn't in the codebase. They deserve the "just fork it" slam because they can't imagine that actually, a maintainer's life is already hard enough.
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.
A middle ground is "just write a plug-in." What I mean is, I like programs that provide a mechanism for scripting, adding a plug-in, whatever. This allows you to add a feature and perhaps even maintain it in your own repo, without trying to manage the entire project yourself.
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.
This is now my favorite explanation of how I feel when people default to “just fork it”. I’ve always had trouble expressing how I think that is a symptom of a community problem. One that is endemic in many Linux communities. The next time I want to explain this, I’ll be linking to this post.
> ... but in practice it is used to protect informal power. Core teams stay untouched ...
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, ...
Loved this article. The focus on social concerns above technical ones is extremely refreshing, and a necessary step forward our culture needs to take in order to survive with any sort of dignity... The fragility/ephemerality of all kinds of software weighs heavily on me.
Part of the problem is the maintenance cost of a fork just in terms of merging upstream commits.
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!
So what is the solution? Is the author demanding that people work for them for free to do the sustainability for them? Because that sure sounds like the only way to "resolve" the complaint.
"start treating it as what it often is: a refusal to do the harder social work in #FOSS"
Your ending is missing something... "a refusal to do the harder social work that I want you to do in #FOSS".
But I didn't promise that. Nobody promised that. FOSS is an unparalleled gift of free work and not a single line of it has formed an obligation on my part to help anyone who wants to come along and make it do something different. You are welcome to do that, but I have no obligation on any level to come along and help you "sustain" your own work. No legal obligation, no moral obligation, no community obligation no reciprocal obligation, no Kantian imperative obligation, no obligation whatsoever. If anything, you owe them, not the other way around; any other read of the ethical situation is utterly absurd.
You want "more social work" done, you feel free to do it. Don't be shocked when I'm not interested in helping.
This is just a demand for more free work from people who have already handed you the result of more free work than any other collection of work in human history. It is deeply ungrateful to demand yet more.
It seems that many people lean into the "community" aspect of open source. In real communities there are webs of mutual responsibility. If you use open source to fill the role of community in your life, it makes sense psychologically that you would project moral stakes or obligation onto the maintainers. But this is really not fair to the maintainers who don't view their work that way.
It's not a delusion, it's reality. The Right-To-Fork is a critical part of the proper definition of FLOSS, and key to its success. OP is just saying that maintaining a FOSS project is hard, but who cares? Maintenance is open to forking too: if you think an existing maintainer is doing a bad job of it, you can just take that code wholesale and maintain a version of it on your own.
The article is technically right, but only because the author misses the point.
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.
In other words, forking punishes poorly managed projects by depriving them of some fraction of their developers, users, and mindshare, and that's fascism?
Judging from the comments here, I think the article would be improved by discussing actual examples of the "just fork it" debate, because commenters seem to be reading different interpretations and different situations into this expression, and I'm not sure that's how the article author was interpreting it.
If the author fundamentally misunderstands the social and technical implications around the topic. Then yes, it's good that all the comments are correcting the misunderstandings of the post.
The blog post makes a lot of arguments, that sound like they might be good. Only until you try to apply them to reality, when they fail. So yes, it's a good thing that examples that would encourage the debate to shift from critiques of the faulty arguments, to heated exchanges over internet drama requiring popcorn.
The point of an essay is not just to make true statements. It's also to convince readers of those statements. Thus, the way the arguments are presented by the writer, and the way that readers interpret the arguments, is crucial.
This attitude is cancer to OSS. The social aspect of OSS isn't required from anyone. Maintainers don't owe anyone a thing. The ability to fork and have your own source with the right to use as you wish is literally the defining feature of OSS, otherwise it's just shareware.
But hey, it's telling that the author places stewardship and branding before functionality when talking about reasons to fork.
> Don’t like how it’s run? Do something different. Don’t like the branding? Change it. Got a better idea? Implement it.
... but somehow fails to qualify that distinction in its actual content. "FOSS" includes opentofu and mysql and the redis alternatives and a lot more than just social media alternatives...
When you inflame that reader with grandstanding titles like "FOSS has delusions" perhaps they could be forgiven for taking that literally when nothing else clarifies your trite generality, me thinks.
Another person that isn't able to make the distinction between developing software and operating platforms and imagining that everyone else is equally befuddled.
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.~~ [edit] This juxtaposition between the article about forking and the one about fascism might not be intentional by the author, but it's still an unhealthy implication to leave on.
Ooh, this is gold: "The slogan pretends to be anti-authority, but in practice it is used to protect informal power."
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.
I agree it’s often used to shut down discussion, but most often I’ve seen it when a contributor is losing an argument (their PR isn’t getting merged, or their feature request is rejected, or their bug is marked wont-fix) and they don’t agree.
“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.
I still don’t understand how someone who wants something different from what’s on offer is “a victim”.
I do agree that “just fork it” is a flippant and pretty unhelpful thing to say, but just because a piece of software is open source, that doesn’t necessarily automatically mean that its development should follow the designs of a committee of its users.
You are absolutely correct that often, open source projects are indeed run with the maintainers exercising absolute control. I think this is where the tension comes in, because sometimes, folks expect that to be different, and approach the project with a sense of entitlement that somehow the project should change to fit their needs.
“Just fork it” is a way of saying “if you need it to fit your needs, feel free to take what we’ve done so far and add what you need, but we aren’t going to”.
The author’s core argument seems to be summarised here: “In social terms, it’s the equivalent of saying: “If you don’t like society, go start your own civilisation.”
It’s not at all equivalent though. It’s more like “I invited everyone round for dinner, and I don’t want my house to smell of fish, so I’m not cooking fish. If you want to cook fish, you can borrow my pans, but invite everyone round to your house instead.”
> Power is concentrated; checks and balances are minimal or nonexistent.
Is power concentrated? What power do maintainer of FOSS projects have over people who would like to use that project? How can they compel people to do what they want as it relates to the project?
> 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.
It can't possibly be suggesting that the person is wrong for wanting something different. The "drive by", "fork it" comment is saying. If you want something different, then make the different thing exist, no one will be able to stop you from making the thing that you want.
Unless you feel that the different thing is the person who is complaining, is entitled to having other people do what the complainer wants, instead of what the maintainer wants?
On the internet; if you wanted to suggest that someone's complaints or suggestions are illegitimate, you wouldn't say "fork it" you would say, "no, that's stupid, you're stupid, how could you suggest such a dumb, stupid, crazy, insane thing?!" surely followed by a series of extra expletives, or angry rage posts.
Or the just fork it comment is from a maintainer. Who has decided that they do not want the suggested changes. In which case, it's still not saying the changes are illegitimate, it's saying that the maintainer objects to them; so they're offering the only remaining solution for the complainer to get the changes they want.
Bottom line: Open Source is a *community* system built around a few flawed assumptions.
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.
Open-Source in its actuality is not a lot about community. It's about making sure other people have everything they need to be able to run and modify a specific piece of software. The fact that, usually communities form around this paradigm is a happy coincidence in my opinion. Additionally, another point on both you and OP are missing the point, is that the communities that are relevant to open-source are not communities of users, but communities of contributors.
And what OP is proposing is actually forced labour. Instead of people being free to work (and fork) to their heart contents, the implication exists that they're losing their time, and instead, should focus on "collaborating" with the existing community. Which frankly nobody in the history of open-source ever denied. Forks are last instance measures, where the steering of a project gets off the rails to a high enough degree to justify such a drastic measure.
I think the wisdom of "just fork it" is that in a project the power lies with the people who do the work (yes, that power is often rented out in exchange for a pay cheque), and in an open source project you have the right to do that work without kowtowing to the authority of other people who did the work before you ("just fork it").
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.
Yes exactly. I've forked many a library to meet my own needs. Usually temporary, but not always. The fact that I can do this when I have to means I can use basically any library. The submitted post is written from the perspective of some kind of social network project. People saying "just fork it" in that perspective are clearly missing the bigger picture, hence the post. And the author of that post, didn't acknowledge that FOSS is much more varied than their particular project.
> Yes exactly. I've forked many a library to meet my own needs. Usually temporary,
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.
Social networks can fork while still being interoperable. That's what the whole federation thing is all about.
[flagged]
There's absolutely a far right fediverse. Though they're mostly (back) on Twitter for obvious reasons.
Not sure why this split would be a problem? It's a very Big Social Media idea that everyone should use the same thing and expose themselves / be exposed to everything.
is this a common problem? are software maintainers in the east sufficiently committed to racial superiority that they can't work with people in the west?
If almost everybody thinks you're so insufferable that they don't want to interact with you, chances are, you are.
This has been a function of societies for as long as societies have existed, and addressing it requires honest reflection. In this case: "why is there such a huge overlap between people competent and willing to host federated social media servers, and people who don't want to be around me?"
Unfortunately there is a pervasive attitude amongst a certain personality type, that if someone criticizes them, then that someone must be wrong, and must be fought, no matter what. It's common enough to have ICD-10 diagnosis codes for it: Narcissistic Personality Disorder and/or Oppositional Defiant Disorder.
This is why I rarely try to change people's minds anymore unless they appear receptive to it: there's a good chance an overactive amygdala will see it as an attack and just make more work for me, wasting my time. It's easier to just talk to them about something else, or if they're being unnecessarily rude to people: not talk to them.
You might reflect upon your own short comment history (or your username) and judge for yourself what proportion is polite & respectful vs. rude & belligerent, and consequently whether the average person would want to try having a nice conversation with you.
> If almost everybody thinks you're so insufferable that they don't want to interact with you, chances are, you are.
Or they disagree with your views so intensely that they want you silenced.
That's what happened with https://spinster.xyz defederation. A group of male administrators of other Fediverse instances took umbrage at the women-centered, feminist discussion there and between them defederated hundreds of servers away from Spinster.
This was on top of misogynistic attacks and attempts to deplatform. Some unfortunately successful, like the removal of the Spinster app from the Google Play Store and F-Droid.
the propensity for fediverse admins to act like tiny dictators is extremely worrying. i haven't seen a good solution to this sort of thing honestly. ultimately it also means that you have to walk on eggshells and force yourself into an impossible shape lest you offend someone's very special interest that you didn't even know you were lightly brushing up against (for example, you say "clanker" and therefore the owner of some instance immediately and without asking thinks you are against cyborgs, and they identify as a cyborg, therefore you are a bigot, and you get banned without warning and all your friendships are gone - didn't happen to me, but i've seen it happen to someone else). one of the worst things about this is that you can't have a really strong disagreement with people who are popular on some instance because social inner circles form very easily on tiny instances, and all of them are tiny, especially compared to non-federated, centralized networks where brushing up against inner circles that have connections to admins is much much less likely.
> Or they disagree with your views so intensely that they want you silenced. That's what happened with https://spinster.xyz defederation.
You're referring to an instance in which nobody was silenced, and all that happened was that some people chose not to interact with other people. That's totally okay! You don't have to interact with folks you think are insufferable.
> This was on top of misogynistic attacks
Unfortunately, most social networks are full of misogynists, racists, etc. As the size of the network grows, the probability of it including a jerk approaches 100%. In fact, this is one of the reasons someone might choose to run their own network in which they don't have to associate with said jerks. Based on a cursory search of your example, it looks like a lot of folks felt that spinster.xyz wasn't worth voluntarily associating with, perhaps because there was a high proportions of jerks.
> you have the right to do that work without kowtowing to the authority of other people who did the work before you ("just fork it").
> 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.
in 30+ years of software development i've never heard "just fork it" or "you're welcome to fork it" used as an encouragement and i've heard it as a dismissal countless times. the article is spot on, and your interpretation of the described real-life situation is a rosy-tinted hypothetical at best.
> i've heard it as a dismissal countless times.
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.
i disagree with that stance. an open source project is made up of contributions by dozens, maybe thousands of people, and they almost always only contributed to that one specific repository under that one specific person's control due to game theoretical processes that are mostly random, such as first-mover advantage, schelling points, etc. the collective effort of those people usually far outweighs what the controlling person usually contributed to ostensibly earn this sort of privilege. if talking about a FOSS repository, that person cannot be correctly described as "the owner" of that work, as the work is owned by the public, i.e. anyone who is provided access to the code. the person you are describing is merely the current maintainer of the project and the fact that most of the work they are maintaining is not theirs, but comes from the public, and is meant for the public, immediately puts a burden of responsibility on them of acting in a way that is much better than "a project owner have the right to be dismissive about anything regarding their own project" - a mode of operation which, if you pull in all the considerations i presented here, sounds childish. a much better way is to talk about this like you would about an old watch: you are merely maintaining it for future generations. that puts you in a more humble and less combative mindset.
It's dismissive because most of the requests open source developers get need to be dismissed.
"Where can I send some cash for your hard work" is 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".
That brings to mind one of my favorite sayings:
"It may be open source, but that doesn't mean that it is afraid of money."
It would be, if it were true. I'm not going to cast the entirety of a very large community in a single light, but there are great deal of people in the open source community who are afraid of money, or more specifically, that someone else might be making some, especially using open source code that they didn't personally hand write.
Another symptom is most projects don't have an easy way to donate money to them.
see, that's the problem, you immediately jump to a combative stance + assume the current maintainer is always right, which is exactly how the situations i presented happen in the first place
Well said. Open source helps with agency, freedom of association, and voluntary action.
Maintainers have the freedom to choose whether to accept an idea or not. Users have the freedom to fork or not.
So this is interesting. It seems worth distinguishing here between a fork (the code itself), and a schism (a split in the community).
A fork doesn't require a schism, but a schism does seem to require a fork.
> forks usually aren't hostile
This. You can't even issue a Git pull/merge request without technically forking the project first! It's super common.
The article isn’t talking about the fork operation. It’s talking about running and maintaining a forked project as a new project and community.
There's software where the continued existence of a diligent community around that project is necessary (web browsers, OS drivers, security-critical software...), but there's also software where I don't need any of that and I'm grateful for the chance to ignore any community around it and keep using the software anyway. Sometimes ideas just aren't compatible, and that's fine, forking allows us to part amicably.
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.
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.
> But you write it as if it's in contradiction with my point, which I'm not seeing.
My point was that a community is members + values + practices + other stuff. In the case where one member who wants to upend the values and practices of an existing community, "just fork it" is an entirely reasonable response.
You say "often used as a first resort to shut down criticism"
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
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.
Hard disagree... sorta. Or rather, I think the author is just looking at it the wrong way.
Most of the time when I see (or give) a "just fork it" response, it's a dismissal of an entitled user who believes that they are owed unpaid labor from a maintainer.
If you're working at some big company and are using open source software, and need a new feature or bug fixed RIGHT NOW, sometimes your best bet is to make an internal fork, implement it yourself, submit it upstream, and continue to maintain your fork until it's accepted upstream and there's a new public release.
I've done this several times in the past, and it's been fine. Sure, it's work to maintain a private fork, but it's usually a hell of a lot less work than implementing all the same functionality from scratch. And I'm getting paid to do that work, so it's fine.
Yes, sometimes "just fork it" is a response given to a random user who doesn't know much about software, is frustrated, and just wants to go about their day. It sucks for them to get a response like that, but really what it is is a brusque education in how the sausage is made.
I think the most rare "just fork it" is due to actual disagreements over project direction from peers. I think this particular case is what this article is really about, but, honestly, it barely warrants discussion. Yes, it's hard to build and sustain a community around a fork. That's life. A maintainer telling you "just fork it" in this instance is implicitly reminding you of this fact, and to consider the implications of striking out in your own. You may choose to do so anyway, and that is the beauty of open source.
I don't really understand these sort of articles. If something is closed source and the original owners quit or decide they move to a subscription model or whatever then you're just screwed no matter what.
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.
> sustaining a living project is not
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").
Seems like the author's only talking about the extreme end of the spectrum. Not every fork is attempting to replace the forked project. There are so many other lesser degrees.
You can fork something just for a fun or experimentation. You could have a use case that the project doesn't handle and you aren't ready or interested in contributing that solution (especially if you only need this for a one-off scenario or a short-lived project).
This could also apply to needs that your client or company has, but it's out of scope for the original project, so you make a private fork that you and your team maintain internally. It could be that you DO actually make this public (either initially or eventually) so other people who have the same need can benefit and possibly contribute.
It could even be that, over time, the amount of users of your fork convince the upstream project that there is a need for this use case. Maybe they decide to handle it themselves or maybe your fork merges back in with the upstream. Sometimes projects just can't say yes to certain things because they wouldn't want to/be able to implement, maintain and support it. Seeing that you and others maintain a fork for a non-trivial amount of time can establish the credibility that there is indeed someone who will maintain this.
> forking is easy, sustaining is hard. Forking code is cheap, sustaining a living project is not.
This what I wish people would remember before they complain that some feature they can barely verbalize isn't in the codebase. They deserve the "just fork it" slam because they can't imagine that actually, a maintainer's life is already hard enough.
> forking is easy, sustaining is hard.
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.
A middle ground is "just write a plug-in." What I mean is, I like programs that provide a mechanism for scripting, adding a plug-in, whatever. This allows you to add a feature and perhaps even maintain it in your own repo, without trying to manage the entire project yourself.
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.
This is now my favorite explanation of how I feel when people default to “just fork it”. I’ve always had trouble expressing how I think that is a symptom of a community problem. One that is endemic in many Linux communities. The next time I want to explain this, I’ll be linking to this post.
It is not a delusion. It happens all the time.
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.
> That’s not empowerment – it’s fragmentation
> 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
Half the comments on this forum itself have this incessant it's not X, it's y" pattern.
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
I really can't understand the mindset of prompt-blogging.
[dead]
> ... but in practice it is used to protect informal power. Core teams stay untouched ...
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, ...
Loved this article. The focus on social concerns above technical ones is extremely refreshing, and a necessary step forward our culture needs to take in order to survive with any sort of dignity... The fragility/ephemerality of all kinds of software weighs heavily on me.
Part of the problem is the maintenance cost of a fork just in terms of merging upstream commits.
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!
So what is the solution? Is the author demanding that people work for them for free to do the sustainability for them? Because that sure sounds like the only way to "resolve" the complaint.
"start treating it as what it often is: a refusal to do the harder social work in #FOSS"
Your ending is missing something... "a refusal to do the harder social work that I want you to do in #FOSS".
But I didn't promise that. Nobody promised that. FOSS is an unparalleled gift of free work and not a single line of it has formed an obligation on my part to help anyone who wants to come along and make it do something different. You are welcome to do that, but I have no obligation on any level to come along and help you "sustain" your own work. No legal obligation, no moral obligation, no community obligation no reciprocal obligation, no Kantian imperative obligation, no obligation whatsoever. If anything, you owe them, not the other way around; any other read of the ethical situation is utterly absurd.
You want "more social work" done, you feel free to do it. Don't be shocked when I'm not interested in helping.
This is just a demand for more free work from people who have already handed you the result of more free work than any other collection of work in human history. It is deeply ungrateful to demand yet more.
It seems that many people lean into the "community" aspect of open source. In real communities there are webs of mutual responsibility. If you use open source to fill the role of community in your life, it makes sense psychologically that you would project moral stakes or obligation onto the maintainers. But this is really not fair to the maintainers who don't view their work that way.
It's not a delusion, it's reality. The Right-To-Fork is a critical part of the proper definition of FLOSS, and key to its success. OP is just saying that maintaining a FOSS project is hard, but who cares? Maintenance is open to forking too: if you think an existing maintainer is doing a bad job of it, you can just take that code wholesale and maintain a version of it on your own.
I feel like this post is a few years too late; with AI assistance you can probably fork things productively now more than ever
The article is technically right, but only because the author misses the point.
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.
> when that problem is big enough that enough people are thinking about forking it
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.
I explained my point wrong.
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.
boundary-setting is natural and reasonable
an inventor has no obligation to fulfill all the side quests observers imagine, that’s why they tell you to fork it
angst over this seems misguided
In other words, forking punishes poorly managed projects by depriving them of some fraction of their developers, users, and mindshare, and that's fascism?
Judging from the comments here, I think the article would be improved by discussing actual examples of the "just fork it" debate, because commenters seem to be reading different interpretations and different situations into this expression, and I'm not sure that's how the article author was interpreting it.
that would turn it into a witch hunt drama post. it's good that this sort of thing wasn't included.
> it's good that this sort of thing wasn't included.
Is it good that the article has inspired mostly "the author is wrong" comments, more so than even the usual for HN?
If the author fundamentally misunderstands the social and technical implications around the topic. Then yes, it's good that all the comments are correcting the misunderstandings of the post.
The blog post makes a lot of arguments, that sound like they might be good. Only until you try to apply them to reality, when they fail. So yes, it's a good thing that examples that would encourage the debate to shift from critiques of the faulty arguments, to heated exchanges over internet drama requiring popcorn.
> If the author fundamentally misunderstands the social and technical implications around the topic.
You present this as a hypothetical, but your next paragraph appears to take it as a fact.
I do not make such an assumption, which is why I think clarification would be useful rather than just a distraction.
a tiny cohort's opinion does not change the truthfulness of a statement
The point of an essay is not just to make true statements. It's also to convince readers of those statements. Thus, the way the arguments are presented by the writer, and the way that readers interpret the arguments, is crucial.
The readers on this website are hopefully less lazy than that
How is it laziness to not be able to magically read a writer's mind?
critical reading does not require clairvoyance
They are reading critically.
This attitude is cancer to OSS. The social aspect of OSS isn't required from anyone. Maintainers don't owe anyone a thing. The ability to fork and have your own source with the right to use as you wish is literally the defining feature of OSS, otherwise it's just shareware.
But hey, it's telling that the author places stewardship and branding before functionality when talking about reasons to fork.
> Don’t like how it’s run? Do something different. Don’t like the branding? Change it. Got a better idea? Implement it.
[flagged]
It is not click-bait. The article does not describe the situations like opentofu or mysql.
... but somehow fails to qualify that distinction in its actual content. "FOSS" includes opentofu and mysql and the redis alternatives and a lot more than just social media alternatives...
thinking critically is left as an exercise to the reader.
When you inflame that reader with grandstanding titles like "FOSS has delusions" perhaps they could be forgiven for taking that literally when nothing else clarifies your trite generality, me thinks.
This has so many characteristics of AI writing. I would be surprised if it was written by a human.
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.
Another person that isn't able to make the distinction between developing software and operating platforms and imagining that everyone else is equally befuddled.
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.~~ [edit] This juxtaposition between the article about forking and the one about fascism might not be intentional by the author, but it's still an unhealthy implication to leave on.
Ooh, this is gold: "The slogan pretends to be anti-authority, but in practice it is used to protect informal power."
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.
I agree it’s often used to shut down discussion, but most often I’ve seen it when a contributor is losing an argument (their PR isn’t getting merged, or their feature request is rejected, or their bug is marked wont-fix) and they don’t agree.
“Victim blaming” is an odd phrase here. Could you clarify what you mean?
Sure.
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 still don’t understand how someone who wants something different from what’s on offer is “a victim”.
I do agree that “just fork it” is a flippant and pretty unhelpful thing to say, but just because a piece of software is open source, that doesn’t necessarily automatically mean that its development should follow the designs of a committee of its users.
You are absolutely correct that often, open source projects are indeed run with the maintainers exercising absolute control. I think this is where the tension comes in, because sometimes, folks expect that to be different, and approach the project with a sense of entitlement that somehow the project should change to fit their needs.
“Just fork it” is a way of saying “if you need it to fit your needs, feel free to take what we’ve done so far and add what you need, but we aren’t going to”.
The author’s core argument seems to be summarised here: “In social terms, it’s the equivalent of saying: “If you don’t like society, go start your own civilisation.”
It’s not at all equivalent though. It’s more like “I invited everyone round for dinner, and I don’t want my house to smell of fish, so I’m not cooking fish. If you want to cook fish, you can borrow my pans, but invite everyone round to your house instead.”
> Power is concentrated; checks and balances are minimal or nonexistent.
Is power concentrated? What power do maintainer of FOSS projects have over people who would like to use that project? How can they compel people to do what they want as it relates to the project?
> 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.
It can't possibly be suggesting that the person is wrong for wanting something different. The "drive by", "fork it" comment is saying. If you want something different, then make the different thing exist, no one will be able to stop you from making the thing that you want.
Unless you feel that the different thing is the person who is complaining, is entitled to having other people do what the complainer wants, instead of what the maintainer wants?
On the internet; if you wanted to suggest that someone's complaints or suggestions are illegitimate, you wouldn't say "fork it" you would say, "no, that's stupid, you're stupid, how could you suggest such a dumb, stupid, crazy, insane thing?!" surely followed by a series of extra expletives, or angry rage posts.
Or the just fork it comment is from a maintainer. Who has decided that they do not want the suggested changes. In which case, it's still not saying the changes are illegitimate, it's saying that the maintainer objects to them; so they're offering the only remaining solution for the complainer to get the changes they want.
Bottom line: Open Source is a *community* system built around a few flawed assumptions.
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.
Open-Source in its actuality is not a lot about community. It's about making sure other people have everything they need to be able to run and modify a specific piece of software. The fact that, usually communities form around this paradigm is a happy coincidence in my opinion. Additionally, another point on both you and OP are missing the point, is that the communities that are relevant to open-source are not communities of users, but communities of contributors.
And what OP is proposing is actually forced labour. Instead of people being free to work (and fork) to their heart contents, the implication exists that they're losing their time, and instead, should focus on "collaborating" with the existing community. Which frankly nobody in the history of open-source ever denied. Forks are last instance measures, where the steering of a project gets off the rails to a high enough degree to justify such a drastic measure.