15 ms·

> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. One of the problems

> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. And you have no idea because they haven't said. They haven't told anyone: it's just drifted into an unclear state of unmaintained-ness. I would suggest rather that what the Moment.js team have done here should be the norm: i.e., clear communication of the situation. That situation, as here, might be "done", or it might be "the thing's only half finished but we don't care enough to carry on any more", or something completely different. These are all good reasons to stop working on something even if they're potentially frustrating for users. E.g., in the "don't care" scenario, people have the option to step in and pick up maintenance, fork the project, or simply not use it. Doesn't matter: understanding the state of a potential dependency in terms of maintenance and development is the key factor that will enable people to make an informed decision about whether to use it or not.

tutfbhuf 6y ago
> One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. Any non-trivial project that has no commit since the last three years is abandoned. Even in the case a project is considered to be done/finished, in order to not abandon it you have to maintain it: fix security issues, update outdated dependencies, update tooling so that you can still run/compile with non outdated tools and so on.
- detaro 6y ago
  That really depends on what the project is I think (and I guess what you consider non-trivial). I can easily see e.g. a numerical library not really needing maintenance of that sort.
- jasonkester 6y ago
  You might benefit from flipping this around and asking yourself why you're not able to ship software that remains shipped without intervention. And why you can't even imagine a world where that would be possible. If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that, you'll have a lot more free time to spend building new things. For what it's worth, this world does in fact exist. And there are lots of us living in it. Here's hoping you find a way to join us!
  - scoopertrooper 6y ago
    So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.
    - DougBTX 6y ago
      A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some programming languages make guarantees that old code will build in new versions (eg, ISO C even refuses to introduce new warnings for code that would previously build without warnings), while others will introduce backwards incompatible changes in minor releases. How much maintenance a project needs after it is "done" really depends on the tooling environment.
      - scoopertrooper 6y ago
        Library and framework maintainers will eventually stop updating previous major versions. So you manage to tread water just fine till your major version reaches EOL, then you've found yourself in the position of having to change over to a completely new API on a schedule set by the maintainer of the dependency.
        hdjdbtbgwjsn 6y ago
        It depends on the language. Fortran last broke backwards compatibility with F90. F77 code is still 100% supported. C is similar.
- wruza 6y ago
  >in order to not abandon it you have to maintain it: fix security issues, update outdated dependencies, update tooling so that you can still run/compile with non outdated tools and so on. If you step back a little, you can see a "positive" feedback loop. The entire issue is that maintainers have to catch crazy rabbits who have no rest, change things and abandon "old" versions that worked but were not perfect. Perfect is the enemy of good.
- JD557 6y ago
  >I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. As another commenter mentioned, this can be pretty common in math libs. Here's an example: https://github.com/fommil/netlib-java https://github.com/fommil/netlib-java This project BLAS/LAPACK/ARPACK bindings for JVM languages. The repository is marked as archived and the owner explicitly states that the project is done. The last commit was 21 Jun 2017. This project is still heavily used, there are still multiple libraries that use those bindings.
  - tutfbhuf 6y ago
    The README.md contains install instructions for Debian and Ubuntu, these tend to outdate (not work) quite fast with newer versions of the distributions. Also if any of the low-level libraries BLAS, LAPACK or ARPACK updates, then the wrapper might not continue to work with newer versions or is stuck on a legacy version including bugs and security issues 4 ever. > This project is still heavily used, there are still multiple libraries that use those bindings. Heavily used does not imply that a dependency is not abandoned.
- sokoloff 6y ago
  I was hoping to use Tex as the counter example here, because it’s a large system that’s remarkably stable. However, it’s not actually a counter example as there are small commits periodically. So I’ll post here admitting to be wrong in my instinct. https://www.tug.org/svn/texlive/ https://www.tug.org/svn/texlive/
  - nathell 6y ago
    That's TeX Live, a distribution of TeX. TeX: The Program has had its most recent release in January 2014.
    - sokoloff 6y ago
      Thanks. I was noodling around on my phone trying to find it and landed there incorrectly.
- hinkley 6y ago
  There are a couple of projects I track where more than half of the commits are just updating dependencies or compatibility information. It's both a responsible thing to do and a form of virtue signalling. Yes, we are still here.
ShorsHammer 6y ago
Does clearly-stated and overt semantic versioning not solve this?
- mekkkkkk 6y ago
  How so? Semantic versioning shows no indication of project status. It's just a set of numbers that defines the impact of changes since the last set of numbers.
  - elliekelly 6y ago
    I'm pretty sure SemVer allows for alpha and beta releases. Why not extend that versioning convention to include an omega release as well? (Is "omega release" even a thing? I'm imagining it as the last stable release - it will be maintained but no new features will be added. Which I think I would consider different from EOL.)
    - freehunter 6y ago
      But even a release titled “Final-1.2.8” releases a year ago doesn’t tell you if the last release was because it was abandoned and shouldn’t be used anymore because it’s out of date or if it still works and just hasn’t been updated because there was nothing else to fix right now.
brospars 6y ago
They explicitly said it will be maintained but they will not be any new features. It's not the same as a project with no commit for three years... I think this post is a bit over the top and shouldn't be required but, I agree, clear communication in OSS librairies is important.
5h 6y ago
Github having an objective "This isn't being worked on anymore" flag with a few options as to why, and pointers for where to reach a community for support/discussion would be most useful, especially overlaid on the crazy huge dependency graph frontend projects tend to acquire.
- simongray 6y ago
  I think that is the point of the "archive" functionality: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-archiving-repositories https://docs.github.com/en/github/creating-cloning-and-archi...
  - 5h 6y ago
    That's part of it, but doesn't give any useful data beyond 'archived' to make use of when considering your dependencies.
- andrewnicolalde 6y ago
  What’s the value in that vs a small note in README.md or similar?
  - kedean 6y ago
    Well, it would be more obvious. Right now, one of the first things the eyes are drawn to on a repository is the date of the last commit. I know I'm I have an internal bias against projects as soon as I see "Feb 23, 2016" as the last commit, it can make me stop scrolling without thinking about it. It would be nice to have a badge that is more obvious than the last commit date to supercede that.
    - barry27 6y ago
      Sure, or it could just not be used by people who subscribe to this silly notion that the last commit has to have been 5 minutes ago.
city41 6y ago
There have been some attempts to improve communication on OSS projects, such as http://unmaintained.tech/ http://unmaintained.tech/
randomdata 6y ago
If an OSS library does what you need, is it not done in any meaningful sense anyway? It makes little difference if the author had hoped to add the kitchen sink, but gave up on it, if you don't need the kitchen sink.
- iforgotpassword 6y ago
  If it does what I need but has a dozen security flaws because the maintainer just doesn't care anymore it makes a difference. You have to dig around to figure this out. On github it's relatively easy to check the issue tracker but still. One case in point is (was) atftp. Since it's packaged with most distros you might be tempted to assume it's safe to use. But then I encountered a crash on Debian. Tracked down the official project page to sourceforge, found the bug was reported years ago including fix, nothing happened. Found it had several other issues like not checking return values of calls like setuid(). Debian at the time had their own patches for this in sid, since coincidentally someone must have hit the same issue around the time. Checked suse out of curiosity and they also had their own patches which were around for quite some time. Same with gentoo (I think). Obviously all three had different patches for different bugs, because unresponsive upstream. I wish there was a joint effort of distros for such cases instead of duplicating work. Or just drop dead projects with known security issues instead of this half arsed approach. Sorry, second part is only semi related with the original issue but it's just one more way in which picking the right open source solution for a problem can be difficult because of lacking communication.
  - randomdata 6y ago
    > If it does what I need but has a dozen security flaws because the maintainer just doesn't care anymore it makes a difference Does it? The alternative might be to write your own code, which will carry your own flavour of security issues. No matter what code you adopt, be it your own or someone else's, will require some level of commitment in maintaining it.
hinkley 6y ago
I ended up resurrecting someone's github project by introducing a PR to fix a configuration bug. It sat for a while before the maintainer saw it, but he merged it. Then half a dozen other PRs showed up in the next six months. You can't tell if a project is dead by the commit dates, but you might be able to tell via open PRs that go unacknowledged.
mam2 6y ago
Is not ci for this ?

tutfbhuf 6y ago

> One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. Any non-trivial project that has no commit since the last three years is abandoned. Even in the case a project is considered to be done/finished, in order to not abandon it you have to maintain it: fix security issues, update outdated dependencies, update tooling so that you can still run/compile with non outdated tools and so on.

detaro 6y ago
That really depends on what the project is I think (and I guess what you consider non-trivial). I can easily see e.g. a numerical library not really needing maintenance of that sort.
jasonkester 6y ago
You might benefit from flipping this around and asking yourself why you're not able to ship software that remains shipped without intervention. And why you can't even imagine a world where that would be possible. If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that, you'll have a lot more free time to spend building new things. For what it's worth, this world does in fact exist. And there are lots of us living in it. Here's hoping you find a way to join us!
- scoopertrooper 6y ago
  So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.
  - DougBTX 6y ago
    A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some programming languages make guarantees that old code will build in new versions (eg, ISO C even refuses to introduce new warnings for code that would previously build without warnings), while others will introduce backwards incompatible changes in minor releases. How much maintenance a project needs after it is "done" really depends on the tooling environment.
    - scoopertrooper 6y ago
      Library and framework maintainers will eventually stop updating previous major versions. So you manage to tread water just fine till your major version reaches EOL, then you've found yourself in the position of having to change over to a completely new API on a schedule set by the maintainer of the dependency.
      - hdjdbtbgwjsn 6y ago
        It depends on the language. Fortran last broke backwards compatibility with F90. F77 code is still 100% supported. C is similar.
wruza 6y ago
>in order to not abandon it you have to maintain it: fix security issues, update outdated dependencies, update tooling so that you can still run/compile with non outdated tools and so on. If you step back a little, you can see a "positive" feedback loop. The entire issue is that maintainers have to catch crazy rabbits who have no rest, change things and abandon "old" versions that worked but were not perfect. Perfect is the enemy of good.
JD557 6y ago
>I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. As another commenter mentioned, this can be pretty common in math libs. Here's an example: https://github.com/fommil/netlib-java https://github.com/fommil/netlib-java This project BLAS/LAPACK/ARPACK bindings for JVM languages. The repository is marked as archived and the owner explicitly states that the project is done. The last commit was 21 Jun 2017. This project is still heavily used, there are still multiple libraries that use those bindings.
- tutfbhuf 6y ago
  The README.md contains install instructions for Debian and Ubuntu, these tend to outdate (not work) quite fast with newer versions of the distributions. Also if any of the low-level libraries BLAS, LAPACK or ARPACK updates, then the wrapper might not continue to work with newer versions or is stuck on a legacy version including bugs and security issues 4 ever. > This project is still heavily used, there are still multiple libraries that use those bindings. Heavily used does not imply that a dependency is not abandoned.
sokoloff 6y ago
I was hoping to use Tex as the counter example here, because it’s a large system that’s remarkably stable. However, it’s not actually a counter example as there are small commits periodically. So I’ll post here admitting to be wrong in my instinct. https://www.tug.org/svn/texlive/ https://www.tug.org/svn/texlive/
- nathell 6y ago
  That's TeX Live, a distribution of TeX. TeX: The Program has had its most recent release in January 2014.
  - sokoloff 6y ago
    Thanks. I was noodling around on my phone trying to find it and landed there incorrectly.
hinkley 6y ago
There are a couple of projects I track where more than half of the commits are just updating dependencies or compatibility information. It's both a responsible thing to do and a form of virtue signalling. Yes, we are still here.

ShorsHammer 6y ago

Does clearly-stated and overt semantic versioning not solve this?

mekkkkkk 6y ago
How so? Semantic versioning shows no indication of project status. It's just a set of numbers that defines the impact of changes since the last set of numbers.
- elliekelly 6y ago
  I'm pretty sure SemVer allows for alpha and beta releases. Why not extend that versioning convention to include an omega release as well? (Is "omega release" even a thing? I'm imagining it as the last stable release - it will be maintained but no new features will be added. Which I think I would consider different from EOL.)
  - freehunter 6y ago
    But even a release titled “Final-1.2.8” releases a year ago doesn’t tell you if the last release was because it was abandoned and shouldn’t be used anymore because it’s out of date or if it still works and just hasn’t been updated because there was nothing else to fix right now.

brospars 6y ago

They explicitly said it will be maintained but they will not be any new features. It's not the same as a project with no commit for three years... I think this post is a bit over the top and shouldn't be required but, I agree, clear communication in OSS librairies is important.

5h 6y ago

Github having an objective "This isn't being worked on anymore" flag with a few options as to why, and pointers for where to reach a community for support/discussion would be most useful, especially overlaid on the crazy huge dependency graph frontend projects tend to acquire.

simongray 6y ago
I think that is the point of the "archive" functionality: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-archiving-repositories https://docs.github.com/en/github/creating-cloning-and-archi...
- 5h 6y ago
  That's part of it, but doesn't give any useful data beyond 'archived' to make use of when considering your dependencies.
andrewnicolalde 6y ago
What’s the value in that vs a small note in README.md or similar?
- kedean 6y ago
  Well, it would be more obvious. Right now, one of the first things the eyes are drawn to on a repository is the date of the last commit. I know I'm I have an internal bias against projects as soon as I see "Feb 23, 2016" as the last commit, it can make me stop scrolling without thinking about it. It would be nice to have a badge that is more obvious than the last commit date to supercede that.
  - barry27 6y ago
    Sure, or it could just not be used by people who subscribe to this silly notion that the last commit has to have been 5 minutes ago.

city41 6y ago

There have been some attempts to improve communication on OSS projects, such as http://unmaintained.tech/ http://unmaintained.tech/

randomdata 6y ago

If an OSS library does what you need, is it not done in any meaningful sense anyway? It makes little difference if the author had hoped to add the kitchen sink, but gave up on it, if you don't need the kitchen sink.

iforgotpassword 6y ago
If it does what I need but has a dozen security flaws because the maintainer just doesn't care anymore it makes a difference. You have to dig around to figure this out. On github it's relatively easy to check the issue tracker but still. One case in point is (was) atftp. Since it's packaged with most distros you might be tempted to assume it's safe to use. But then I encountered a crash on Debian. Tracked down the official project page to sourceforge, found the bug was reported years ago including fix, nothing happened. Found it had several other issues like not checking return values of calls like setuid(). Debian at the time had their own patches for this in sid, since coincidentally someone must have hit the same issue around the time. Checked suse out of curiosity and they also had their own patches which were around for quite some time. Same with gentoo (I think). Obviously all three had different patches for different bugs, because unresponsive upstream. I wish there was a joint effort of distros for such cases instead of duplicating work. Or just drop dead projects with known security issues instead of this half arsed approach. Sorry, second part is only semi related with the original issue but it's just one more way in which picking the right open source solution for a problem can be difficult because of lacking communication.
- randomdata 6y ago
  > If it does what I need but has a dozen security flaws because the maintainer just doesn't care anymore it makes a difference Does it? The alternative might be to write your own code, which will carry your own flavour of security issues. No matter what code you adopt, be it your own or someone else's, will require some level of commitment in maintaining it.

hinkley 6y ago

I ended up resurrecting someone's github project by introducing a PR to fix a configuration bug. It sat for a while before the maintainer saw it, but he merged it. Then half a dozen other PRs showed up in the next six months. You can't tell if a project is dead by the commit dates, but you might be able to tell via open PRs that go unacknowledged.

mam2 6y ago

Is not ci for this ?