8 ms·

I can relate to the frustration of the author. I wrote an open source library which gets downloaded 50K+ times per week. At one point, I hadn't updated it in se

I can relate to the frustration of the author. I wrote an open source library which gets downloaded 50K+ times per week. At one point, I hadn't updated it in several months and people started asking if the project is dead... In fact, it wasn't updated in a while because it had been working perfectly and was built in a forward-compatible way; that makes it more healthy and therefore more alive than probably 99% of libraries on the internet. The expectation that software libraries or frameworks should break every few months is disturbing. I think this may be due to the fact that many of the most popular frameworks do this. I find that React-based apps tend to break every few months for a range of reasons; often because of reliance on obscure functionality or bundling of binaries which aren't forward-compatible with newer engine versions.

testingwaters4 4y ago
> built in a forward-compatible way What do you mean by this?
tinalumfoil 4y ago
I don’t know the details of your particular library but I think 50k/week downloads and no problems is an outlier. In my experience even projects with small audiences tend to accumulate outstanding bug reports faster than they’re fixed.
- oliveshell 4y ago
  I’m sure you’re right, but it sounds like it’s an outlier not by random chance, but because it was built carefully. I think there’s a useful lesson there.
  - smaudet 4y ago
    Built carefully, extremely tiny, or single purpose. "Do one thing and do it well" - the unix philosophy, and why I still use cd, ls (dir on windows) today. If a project exceeds two functions its probably doomed to become either redundant or broken. If a project does one thing well, even if something else uses it, you can always decompose to it (your software is always useful, even when somebody writes the fancy bells and whistles version).
  - jongjong 4y ago
    I can confirm that this is the norm for all my open source projects. Forward-compatibility issues can be easily avoided by not using too many dependencies and by carefully checking dependencies before using them. I check for things like over-engineering and I check out the author (check their other libraries if there are any).
  - adolph 4y ago
    What non-game-able metrics do you think an outsider can use to evaluate the quality of a tool? In some ways a "perfect" tool would have no flaws (thus no issues/pull reqs) and be so easy to use (few training updates, SO questions) that it would appear to be dormant. SQLite seems to hit a good balance. There's always something new but nothing particularly breaking (from my light usage POV), so it looks live.
    - WesolyKubeczek 4y ago
      Filed issues are getting radio silence, no matter their quality. The author chimes in, says he’ll take a look next evening, then two years whoosh by. There is an ambitious todo and nothing moves. The code is in alpha for years, considered unstable, huge exclamation points in the readme that it should not be used, and yet somehow there are hundreds of reverse dependencies and it’s like this for years (usually should mean “RUN!!!”). Sometimes sneaky as it’s not a direct dependency for you, but for those two or three libraries used by like 80% of the ecosystem.
- jongjong 4y ago
  It's an open source pub/sub and RPC server/client (similar to gRPC) - It has a client and server component written with JavaScript and Node.js. I avoided using any dependency which relied on pre-built binaries. Also, I skim-read the code of all dependencies and made sure that they were well written and didn't use too many sub-dependencies. The trick is to minimize the number of dependencies and maximize their quality.
  - tinalumfoil 4y ago
    I 100% believe that’s it’s possible to build a library without tons of bugs, and appreciate that there’s people who put out quality libraries like yours. I do think as a general heuristic no updates for 3 months means it’s been at least 2 months since anyone paid attention to outstanding bugs, especially the npm ecosystem.
    - franciscop 4y ago
      It really depends on the size and complexity of the library. Do you think something like leftPad needed updates every month to perform its function as expected and remove bugs? Of course not, the mere suggestion is ridiculous, but also something like jQuery def needs constant upkeep. In the middle, there's a world of possibilities.
      - boredtofears 4y ago
        Leftpad shouldn't exist and any library using it as a direct dependency should be treated suspiciously. I'm not saying that because of the leftpad fiasco, I mean that any library that small should simply be pasted into your codebase because the risk of managing the dependency outweighs the benefits.
        jongjong 4y ago
        I strongly agree with this. Another set of libraries I take issues with is gulp and its plugins. I find that gulp plugins keep breaking constantly and are often flagged with vulnerabilities. The sad thing is that these plugins solve very simple problems, there is no reason for them to keep breaking every few months for the last 5 years or so. If I see a library which is supposed to solve a simple problem but it requires a large number of dependencies to do it, that's a big red flag which indicates to me that the developer who wrote it is not good enough to have their code included in my project - I don't care how popular that library is.
contravariant 4y ago
The annoying thing about software is that we still haven't quite gotten the transfer of knowledge working to the point that you can communicate all knowledge about a piece of software purely through code (and no, being able to emulate all behaviour is not the same, otherwise decompiling wouldn't be a thing). What this means is that for most software an essential part of that software consists of knowledge that needs to be kept alive. The only proof people can have of this is activity surrounding the project. This puts us in the uncomfortable position of having to designate someone as the 'keeper of all knowledge' surrounding a project if it is to be sustained, and failing to do so will result in knowledge being irrevocably lost.
- jongjong 4y ago
  I think it depends heavily on the coding style. In many corporate environments, developers tend to obfuscate or over-engineer or they will tend to introduce too much complexity into the project.
- eternityforest 4y ago
  If you have source, you can figure it out. If there's something clever in source that isn't obvious, that's either a problem, or a well documented exception to the rule. If your whole entire source code is so innovative that you can't immediately understand it, there might be trouble, but so much code is or can be pretty boring. At most, changing something will make a bug that's not really in the spec but is something everyone wants and relies on, but isn't immediately obvious, then you'll have to fix it. The trouble is that if knowledge is lost, people will probably not bother to figure it out, and starting fresh might be more appealing. The bigger issue especially in open source is that if there's no activity, there might not be any in the future. It could be abandoned for 10 years and perfectly fine, until a change is needed, and even if the change is easy and the knowledge is there, it might not happen if nobody cares anymore, and you'll have to fork it yourself, so maybe you choose the actively maintained thing even if it's less complete or more complex or ugly to use.
  - thristian 4y ago
    Even if you have source, you can't necessarily figure it out. Sure, you can figure out what the program does, but you can't know precisely what the program was intended to do, or how closely the current version matches that eventual goal. Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.
maw 4y ago
When evaluating libraries, recent activity is one of the things I look at. It's a far from perfect heuristic. I've probably rejected libraries like yours for what amounts to no very good reason. I don't know if this is a good suggestion or not but I wonder if some form of "keepalive commit" might help here. I can imagine a few ways they might work, some simple, some more elaborate.
- nerdponx 4y ago
  I don't check the commit history, I check the issue tracker. If something has unmerged bugfix patches from 3 years ago without any comment from the maintainer, I assume that it's just not being maintained.
nerdponx 4y ago
I think communicating this information in your README or whatever might help a lot. It's hard to know if something is finished or abandoned in general, so a message indicating the former would help people arrive at a decision sooner.
pmontra 4y ago
> The expectation that software libraries or frameworks should break every few months is disturbing. Dependecies and external APIs change so software breaks. An example from a project of a customer today: Ruby had a Queue class up to 3.0.2. For some reason they moved it to Thread::Queue since 3.1.0. It's only a name change but it's still one release to do.
- tluyben2 4y ago
  Depends on your choice of language and framework etc though? The js ecosystem is very break-y and, at least when I worked with it, so was the Ruby/RoR ecosystem. In .net or Java, far less so; we have almost 10 year old software which we can update the libs off and it compiles and runs the tests just fine.
  - thayne 4y ago
    Even Java broke things between java 8 and 9
    - haimez 4y ago
      With flags to recover the previous behavior, and the changes of which only broke code using non-public API surface, i.e.: code that should never have been using those APIs but which previously had no way to prevent usages.
      - thayne 4y ago
        > With flags to recover the previous behavior I'm not sure what flags you are referring to, but that might be because I went from 8 to 11 and skipped 9 and 10. > the changes of which only broke code using non-public API surface The APIs weren't non-public. They were publicly documented. They did say they were internal and you should avoid them, but they were still used in libraries and referenced in tutorials and stack overflow answers. And if you happened to transitively use a library that used one of those APIs, it would cause a fair amount of pain when you upgraded.
sportslife 4y ago
How do you think users would react to a monthly no-changes-required update?
- vlunkr 4y ago
  Sounds like they consider the software to be complete. I that case an update provides no value.
  - sportslife 4y ago
    An update provides no value except as a signal to users that the developer hasn't killed the project. I was wondering how annoyed or reassured users would be if they saw version x.x.x+1 with release notes noting no changes.
    - jraph 4y ago
      Please don't. A sentence like "I'm still around, don't have anything to release for now because the library is feature-complete and no bug has been found for a while" would be better.
    - vlunkr 4y ago
      If you have some kind of security review process for dependency updates, then this is annoying.
thayne 4y ago
> The expectation that software libraries or frameworks should break every few months is disturbing I think it is more that recent updates are used as a proxy for determining if the developer still cares about the project. The problem is it is hard to distinguish between a project that has been abandoned, and a project that is feature complete and hasn't had any bugs reported in a while. Although, if you assume that any software is free of bugs, and that at least some users will report bugs, if there is low activity, that suggests that either it isn't well maintained, or there isn't a critical mass of users to find and report those bugs. But then, higher quality software will require a higher number of users to hit that critical mass so it doesn't give you that much information unless you also know how good the software is.
- maxloh 4y ago
  Maintainer's activity in GitHub issue is also a good metric.
  - ungamedplayer 4y ago
    I disagree. I have some common lisp libraries that have not been touched in years and the majority of my day to day is in company git. I imagine that I am not the only one.
    - simfree 4y ago
      If your using a non-github platform without mirroring the repository, your pretty SoL for getting those green squares of activity to reflect your actual activity.
      - samarthr1 4y ago
        SoL?
        bussierem 4y ago
        Shit outta luck
the__alchemist 4y ago
I think one of the core issues contributing to fragile, continuously-updated software is a culture of over-using dependencies. Each dependency added is a potential complexity trap. Using a dependency that has few sub-dependencies is less likely to cause problems. Or that has several sub-dependencies that each have no dependencies. It's deep dependency trains that are likely to cause this. Ie, dependencies that depend on multiple others.
makeitdouble 4y ago
I understand your frustration, also thank you for your work. > The expectation that software libraries or frameworks should break every few months is disturbing. As a library user, it's hard to find a good balance between fully trusting a system to stay alive for a while without maintenance, while being super paranoid about every aspect I rely on. Mentally it's easier to expect it to break every now and then, than to keep thinking "it's probably fine, but I still need to be defensive about stuff that never happen". I think the issue on a library being "alive" or not is best mitigated by the users being comfortable to fix it if it broke under their use case. There's libraries I thought were completely dead but were a good shortcut to where we wanted to go, and we expected to extend it here and there anyway. That can't work for everything (thinking of security libs in particular, I wouldn't want to touch them) but it's to me the ideal situation, with no undue stress on the lib maintainer as well.
vonseel 4y ago
Try opening an old project from 3-5 years ago that has a lot of dependencies like something from react-native, Django, etc. and you’ll find many of them impossible to even install without using the original Python or Javascript versions - that’s assuming the oldest dependencies are still available in the pinned versions. It’s not a common use-case, I guess, but I had some old projects that I abandoned and wanted to try working on them again and found it almost impossible. The worst cases had dependencies which weren’t available unless I used an x86 laptop with an older version of Mac, because the packages were never built for arm laptops.
- thejosh 4y ago
  That's what version pinning and semver is for. If I install 1.2.3 in 2018, and the software is now 4.5.6, I don't expect it to work without updates. In regards to the second case, bet that's Python with the wheels situation, where it doesn't fallback to building from source by default for some reason (instead throwing a super obtuse error), at least with Poetry.
_carbyau_ 4y ago
Depending on how you feel about it you could update the readme every so often with: [date] Checked project, still is ok in current form.
_skel 4y ago
The problem with not updating dependencies for a long time is that it can force you to make sudden version jumps if something like a CVE is discovered. At my company we had a real scramble to upgrade log4j when the CVE for that came out. A lot of software was many versions behind. Luckily for us, no breaking changes had been made, and it was simply a matter of bumping the version to the latest one. That was a lucky break, because if that had been a library like Jersey or Spring it would have been an entirely different ballgame. If you don't keep your builds up to date, you open yourself up to risks like that, which are unknown and to some extent unknowable.
Foobar8568 4y ago
I had to choose between two libraries at work, lead rejected my recommendation because github was showing less activities, the other project was seeing a total rewrite regularly, largely buggy because of that, and unclear documentations, yet it was the popular choice.
deleted 4y ago
[deleted]
triknomeister 4y ago
If your product relies on any compilers/tools which are themselves updated, then at least your CI needs to be updated regularly enough. May be in your case, that was the case, but if not, then that would just to me that the product is not being maintained, even if the product is feature complete.
gregoriol 4y ago
We have the same problem with our sass product: the product is "complete" in our minds, we don't want to add more features, make it more complicated, ... we perform minor updates of third-party components, some minor fixes, ... This means we don't maintain a blog with very recent posts, or a very active twitter. We have a daily usage counter on the homepage though, which shows that thousands of users use it these days. But from time to time someone still asks if the product is alive... We haven't found a solution to this yet: it's as if we are expected have a blog post every few days or weeks, create new stuff all the time, ...
- azmodeus 4y ago
  Could you post release notes on Twitter and on your blog? That way users knew that the product is still currently supported
  - gregoriol 4y ago
    We do have a release notes page, but it's really not interesting content: updates of some third-party frontend or backend packages that users never actually see, fixed a typo, minor css alignment, ... We do announce when there is a user-visible and significant issue or update, but that's quite rare, maybe once every 6 months or more.
lwhi 4y ago
I think one issue, is that the world changes around an app or library. In these cases, the code base could need updating as a side effect of this change. Also, not many people (especially me included) are able to write something that's perfect first time. In an ideal world, other developers would be testing and challenging what's been written; which would meant the product or library needs updating. I think it's (perhaps ideally) likely, that at least one of these factors is relevant.
1vuio0pswjnm7 4y ago
"I think this may be due to the fact that many of the most popular frameworks do this." According to the OP, it is also due to companies controlling mobile OS such as Apple. One of the things I like about non-corporate open source OS like NetBSD is I can run old userland utilities with new kernels without any problems.
rcarmo 4y ago
I recently added a very visible note to the README.md of one of my projects that essentially said: "lack of commits means this is STABLE, not dead. Our plan for <next major runtime> is bla bla, in a year or so" This expectation that things need to be committed to or updated every month has to stop, we're just wasting time and energy on stuff that is already fixed (unless there are security issues, of course). Maybe GitHub needs to automatically include an UPDATES.md into each page, I dunno.
mk89 4y ago
Well, there is also the security aspect in mind. Most software relies on libraries that repeatedly get CVEs over months (not years). You might not care too much, and it clearly depends on the application, but for me updating a software that doesn't use anymore a library for getting user input that leads to a buffer overflow if you insert a certain character, or similar things (like remote code execution, etc.), can be quite important. Finally, apps are most of the time connected to the Internet, which makes them inherently vulnerable. After searching "android software libraries CVEs" I found this in the first results' page: https://github.com/dotanuki-labs/android-oss-cves-research https://github.com/dotanuki-labs/android-oss-cves-research It might be outdated, but the principle still applies. It's very unlikely that your application is self-sufficient and doesn't need updates. EDIT: I read the message from Apple as a "hopeful" attempt to say "come on, man at least update the dependencies".
- hulitu 4y ago
  > Well, there is also the security aspect in mind. What security ? "Google security" where everyone except the user has access to his data ? Why does a note taking app needs internet to function ? Why does my phone app need access to internet ?
  - catlifeonmars 4y ago
    Those are great counterpoints. Instead of relying on developers to keep their own apps up to date (you will always have a significant number of outliers), you enforce security better at the system level. Having more tightly scoped permissions and better sandboxing of runtimes solves this way better than depending on individual app developers to secure their own apps.
  - mk89 4y ago
    how many note taking apps do you have? without even going on my phone, I think 70% of my apps need internet access (for a reason).
mihaaly 4y ago
Perhaps you should commit a new "Still working well..." line to its readme file in every few weeks to satisfy the update hungry crowd. :)
HWR_14 4y ago
I feel like, and hope gorhill responds to this, that uMatrix was similar to this. Done and stable and needing to be touched just so people can wouldn't ask if it was still maintained. (Pre manifestv3 that is)
brokenmachine 4y ago
Any general comments on how to write forward-compatible software for a hack programmer?

testingwaters4 4y ago

> built in a forward-compatible way What do you mean by this?

tinalumfoil 4y ago

I don’t know the details of your particular library but I think 50k/week downloads and no problems is an outlier. In my experience even projects with small audiences tend to accumulate outstanding bug reports faster than they’re fixed.

oliveshell 4y ago
I’m sure you’re right, but it sounds like it’s an outlier not by random chance, but because it was built carefully. I think there’s a useful lesson there.
- smaudet 4y ago
  Built carefully, extremely tiny, or single purpose. "Do one thing and do it well" - the unix philosophy, and why I still use cd, ls (dir on windows) today. If a project exceeds two functions its probably doomed to become either redundant or broken. If a project does one thing well, even if something else uses it, you can always decompose to it (your software is always useful, even when somebody writes the fancy bells and whistles version).
- jongjong 4y ago
  I can confirm that this is the norm for all my open source projects. Forward-compatibility issues can be easily avoided by not using too many dependencies and by carefully checking dependencies before using them. I check for things like over-engineering and I check out the author (check their other libraries if there are any).
- adolph 4y ago
  What non-game-able metrics do you think an outsider can use to evaluate the quality of a tool? In some ways a "perfect" tool would have no flaws (thus no issues/pull reqs) and be so easy to use (few training updates, SO questions) that it would appear to be dormant. SQLite seems to hit a good balance. There's always something new but nothing particularly breaking (from my light usage POV), so it looks live.
  - WesolyKubeczek 4y ago
    Filed issues are getting radio silence, no matter their quality. The author chimes in, says he’ll take a look next evening, then two years whoosh by. There is an ambitious todo and nothing moves. The code is in alpha for years, considered unstable, huge exclamation points in the readme that it should not be used, and yet somehow there are hundreds of reverse dependencies and it’s like this for years (usually should mean “RUN!!!”). Sometimes sneaky as it’s not a direct dependency for you, but for those two or three libraries used by like 80% of the ecosystem.
jongjong 4y ago
It's an open source pub/sub and RPC server/client (similar to gRPC) - It has a client and server component written with JavaScript and Node.js. I avoided using any dependency which relied on pre-built binaries. Also, I skim-read the code of all dependencies and made sure that they were well written and didn't use too many sub-dependencies. The trick is to minimize the number of dependencies and maximize their quality.
- tinalumfoil 4y ago
  I 100% believe that’s it’s possible to build a library without tons of bugs, and appreciate that there’s people who put out quality libraries like yours. I do think as a general heuristic no updates for 3 months means it’s been at least 2 months since anyone paid attention to outstanding bugs, especially the npm ecosystem.
  - franciscop 4y ago
    It really depends on the size and complexity of the library. Do you think something like leftPad needed updates every month to perform its function as expected and remove bugs? Of course not, the mere suggestion is ridiculous, but also something like jQuery def needs constant upkeep. In the middle, there's a world of possibilities.
    - boredtofears 4y ago
      Leftpad shouldn't exist and any library using it as a direct dependency should be treated suspiciously. I'm not saying that because of the leftpad fiasco, I mean that any library that small should simply be pasted into your codebase because the risk of managing the dependency outweighs the benefits.
      - jongjong 4y ago
        I strongly agree with this. Another set of libraries I take issues with is gulp and its plugins. I find that gulp plugins keep breaking constantly and are often flagged with vulnerabilities. The sad thing is that these plugins solve very simple problems, there is no reason for them to keep breaking every few months for the last 5 years or so. If I see a library which is supposed to solve a simple problem but it requires a large number of dependencies to do it, that's a big red flag which indicates to me that the developer who wrote it is not good enough to have their code included in my project - I don't care how popular that library is.

contravariant 4y ago

The annoying thing about software is that we still haven't quite gotten the transfer of knowledge working to the point that you can communicate all knowledge about a piece of software purely through code (and no, being able to emulate all behaviour is not the same, otherwise decompiling wouldn't be a thing). What this means is that for most software an essential part of that software consists of knowledge that needs to be kept alive. The only proof people can have of this is activity surrounding the project. This puts us in the uncomfortable position of having to designate someone as the 'keeper of all knowledge' surrounding a project if it is to be sustained, and failing to do so will result in knowledge being irrevocably lost.

jongjong 4y ago
I think it depends heavily on the coding style. In many corporate environments, developers tend to obfuscate or over-engineer or they will tend to introduce too much complexity into the project.
eternityforest 4y ago
If you have source, you can figure it out. If there's something clever in source that isn't obvious, that's either a problem, or a well documented exception to the rule. If your whole entire source code is so innovative that you can't immediately understand it, there might be trouble, but so much code is or can be pretty boring. At most, changing something will make a bug that's not really in the spec but is something everyone wants and relies on, but isn't immediately obvious, then you'll have to fix it. The trouble is that if knowledge is lost, people will probably not bother to figure it out, and starting fresh might be more appealing. The bigger issue especially in open source is that if there's no activity, there might not be any in the future. It could be abandoned for 10 years and perfectly fine, until a change is needed, and even if the change is easy and the knowledge is there, it might not happen if nobody cares anymore, and you'll have to fork it yourself, so maybe you choose the actively maintained thing even if it's less complete or more complex or ugly to use.
- thristian 4y ago
  Even if you have source, you can't necessarily figure it out. Sure, you can figure out what the program does, but you can't know precisely what the program was intended to do, or how closely the current version matches that eventual goal. Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.

maw 4y ago

When evaluating libraries, recent activity is one of the things I look at. It's a far from perfect heuristic. I've probably rejected libraries like yours for what amounts to no very good reason. I don't know if this is a good suggestion or not but I wonder if some form of "keepalive commit" might help here. I can imagine a few ways they might work, some simple, some more elaborate.

nerdponx 4y ago
I don't check the commit history, I check the issue tracker. If something has unmerged bugfix patches from 3 years ago without any comment from the maintainer, I assume that it's just not being maintained.

nerdponx 4y ago

I think communicating this information in your README or whatever might help a lot. It's hard to know if something is finished or abandoned in general, so a message indicating the former would help people arrive at a decision sooner.

pmontra 4y ago

> The expectation that software libraries or frameworks should break every few months is disturbing. Dependecies and external APIs change so software breaks. An example from a project of a customer today: Ruby had a Queue class up to 3.0.2. For some reason they moved it to Thread::Queue since 3.1.0. It's only a name change but it's still one release to do.

tluyben2 4y ago
Depends on your choice of language and framework etc though? The js ecosystem is very break-y and, at least when I worked with it, so was the Ruby/RoR ecosystem. In .net or Java, far less so; we have almost 10 year old software which we can update the libs off and it compiles and runs the tests just fine.
- thayne 4y ago
  Even Java broke things between java 8 and 9
  - haimez 4y ago
    With flags to recover the previous behavior, and the changes of which only broke code using non-public API surface, i.e.: code that should never have been using those APIs but which previously had no way to prevent usages.
    - thayne 4y ago
      > With flags to recover the previous behavior I'm not sure what flags you are referring to, but that might be because I went from 8 to 11 and skipped 9 and 10. > the changes of which only broke code using non-public API surface The APIs weren't non-public. They were publicly documented. They did say they were internal and you should avoid them, but they were still used in libraries and referenced in tutorials and stack overflow answers. And if you happened to transitively use a library that used one of those APIs, it would cause a fair amount of pain when you upgraded.

sportslife 4y ago

How do you think users would react to a monthly no-changes-required update?

vlunkr 4y ago
Sounds like they consider the software to be complete. I that case an update provides no value.
- sportslife 4y ago
  An update provides no value except as a signal to users that the developer hasn't killed the project. I was wondering how annoyed or reassured users would be if they saw version x.x.x+1 with release notes noting no changes.
  - jraph 4y ago
    Please don't. A sentence like "I'm still around, don't have anything to release for now because the library is feature-complete and no bug has been found for a while" would be better.
  - vlunkr 4y ago
    If you have some kind of security review process for dependency updates, then this is annoying.

thayne 4y ago

> The expectation that software libraries or frameworks should break every few months is disturbing I think it is more that recent updates are used as a proxy for determining if the developer still cares about the project. The problem is it is hard to distinguish between a project that has been abandoned, and a project that is feature complete and hasn't had any bugs reported in a while. Although, if you assume that any software is free of bugs, and that at least some users will report bugs, if there is low activity, that suggests that either it isn't well maintained, or there isn't a critical mass of users to find and report those bugs. But then, higher quality software will require a higher number of users to hit that critical mass so it doesn't give you that much information unless you also know how good the software is.

maxloh 4y ago
Maintainer's activity in GitHub issue is also a good metric.
- ungamedplayer 4y ago
  I disagree. I have some common lisp libraries that have not been touched in years and the majority of my day to day is in company git. I imagine that I am not the only one.
  - simfree 4y ago
    If your using a non-github platform without mirroring the repository, your pretty SoL for getting those green squares of activity to reflect your actual activity.
    - samarthr1 4y ago
      SoL?
      - bussierem 4y ago
        Shit outta luck

the__alchemist 4y ago

I think one of the core issues contributing to fragile, continuously-updated software is a culture of over-using dependencies. Each dependency added is a potential complexity trap. Using a dependency that has few sub-dependencies is less likely to cause problems. Or that has several sub-dependencies that each have no dependencies. It's deep dependency trains that are likely to cause this. Ie, dependencies that depend on multiple others.

makeitdouble 4y ago

I understand your frustration, also thank you for your work. > The expectation that software libraries or frameworks should break every few months is disturbing. As a library user, it's hard to find a good balance between fully trusting a system to stay alive for a while without maintenance, while being super paranoid about every aspect I rely on. Mentally it's easier to expect it to break every now and then, than to keep thinking "it's probably fine, but I still need to be defensive about stuff that never happen". I think the issue on a library being "alive" or not is best mitigated by the users being comfortable to fix it if it broke under their use case. There's libraries I thought were completely dead but were a good shortcut to where we wanted to go, and we expected to extend it here and there anyway. That can't work for everything (thinking of security libs in particular, I wouldn't want to touch them) but it's to me the ideal situation, with no undue stress on the lib maintainer as well.

vonseel 4y ago

Try opening an old project from 3-5 years ago that has a lot of dependencies like something from react-native, Django, etc. and you’ll find many of them impossible to even install without using the original Python or Javascript versions - that’s assuming the oldest dependencies are still available in the pinned versions. It’s not a common use-case, I guess, but I had some old projects that I abandoned and wanted to try working on them again and found it almost impossible. The worst cases had dependencies which weren’t available unless I used an x86 laptop with an older version of Mac, because the packages were never built for arm laptops.

thejosh 4y ago
That's what version pinning and semver is for. If I install 1.2.3 in 2018, and the software is now 4.5.6, I don't expect it to work without updates. In regards to the second case, bet that's Python with the wheels situation, where it doesn't fallback to building from source by default for some reason (instead throwing a super obtuse error), at least with Poetry.

_carbyau_ 4y ago

Depending on how you feel about it you could update the readme every so often with: [date] Checked project, still is ok in current form.

_skel 4y ago

The problem with not updating dependencies for a long time is that it can force you to make sudden version jumps if something like a CVE is discovered. At my company we had a real scramble to upgrade log4j when the CVE for that came out. A lot of software was many versions behind. Luckily for us, no breaking changes had been made, and it was simply a matter of bumping the version to the latest one. That was a lucky break, because if that had been a library like Jersey or Spring it would have been an entirely different ballgame. If you don't keep your builds up to date, you open yourself up to risks like that, which are unknown and to some extent unknowable.

Foobar8568 4y ago

I had to choose between two libraries at work, lead rejected my recommendation because github was showing less activities, the other project was seeing a total rewrite regularly, largely buggy because of that, and unclear documentations, yet it was the popular choice.

deleted 4y ago

[deleted]

triknomeister 4y ago

If your product relies on any compilers/tools which are themselves updated, then at least your CI needs to be updated regularly enough. May be in your case, that was the case, but if not, then that would just to me that the product is not being maintained, even if the product is feature complete.

gregoriol 4y ago

We have the same problem with our sass product: the product is "complete" in our minds, we don't want to add more features, make it more complicated, ... we perform minor updates of third-party components, some minor fixes, ... This means we don't maintain a blog with very recent posts, or a very active twitter. We have a daily usage counter on the homepage though, which shows that thousands of users use it these days. But from time to time someone still asks if the product is alive... We haven't found a solution to this yet: it's as if we are expected have a blog post every few days or weeks, create new stuff all the time, ...

azmodeus 4y ago
Could you post release notes on Twitter and on your blog? That way users knew that the product is still currently supported
- gregoriol 4y ago
  We do have a release notes page, but it's really not interesting content: updates of some third-party frontend or backend packages that users never actually see, fixed a typo, minor css alignment, ... We do announce when there is a user-visible and significant issue or update, but that's quite rare, maybe once every 6 months or more.

lwhi 4y ago

I think one issue, is that the world changes around an app or library. In these cases, the code base could need updating as a side effect of this change. Also, not many people (especially me included) are able to write something that's perfect first time. In an ideal world, other developers would be testing and challenging what's been written; which would meant the product or library needs updating. I think it's (perhaps ideally) likely, that at least one of these factors is relevant.

1vuio0pswjnm7 4y ago

"I think this may be due to the fact that many of the most popular frameworks do this." According to the OP, it is also due to companies controlling mobile OS such as Apple. One of the things I like about non-corporate open source OS like NetBSD is I can run old userland utilities with new kernels without any problems.

rcarmo 4y ago

I recently added a very visible note to the README.md of one of my projects that essentially said: "lack of commits means this is STABLE, not dead. Our plan for <next major runtime> is bla bla, in a year or so" This expectation that things need to be committed to or updated every month has to stop, we're just wasting time and energy on stuff that is already fixed (unless there are security issues, of course). Maybe GitHub needs to automatically include an UPDATES.md into each page, I dunno.

mk89 4y ago

Well, there is also the security aspect in mind. Most software relies on libraries that repeatedly get CVEs over months (not years). You might not care too much, and it clearly depends on the application, but for me updating a software that doesn't use anymore a library for getting user input that leads to a buffer overflow if you insert a certain character, or similar things (like remote code execution, etc.), can be quite important. Finally, apps are most of the time connected to the Internet, which makes them inherently vulnerable. After searching "android software libraries CVEs" I found this in the first results' page: https://github.com/dotanuki-labs/android-oss-cves-research https://github.com/dotanuki-labs/android-oss-cves-research It might be outdated, but the principle still applies. It's very unlikely that your application is self-sufficient and doesn't need updates. EDIT: I read the message from Apple as a "hopeful" attempt to say "come on, man at least update the dependencies".

hulitu 4y ago
> Well, there is also the security aspect in mind. What security ? "Google security" where everyone except the user has access to his data ? Why does a note taking app needs internet to function ? Why does my phone app need access to internet ?
- catlifeonmars 4y ago
  Those are great counterpoints. Instead of relying on developers to keep their own apps up to date (you will always have a significant number of outliers), you enforce security better at the system level. Having more tightly scoped permissions and better sandboxing of runtimes solves this way better than depending on individual app developers to secure their own apps.
- mk89 4y ago
  how many note taking apps do you have? without even going on my phone, I think 70% of my apps need internet access (for a reason).

mihaaly 4y ago

Perhaps you should commit a new "Still working well..." line to its readme file in every few weeks to satisfy the update hungry crowd. :)

HWR_14 4y ago

I feel like, and hope gorhill responds to this, that uMatrix was similar to this. Done and stable and needing to be touched just so people can wouldn't ask if it was still maintained. (Pre manifestv3 that is)

brokenmachine 4y ago

Any general comments on how to write forward-compatible software for a hack programmer?