4 ms·

I think it’s hard to tell with the signals we have on GitHub for example the difference between mature and dead as a project. Regardless of what a commit is for

I think it’s hard to tell with the signals we have on GitHub for example the difference between mature and dead as a project. Regardless of what a commit is for, it’s a sign that someone is watching and maintaining and any novel issue will likely be quickly addressed. I think this means new stuff always will have an advantage there.

Sponge5 2y ago
The age of last commit on trunk is a useless metric in isolation. The fact that it is the most prominent number on the front page of a repository is a shame.
- Lyngbakr 2y ago
  A metric I think is useful is responsiveness to issues. If there haven't been any recent commits and if I open the issue tracker and the maintainer hasn't even acknowledged issues that have been opened in the last 6 months, then I assume the project is no longer maintained.
  - eadmund 2y ago
    I would love to see a metric of the number (or proportion) of issues closed even though users are trying to get assistance. No idea how to make that machine-calculable though. Even better, a metric for refused PRs (maybe including PR size somehow), tracking where users cared enough to try to contribute and the owner just refused to accept the changes. Easily gamed though.
ysofunny 2y ago
in open source, there are no 'dead projects'. maybe just abandoned but if you find a mature/dead project there's a chance it's just old and stable. what I'm getting at is in an unmantained project any stranger should be able to figure out how to adrees any novel issues. it's the point of open source; I don't undrestand why this is failing. maybe beacuse understanding an anonymous code base is hard work?
- LegionMammal978 2y ago
  In the limit, there are also many ways to debug and patch issues in closed-source projects (someting I've done once or twice myself), unless they're run through an obfuscator or something. But there's always a dividing line where "reimplementing the functionality you need yourself" is far easier than "trudging through an old codebase that's tough to even get building".
LegionMammal978 2y ago
Yeah, sometimes people on HN make this assumption in the other direction, insisting that such-and-such a project is surely very mature (with a very quiet userbase) and not dead, on account of it not having any recent updates. But sometimes projects are truly just dead and buried. E.g., the million old frameworks and libraries that haven't been touched since 2005 and haven't had a functioning website since 2015. Bonus points if the only downloads were hosted on a SourceForge clone that also no longer exists outside the Internet Archive. It's sometimes possible for a project to have 0 bugs to fix and 0 in-scope improvements (for performance, compatibility, etc.) left to make, but only if its scope is extremely limited. Even Knuth still gets bug reports for his age-old TeX.
chefandy 2y ago
If you’re just glancing, then sure… and maybe if it’s only glancing-level important then that’s fine. In my experience there are almost always some issues (either legit or misguided support requests,) PRs for docs and features, updates to libraries for vulnerabilities or deprecated code. Worth looking at stuff that isn’t open also. Even if it’s a 10 year old project and the last commit is from 6 months ago fixing a seemingly minor bug, if there more than a few stars or forks, and there aren’t ignored issues and PRs sitting there, I’d consider it trustworthy. And if it does look abandoned but was active at some point, it’s always a good idea to take a stroll through the forks.
- jasonthorsness 2y ago
  I ran into this mature (AND dead?) project yesterday: benchmark.js https://github.com/bestiejs/benchmark.js/ https://github.com/bestiejs/benchmark.js/ This one is actually archived last year so clearly unmaintained but so far seems to be working great. But no successor fork. I think in this case I will use it, especially because it's in test code and not product.
  - chefandy 2y ago
    Yeah they're definitely out there. Looks like there aren't any active forks either. Bummer. I had another really good example of one that was super popular but I can't remember what it was.
tmsbrg 2y ago
I wish we could just let software "die" aka be stable without constant updates. For software that doesn't have a significant attack surface (security) it'd be amazing. But because of the bitrot of constantly changing underlying APIs and platforms, oftentimes if you find some Python script that hasn't been updated for a few years it'll already be broken in some horrible ways due to dependencies changing and no longer being compatible with current versions of certain libraries. Think of how much time is wasted because so much software that's been written but not maintained and can't be used because of how libraries have "evolved" since then.
dspillett 2y ago
I don't have anything of note publicly out there, if I did and it was still a going concern despite having had no updates for quite some time (so “fished and stable” rather than “dead and not to be relied upon unless you want to maintain it yourself”), I'd chuck a commit in every now and then (annually? every six months?) if only to update the readme.md to say that as of <current date> I didn't consider the project any less supported than it was at the point of the previous update.
blueflow 2y ago
I found it useful to read through the open and closed issues and estimate what caused the described problems. Look at the usecases that do not work, are they common or exotic? Does the program fail safely or does it fall back to unwanted behavior? Does a certain configuration cause the program to run amok and wipe your disk? If you get many "wtf" moments while doing this, the project is not mature.

Sponge5 2y ago

The age of last commit on trunk is a useless metric in isolation. The fact that it is the most prominent number on the front page of a repository is a shame.

Lyngbakr 2y ago
A metric I think is useful is responsiveness to issues. If there haven't been any recent commits and if I open the issue tracker and the maintainer hasn't even acknowledged issues that have been opened in the last 6 months, then I assume the project is no longer maintained.
- eadmund 2y ago
  I would love to see a metric of the number (or proportion) of issues closed even though users are trying to get assistance. No idea how to make that machine-calculable though. Even better, a metric for refused PRs (maybe including PR size somehow), tracking where users cared enough to try to contribute and the owner just refused to accept the changes. Easily gamed though.

ysofunny 2y ago

in open source, there are no 'dead projects'. maybe just abandoned but if you find a mature/dead project there's a chance it's just old and stable. what I'm getting at is in an unmantained project any stranger should be able to figure out how to adrees any novel issues. it's the point of open source; I don't undrestand why this is failing. maybe beacuse understanding an anonymous code base is hard work?

LegionMammal978 2y ago
In the limit, there are also many ways to debug and patch issues in closed-source projects (someting I've done once or twice myself), unless they're run through an obfuscator or something. But there's always a dividing line where "reimplementing the functionality you need yourself" is far easier than "trudging through an old codebase that's tough to even get building".

LegionMammal978 2y ago

Yeah, sometimes people on HN make this assumption in the other direction, insisting that such-and-such a project is surely very mature (with a very quiet userbase) and not dead, on account of it not having any recent updates. But sometimes projects are truly just dead and buried. E.g., the million old frameworks and libraries that haven't been touched since 2005 and haven't had a functioning website since 2015. Bonus points if the only downloads were hosted on a SourceForge clone that also no longer exists outside the Internet Archive. It's sometimes possible for a project to have 0 bugs to fix and 0 in-scope improvements (for performance, compatibility, etc.) left to make, but only if its scope is extremely limited. Even Knuth still gets bug reports for his age-old TeX.

chefandy 2y ago

If you’re just glancing, then sure… and maybe if it’s only glancing-level important then that’s fine. In my experience there are almost always some issues (either legit or misguided support requests,) PRs for docs and features, updates to libraries for vulnerabilities or deprecated code. Worth looking at stuff that isn’t open also. Even if it’s a 10 year old project and the last commit is from 6 months ago fixing a seemingly minor bug, if there more than a few stars or forks, and there aren’t ignored issues and PRs sitting there, I’d consider it trustworthy. And if it does look abandoned but was active at some point, it’s always a good idea to take a stroll through the forks.

jasonthorsness 2y ago
I ran into this mature (AND dead?) project yesterday: benchmark.js https://github.com/bestiejs/benchmark.js/ https://github.com/bestiejs/benchmark.js/ This one is actually archived last year so clearly unmaintained but so far seems to be working great. But no successor fork. I think in this case I will use it, especially because it's in test code and not product.
- chefandy 2y ago
  Yeah they're definitely out there. Looks like there aren't any active forks either. Bummer. I had another really good example of one that was super popular but I can't remember what it was.

tmsbrg 2y ago

I wish we could just let software "die" aka be stable without constant updates. For software that doesn't have a significant attack surface (security) it'd be amazing. But because of the bitrot of constantly changing underlying APIs and platforms, oftentimes if you find some Python script that hasn't been updated for a few years it'll already be broken in some horrible ways due to dependencies changing and no longer being compatible with current versions of certain libraries. Think of how much time is wasted because so much software that's been written but not maintained and can't be used because of how libraries have "evolved" since then.

dspillett 2y ago

I don't have anything of note publicly out there, if I did and it was still a going concern despite having had no updates for quite some time (so “fished and stable” rather than “dead and not to be relied upon unless you want to maintain it yourself”), I'd chuck a commit in every now and then (annually? every six months?) if only to update the readme.md to say that as of <current date> I didn't consider the project any less supported than it was at the point of the previous update.

blueflow 2y ago

I found it useful to read through the open and closed issues and estimate what caused the described problems. Look at the usecases that do not work, are they common or exotic? Does the program fail safely or does it fall back to unwanted behavior? Does a certain configuration cause the program to run amok and wipe your disk? If you get many "wtf" moments while doing this, the project is not mature.