> Yeah, on the surface that stuff always sounds nice because "see, I can run this thing from 20 years ago and I didn't have to do any extra work" sounds nice, but that also means it hasn't been maintained for 20 years...

Some things don't need intensive maintenance, and it's a bad thing to force it for unnecessary reasons. Backwards compatibility can often be understood as 10 vendor engineers performing maintenance effort so 10,000 customer engineers don't have to. It's a massive productivity win for society.

I'm a software engineer. I hate working on ancient codebases as much as the next guy, and I personally benefit from the constant make-work of re-engineering. But, as a customer, I'd rather invest my time and money to solve new problems, rather than spend it re-solving old problems.

This assumes (like everyone else seems to do) that the code was perfect, the APIs that were called were perfect, and that the process never changed. This is almost never the case.

> This assumes (like everyone else seems to do) that the code was perfect, the APIs that were called were perfect, and that the process never changed. This is almost never the case.

The code and APIs will never be "perfect," and many processes change little.

Also, it's a little ambiguous who's code you're talking about: the customer's or the platform's? If a platform that maintains backwards-compatibility is an achievement worth celebrating, because it saves loads of effort across society and give people access to software who might not otherwise be able to afford it. If a platform breaks its customer's code because it's chasing after API perfection, it's kinda abusing its customers.

Yet in reality almost no business software will 'work' on newer versions of a platform be it purely due to licensing, support or version check restrictions. Heck, get a SIMATIC PC and randomly upgrade that 'platform' and watch a whole system stop functioning.

The theory that a platform as 'backwards compatibility' is only good for lazy developers and lost source code. And yes, not doing maintenance saves time, but so does not upgrading your platform. I mean, if 8 inch floppies work for nuclear installations, OS/2 works for subway passenger systems, and Windows 3.1 for radio servers and other flight control systems, might as well not maintain anything at all. Heck, why not use relay logic in the subway control rooms.

> might as well not maintain anything at all.

I think the issue here is that you're viewing this as too all-or-nothing. If the OS/2 subway software is well-tested and does everything it needs to do, what's the benefit of spending $10 million rewriting it or paying a guy to keep up with platform changes? If IBM (or whoever owns it now) keeps maintaining OS/2 so the software can run with little to no modifications on new hardware (since hardware fails), good on them. There's probably 1,000 such systems, and that's $10 billion in savings for society.

That doesn't mean no software should actively be maintained, a lot of it should. It also doesn't mean that working old systems shouldn't sometimes be replaced or upgraded. But it does mean backwards compatibility is important and shouldn't be dismissed.

This looks like very idealistic approach. The world does not revolve around perfectionist's wishes.

As for "...means it hasn't been maintained for 20 years..." - the OS did maintain the old API's and the way they behave to make sure old software that uses said APIs still works on new OS. Does not mean that the new APIs were not developed.

With complex formats, you can make them as open as you'd like and nobody is going to get it right but you. See the Office Open XML format.