zlacker

> dropped on github, and then forgot about.

I really wish GitHub would have some sort of flag for "stale" projects. I use your methods too (issues, dates, etc.), and I'm usually disappointed when search results bring up ghost projects. However, in a few instances, I found a project that was similar to an issue I was working on that went one step beyond where I was, and even though it was a ghost project, it helped. But in general, these projects don't help. I'm also disappointed that I'm thinking, "Hmmm, maybe LLMs can help..."

>>Chancy+(OP)
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.

>>Chancy+(OP)
I have one project on GitHub that I use all the time as part of a script and only push changes when the python API breaks it. It is essentially “finished” and usually just needs a quick compile against the new python version whenever I upgrade the distro. I haven’t even had to touch for at least as long as GitHub required ssh keys so by all accounts this would be an abandoned project.

Now that I think about it — it is a python wrapper around a boost library and neither of those have made backwards incompatible changes in a long time which is quite suspicious.

>>dylan6+v2
"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+v2
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+v2
Stale is bad. Asymptotically approaching stale is great.

>>dasil0+bc
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+q6
i think you're leaving out the state of "good enough"

>>dylan6+v2
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.

>>UncleE+e3
Boost libs circa Ubuntu (14 or 16.04) had JSON parser that allowed comments, while the newer Boost in Ubuntu 20.04 (and I think already in 18.04) had "updated" it and then it didn't allow comments any more.

Just a small anecdote of Boost changing behavior that broke some of my stuff.

>>dylan6+v2
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+Yw
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.

>>j1elo+7F
I kind of expect that I’ll have to do some work at upgrade time but it’s been a while. Usually python is the culprit and can only remember boost breaking something once but that was a different project. The maintainer was quite nice on trying to help me figure it out but I don’t think I ever got it working the same again.