I sometimes release software under an OSS license. I sometimes take patches from people. Other times I reject them because it's not the direction I want to take the project.
I sometimes use software under an OSS license. Sometimes I submit patches for fixes and they get accepted after appropriate amounts of reviews. Sometimes I maintain an internal fork for years before my fix lands. Sometimes I choose a different solution because my projects needs no longer align with the software's direction.
At no point do I ever think it's a great idea to bully an OSS maintainer into my way of thinking. I have all kinds of empathy for both groups but the rules of engagement here are very clear and anyone who thinks they should be different is just going to be hurt in the long run.
I release open source software so other people can use my work if it would help them help themselves. The code took some work and its nice for it to be known, but i dont have time to help anyone with anything, what with a corporate job and kids.
the people expecting more seem to be saying it would be better not to release code that one has no intention of helping people with, but that world is strictly worse.
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.”
