Comment by jamesbelchamber
6 hours ago
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]
6 replies →
> 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.
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."
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
> 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.
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.