11–20 of 91 posts
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.
[flagged]
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.
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.
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.
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.
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.
Does that help?
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.
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.
> 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