This is not so. If you said "forking can be perceived as an aggressive action"* I would not disagree with you, but in the context of an FOS ecosystem, forking should not be perceived as aggressive, and it definitely is not inherently so. If someone doesn't want anyone to fork their project, why release it under an open source license? Free/Open source, full control: pick one.
I object to the characterization of forking as aggressive first because it's not, and second because it cuts off another potential avenue of redress or action. We already agree that "shouting on twitter and reddit" is not a good response. If you declare forking off limits or "impolite," what alternatives are left in a case like this?
I acknowledge the complicated ecosystem impacts of forking a popular project (I'm from the JS world where the impacts are extreme), but I don't think "let a project stagnate or yell and shout because the maintainer has other priorities" is a better alternative.
Forking a project in a case like this should be seen as "putting your money where your mouth is"/"stepping up to the plate"/taking on responsibility for change if you think a project is going in the wrong direction. Personally, I fault bitter complainers who don't fork a project for being lazy: do you care enough to actually do the maintainer's job, to take on that responsibility? If no, then what gives you the right to condemn them? If yes, great! Your problem is solved and you can maintain rather than complain.
More forks please.
* just as asking someone "where are you from?" can be perceived as aggressive but that doesn't make it objectively/inherently aggressive.
Why? What's the danger here? Is the original maintainer going to send someone named Vinny to break your legs if you fork a project that won't accept a security patch you need?
I think you should just fork it privately, apply your patch, and move on with your life.
If you're keeping it private, none of this applies. I'm talking about "hey that project is bad, I am now maintaining a competing project, please use it instead."
Instead of framing it as "that project is objectively bad, my one is better", why not say "my project is a fork of this project but with a bit less unsafe" and then see what the community does?
Forking isn't provocative. Forking and then claiming your fork is objectively superior is.
What peril? Why is everyone treating online outrage mobs as if they had any power or authority? Who cares if some unimportant anonymous commentator thinks a fork is aggressive?
Agreed. But how do we define "people"? Are your prospective users all hanging out on Reddit and Twitter? Or are these two communities, as I believe, vocal but unrepresentative slices of a much larger potential silent user base?
Totally, I think that sometimes, forks do make sense! Sometimes, you have to be aggressive, and people will find it justified. io.js is a great example of this happening and working.
On the consumer-dev side, more forks make discoverability much harder. It really helps when there's a canonical place to find a given piece of software. Having to follow comment threads across various platforms to find the most stable version with that feature you want is a huge pain.
Also the core dev(s) for larger projects are usually somewhat responsive, whereas devs who fork to add their one feature usually aren't signing up for that core maintainer experience when they do so.
I wanted SimpleProtocolPlayer to be in F-Droid. This requires the author's explicit consent. Unfortunately, the author had not been seen active on the project for a while and did not respond to our questions.
I forked the project so I could be the "author" and give my consent (yes, clearly a hack), told them about it, and my willing to merge back at any time. See [1] if interested.
They eventually told me they were fine with the fork, and preferred having a fork for the F-Droid version of the app so we did not have to rely on their responsiveness.
My fork included a fix that they merged.
Some situations warrant a fork, and if communication (about the intents, the means and the expectations) is handled as best as possible, the fork can be seen as friendly by everyone.
You are right though, I would not want to become the maintainer of projects I sent a patch to. And by the way, I did not really want to become the maintainer of the F-Droid version of SimpleProtocolPlayer at first, but this is fine.
Shouldn't we disabuse ourselves of that notion? Forking a project to solve an issue is just that. We shouldn't attach any sort of emotional connotation to it.
We are already WAY past that line, just because people don't fork
> and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.
So DON'T run a project. Fork it, fix your problems and be done with it.
This seems to be at the core of the disagreements in this thread, one argument being that you shouldn't be expected to maintain a community project just because you put code on the internet.
Expecting that will lead to less open sourced code, which is bad IMHO.
Lastly, your last argument argument reads a little bit as "Not everybody has the desire or time to run a project, so what they want is somebody else to do it"
I might be reading in to much into it though. This thread has a fair amount of pronounced entitlement.
Forking is an act of love. If you fork a project of mine, you show that you care enough about it to maintain it yourself, but your time and energy into my "original" code.
Forking can be aggressive if you write deprecating things into the forked project's readme, but of course you don't have to do that.
You could also talk to the old maintainer before forking; maybe they are happy to give up some responsibility, or maybe they even endorse a fork.
Forking someone’s project because they won’t accept your PRs will definitely make them feel harangued by the community. I’m not sure if it necessarily has to be that way, but creating a hostile fork is conventionally considered very rude.
What makes it hard is that upstream users have no attention bandwidth to dedicate to your project's (meta-project's?) internal disputes. They're just going to decide which fork they think is the main one and use that. If you look at Presto, that's a good example of how hostile forks tend to go; both sides have to insist they're the real project, the main project, because otherwise nobody will use them.
Maybe there's a solution to that other than avoiding forks, but I'm not sure what it would be. It seems like a pretty fundamental challenge.
But… are there ways forking could be made less aggressive (perhaps easy re-joining, community-based PR review and testing)? I remember this was a huge deal in the NodeJS community a few years back—it took a hostile fork to get the conservatives and progressives to agree on a way forward together.
