zlacker

Why is stale a bad thing? It could be something that was created to serve a purpose, developed to the point that it was feature complete for that purpose, and now requires no more development yet continues to do its purpose without modifications.

It's almost like you are thinking of it as an expiration date and the software has spoiled.

>>dylan6+(OP)
"Stale" and "done" are different states. Stale is when bugs are known but not fixed, dependencies old and unsupported, build instructions do not work any more on modern versions of OSes and other environments.

>>dylan6+(OP)
All software is subject to shifting environments over time that will eventually render it obsolete. How fast this happens really depends on the ecosystem—it's a function of the abstraction level and context in which it runs. C or Go code that compiles to a standalone binary will be less susceptible to this, higher level Ruby or Node code that depends on a lot of peer libraries moving in lockstep will be more susceptible. Newer languages that have some notion of backwards compatibility baked into their charter like Elixir or Rust are somewhere in between.

>>dylan6+(OP)
Stale is bad. Asymptotically approaching stale is great.

>>dasil0+G9
well, the original dev did release the code as open source. you are free to take their lead and continue on with modifications in your own source or even as a fork if you feel so strongly about it needing to be maintained to that level.

>>nine_k+V3
i think you're leaving out the state of "good enough"

>>dylan6+(OP)
Because many languages have breaking changes in the interpreter. For example it is almost impossible to review old Python projects you have to change so much, it is easier to rewrite in many cases.

Rust and other compiled languages that have backward and forward compatibility in mind do much better.

>>dylan6+(OP)
But in that case it should have a note saying it's finished or in maintenance mode (e.g. https://github.com/sirupsen/logrus); include references to replacements, offer paid support if you really need it or still use it, keep an eye on issues, and update dependencies.

Else, ask for a new maintainer. While code can be considered done (especially if no new features are added), it should never go unmaintained. If it's actually used a lot of course.

>>dylan6+tu
Yes, I certainly could. This comment chain started with "why is stale a bad thing". It's bad because I have to do that.

There might be a maintained fork/separate project that does what I want that I would like to find instead. Or maybe I was just searching to save myself 30 minutes on a one time task and I'm not up for adopting an abandoned project.