[jamesbelchamber]

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.

[jeremyjh]

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.

[Aurornis]

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

[zozbot234]

Social networks can fork while still being interoperable. That's what the whole federation thing is all about.

[Aurornis]

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

[boltzmann-brain]

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.

[chii]

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

[boltzmann-brain]

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.

[chii]

a project is a dictatorship, not a democracy.

The dictator could be benevolent - as is most, because it's the most beneficial to be one. However, there's no rules that says they must be. They could run it with an iron fist. The contributors do so knowing this - or at least, should have known this.

Look at wordpress's fiasco, for example.

You are under the illusion that the owner is doing the project for the betterment of the community. They _might_ be, but it's not a requirement.

I personally behave as if everyone is selfish, and will be out to screw you if given the opportunity and reason. Assume the worst and plan for that; if it turns out they are nice, then all the better.

[cornholio]

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

[ssl-3]

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

[fragmede]

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.

[LtWorf]

> Another symptom is most projects don't have an easy way to donate money to them.

The money/downloads value is so low it's basically a waste of time to set it up.

[boltzmann-brain]

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

[cornholio]

The current maintainer is always right by definition, has put in the hard work and is entitled to drag the project into whatever deranged fantasy they might have.

You just don't get a vote, there is no objective truth to settle disputes when it comes to someone else's work and projects. You can stop using the work or fork it, perhaps alongside other like minded users and contributors, crating a viable split.

[kfreds]

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.

[zozbot234]

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

[Aurornis]

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.

[andai]

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.