Companies who cannot upgrade their codebases are companies who cannot maintain their codebases.

Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will.

(small and non-notable exceptions for the literal handful of types of orgs where this is not the case)

True, but is there a situation where upgrading will hurt instead of benefit?

Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme.

For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, they simply have different opinions on what is valuable than you do.

It

Yes, upgrading is an engineering expenditure like any other. If you devote manpower to maintaining your codebase you're not devoting it to user-facing features. As such, upgrading your codebase can hurt your ability to deliver some priority feature on-time.

But that kind of zero-sum thinking is myopic. My whole point is that if you only ever prioritize feature work, eventually you lose the ability to deliver features. Nobody in their right mind thinks you can have a company with zero technical debt, there's always a balancing act in play, but if your managers are just playing the risk card without, you know, doing an actual risk analysis which includes the risk of not being able to deliver future features, then your company isn't making smart decisions.

Now, there do exist codebases where you can make the logical conclusion that there really will not be any future feature work, but it's still running in production and so it will need support, and it's a fairly large codebase, and so there would be an enormous cost to re-certifying for the upgrade with very little apparent benefit. That happens, but it only (really, truly, only) happens in large enterprises with many, large codebases and only so many engineers. Those enterprises do have the resources to hire new employees and/or outside contractors to pay down the technical debt on these half-alive projects - they just aren't prioritizing those resources on the technical debt, even long after it became clear that the clock couldn't be stretched out any longer. Through painful personal experiences, I have zero sympathy for companies in that position who think that they can solve their problems with more firewalls.

That's right, but...

It seems to me that all counter-arguments I get ignore the context that I set which is to not do things "simply because you have the money".

What I get is "hey, you have the money and it's obviously the right thing to do so do it".

"Having the money" is orthogonal to "it's the right thing to do" but this thread is too old to recover.

There is cost the individual user of an open source project has to consider, and there is cost the community of that project as a whole has to consider.

So from your perspective, just keeping the old version might be "the right thing to do", and at the same time the decision of the community to not support it anymore is also "the right thing to do" from their perspective.

As the community does their work unpaid, it seems you have no right to impose your perspective on them, except if you pay money for the necessary work. Which you are free to do.

I guess what the parent posters point out is that this will usually shift your own cost/benefit ratio in a way that upgrading becomes "the right thing to do" for you, too.

s/security/bug

I don't think that centos 6 is bug free yet it EOL in 2010 too.

Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox.

My client won't upgrade. They pay support, expensive support, to keep their old version.

In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't migrate.

Sometimes I wonder if the opensource movement, with its perennial “update anxiety”, is actually busy generating an industry of legacy maintenance. In a way, it’s a natural extension of the original “development is free but you pay for support” idea, but I don’t think anyone openly elaborated it into a long-term revenue-generating strategy. It looks like a slam-dunk, to be honest, with the only caveat being that work is extremely unfashionable.

It's not the opensource movement. It's IT in general. A lot of software stopped working with the windows 10 update that was forced on the users.

Android breaks the API regularly by changing the permission game.

The PSF has limited resources (3 million of dollar of budget) to exists (this includes running pypi and organising pyconf), but I think it's track record is quite good, even comparing to commercial products.

Actually, Android doesn't break the API, even by changing the definition of permissions. If you have a breakage, investigate your app manifest, what API version you are targeting. Android frameworks shim the old behaviors for the apps that declare the use of the old API versions.

E.G: Since API Level 19, the Alarm system has been completely remade. One must check the API Level to act some how or some differently. The same is for permissions after the advent of Android OS 6.0+. But we still need the support library to give Fragments and the ActionBar to API Levels lower than 11. And VectorDrawables to API Levels lower than 23. And many more objects.

It's not that simple.

The shims are managed by targetSdkVersion, i.e. if you declare targetSdkVersion >= 23, you will get the new permission system (because it was introduced in 23) if running on [23,maxSdkVersion] device; if it is running on device that has API level [minSdkVersion,23), you get the old one; if you declare it < 23, you will get the old one, always, on newer devices too.

The targetSdkVersion says what you designed against. If you claim supporting the new API, you should handle the new API (and that includes detecting what the underlying device supports). That does not preclude you from including the support library needed for lower API levels still supported.

Except if you release a new/updated app, it MUST target a recent (less than a year) targetSdkVersion.

"2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher."

https://android-developers.googleblog.com/2017/12/improving-...

That's Play Store policy for new apps and app updates, not a technical limitation of the OS. Old apps will keep working just like they did before, the new APIs will not break them.

the old trick is to get your changes to the main branch so you dont need to maintain your it. that is also why anyone bothers to do so in the first place

More power to you, but my initial argument was contingent on "for your definition of works".

Eventually, your client will see that money spent on maintaining old (more appropriately rusty) packages will better be spent on upgrading.