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."

Is it hard to undo? How so?

If you don't look at any PR in the next 3/6 months, mark it unsupported.

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.

That was my thought about the "Dealing via Boundaries" section. The solution of "defer some maintainer responsibilities to someone else" never came up. When you insist that you have to do everything by yourself, you are creating that massive asymmetry between users and maintainers.

> "defer some maintainer responsibilities to someone else"

I have of course done this many times across different projects. Sometimes it works. Sometimes it doesn't. It isn't the silver bullet you portray it to be. Nevermind the risks involved due to supply chain attacks.

This sense of entitlement is specifically addressed in the post.

Sort of. But, the most egregious form of entitlement is low-effort.

Whereas "the account has too many prominent repositories to accept contributions to in a reliable manner" lowers trust (which the burntsushi post also discusses).

It's as fair to say "I don't trust the project because it isn't maintained" as it is to say "the code is free, the maintainer's time is not". - I think this is exasperated by that "just fork it" works in a small sense for one or two patches; but there's a communal inertia that complicates it in a larger sense.

Buddy I made an actual contribution taking the trouble to understand the codebase and contributing a feature which was in the spec but not in his library. If Andrew didn't have time to address it as his interests were changing or whatever, he could have clearly stated it upfront in which case I probably would have picked a different library to invest in.

Characterizing this as "sense of entitlement" in a one liner is quite uncalled for.

A contribution to an open source project is a gift with a hundred strings attached.

In most cases it's a request for more of the maintainer's time to review, fix, and merge a change which they themselves likely don't need (otherwise they would have added it). In my experience, at least 80% of the time I end up spending more time and effort on accepting someone's change than I would have writing it myself. It only becomes net-positive when a contributor has a long-lived interest in the project and turns out to be a capable maintainer with similar sensibilities; even then there is significant ramp-up time. 99% of the time this doesn't happen; most contributions are drive-bys.

P.S. It so happens that that we previously interacted on that very PR thread: https://github.com/BurntSushi/toml/pull/65#issuecomment-1919...

> P.S. It so happens that that we previously interacted on that very PR thread:

Yup. I recognized your username and note that our interaction happened over a year after the original pull request discussion with no response from the repo owner.

> In my experience, at least 80% of the time I end up spending more time and effort on accepting someone's change than I would have writing it myself

Sure but the general culture and expectation in open source is when people find bugs or create features, as good citizens they share the changes upstream. If what you want to do is "throw the code over" or you've lost interest in developing further, all you need to do is to say that as common courtesy to your fellow open source developer especially if like in this case a lot of people use it. Lots of repos do this and clearly stated deprecation.

@cespare Which section?

This should have been solved ages ago but it isn't. What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity?

The one contributing the most gets notified to accept or deny the request.

> What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity?

This is unworkable for a large number of reasons. But it's also largely beside the point. If the code is available under a permissive license and is not being maintained, fork it.

Security is the main issue: you can’t just give away control of a widely used tool without vetting the new maintainer because that would open all your users to malicious code.

You aren't giving control to unknown people here. You are giving it to good contributors who you have added personally. We can still have a system where core contributors can vote on someone accepting the request or author can disable this feature.

How many people vet the author before installing something from npm? If you trust someone because they have some code that looks good, then shouldn't you trust contributors who have good code in there too.

How many points of cracks are there in the dependencies of dependency?

If it's a widely used tool then author wouldn't go inactive for a year without doing something unless they are not getting paid or even acknowledged for their efforts.

If people like security, then pin and mirror your dependencies. Don't update without checking them.

My point was that the maintainer shouldn’t give up maintenance unless they trust the new maintainer, so we agree. (I did misread your original post, but I think it can’t be just any contributor)