>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target.
Actually, some software are running the water-heater/heat-pump system in my basement. There is a small blue light screen, it keeps logs of consumed electricity/produced heat and can make small histograms. Of course there is a smart option to make it internet connected. The kind of functionality I’m glad it’s disabled by default and not enforced to be able to operate. If possible, I’ll never upgrade it. Release then go back to the cave has definitely its place in many actual physical product in the world.
I’ll deal with enough WTF software security in my daily job during my career. Sparing some cognitive load of whatever appliance being turned into a brick because the company that produced it or some script-kiddy-on-ai-steroid decided it was desirable to do so, that’s more time to do whatever other thing cosmos allows to explore.
There's an anecdote I remember reading somewhere: When an 'embedded systems' engineer was to present a web-based product they were tasked to build, the managers/reviewers were puzzled they couldn't find any bugs. Asked about this, the engineer replied: "I didn't know that was an option".
Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "quick fixes" from the web.