Note that the baseline being discussed here, and in the article, is accepting a patch, not writing a bug fix or new feature yourself.
If every bugfix mandates a fork, the whole ecosystem becomes impossible. So the answer to you question is yes: unless you explicitly label something as a research project, one-time release, no patches welcome, we’re better off without it in the long run, as the sea of dead npm packages shows.
I guess I was picturing just a GitHub, but for go, that is the same as npm. I have gotten excellent benefit from gists only and for that matter code on stack overflow.
Still I guess I regard open source as more like twitch broadcasts than shopping for shrink wrap. If some one wants to take patches and so on, great but that seems extra to just releasing the code. The fundamental advantage of code is that it is malleable. That gist might not fit my project but if it solves the problem I can meld it into what I need so fast.
And a lot of bug fixes aren’t really bug fixes per se but are extra use cases, so a fork per use case doesn’t seem so bad. And I guess the advice for “person that wants a popular open source project” might be different for “just wants as much code as possible to be part of the common knowledge of humanity.”
If every bugfix mandates a fork, the whole ecosystem becomes impossible. So the answer to you question is yes: unless you explicitly label something as a research project, one-time release, no patches welcome, we’re better off without it in the long run, as the sea of dead npm packages shows.