Stop expecting that of him. He wrote the code, and open sourced it. He doesn't owe it to you or anyone to say that he doesn't care about it anymore, though doing so would be a nicety. It's open source. If you feel he isn't maintaining something, fork it and own it. Or pay him to.
Going against the grain here, but, why so sensitive? A simple suggestion is not an insult, a sign of unthankfulness, or in itself denigrating the author's efforts.
I got the same vibe from the article TBH, a lot of what he considers rude just seems like well intentioned, if possibly misunderstood, suggestions.
Consider that even filing a bug report is an effort 95% of users would never make. So even doing that is in most cases a contribution, at least as seen from the point of view of the submitter. But the author actually considers it an affront if it doesn't conform to the bug report template.
With the disclaimer that I have never maintained a highly popular GitHub repo, I get a lot of feedback for my projects that is unuseable, and some that is aggravating. I always have the option of simply ignoring it, and that's the end of that interaction. Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
> Consider that even filing a bug report is an effort 95% of users would never make. So even doing that is in most cases a contribution, at least as seen from the point of view of the submitter. But the author actually considers it an affront if it doesn't conform to the bug report template
This was not the vibe I meant to express. I'm sorry it came across that way. I meant to express how it made me _feel_. The next paragraph goes on to say how such issues are eminently reasonable in a lot of cases, and my coming to terms with that is a struggle I face.
My goal was to explain my own perspective in the hope that it increases understanding of everyone involved.
> Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
I tried really hard to leave blame out of my article (for anyone other than myself). That is not how I feel. On the contrary, as I mentioned in my article, setting boundaries is exactly what has helped me so much.
The problem is not the "expectation" of ownership. The problem is in lack of clarity in communication. For whatever reason (usually because they're very good), a lot of Andrew's libraries became very popular in the Go world. If his interests have changed to Rust, all he needs to have done is say so.
I'm not faulting you for your expectations, please see my other comment for thought on that. The problem is that even expecting that is more free labor. Sure it's small, and courteous, but is labor. Speaking from experience, I go through weird phases where I want to hide from the world. I know things suffer for it, but it's me. And even writing a short note to let people know is not on my radar as something I care about.
I hope you don't take my comments as combative, I'm trying to speak from experience. I also learned of Mr. Gallant from being on the Go code review lists. I also noticed he seemed to "switch" to Rust. With that knowledge, anything I used heavily I would fork. If one day the two can reconcile, great. If not, congratulations, you own it until you get tired of it and someone else forks it. Such is the nature of open source!
Deciding that you don't intend to maintain a project is labor. This sort of decision is hard to make and extremely hard to undo. Much easier to keep thinking, "I'll get to it next month."
Depends on whether the upstream project is still active, and whether your fork is targeting the same audience.
eg If you fork the code where the upstream project is obviously still active, and your changes target the same audience as the original (eg not taking in a new/experimental direction), then it could be rude.
However, if the upstream repo is no longer active the upstream authors may even happy to have someone picking up the leadership role for that particular project.
