|
OP here - fairly nervous about posting this, but just to give some context of where this is coming from: A decade ago, I got interested in JSON Schema, and at the time there was no JavaScript validator. I quickly knocked one together and shared it. It took a couple of hours, and was 460 lines plus a bunch of tests. Only a few years after that, it had grown into a much bigger project. Other people were contributing, but I was still the lead developer. I had my own personal life going on (and other projects), and started to feel tied to this thing, like I wasn't allowed to leave. I wanted to be a responsible maintainer, but it wasn't fun any more. Maybe someone with more experience (or a different brain) could have sustained this project indefinitely, but I eventually hit open-source burnout. I didn't sign into GitHub for several years, because I couldn't handle seeing the little notification icon. In retrospect I should have stepped back in a more proactive way (reaching out to regular maintainers first, and then putting a notice on the repo if nobody stepped up), but by the time things got bad I couldn't face it. The license had standard boilerplate saying: THE SOFTWARE IS PROVIDED "AS IS" - but that's a legal disclaimer, not a social one. The package was (and still is) being downloaded millions of times per week on NPM, and those people had a (reasonable!) expectation that a popular and relatively-established package would be maintained, and bugs would be fixed. There's a tension between the two sides, and this discussion has happened a few times recently. Some open-source developers want to provide reliable tools, and some others say "this is free work, you shouldn't expect anything". Some open-source users say "you published this, so you wanted me to use it, and that comes with obligations", and these disagreements can get quite heated. Sharing code is fun, but I think the default assumptions should have more explicit limits, and a natural path to stepping back. I'm not fixated on this particular format, but I would like to see what happens if a missing SUPPORT.txt raised as many questions as a missing LICENSE. |
--- Shouldn't you find a replacement maintainer?
That's ideal (and compatible with this proposal), but it shouldn't be a requirement for stepping down.
--- Couldn't you just update the README when a project's inactive?
It would be good housekeeping to periodically do this for stale projects, but that's quite pro-active. Plus, it only tells users when it's too late - it doesn't give them any sense of how soon that might happen.
(Also, the latest commit or "last publish" for packages might be misinterpreted as an active contribution.)
--- How could anybody build on a project that has a finite lifetime?
We're already living with that uncertainty, it's just invisible.
And as I said in the README: "If you need stronger guarantees, you may need to produce/negotiate them yourself". If an open-source dependency is essential to your project, then it's not unreasonable to have a support agreement in place, or have a plan for who'll do buxfixes if the maintainer steps back.