I think this argument massively ignores the underlying message of this blogpost: addressing that the human beings that make and use software aren't always treated as, well, human beings.
> A maintainer goes to jail for vehicular manslaughter and a bugs needs fixing, no problem
The author didn't seem to hint that open bugs in core-js or its usefulness to its community of users are / is problematic. They hinted that maintainers are people with real life problems, whether that's struggling to make a livelihood, or facing imprisonment and ignoring that social/economic context is problematic.
Stating "well, let's just fork their code and off we go" basically ignores the person behind the code entirely. It reduces the value of a person to their ability to spend time and effort on maintaining code. And that's just a morally very questionable way of approaching other people. That kind of behavior just doesn't foster any mutual trust or respect which are the basic requirements for open source to thrive to begin with.
> But that's all part of the deal going in, and everyone is fully aware of all the trade-offs straight from the onset.
No, absolutely not. That's not how the original instigators of the Open Source movement envisioned this.
Yes, open source licensing allows forking, but that's not something you'd do, for instance, because a maintainer fails to respond to your issues on GitHub.
Eric S. Raymond can be quoted from his seminal essay "Homesteading the noosphere":
> The three taboos we observed above make perfect sense under this analysis. One's reputation can suffer unfairly if someone else misappropriates or mangles one's work; these taboos (and related customs) attempt to prevent this from happening. (Or, to put it more pragmatically, hackers generally refrain from forking or rogue-patching others' projects in order to be able to deny legitimacy to the same behavior practiced against themselves.)
> Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork. (This would generally be too confusing or difficult to be practical.)
> Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches (but see [RP]).
> Surreptitiously filing someone's name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim's gift to be presented as the thief's own.
http://catb.org/~esr/writings/homesteading/homesteading/ar01...
Especially the last taboo is incriminating.
In the past, I kept a handful of tiny open source libraries in PHP on Packagist. Someone forked one of those without notifying me and started directly competing with mine. I can't express how off putting that experience was at the time. It has made me quite apprehensive of pro-actively sharing code I write in my spare time under an open source license.
Because someone falls on hard times or isn't available for a while, that doesn't justify taking their work and presenting it as your own under the guise of "having a thriving, organic, creative, productive ecosystem."