[ddevault]

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care"

Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.

[Ygg2]

> They were hateful and virtrolous

Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

[hjek]

> Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?

[dependenttypes]

This was posted after fafhrd91 was rude. Also...

> The last few were rude, but so was the fafhrd91

[ivanbakel]

Cherry-picking a comment doesn't give a good representation of the community. The GP is right - most comments were courteous. The point is that saying "the community" was hateful and vitriolic needs more evidence than a couple of bad eggs, because those exist everywhere.

[enumjorge]

The parent comment still stands. Whether the maintainer was in the right or in the wrong, whether they were being a jerk or not, if he wasn’t listening to the community why not just fork the code? GitHub’s UI makes that super easy.

[jhall1468]

Just because it's easy to fork in the UI, doesn't mean it's easy to get people to switch. Some people are actually concerned about the community as a whole, rather than their own projects.

[Ygg2]

He explicitly made the repo private over handing it to someone else.

https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

[nevi-me]

Counter: what about the tension and potential community split when a fork starts getting popular?

I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps.

We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would still keep tension high.

[notyourday]

nodejs <=> io.js split was a great evolutionary step.

It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright.

If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.

[nevi-me]

The risk was worth it, node was stuck (in 0.12), and it was the whole thing, not "one of the things that you use to run JS on the server". A fork of actix wouldn't enjoy the same conditions that existed with Node.

Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense?

There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await.

Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...

[jasondclinton]

You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.

[kungtotte]

Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise.

Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour.

Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...

[jasondclinton]

Should a politician be held responsible for every unhinged, vitriolic tweet by one of their supporters?

[gbear605]

Maybe not the politician, but the general group of “supporters of politician X” should be.

[cushychicken]

I wholly agree with your viewpoint in this comment.

There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project.

This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me.

Pull requests welcome, jerks. </s>