Ah, the fun (irony here). Before user-end computing can regain a semblance of sensibility we will need to move towards guaranteed secure sandbox environments for apps that allow historical re-use of earlier versions.
What is happening at the moment is that IMMENSE quantities of skill development and time is continually flushed away everytime Google/Microsoft/Take-your-pick-software-company decides to retire or dramatically rewrite an app. The situation is even wilder in the closed gardens (Android/IOS) and cloud/web-only where perfectly fine software disappears overnight and then.. that's it. Wake up, we're throwing our mental resources down the drain on a completely unprecedented scale because no systemic solution to this issue exists!!
Not really. Notice that grandparent said "the situation is even wilder in the closed gardens". It still exists in open source. Rolling back a set of packages to some older state isn't a trivial operation, and rewrites are incredibly expensive no matter who's doing them.
Open source is a prerequisite, but this isn't a solved technical problem. The challenge is to make codebases rewrite friendly. The bottleneck isn't the rewrite itself, it's all the risk due to the regressions that rewrites tend to cause, and all the stress from trying to catch these regressions before a release. I've been working on ways to express more tests than our current (c 1970) unix stack can support. The goal: to be able to certify a release to production just by running its automated tests. No large projects today meet this standard. Once we do I think we'll be in much better shape to undertake dramatic rewrites, and to reuse code between projects/rewrites.
It's unfortunately hard to make money on your software if it's free. (Assuming your primary interest is making software, not providing support.)
Personally, I'm going to try open-sourcing my retail software a) once sales goals have been met, and b) without the art assets. Maybe that would be a good compromise.
I haven't really seen this done but couldn't Google pour money in to developing very high quality GPL'd libraries for say.. C++ or Python - becoming the defacto standard libraries. If other's want to use them in their closed source projects they'd have to pay licenses to Google, however internally they can use them in their closed source code since they own the rights to it.
The trick would be get that critical mass where competing libraries aren't used as much. Google definitely seems to have the talent and workforce to do it
Anything that makes it easier to develop native software (which 'won't-suddenly-disappear' software has to be) is in direct conflict with Google's strategic interests (Chrome, ChromeOS) and their bottom line.
Isn't this why standards exist? We have standard image formats (jpg, dng). Even standard metadata formats (xmp, exif).
Why can't we have a standard for image libraries, albums, and storage that can work on a smartphone or desktop? It sure would make it easier to roll your own imports, exports, backups. It would be easier to move your stuff when Apple shuts down Aperture, Google shuts down Picasa, you switch smartphone OSs, you decide to quit Facebook, etc. Some XML or some JSON amirite?
If 1 or 2 big players got on board, I feel like others would follow. But I'm probably wrong.
Microsoft seems much better at this than the others you mentioned (or Linux).
Compatability seems like something that the Qubes model could help with quite a bit. Rump kernels can also help by simplifying the OS level interface to where effective sandboxing is possible. Getting safe and convient access to the data an app actually needs is still a difficult issue.
Minus the sandboxing, some package managers are better at this than others, particularly Nix or OpenPandora's PND packages. However, that only helps as long as the OS provides binary compatability.
Even with sandboxing, applications that require network access can be a major security issue. It is no consolation to the rest of the network if your botnet node is nicely isolated from the rest of your system. To fix this, applications need to not directly interact with the network but with other system components that do so and can be updated separately.
OTOH, often the compatibility loss is independent of the application, either communications standards change or expected features change, so being able to run old applications only gets you so much. In those cases, open source can have a major advantage.
What is happening at the moment is that IMMENSE quantities of skill development and time is continually flushed away everytime Google/Microsoft/Take-your-pick-software-company decides to retire or dramatically rewrite an app. The situation is even wilder in the closed gardens (Android/IOS) and cloud/web-only where perfectly fine software disappears overnight and then.. that's it. Wake up, we're throwing our mental resources down the drain on a completely unprecedented scale because no systemic solution to this issue exists!!