[sjellis]

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]

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.

[MrQuincle]

There is no software without bugs.

People seem to know that. Developers sometimes do not.

[gizmo]

There are projects that are close to bugfree, though. You can use a 3 year old version of sqlite without any difficulty. I don't know what version of "ls" or "mkdir" my machine runs, but I never worry about these simple utilities being out of date or behaving differently in release/staging. These utilities are essentially done, and 30 years from now they'll still work fine.

There is no software without bugs in the same sense that there exists no hardware that cannot fail. But you can create software that is so close to perfect that hardware failures outnumber software failures 100:1, so there is no point in pursuing perfection any further.

[ken]

SQLite is not typical software. It has over 90 million lines of test code, and is run in production every day by pretty much every computer in the world.

mkdir(1) is also not typical. Excluding the copyright header comment, it's so short that it fits entirely on one screen. If I ran into a bug, I could probably find it and fix it (or write my own version) in about 3 minutes.

It is indeed possible to "create software that is so close to perfect that hardware failures outnumber software failures 100:1", but it's so time-consuming that almost nobody ever does it.

Version 1.0.1 of a free mind-mapping app may be good and useful software, but I can virtually guarantee it has bugs. I doubt even the author would claim it's only at 1.0.1 because "there is no point in pursuing perfection any further".

[gizmo]

I agree that sqlite's quality is unusually high. That's why I used it as an example of what kind of quality is achievable.

However, I think you're approaching this from the wrong way. The most important thing about sqlite isn't the amount of manhours put into it, but the millions upon millions of manhours that have been saved because the product works so unbelievably well.

sqlite is the exception, and this is because the people involved in it really care about quality. Our software engineering culture has a lot to learn from the success of sqlite.

[cesarb]

> mkdir(1) [...] it's so short that it fits entirely on one screen.

296 lines in the main .c file, without counting the headers and helper functions: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...

[carbocation]

And, entertainingly, it contains a FIXME! https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...

[PatchMonkey]

http://www.cvedetails.com/vendor/9237/Sqlite.html

Really? A running 3 years out-of-date sqlite install?

Methinks some hackers smell chum in the water. XSS, remote code execution, priviledge escalation, directory traversal... and for most of these, we even have choices on how to attack! Plenty of overflow attacks involved here. Where are the idiot script kiddies when you need them to demo how this ignorance hurts?

And once in to your sql database, I wonder where else we can pivot...

Remember how shellshock shook the world, because the software bedrock was actually insecure? Yeah... your old, "stable" stuff has had holes the entire time.

Stay current. If your OS makes that a challenge, ditch it for a better one.

[criddell]

mkdir? I'm trying to imagine somebody deciding to no longer use directories because mkdir looks like it's been abandoned.

[tluyben2]

> are close to bugfree

Or bugfree for the use cases of it's users (how many or few there may be).

[MrQuincle]

I've had enough of small utilities that didn't work as expected. Also ls or mkdir can for example be part of busybox ported to a Blackfin. No guarantees that there are no bugs in these by far!

Edit: here you have the source code for the "small" ls utility: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c. Yes, over 5000 lines.

[gizmo]

Your claim was that "there is no software without bugs". I'm pointing out that this is true only in the narrow philosophical sense. You cannot draw a perfect circle, either. But you can draw a circle that gets pretty damn close.

Software cannot be perfect but this doesn't mean that software needs to be shoddy. sqlite is a complex product and it has orders of magnitude fewer bugs than other projects of similar complexity.

It is factually, observably, possible to create software that is very close to perfect, it just takes a lot of hard work. Software has a reputation for being buggy not because it's impossible to write flawless software, but because most software is really poorly written.

[thisacctforreal]

The feature bloat is typical for gnu coreutils; for reference ls.c for OpenBSD, NetBSD and FreeBSD is 614, 716, 933 lines respectively [1][2][3]

[1] https://github.com/Bluerise/OpenBSD-src/blob/master/bin/ls/l... [2] cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/ls/ls.c?rev=1.75.4.1 [3] https://github.com/freebsd/freebsd/blob/master/bin/ls/ls.c

[sillysaurus3]

While this is true, I think all that matters is promptness.

If someone opens an issue, will it get addressed quickly? That's what users care about.

[stuaxo]

Maybe the developer is developing something else and will come back to the first project in time.

[felipelemos]

and from the article itself: "[...] and is pretty stable and bug-free by now."

[tjoff]

Because being maintained is very important for users and one of the easiest and most convincing ways to show that is to release updates.

But then we have the other side, releasing update after update without fixing or responding to common issues. That is quite damaging as well.

[AnIdiotOnTheNet]

> Because being maintained is very important for users and one of the easiest and most convincing ways to show that is to release updates.

It's so true that you never ever see people using decade old versions of software, right?

Users care that their shit works, that's it.

[tjoff]

> Users care that their shit works, that's it.

Exactly, so when that forced OS update broke the software it is kind of nice to know that someone is still around to fix it.

[digi_owl]

Never mind when an update is effectively a rewrite that strips out features/behaviors someone, somewhere, relied upon.

This duality of updates is why people avoid updating.

[mjevans]

Maybe for 'trivial' software that can be the case. However for anything complex even if there isn't a problem inherent in the software there are still interactions with the environment which could cause a need for some workaround.

[lomnakkus]

> Just release when there's something to release.

This emphatically does not work very well for big projects. The problem is human pyschology and the unreliability of all effort estimation processes (in software development). Once people get used to the idea that "well, we'll just postpone the release a little bit" then it eventually becomes a routine thing and for popular projects there's always someone who has a good reason that their particular feature should make it in before the release. (Because who knows when the next release will be?)

The Linux kernel and the C++ ISO standards committee have got this EXACTLY right (since C++11). Predictable releases means:

a) you don't need to rush anything particularly because you know there'll be a new release in N months.

b) any incidental small (not-worthy-of-a-release) bugs get fixed in the interim.

c) downstreams can plan based on when your next release is going to happen.

Predictability is a huge deal and IMO it's incredibly underappreciated just how much it matters. Even if it meant a 10% or 20% 'efficiency' loss (on some metric) I would personally still consider it a win.

For an example of not doing it this way, look at C++ pre-2011 and perhaps also ECMAScript pre-2015. (This is also rampant is development, though no public examples come to mind right now. I'm sure some other commenter can supply some. It's so bad that it can in fact kill projects.)

EDIT: I forgot to mention: Regular updates also means that the "consumer" must get into the practice of regularly applying updates... and will thus become forced to get better at doing that. Ideally to the point of having completely automated updates.

[jcelerier]

Some people just want to stay home and watch movies and live a tranquil life while others don't feel good if they aren't permanently moving and discovering the world.

[CmdrKrool]

Some people want to move and discover the world but can't because their computer is constantly bleating for attention toward make-work 'updates' that really do nothing but bump the version number to reassure the insecure sorts that stay home all the time.

[muzani]

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.

[egypturnash]

Photoshop has a new release every year or so, usually with new features.

[justinclift]

The term "Creeping Featuritis" probably applies to that specific example. And any MS Office release in the last decade or so. :)

[chakalakasp]

Nah, with Photoshop most of the new features are pretty useful. As abysmal as Adobe is with some stuff, they seem to get Photoshop right all the time.

[digi_owl]

DF is also unlikely to be critical to someones workflow or similar.

[kazinator]

Here is an example: old wi-fi router firmware that you can't get updates for is vulnerable to problems discovered in the original algorithms, which are correctly implemented in that firmware.

Software can only be as correct and complete as its specification. If that is a moving target, oops!

[jimmaswell]

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.

[xg15]

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.

[PatchMonkey]

Did you realize that Torvalds did not have anything to do with Linux 2.6.32.70?

He offloaded the whole project onto another team (who mostly backported fixes) that kept it going until early 2016. The rest of us were already in Linux 4.X territory by then.

If you cant maintain it, you can pay someone.

Or, thanks to Github, lets talk about letting the code-literate userbase sort it out themselves. Assuming they care enough.

Or, we could pivot this discussion to the "evils of Capitalism" and whatnot since that userbase probably needs to eat.

[xg15]

This assumes there is a team or a "code-literate userbase" and you trust them enough not to do bad things with your software (e.g. add adverts, tracking, backdoors or miners)

> Or, we could pivot this discussion to the "evils of Capitalism" and whatnot since that userbase probably needs to eat.

Or we could try to back and accept that software could also simply be a tool and doesn't have to be an enterprise.

[asperous]

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.

[digi_owl]

Difference is that buildings etc need to be maintained or else they break down. Sofware, baring weirdness like "bitrot" from unreliable storage hardware, do not break down.

[PatchMonkey]

CVEs, etc accumulate with enough attention. Whether they're published depends on whether your team courts or snubs the security side of the industry.

I wonder how many coders out there don't know about the dangers of global variables in production software, sans obifuscation. Or that can't articlate why an unbounded array is evil, even if the compiler lets you do that.

Seriously... free love was a nice party. But then when public knowledge of STDs arose, the party died down. Today, condom use is on the rise.

Similarly, our free Hobbyist Software love has had a good run. If it dies back, we'll lose a generation of up-and-coming coders. So I guess the message here is jails/containers? Wear your software condoms, kiddies.