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.
Literally every time I've let my phone update the Android version, something changed to my detriment - missing feature, not being able to do something a certain way anymore, etc. with the only benefit being the ability to run apps that only target the new version. App updates are often no better.
I think this is part of the mindset the OP is criticizing.
Following that logic, a software cannot possibly be completed - It can be either in development or dead. Which would mean you either have a budget of time, money and resources for constant maintenance of your software - or you might not write that software at all. Repeat that for every new piece of software you want to write.
The problem is that this is impossible to do for hobbyist authors, so we would lose a large amount of free or open-source software currently available.
There's kind of a parallel with signals regarding businesses as well. There may be nothing wrong with a store that hasn't been renovated since the 90s, but it gives off a "run-down" vibe like it wouldn't be there much longer.
"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. 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.
Whether or not software can be finished with 0 bugs is sort of irrelevant. Windows and other software users use most will basically never be "finished".
The updates that are causing the fever are not just "bugfixes", they are the current state of living software--always expanding and improving (at least in intent). The fact users see software that hasn't been updated as dead is a reflection of their learned expectations. And they are correct, it likely is dead in the "no longer improving as my other software is" sense.
The real issue I have is how shitty most update processes are. Thanks for rebooting my PC Win 10, yes Sublime Text, please tell me again in a dialog that there is an update, etc. Some apps have done much better here like Chrome and Discord, but it is not an easy thing to build.
> 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.
Addendum: I also believe it is possible to write software that does not need to be "improved". I prefer reliable software more than "dynamic" software that is a constant state of flux. And as you might guess I am not fond of software that keeps expanding with "features" to fill available space. I am quite happy if software just keeps doing what I expect it do, without slowing down or failing.
The question I would have as to other users who appear to want updates is whether they want new features or whether they are hoping the next update fixes some specific or general annoyance they are experiencing, e.g., perhaps generally they are not thrilled with the software and hope the "new" or "updated" version will be less disappointing.
While some may think I have misinterpreted the blog author (and I acknowledge this is a valid response), I still think that bug or nondescript "security fixes" is a powerful, fear-based mechanism to compel users to allow updates -- of any kind. And it therefore relevant to any discussion of "updates". Especially when it is common for these bug or "security fixes" to be inextricably mixed with non-security items such as "features" in such a way that the user must except the "whole hog", perhaps in some way similar to "omnibus legislation" in the US Congress.
I respect everyone's opinions whether you agree with me or not. I am just happy to see that some users may be thinking about "updates" and what they really are instead of blindly accepting them without ever pausing to think.
From my perspective every new "feature" that adds code is also introducing a new potential for a bug or security issue. I want programs and systems to get smaller not larger.
A Linux util is more like a program function than a piece of software. The fact that it’s compiled as a separate executable isn’t really relevant as it’s typically deployed as part of something bigger such as a Linux distribution - which is a piece of software that is certainly is complex enough to have bugs forever. “Bug free” software might exist but it’s rare.
The most important thing is that I need to be reassured that if a major bug is discovered in the software I’m using, then it will be fixed. How can I be sure of that? The absolutely simplest way is if the software releases regular updates with very small changes. It’s a heartbeat to let people know there is someone that will solve the future problem.
I don’t even need to install these updates! They are mostly symbolic, that doesn’t make them irrelevant.
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.
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.
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.
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.
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 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.
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.
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.
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-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.
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 ...).
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.
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-...
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.
Binaries (without external runtime dependencies) generally don't just "stop working" like that unless you change something significant about your system.
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.
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-...), or just because updates are automatically installed and it's too late when you realize it's broken :-/
>>> 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.
An appropriately sandboxed process that has no access to other processes or files can be considered non-security critical. But sadly nearly all programs commonly in use can access all the user's data and do with them as it wishes (hence ransomware) thus we have to perforce consider every program as security critical.
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.
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.
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!"
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.
> 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.
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..
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.
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.
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.)
sjellis|8 years ago
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|8 years ago
Just release when there's something to release.
jimmaswell|8 years ago
xg15|8 years ago
Following that logic, a software cannot possibly be completed - It can be either in development or dead. Which would mean you either have a budget of time, money and resources for constant maintenance of your software - or you might not write that software at all. Repeat that for every new piece of software you want to write.
The problem is that this is impossible to do for hobbyist authors, so we would lose a large amount of free or open-source software currently available.
asperous|8 years ago
feelin_googley|8 years ago
"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. 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.
Guzba|8 years ago
The updates that are causing the fever are not just "bugfixes", they are the current state of living software--always expanding and improving (at least in intent). The fact users see software that hasn't been updated as dead is a reflection of their learned expectations. And they are correct, it likely is dead in the "no longer improving as my other software is" sense.
The real issue I have is how shitty most update processes are. Thanks for rebooting my PC Win 10, yes Sublime Text, please tell me again in a dialog that there is an update, etc. Some apps have done much better here like Chrome and Discord, but it is not an easy thing to build.
throwaway613834|8 years ago
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.
MrQuincle|8 years ago
There is no such thing as finished software.
The size of a bug is in the eye of the beholder.
Sorry for the Shellshock.
Edit, took me two seconds to find: https://news.ycombinator.com/item?id=502651. Just as response to http://cr.yp.to/djbdns/guarantee.html
feelin_googley|8 years ago
While some may think I have misinterpreted the blog author (and I acknowledge this is a valid response), I still think that bug or nondescript "security fixes" is a powerful, fear-based mechanism to compel users to allow updates -- of any kind. And it therefore relevant to any discussion of "updates". Especially when it is common for these bug or "security fixes" to be inextricably mixed with non-security items such as "features" in such a way that the user must except the "whole hog", perhaps in some way similar to "omnibus legislation" in the US Congress.
I respect everyone's opinions whether you agree with me or not. I am just happy to see that some users may be thinking about "updates" and what they really are instead of blindly accepting them without ever pausing to think.
From my perspective every new "feature" that adds code is also introducing a new potential for a bug or security issue. I want programs and systems to get smaller not larger.
alkonaut|8 years ago
The most important thing is that I need to be reassured that if a major bug is discovered in the software I’m using, then it will be fixed. How can I be sure of that? The absolutely simplest way is if the software releases regular updates with very small changes. It’s a heartbeat to let people know there is someone that will solve the future problem.
I don’t even need to install these updates! They are mostly symbolic, that doesn’t make them irrelevant.
wbkang|8 years ago
sholladay|8 years ago
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|8 years ago
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.
JeffL|8 years ago
5ilv3r|8 years ago
jamy015|8 years ago
[deleted]
Santosh83|8 years ago
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.
eadmund|8 years ago
E.g. 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|8 years ago
anothertraveler|8 years ago
digi_owl|8 years ago
jodrellblank|8 years ago
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...
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|8 years ago
nmstoker|8 years ago
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.
nautilus12|8 years ago
frik|8 years ago
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|8 years ago
_ph_|8 years ago
aiNohY6g|8 years ago
Edit: Android devices does not suffer from this fever, btw. How good. Really. https://danluu.com/android-updates/
bluedino|8 years ago
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.
cwyers|8 years ago
What software is non-security critical anymore?
Santosh83|8 years ago
throwaway613834|8 years ago
LaTeX, MATLAB, CMake...
awinder|8 years ago
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.
ilaksh|8 years ago
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.
martin_ky|8 years ago
Such discussions usually end in one final argument from the new developer: "But your version is no longer maintained!"
ChuckMcM|8 years ago
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.
oconnor663|8 years ago
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.
jimjimjim|8 years ago
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
bugmen0t|8 years ago
jakobegger|8 years ago
The result can be an app that requires minimal maintenance and it might work for years without any changes at all.
alvil|8 years ago
petre|8 years ago
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.
rajeshmr|8 years ago
jlebrech|8 years ago
sjmulder|8 years ago
"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.)