11 ms·

Why the Update Fever Is Bad

149 points by irrlichthn 9y ago

aiNohY6g 9y ago
It's not like we always have the choice not to upgrade, either because of security (IoT anyone?), because one of the giant's shoulder a software has been built on has gone wild or has its own security fix to deploy (https://github.com/blog/2470-introducing-security-alerts-on-github https://github.com/blog/2470-introducing-security-alerts-on-...), or just because updates are automatically installed and it's too late when you realize it's broken :-/ Edit: Android devices does not suffer from this fever, btw. How good. Really. https://danluu.com/android-updates/ https://danluu.com/android-updates/
Santosh83 9y ago
I guess if your software is stable and 'finished' enough not to be updated often then it would be good if you have an established communication channel (like a website or a GitHub page) that will periodically come out with, well, 'news updates', since it is true that most users are conditioned to expect some kind of update/activity surrounding their software. Besides any moderately complex software will probably have enough bugs to require updates now & then for years, even if no new features or added. Not only bugs but often the underlying platform changes/breaks, needing workarounds or rebuilds.
feelin_googley 9y ago
Glad to see this being written. "Trained" is the word I have thought of many times as well. It is perplexing to see people wanting updates. It is possible to write finished programs that are bug-free[FN1]. But when eternal rounds of patching becomes a religion, what sort of standard are developers promoting? Every program is expected to have security holes that will need to be patched? What about not releasing software unless it is safe to begin with? Why does a liability need to be created? Solve the problems before the software is released. Not after. Can't solve them? Then do not release. Automatic updates are also a security hazard in the same way as "antivirus", which also trained users to want updates. It is a backdoor that users are advised to leave open. FN1. Inevitably there will be the HN commenter who repeats some meme that says all software has bugs. True perhaps if we forget about Ada and the world outside of MS Windows, but are all the bugs major ones? Consider the stuff you find at http://cr.yp.to http://cr.yp.to. Or many of the small UNIX utilities. I could name more selected examples. There is such a thing as finished software. With no major bugs. That does not need constant updates.
- throwaway613834 9y ago
  > There is such a thing as finished software. With no major bugs. That does not need constant updates. The general attitude (both on HN and elsewhere) is that if any security update exists for a product you use then you are a complete moron not to update it immediately. There is virtually no acknowledgment of any nuance on the topic in my experience.
  - dvfjsdhgfv 9y ago
    I think this is what people officially say, because this is the "right" thing to do, and in general it makes sense. But in real life things are different. I had to support many ancient systems with no security updates for years or even decades now. For some of them some updates were available, but we didn't even have the hardware to test them on. Yes, we were gradually moving many older parts to newer systems. Nevertheless, in the case of these older machines working in isolated networks, trying to patch them was just asking for trouble. I bet many admins on HN have similar experience.
    - digi_owl 9y ago
      In other words, people are "virtue signaling"...
  - jamy015 9y ago
    Not applying a security update is willingly leaving a known security hole in place. At best, you are making your system insecure, and at worst, you are putting others on your network and/or in your social circles at risk.
    - CaptSpify 9y ago
      or.... You are trying to avoid an update that is going to break your machine/workflow. If security updates were sent along a different channel than feature updates, this wouldn't be an issue. But companies keep tying these together, and there are only so many features you can carelessly break before users become aware of what you are really doing.
alvil 9y ago
Do fake update at semi-random time. Visualize it, eg. show them a dialog with progress bar and percentage.
- petre 9y ago
  Thus wasting other people's time and productivity? I'm using the Atom editor. It's kind of annoying how it pushes new updates every week. Previously used Subline Text 2 which just worked and did not have an update for years.
  - sicher 9y ago
    Sublime is a great example of users getting update fever. The forum is riddled with long ”is this software dead?” threads that pop up at regular intervals.
    - empath75 9y ago
      Eventually it will be, if they stop updating it. Atom and visual studio code are overtaking it.
sholladay 9y ago
People expect their software to improve over time, and thus receive updates, and this is perfectly reasonable. Most software is never "done". If it is a small module written in a highly mature language and operating in a stable, slow moving ecosystem, then fine. In those cases, simply document that updates will be few and far between and that this is expected for the above reasons. More likely, development simply slows down because the maintainer got lazy, moved on to other interests, or doesn't have time for other reasons. Users don't like this and they are right to worry that the maintainer may be unresponsive or that the software will not be quickly patched in the event of a security vulnerability being discovered because the software is not actively maintained. Your software is not complete. It is merely functional. In fact, it may not even be functional, as the rest of the world moves on without you and your code rots away.
- blincoln 9y ago
  Counterpoint: I've written a lot of niche utilities over the years. Some of them are very simple, and some of them are very complex. They're specialized enough that in most cases, they are the only software that performs a specific type of work. To my knowledge, they all still do exactly what I made them to do. Are there things I would like to add to some of them if I had unlimited time? Yes. Does not having time to do that mean that they've stopped doing what they were designed to do? No. The only time I can see an argument for frequent updates being required (as opposed to a bonus) is for software with direct dependencies on other things. youtube-dl, for example, or the NTDS.dit-extracting functionality in Impacket are good examples of this - they work directly with content that may change at any time, so someone needs to make sure they're compatible with the current versions of that content.
frik 9y ago
Show them somehow it is still supported, update the minor version or something. In general: If I come across a 3 year old binary, and no news article about dev activity it looks "dead and unsupported". Also on GitHub, if there is no commit for 1+ year, it looks "dead and unsupported", piling up of Github issues is also a bad sign. Using "dead" binary asks for troubles down roads, when you want to use it in a few months and it stopped working.
- taneq 9y ago
  Binaries (without external runtime dependencies) generally don't just "stop working" like that unless you change something significant about your system.
  - frik 9y ago
    Ideally yes, but the world changed. There are a constant stream of updates for your OS, graphic card driver, etc which constantly break things left and right. If it affects a big software, even an outdated version) the user outcry will make sure it get fixed. But you better make sure not to rely on an unsupported 3 year old rather niche software if you plan to upgrade anytime soon.
cwyers 9y ago
> So for non-security critical software, it is sometimes better not to update that often. This update fever is bad both for developers and users. What software is non-security critical anymore?
- throwaway613834 9y ago
  > What software is non-security critical anymore? LaTeX, MATLAB, CMake...
  - rhn_mk1 9y ago
    Terrible examples, considering that these are programming languages that people will use to run code from random sources. "git clone foo && cmake foo" can definitely be a security problem, and not just because the code itself is untrusted.
    - saywatnow 9y ago
      It's not cmake's job to limit the behaviour of programs written with it.
      - al2o3cr 9y ago
        OTOH, allocating & using memory correctly so that a maliciously-crafted Makefile can't get elevated permissions is.
        pedrocr 9y ago
        A makefile can call whatever it wants so if you run a malicious one you're already hacked. There's nothing you can do with a cmake buffer overrun that you can't also do just by writing a normal cmake file to call out whichever malicious commands you want.
        throwaway613834 9y ago
        >> It's not cmake's job to limit the behaviour of programs written with it. > OTOH, allocating & using memory correctly so that a maliciously-crafted Makefile can't get elevated permissions is. https://en.wikipedia.org/wiki/Not_even_wrong https://en.wikipedia.org/wiki/Not_even_wrong
JeffL 9y ago
I stopped letting my iPhone update. I swear every update makes it slower and buggier. My old iPad which was perfectly fast and great at the time is now almost unusable after 4 iOS upgrades. It won't even play Sudoko without constant mini freezes.
- jamy015 9y ago
  I'm sure cybercriminals are very thankful for people like you. Are you also still running Windows XP, because newer versions slow down your computer which "was perfectly fast and great at the time"?
  - sctb 9y ago
    Please don't be personally rude to user users here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- 5ilv3r 9y ago
  People would rather use a functional but insecure tool than a broken secure one. No question. It's hard for devs to understand that for some reason.
  - digi_owl 9y ago
    Because devs live and breath security. End result is that they develop blinders to anything else. Also they know when and why to update stuff they work on, thus i never happens at an inopportune time. Nor do they find themselves having to wrangle the new dependency kudzu they created, because for them it built up over time.
  - timrichard 9y ago
    My iOS device is noticeably laggier too, and I find it difficult to point the finger at security fixes. More likely the bloat from a load of features that nobody asked for.
  - martin_ky 9y ago
sjellis 9y ago
Software updates are a kind of project heartbeat. The content of them is less important than the signal, "this project is still alive, and maintainers are fixing issues for people". If a project does not put out updates, then users may (understandably) worry that if they have an issue, it won't get addressed promptly. I actually don't think there is anything wrong with having time-based releases, and putting very little content in some of them. If you only fix one bug in a quarterly/bi-annual release and tweak some docs, because that's all that's needed, you have still fixed an issue for somebody, and demonstrated to all of your other users that you are still keeping your commitments, and there for them if they need you.
- chii 9y ago
  But on the other hand, if the software is stable and no longer needs updating why force small inconsequential changes just to appear to be maintained? Just release when there's something to release.
  - muzani 9y ago
    Software is very rarely perfect though. There are some rare cases like Winamp and Photoshop where there's just not much to add. I do find projects like Dwarf Fortress very charming in that there's an endless supply of new things to look forward to.
    - digi_owl 9y ago
      DF is also unlikely to be critical to someones workflow or similar.
    - egypturnash 9y ago
      Photoshop has a new release every year or so, usually with new features.
      - justinclift 9y ago
        The term "Creeping Featuritis" probably applies to that specific example. And any MS Office release in the last decade or so. :)
ilaksh 9y ago
BTW Irrlicht is great so thank you to the author for making it. CobberCube looks good too. But that is one reason someone might not update a project a lot -- they are making other stuff, for example one along the same lines that could make money. But Irrlicht works great still and still has a forum etc. so I would not complain if there weren't more updates. Actually I wouldn't really want another update at this point, because I already have a code base built on the existing thing that does what I want and adapting to new/changed stuff would distract from developing features specific to my system.
jodrellblank 9y ago
This doesn't say much about why it's bad. Colin Percival wrote a more detailed piece on updates, their problems and considerations here: http://www.daemonology.net/blog/2017-06-14-oil-changes-safety-recalls-software-patches.html http://www.daemonology.net/blog/2017-06-14-oil-changes-safet... and suggests separate channels for 'updates' vs. 'security fixes'. This is something new for Microsoft: Usually they won't break their own old software with updates, they are known for keeping up backwards compatibility at all costs. It really isn't. Thirteen years ago: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... If you ask the users about it, they don't even know why they want these updates. Is there a feature they are missing? New things are fun. Maybe there'll be a feature I don't know I'm missing until I see it. I'm hankering for you to amaze me and fix all my problems. Be my Holy Grail of (text editing, browsing, productivity, databasing, developing, life ...).
- digi_owl 9y ago
  New things are fun when you are young. As you grow older you learn to appreciate stable reliable behavior.
_ph_ 9y ago
If a software is under active development, one would at least occasionally expect updates with new features and enhancements. Even if it is just in maintenance mode, there would be bug and security fixes. Not every week, but at least every couple of months. With software like iOS apps, it is a huge warning sign, if apps are not updated after OS updates or especially after new devices introduce new screen sizes. And with iOS, those apps are eventually going to stop working.
rajeshmr 9y ago
Excellent, well put!
jlebrech 9y ago
maybe nullupdates should be a thing.
- sjmulder 9y ago
  For anyone thinking about doing this, here are some free release note templates: "Bug fixes and stability improvements" "Thank you for using <X>! For your benefit, we update <X> continuously. Every updates for <X> potentially includes new features, bug fixes and other improvements. Don't hesitate to reach out to noreply@<X>app.com if you have any questions or suggestions." "Bedankt dat je <X> gebruikt! Bij het invullen van de releasenotes heeft onze stagiair niet opgelet en per ongeluk de verkeerde taal geplakt. Geen probleem. We hopen dat je van deze nieuwe versie geniet!" (For the longest time, the Dutch Facebook Messenger app had release notes in some Scandinavian language.)
  - mizaru 9y ago
    A lot of popular iOS apps are doing this, which I personally find extremely annoying.
    - digi_owl 9y ago
      So many big apps (including some from Google themselves) have such a line permanently bolted to them over at Android as well.
    - obmelvin 9y ago
      I would reckon that the average user doesn't care for a list of specific bug fixes.
nmstoker 9y ago
With such a huge spectrum of kind of software, what applies in one kind won't necessarily be so for another. The heartbeat argument is an obvious case. It's the same reason people look at the UI "chrome" in the screenshots in Android Play Store - if the battery indicator is from Eclair it doesn't built confidence it'll work in Nougat! But that may apply less to a more minimalist utility (eg a command line tool) Merely to update it so that you formally confirm that this version was tested on newer systems may be valid in some cases (although one could merely update documentation in many cases for that). And then there is the dependency argument. Where a tool directly contains underlying packages, it builds confidence the developer won't get stuck too far behind current(ish) versions (with the greater risk of it becoming abandonware). Where the dependencies are external (ie up to the user to have installed) you do not want to be stuck on some old version, as other tools may move on, even if this super-stable software doesn't feel the need.
awinder 9y ago
A lot of commenters have keyed into the product heartbeat line. Shipping updates is one common signals of a healthy product but it’s not the only one. If your product has non-user-facing changes, you should try to make noise about what other people are actively building or doing with your product. Or if you’re offering a service, market reliability and put time into showing stability and educating customers on why they should trust that they can build with you. You should also be working on acquiring customers if your product is in that phase. Realistically you’re talking about a product that requires little to no maintenance for existing customers which should free you up to spend time getting more customers. Any of the above is going to realistically create feature work as you work with new customers or users and find further areas for completing your product offering. Word of caution — this work will never realistically end, or you will end. There is no end state to software. Software is the tool, the product is your user or customer community and the problems you solve together. If you’re looking to build software as an end state, I see obvious problems, and your customers do too.
nautilus12 9y ago
I agree with this to a certain extent. If more care had been put into the software to start with then they should need frequent updating. And often bugs can be introduced with an update of a dependency for example, because you cannot be sure that all your dependencies are preserving backwards compatibility. Usually it goes something like this, inconsequential dependency has a security vulnerability that needs updated, that requires two other dependencies to be updated, the third one is pretty hacky and has a latent bug. Software is updated, but over the next month three more hotfixes are needed to address the bugs by the bad dependency. Thus the software lifecycle continues on. Btw, I thought this article related to this was really interesting: https://www.siliconrepublic.com/innovation/darpa-working-on-software-that-doesnt-need-updates-for-100-years https://www.siliconrepublic.com/innovation/darpa-working-on-...
anothertraveler 9y ago
I gave up on Windows about 10 years ago. I've had to use it for work sometimes, but the Windows Updates are actually destructive sometimes, and often take hours to install during business hours (especially if you happen to need to reboot before an important meeting...). I can't handle uncertainty in Software, and I think that many business are losing productivity because of this. Or maybe IT support departments are happy to keep themselves employed.
- digi_owl 9y ago
  Sadly the Linux ecosystem (baring the kernel and the GNU supplied coreutils) do not seem to do any better. And from what gather, Apple is notorious for breaking things as they see fit as well. Not sure how well the BSDs do in this regard.
  - anothertraveler 9y ago
    I am a Debian sid user, so I know well what you mean, but as long as you don't do a kernel upgrade, Linux has been extremely stable for me. This wasn't always the case. 10 years ago, Debian sid would break all the time, but I have probably had only one or two non-kernel/driver related issues in the past 5 years. Another subtle difference is that on Linux platforms, you have more control over when/how to update, as well as visibility into exactly what is updating. I'm sure it's visible on other platforms, but I don't have to worry about rebooting my machine and having to wait 2 hours for it to come up. Perhaps another point worth mentioning, LTS versions of Linux distros (Debian stable, or Ubuntu LTS versions) mainly get security patches, and, optionally, back ported software. That makes your OS stack super stable! I'd put kernel upgrades into a different bucket... but most users don't need to update their kernel on a daily or even yearly basis except for security patches. Great point about coreutils too! No need to update ls and grep...
oconnor663 9y ago
> Is there a feature they are missing? A specific bug they want to have fixed? They don't know. They only want updates, because they are used to it. That doesn't sound like the most charitable reading. A lot of customers expect updates to mean performance improvements or security fixes, neither of which they'd be able to ask for with any kind of specifics.
bluedino 9y ago
>>> Is there a feature they are missing? A specific bug they want to have fixed? They don't know. They only want updates, because they are used to it. A long, long time ago DJGPP 2.0 was released, and almost immediately people were asking when version 3.0 was coming out. It was a DOS port of the GNU C compiler, so really you can't make a new version of it until the next GCC comes out. Plus, the question was, "What would the update have?" It's not like commercial software where you need to add features every quarter so your competition doesn't leave you in the dust.
ChuckMcM 9y ago
Interesting debate, updates as a product viability signal. I can see the angle as a developer that there isn't anything new this week/month/quarter in the software. And I can see the user angle that if it hasn't been updated perhaps updates are no longer available. That makes me wonder if an update that says the software continues to be in good shape (a non-update update) would assuage the user. Something like that could be automated and so not impact the developer.
bugmen0t 9y ago
I wouldn't call myself very experienced, but software is really brittle and everything is built on top of something else, so an update triggers an update triggers an update..
- jakobegger 9y ago
  But there are other ways to build software. You can make apps with very few dependencies, use stable APIs only, program defensively, make sure you properly read the docs and handle all error conditions, don’t add unnecessary features, etc. The result can be an app that requires minimal maintenance and it might work for years without any changes at all.
  - digi_owl 9y ago
    But doing so takes focus and diligence, something the software world is notoriously short on (likely they can always push another fix to prod, unlike with hardware).
    - timrichard 9y ago
      And it wasn't always like that with software. We're used to the current situation in the age of portable devices and app stores, but I remember buying software in the 80s and 90s when most people didn't have a modem or any networking connectivity on their home machines. You went to a store, and bought software on disk or CD that came in a cardboard box shrinkwrapped in cellophane. You tried out the features, and it either worked or it didn't. And if it didn't, you were stuck - but that generally didn't happen, to my memory. Because of the lack of options when the product was on the shelves, it was tested rigorously. (Of course it would be fair to say that it would be a siloed runnable that wouldn't generally have dependencies or be required to interoperate with anything else, but the feature density would be comparable). There was none of this "fix it in tomorrow's release" from the "just ship it duuuudes", so you didn't find obvious defects in features within minutes.
eadmund 9y ago
This is something I see with Common Lisp libraries a lot. Many of them look abandoned, because they've had no updates in years. But they're really not: they each aimed to do one thing, they each do it well, and they don't have any more (notable) bugs. The Lisp spec doesn't change, so if a library's functional spec doesn't change … it's complete. E.g. https://github.com/dardoria/uuid https://github.com/dardoria/uuid a library to generate UUIDs: once it fulfills the spec properly, it's essentially done. This particular example could contain a bug, of course, but the principle stands.
- watt 9y ago
  It does not even have a readme. What kind of definition of done is this?
jimjimjim 9y ago
Tail wagging the dog. If it needs a fix, update it. If you want to increase awareness, add a feature. If people are paying a software support fee or have a contract stating a certain number of releases a year then do releases. Otherwise why risk introducing new problems
martin_ky 9y ago
I don't know if it's just me, but I have to exert significant energy to convince (typically) new hires, that it does not really hurt anything if we use older versions of some dependencies, as long as they are stable and we are not hitting any bugs or vulnerabilities. In other words: it is not reason enough and not worth to update only because a new version was just released. Such discussions usually end in one final argument from the new developer: "But your version is no longer maintained!"

149 points by irrlichthn 9y ago

It's not like we always have the choice not to upgrade, either because of security (IoT anyone?), because one of the giant's shoulder a software has been built on has gone wild or has its own security fix to deploy (https://github.com/blog/2470-introducing-security-alerts-on-github https://github.com/blog/2470-introducing-security-alerts-on-...), or just because updates are automatically installed and it's too late when you realize it's broken :-/ Edit: Android devices does not suffer from this fever, btw. How good. Really. https://danluu.com/android-updates/ https://danluu.com/android-updates/

Santosh83 9y ago

I guess if your software is stable and 'finished' enough not to be updated often then it would be good if you have an established communication channel (like a website or a GitHub page) that will periodically come out with, well, 'news updates', since it is true that most users are conditioned to expect some kind of update/activity surrounding their software. Besides any moderately complex software will probably have enough bugs to require updates now & then for years, even if no new features or added. Not only bugs but often the underlying platform changes/breaks, needing workarounds or rebuilds.

feelin_googley 9y ago

Glad to see this being written. "Trained" is the word I have thought of many times as well. It is perplexing to see people wanting updates. It is possible to write finished programs that are bug-free[FN1]. But when eternal rounds of patching becomes a religion, what sort of standard are developers promoting? Every program is expected to have security holes that will need to be patched? What about not releasing software unless it is safe to begin with? Why does a liability need to be created? Solve the problems before the software is released. Not after. Can't solve them? Then do not release. Automatic updates are also a security hazard in the same way as "antivirus", which also trained users to want updates. It is a backdoor that users are advised to leave open. FN1. Inevitably there will be the HN commenter who repeats some meme that says all software has bugs. True perhaps if we forget about Ada and the world outside of MS Windows, but are all the bugs major ones? Consider the stuff you find at http://cr.yp.to http://cr.yp.to. Or many of the small UNIX utilities. I could name more selected examples. There is such a thing as finished software. With no major bugs. That does not need constant updates.

throwaway613834 9y ago
> There is such a thing as finished software. With no major bugs. That does not need constant updates. The general attitude (both on HN and elsewhere) is that if any security update exists for a product you use then you are a complete moron not to update it immediately. There is virtually no acknowledgment of any nuance on the topic in my experience.
- dvfjsdhgfv 9y ago
  I think this is what people officially say, because this is the "right" thing to do, and in general it makes sense. But in real life things are different. I had to support many ancient systems with no security updates for years or even decades now. For some of them some updates were available, but we didn't even have the hardware to test them on. Yes, we were gradually moving many older parts to newer systems. Nevertheless, in the case of these older machines working in isolated networks, trying to patch them was just asking for trouble. I bet many admins on HN have similar experience.
  - digi_owl 9y ago
    In other words, people are "virtue signaling"...
- jamy015 9y ago
  Not applying a security update is willingly leaving a known security hole in place. At best, you are making your system insecure, and at worst, you are putting others on your network and/or in your social circles at risk.
  - CaptSpify 9y ago
    or.... You are trying to avoid an update that is going to break your machine/workflow. If security updates were sent along a different channel than feature updates, this wouldn't be an issue. But companies keep tying these together, and there are only so many features you can carelessly break before users become aware of what you are really doing.

alvil 9y ago

Do fake update at semi-random time. Visualize it, eg. show them a dialog with progress bar and percentage.

petre 9y ago
Thus wasting other people's time and productivity? I'm using the Atom editor. It's kind of annoying how it pushes new updates every week. Previously used Subline Text 2 which just worked and did not have an update for years.
- sicher 9y ago
  Sublime is a great example of users getting update fever. The forum is riddled with long ”is this software dead?” threads that pop up at regular intervals.
  - empath75 9y ago
    Eventually it will be, if they stop updating it. Atom and visual studio code are overtaking it.

sholladay 9y ago

People expect their software to improve over time, and thus receive updates, and this is perfectly reasonable. Most software is never "done". If it is a small module written in a highly mature language and operating in a stable, slow moving ecosystem, then fine. In those cases, simply document that updates will be few and far between and that this is expected for the above reasons. More likely, development simply slows down because the maintainer got lazy, moved on to other interests, or doesn't have time for other reasons. Users don't like this and they are right to worry that the maintainer may be unresponsive or that the software will not be quickly patched in the event of a security vulnerability being discovered because the software is not actively maintained. Your software is not complete. It is merely functional. In fact, it may not even be functional, as the rest of the world moves on without you and your code rots away.

blincoln 9y ago
Counterpoint: I've written a lot of niche utilities over the years. Some of them are very simple, and some of them are very complex. They're specialized enough that in most cases, they are the only software that performs a specific type of work. To my knowledge, they all still do exactly what I made them to do. Are there things I would like to add to some of them if I had unlimited time? Yes. Does not having time to do that mean that they've stopped doing what they were designed to do? No. The only time I can see an argument for frequent updates being required (as opposed to a bonus) is for software with direct dependencies on other things. youtube-dl, for example, or the NTDS.dit-extracting functionality in Impacket are good examples of this - they work directly with content that may change at any time, so someone needs to make sure they're compatible with the current versions of that content.

frik 9y ago

Show them somehow it is still supported, update the minor version or something. In general: If I come across a 3 year old binary, and no news article about dev activity it looks "dead and unsupported". Also on GitHub, if there is no commit for 1+ year, it looks "dead and unsupported", piling up of Github issues is also a bad sign. Using "dead" binary asks for troubles down roads, when you want to use it in a few months and it stopped working.

taneq 9y ago
Binaries (without external runtime dependencies) generally don't just "stop working" like that unless you change something significant about your system.
- frik 9y ago
  Ideally yes, but the world changed. There are a constant stream of updates for your OS, graphic card driver, etc which constantly break things left and right. If it affects a big software, even an outdated version) the user outcry will make sure it get fixed. But you better make sure not to rely on an unsupported 3 year old rather niche software if you plan to upgrade anytime soon.

cwyers 9y ago

> So for non-security critical software, it is sometimes better not to update that often. This update fever is bad both for developers and users. What software is non-security critical anymore?

throwaway613834 9y ago
> What software is non-security critical anymore? LaTeX, MATLAB, CMake...
- rhn_mk1 9y ago
  Terrible examples, considering that these are programming languages that people will use to run code from random sources. "git clone foo && cmake foo" can definitely be a security problem, and not just because the code itself is untrusted.
  - saywatnow 9y ago
    It's not cmake's job to limit the behaviour of programs written with it.
    - al2o3cr 9y ago
      OTOH, allocating & using memory correctly so that a maliciously-crafted Makefile can't get elevated permissions is.
      - pedrocr 9y ago
        A makefile can call whatever it wants so if you run a malicious one you're already hacked. There's nothing you can do with a cmake buffer overrun that you can't also do just by writing a normal cmake file to call out whichever malicious commands you want.
      - throwaway613834 9y ago
        >> It's not cmake's job to limit the behaviour of programs written with it. > OTOH, allocating & using memory correctly so that a maliciously-crafted Makefile can't get elevated permissions is. https://en.wikipedia.org/wiki/Not_even_wrong https://en.wikipedia.org/wiki/Not_even_wrong

JeffL 9y ago

I stopped letting my iPhone update. I swear every update makes it slower and buggier. My old iPad which was perfectly fast and great at the time is now almost unusable after 4 iOS upgrades. It won't even play Sudoko without constant mini freezes.

jamy015 9y ago
I'm sure cybercriminals are very thankful for people like you. Are you also still running Windows XP, because newer versions slow down your computer which "was perfectly fast and great at the time"?
- sctb 9y ago
  Please don't be personally rude to user users here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
5ilv3r 9y ago
People would rather use a functional but insecure tool than a broken secure one. No question. It's hard for devs to understand that for some reason.
- digi_owl 9y ago
  Because devs live and breath security. End result is that they develop blinders to anything else. Also they know when and why to update stuff they work on, thus i never happens at an inopportune time. Nor do they find themselves having to wrangle the new dependency kudzu they created, because for them it built up over time.
- timrichard 9y ago
  My iOS device is noticeably laggier too, and I find it difficult to point the finger at security fixes. More likely the bloat from a load of features that nobody asked for.
- martin_ky 9y ago

sjellis 9y ago

Software updates are a kind of project heartbeat. The content of them is less important than the signal, "this project is still alive, and maintainers are fixing issues for people". If a project does not put out updates, then users may (understandably) worry that if they have an issue, it won't get addressed promptly. I actually don't think there is anything wrong with having time-based releases, and putting very little content in some of them. If you only fix one bug in a quarterly/bi-annual release and tweak some docs, because that's all that's needed, you have still fixed an issue for somebody, and demonstrated to all of your other users that you are still keeping your commitments, and there for them if they need you.

chii 9y ago
But on the other hand, if the software is stable and no longer needs updating why force small inconsequential changes just to appear to be maintained? Just release when there's something to release.
- muzani 9y ago
  Software is very rarely perfect though. There are some rare cases like Winamp and Photoshop where there's just not much to add. I do find projects like Dwarf Fortress very charming in that there's an endless supply of new things to look forward to.
  - digi_owl 9y ago
    DF is also unlikely to be critical to someones workflow or similar.
  - egypturnash 9y ago
    Photoshop has a new release every year or so, usually with new features.
    - justinclift 9y ago
      The term "Creeping Featuritis" probably applies to that specific example. And any MS Office release in the last decade or so. :)

ilaksh 9y ago

BTW Irrlicht is great so thank you to the author for making it. CobberCube looks good too. But that is one reason someone might not update a project a lot -- they are making other stuff, for example one along the same lines that could make money. But Irrlicht works great still and still has a forum etc. so I would not complain if there weren't more updates. Actually I wouldn't really want another update at this point, because I already have a code base built on the existing thing that does what I want and adapting to new/changed stuff would distract from developing features specific to my system.

jodrellblank 9y ago

This doesn't say much about why it's bad. Colin Percival wrote a more detailed piece on updates, their problems and considerations here: http://www.daemonology.net/blog/2017-06-14-oil-changes-safety-recalls-software-patches.html http://www.daemonology.net/blog/2017-06-14-oil-changes-safet... and suggests separate channels for 'updates' vs. 'security fixes'. This is something new for Microsoft: Usually they won't break their own old software with updates, they are known for keeping up backwards compatibility at all costs. It really isn't. Thirteen years ago: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... If you ask the users about it, they don't even know why they want these updates. Is there a feature they are missing? New things are fun. Maybe there'll be a feature I don't know I'm missing until I see it. I'm hankering for you to amaze me and fix all my problems. Be my Holy Grail of (text editing, browsing, productivity, databasing, developing, life ...).

digi_owl 9y ago
New things are fun when you are young. As you grow older you learn to appreciate stable reliable behavior.

_ph_ 9y ago

If a software is under active development, one would at least occasionally expect updates with new features and enhancements. Even if it is just in maintenance mode, there would be bug and security fixes. Not every week, but at least every couple of months. With software like iOS apps, it is a huge warning sign, if apps are not updated after OS updates or especially after new devices introduce new screen sizes. And with iOS, those apps are eventually going to stop working.

rajeshmr 9y ago

Excellent, well put!

jlebrech 9y ago

maybe nullupdates should be a thing.

sjmulder 9y ago
For anyone thinking about doing this, here are some free release note templates: "Bug fixes and stability improvements" "Thank you for using <X>! For your benefit, we update <X> continuously. Every updates for <X> potentially includes new features, bug fixes and other improvements. Don't hesitate to reach out to noreply@<X>app.com if you have any questions or suggestions." "Bedankt dat je <X> gebruikt! Bij het invullen van de releasenotes heeft onze stagiair niet opgelet en per ongeluk de verkeerde taal geplakt. Geen probleem. We hopen dat je van deze nieuwe versie geniet!" (For the longest time, the Dutch Facebook Messenger app had release notes in some Scandinavian language.)
- mizaru 9y ago
  A lot of popular iOS apps are doing this, which I personally find extremely annoying.
  - digi_owl 9y ago
    So many big apps (including some from Google themselves) have such a line permanently bolted to them over at Android as well.
  - obmelvin 9y ago
    I would reckon that the average user doesn't care for a list of specific bug fixes.

nmstoker 9y ago

With such a huge spectrum of kind of software, what applies in one kind won't necessarily be so for another. The heartbeat argument is an obvious case. It's the same reason people look at the UI "chrome" in the screenshots in Android Play Store - if the battery indicator is from Eclair it doesn't built confidence it'll work in Nougat! But that may apply less to a more minimalist utility (eg a command line tool) Merely to update it so that you formally confirm that this version was tested on newer systems may be valid in some cases (although one could merely update documentation in many cases for that). And then there is the dependency argument. Where a tool directly contains underlying packages, it builds confidence the developer won't get stuck too far behind current(ish) versions (with the greater risk of it becoming abandonware). Where the dependencies are external (ie up to the user to have installed) you do not want to be stuck on some old version, as other tools may move on, even if this super-stable software doesn't feel the need.

awinder 9y ago

A lot of commenters have keyed into the product heartbeat line. Shipping updates is one common signals of a healthy product but it’s not the only one. If your product has non-user-facing changes, you should try to make noise about what other people are actively building or doing with your product. Or if you’re offering a service, market reliability and put time into showing stability and educating customers on why they should trust that they can build with you. You should also be working on acquiring customers if your product is in that phase. Realistically you’re talking about a product that requires little to no maintenance for existing customers which should free you up to spend time getting more customers. Any of the above is going to realistically create feature work as you work with new customers or users and find further areas for completing your product offering. Word of caution — this work will never realistically end, or you will end. There is no end state to software. Software is the tool, the product is your user or customer community and the problems you solve together. If you’re looking to build software as an end state, I see obvious problems, and your customers do too.

nautilus12 9y ago

I agree with this to a certain extent. If more care had been put into the software to start with then they should need frequent updating. And often bugs can be introduced with an update of a dependency for example, because you cannot be sure that all your dependencies are preserving backwards compatibility. Usually it goes something like this, inconsequential dependency has a security vulnerability that needs updated, that requires two other dependencies to be updated, the third one is pretty hacky and has a latent bug. Software is updated, but over the next month three more hotfixes are needed to address the bugs by the bad dependency. Thus the software lifecycle continues on. Btw, I thought this article related to this was really interesting: https://www.siliconrepublic.com/innovation/darpa-working-on-software-that-doesnt-need-updates-for-100-years https://www.siliconrepublic.com/innovation/darpa-working-on-...

anothertraveler 9y ago

I gave up on Windows about 10 years ago. I've had to use it for work sometimes, but the Windows Updates are actually destructive sometimes, and often take hours to install during business hours (especially if you happen to need to reboot before an important meeting...). I can't handle uncertainty in Software, and I think that many business are losing productivity because of this. Or maybe IT support departments are happy to keep themselves employed.

digi_owl 9y ago
Sadly the Linux ecosystem (baring the kernel and the GNU supplied coreutils) do not seem to do any better. And from what gather, Apple is notorious for breaking things as they see fit as well. Not sure how well the BSDs do in this regard.
- anothertraveler 9y ago
  I am a Debian sid user, so I know well what you mean, but as long as you don't do a kernel upgrade, Linux has been extremely stable for me. This wasn't always the case. 10 years ago, Debian sid would break all the time, but I have probably had only one or two non-kernel/driver related issues in the past 5 years. Another subtle difference is that on Linux platforms, you have more control over when/how to update, as well as visibility into exactly what is updating. I'm sure it's visible on other platforms, but I don't have to worry about rebooting my machine and having to wait 2 hours for it to come up. Perhaps another point worth mentioning, LTS versions of Linux distros (Debian stable, or Ubuntu LTS versions) mainly get security patches, and, optionally, back ported software. That makes your OS stack super stable! I'd put kernel upgrades into a different bucket... but most users don't need to update their kernel on a daily or even yearly basis except for security patches. Great point about coreutils too! No need to update ls and grep...

oconnor663 9y ago

> Is there a feature they are missing? A specific bug they want to have fixed? They don't know. They only want updates, because they are used to it. That doesn't sound like the most charitable reading. A lot of customers expect updates to mean performance improvements or security fixes, neither of which they'd be able to ask for with any kind of specifics.

bluedino 9y ago

>>> Is there a feature they are missing? A specific bug they want to have fixed? They don't know. They only want updates, because they are used to it. A long, long time ago DJGPP 2.0 was released, and almost immediately people were asking when version 3.0 was coming out. It was a DOS port of the GNU C compiler, so really you can't make a new version of it until the next GCC comes out. Plus, the question was, "What would the update have?" It's not like commercial software where you need to add features every quarter so your competition doesn't leave you in the dust.

ChuckMcM 9y ago

Interesting debate, updates as a product viability signal. I can see the angle as a developer that there isn't anything new this week/month/quarter in the software. And I can see the user angle that if it hasn't been updated perhaps updates are no longer available. That makes me wonder if an update that says the software continues to be in good shape (a non-update update) would assuage the user. Something like that could be automated and so not impact the developer.

bugmen0t 9y ago

I wouldn't call myself very experienced, but software is really brittle and everything is built on top of something else, so an update triggers an update triggers an update..

jakobegger 9y ago
But there are other ways to build software. You can make apps with very few dependencies, use stable APIs only, program defensively, make sure you properly read the docs and handle all error conditions, don’t add unnecessary features, etc. The result can be an app that requires minimal maintenance and it might work for years without any changes at all.
- digi_owl 9y ago
  But doing so takes focus and diligence, something the software world is notoriously short on (likely they can always push another fix to prod, unlike with hardware).
  - timrichard 9y ago
    And it wasn't always like that with software. We're used to the current situation in the age of portable devices and app stores, but I remember buying software in the 80s and 90s when most people didn't have a modem or any networking connectivity on their home machines. You went to a store, and bought software on disk or CD that came in a cardboard box shrinkwrapped in cellophane. You tried out the features, and it either worked or it didn't. And if it didn't, you were stuck - but that generally didn't happen, to my memory. Because of the lack of options when the product was on the shelves, it was tested rigorously. (Of course it would be fair to say that it would be a siloed runnable that wouldn't generally have dependencies or be required to interoperate with anything else, but the feature density would be comparable). There was none of this "fix it in tomorrow's release" from the "just ship it duuuudes", so you didn't find obvious defects in features within minutes.

eadmund 9y ago

This is something I see with Common Lisp libraries a lot. Many of them look abandoned, because they've had no updates in years. But they're really not: they each aimed to do one thing, they each do it well, and they don't have any more (notable) bugs. The Lisp spec doesn't change, so if a library's functional spec doesn't change … it's complete. E.g. https://github.com/dardoria/uuid https://github.com/dardoria/uuid a library to generate UUIDs: once it fulfills the spec properly, it's essentially done. This particular example could contain a bug, of course, but the principle stands.

watt 9y ago
It does not even have a readme. What kind of definition of done is this?

jimjimjim 9y ago

Tail wagging the dog. If it needs a fix, update it. If you want to increase awareness, add a feature. If people are paying a software support fee or have a contract stating a certain number of releases a year then do releases. Otherwise why risk introducing new problems

martin_ky 9y ago

I don't know if it's just me, but I have to exert significant energy to convince (typically) new hires, that it does not really hurt anything if we use older versions of some dependencies, as long as they are stable and we are not hitting any bugs or vulnerabilities. In other words: it is not reason enough and not worth to update only because a new version was just released. Such discussions usually end in one final argument from the new developer: "But your version is no longer maintained!"