FOSS "Just Fork It" Delusion

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.

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.

> 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.

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.

> 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").

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.

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.

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.

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.

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.

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!

> ... 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, ...

> 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

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

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

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.

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.

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.

[flagged]

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.

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.