Maybe a hint?

Posted Jan 15, 2026 23:15 UTC (Thu) by Wol (subscriber, #4433)
In reply to: Maybe a hint? by rgmoore
Parent article: Debian discusses removing GTK 2 for forky

> and they never think about where they're going to be in a year, much less 10.

Or maybe they HAVE thought about where they're going to be in a year, and the spec says "this software is feature-complete"?

I bang on about truth tables, but if you've done your truth table, and addressed every option, what else is there to do?

Cheers,
Wol

to post comments

Problem with the concept of "feature-complete"

Posted Jan 16, 2026 12:31 UTC (Fri) by farnz (subscriber, #17727) [Link] (8 responses)

The problem with the whole idea there is that you never have a complete and fully explicit specification for any software; there's always parts that are either implicit (and that you may not know about at all, because you meet them accidentally, like "needs to have an attractive colour scheme" when you have good taste in colours), and there are pieces that are time or environment dependent (like "doesn't cost too much in terms of low-end consumer connectivity", which in 1999 meant thinking about how to minimise the number of seconds spent online, and in 2025 means thinking about how to minimise the number of bytes used).

That makes it very hard to accurately declare yourself "feature-complete", because you don't have a complete and accurate spec, and that's a requirement to declare yourself complete.

Problem with the concept of "feature-complete"

Posted Jan 16, 2026 13:59 UTC (Fri) by pizza (subscriber, #46) [Link] (7 responses)

> That makes it very hard to accurately declare yourself "feature-complete", because you don't have a complete and accurate spec, and that's a requirement to declare yourself complete.

You're over-thinking this, applying formal engineering principles to something that ... isn't.

The _actual_ spec involved: "It does what I need it to do"

Granted, there's usually "...without any problems too annoying for me to ignore" implicitly tacked on. [1]

With that in mind, yes, software is quite easily "finished" from the perspective of the person writing it.

...and as I so often point out here, if random other folks out there disagree, they can try to persuade the author to change their mind [2] [3] or fix the problem to their own satisfaction. Otherwise... <taps the sign>

[1] which in turn implies "..and/or worth the effort to fix"
[2] As opposed to "demand / berate / complain / threaten / ... "
[2] I've found that home-baked desserts with a side of cash does wonders.

Problem with the concept of "feature-complete"

Posted Jan 16, 2026 15:49 UTC (Fri) by farnz (subscriber, #17727) [Link] (6 responses)

No, I'm saying that the formal engineering principle of "fully meets the specification, therefore it's complete and needs no further work" rarely, if ever, applies to software, because the specification is itself incomplete in the ways we're both describing.

Now, you can declare that you're not working on this any more (for any reason - not just because you think it's "good enough"), and that's separate. But it's extremely rare (I cannot think of software in this state, not even TeX meets it) for you to have a complete enough specification that you can declare the software "complete against the specification".

Separate to that is the problem with people neither being able (or, in some cases, willing) to fund maintainers doing "no change that I notice", nor to accept "this stops being maintained". At some point, something has to give - either people find ways to fund maintenance that meets their needs, or they have to accept that sometimes, good things come to an end. And in some ways, that's harder with Free software, since at least with proprietary software, the usual way for good things to come to an end was for the company to go bankrupt (with rare exceptions), and thus it's clear why you can't buy it any more, while with Free software, it's people walking away from the project.

Problem with the concept of "feature-complete"

Posted Jan 16, 2026 16:20 UTC (Fri) by pizza (subscriber, #46) [Link] (5 responses)

> No, I'm saying that the formal engineering principle of "fully meets the specification, therefore it's complete and needs no further work" rarely, if ever, applies to software, because the specification is itself incomplete in the ways we're both describing.

Uh, the spec is, by definition, what determines if something has been "completed" or not.

...Whether or not the spec itself is "complete" (according to whom, exactly?) or can ever be considered truly "complete" is an entirely separate issue.

Problem with the concept of "feature-complete"

Posted Jan 16, 2026 17:39 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

No - if the specification is incomplete, then you cannot say if something is completed or not, since when the gaps in the specification are filled in, you may find out that something you thought was correct against the specification was, in fact, only correct against your assumptions.

A specification is complete if there are no gaps in the specification, where a relevant part of the system is not specified, but it's assumed that people's "best efforts" will result in the required outcome happening anyway. In other words, the specification is only complete if, for all things you care about, the specification says (either directly, or by reference) what's acceptable, rather than being silent on that point, and the only things that are unspecified are things where it does not matter to you.

It's very common for specifications to be incomplete - for example, the specification for rewiring a building I worked in did not say that if all switches are in the same position, power should either be consistently off, or consistently on, because there's a local norm that means that most electricians will do that anyway, as a side effect of it being considered part of doing a good job.

And this is a big deal with software, since we have relatively few reference documents that would provide most of a spec by reference; the rewire job brought in around 700 pages of electrical specification by reference to a standard, for example, and still missed something that the building owner cared about, because he didn't even realise that it was something that "should" be specified somewhere. As it happened, there was one set of switches where doing that was relatively challenging, and the contractor didn't bother - he chose to fill in the gap in the specification with his own preferences, and the building owner had to pay to have it redone, but this time with the gap in the specification filled in.

Problem with the concept of "feature-complete"

Posted Jan 16, 2026 20:22 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> No - if the specification is incomplete, then you cannot say if something is completed or not.

I'm sorry, but a "complete specification" dwells in the realm of spherical cows, and as such is utterly irrelevant for things built in the real world.

Problem with the concept of "feature-complete"

Posted Jan 18, 2026 11:57 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)

That's exactly my point - if you're saying that this thing is "feature complete and will never need further maintenance", you're also implying that the specification against which you claim it's "feature complete and will never need further maintenance" is also itself complete and will never need updating.

And I think we'd be a lot better off as a wider software community if we stopped trying to pretend that there is such a thing as a software project that's "completed, will never need further work", and accepted that software that's not maintained is a liability.

Of course, that doesn't force anyone to maintain it - you can abandon anything for any reason - but it does mean that if you're using unmaintained software, you need to be aware that you're taking on that liability.

Problem with the concept of "feature-complete"

Posted Jan 18, 2026 12:32 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> And I think we'd be a lot better off as a wider software community if we stopped trying to pretend that there is such a thing as a software project that's "completed, will never need further work", and accepted that software that's not maintained is a liability.

Ok, congratulations... by your definition nearly all software is "unmaintained" and is therefore a "liability". What's step two?

> Of course, that doesn't force anyone to maintain it - you can abandon anything for any reason - but it does mean that if you're using unmaintained software, you need to be aware that you're taking on that liability.

In other words... the "AS-IS, NO WARRANTY WHATSOEVER" status quo of nearly every software package ever?

Maintenance costs time and money. Taking on liability for something also comes with a price premium. Who's going to pay for those costs? Hint: It's going to be end-users that benefit from said software, not "the wider software community" (which will at best just pass any costs through)

Problem with the concept of "feature-complete"

Posted Jan 19, 2026 15:15 UTC (Mon) by farnz (subscriber, #17727) [Link]

Step 2 is either to arrange maintenance for the software you care about - whether you do it yourself, or pay someone to do it for you doesn't matter - or to accept that the software is at risk of having problems in the future, and you're going to have to address those problems when they come up one way or another. Addressing those problems, in turn, could be "I'll fix them when I know about them", but it could also be "if they hit, I'll accept my system being wiped - my fault for not maintaining things properly".

The key is to stop imagining that non-trivial software can practically be "finished and safe to use as-is forever". Either it's being maintained, and therefore the maintenance work will keep it in "safe to use" condition, or it's not being maintained, and you're at risk of finding a critical bug that means you can no longer safely use it.

It also changes how product liability law in the EU sees offers of free stuff (and is part of why early CRA drafts got things so badly wrong for Free and open source software). Gifting unfinished things is something that incurs liability in part to stop manufacturers having the bright idea of selling you just enough of the product that the free bit is useless without the paid-for bit, while gifting you the rest so it's not part of the paid-for bits. In contrast, it's understood by product liability law that gifting you something that's in what I considered working order at the time I gifted it does not put me on the hook for providing free maintenance into the future.

Maybe a hint?

Posted Jan 16, 2026 13:43 UTC (Fri) by koflerdavid (subscriber, #176408) [Link] (5 responses)

If the tool will be needed for longer than about five years (just ballparking that number) then you really need to consider the software lifecycle of your dependencies as well.

Maybe a hint?

Posted Jan 16, 2026 14:08 UTC (Fri) by pizza (subscriber, #46) [Link] (2 responses)

> If the tool will be needed for longer than about five years (just ballparking that number) then you really need to consider the software lifecycle of your dependencies as well.

The mistake you (and far too many others) keep making is by treating "some random person wrote some software and released it on the internet" as a binding commitment to perpetually support and maintain said software. Worse yet, do so in accordance with <formal software engineering process>. Even worse yet, do so for free.

Maybe a hint?

Posted Jan 22, 2026 10:31 UTC (Thu) by davidgerard (guest, #100304) [Link] (1 responses)

The case at hand is Red Hat, not a single volunteer FOSS developer.

Maybe a hint?

Posted Jan 22, 2026 11:02 UTC (Thu) by farnz (subscriber, #17727) [Link]

If it's Red Hat, then you should be able to negotiate longer support via your support contract with Red Hat.

Else, Red Hat is just another volunteer FOSS developer. They might be a big one, thanks to the money they make selling support contracts for FOSS, but unless you're paying them to fix things for you, they're a volunteer.

Maybe a hint?

Posted Jan 16, 2026 14:25 UTC (Fri) by pizza (subscriber, #46) [Link]

> you really need to consider the software lifecycle of your dependencies as well.

In the case of GTK2, that was *eighteen years*.

Goes to show you that no matter how the support period for something is, it will never be long enough.

Maybe a hint?

Posted Jan 23, 2026 19:32 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

The design lifespan and actual lifespan frequently don't line up very well. As the saying goes, there is nothing more permanent than a temporary solution. The quick and dirty solution turns out to be good enough and is never replaced with the well defined, perfectly executed follow up. We've all seen it happen, so we shouldn't be surprised when it happens again.

I think what this actually shows is that our intuition- or my intuition, at least- about the lifecycle of dependencies is backward. My intuition is that big important projects need to focus on stable dependencies, while quick and dirty ones can use whatever is handy. In reality, big, well-maintained projects can afford to use less stable dependencies because they have the resources to deal with things changing under them. It's the quick and dirty projects that need to be built on the most stable base, because they're going to have to keep working without assistance.