Just need to vent...

It's not even so much the $ that makes the difference for me. I'd be willing now and then to pay for commercial software, if they would take my money and hand me the software. If I didn't know full well that by paying them for it I am volunteering for the kind of headaches Mendel is having.

 

The other Oddity about older Photoshop/ adobe acrobat versions is that they no longer support it anyway.

 

That's sort of my point. I kind of doubt that anybody bothered to check whether these old versions would be swept up in a remote shutdown, because it's old and abandoned.

I mean think about it, if the last meaningful revenue you got from your customer was ...13 years ago? are they still really a customer you need to care about? Of course, they need to honor the license they wrote, but that's all.

 

Living overseas may have oddly different foods but it’s what comes in or on the foods that can be a real local experience.

 

I understand both sides of this issue, actually.

I loathe Adobe like a Southern Baptist preacher hates rowdy bars.
This comes from the fact that I was forced to use FrameMaker about 30 years ago on a gubmint project.
It was eye-wateringly expensive and about as intuitive as CalvinBall AND I knew when the project sun-settled that I would retain nothing useful from having slogged my way through it except for the paychecks.

BUT....as life itself should have its seasons software product support should have expiration dates.

One of the things that I hate to love about Apple is that they don't victimize their customers by forcing them to buy a 'new and improved' OS every five years or so.
They do that with their hardware if you want a specific single feature or the latest gigapixel camera, but they're also happy to sell their "SE" flavors to the unwashed masses and keep them working for 7-8 years for for their phones which is about as long as one would expect them to remain technologically viable.

There are about a zillion fairly capable graphic editors in the Linux world but for those that are stuck in a walled-off garden:
Best free Photoshop alternatives for Mac

 

As I hardly ever call for support on software products I use, I mostly wouldn't even notice when the software product support expires.

However, I don't agree that software itself, once acquired, should one day stop working, as long as it's still being used on a compatible system.

Sure, if I upgrade the OS and they've deprecated some API the software was using. Or if I migrate to another box with a different instruction set. Can't expect the software to keep working then.

But even then, if run in a VM that looks like before, I'd expect the software to go right on working.

 

I have the same gripe with hardware support. I have a USB Ethernet NIC dongle that I used when the WiFi was unreliable at school. It was just two months old when my PC was upgraded to Windows 10 and there was no driver available from the vendor (Cisco). They offered no compensation for making my HW worthless and I had to buy another one from a different vendor. Cisco is now a vendor whose products I will never buy, but then again I am running our of companies whose products I will buy as many of them misbehave.

JeffD

 

Well, sometimes there's no helping it, say if you've installed an OS update and the OS people have decided some API in the old version was hopelessly flawed so they disabled it in favor of some new, better-designed API, and your software uses the old one. Then you would ideally want an upgraded version of the software that uses the newer API.

Still, I'd want to be able to spin up a VM on the older OS version and still be able to use the software there. After thinking about any risks. Maybe the OS changes were to plug a security hole, so I want to restrict what that VM can do or where it can connect, and only use it locally.

But yeah, some commercial software licenses have even had terms like, if you upgrade your machine to one where the hardware runs faster, you owe the software vendor more money for the software you already bought. Because it's faster now.

I'm allergic to software with terms like that.

 

I am not computer literate - but - I always wondered why Microsoft and other makers don't make their software backward compatible to include earlier technology/software - unless it is just laziness or greed.

Apple seems to at least take backward compatibility into consideration in their product Developoment.
I believe Microsoft made an economic consideration to go to subscription and no backwards compatibility.

My impressions may be due to my lack of knowledge on this subject

 

Sometimes the vendor has no real choice—as when some API in an older OS version has been discovered to have a flawed design with a gaping security hole and the only thing for it is to release a new OS version where that API doesn't work anymore and there's some replacement for it that doesn't have the flaw. Too bad for your old software that was written to use the old API.

I don't think it's usually pure greed. Laziness, sometimes, sure, say if there was an old API that wasn't a glaring vulnerability, so they didn't have to make it stop working, but they realized there were some things that just couldn't be done that way, so they introduced a newer API without the same limitations, and then they ask "how much harder will we have to work to keep maintaining the old one forever alongside the new one?".

 

Not supported. Artificial end of life restrictions. This IS my strongest gripe. Especially when the company that complains about the cost of support makes billions of dollars per year.

Once upon a time I provided the full lifecycle of software management from requirements analysis through keeping up with OS changes after the software was no longer being marketed. Through our research and planning we found that the cost of making upgrades to software packages was not as expensive as it appeared to be. Providing technical support after end of life was problematic but the reality was that company IT departments need technical support ; the individuals within the company seldom, if ever, talk to tech support provided by a company like Adobe or Microsoft.

I suspect that it would cost Microsoft very little to make sure that the authorized API library used by Adobe in 2012 was still working the same when they force people to upgrade to the next version of the OS.

Good design and proper practices keep the impact of changes minimized. If you paid for a software package, there is no reason that it should ever need to be retired. That's why we still see schools using COBAL based software that was developed in the last century.

Given my way, I'd insist that any software that is abandoned due to claims of "too hard to maintain" should be made public domain and all documents should be turned over to the public to repair all security problems.

 

The purpose for using an API as the gateway into the OS functions is simple. It allows the application programmers to write code that interfaces to the OS via code that is not supposed to change in function nor in the data structures that are passed back and forth between the application and the OS. If a developer group is replacing one version of the API with an incompatible version, the dev's are not doing their job properly.

According to the European Courts, Microsoft's main reason for changing the API is to prevent compatibility with 3rd parties and forcing updates to otherwise usable software.

How much harder do you have to work to maintain the old version of an API or application forever alongside the new one? It depends on how you define "maintaining the old version". That's supposed to fix only the security problems or problems that cause system / application crashes. It's not supposed to include changing the old code to add new features that were not in the original.

The last time I froze a program and released it to the public domain, I turned the code over to another person so that he could make the changes that he felt were needed. I made no changes to the 1.3 version in the last 30 years despite the fact that some people still opt to use that version. The person who went on to create a branch ( version 2.0 ) to meet his view of the world died a few years back. His version is also still in use, and the only update is the web site where he was maintaining the code. The advent of Amazon's Alexa has largely made my software unnecessary.

 

We agree that's the objective. We might not agree that it is always achievable in every case. Sometimes it genuinely happens, for example, that the original API designers did the best they could, and thought they had devised an interface for the ages, and then, possibly years later, a security researcher discovers a fundamentally unfixable way to exploit it to accomplish a breach, and so a replacement API must be designed.

How the development team responds to that could have stages. They could start by adding the new API alongside and strongly deprecating use of the old one, hoping actively-developed apps will take the hint and start using the new one. The devs could start adding runtime warnings that pop up anytime an app uses the old one, saying you have an unsafe version of an app. They might leave it that way for some span of years, and then just quit having the old API work at all. Those are difficult judgments that get made case by case, sometimes taking into account both the severity of the possible exploit and its ease of exploitation.

And then there are other situations where a new API just allows doing some nice new thing the old one didn't, and they can go on supporting the old one alongside it forever at trivial cost. Often it won't take anything more than reimplementing the old calls so they work by calling the new ones. Those cases are easy.