I'm very confused. What does it matter, for running old software, whether a framework was a fad or not? And what does a "brittle" dependency even mean in the context of preserving software?
If you're trying to preserve software, you've got two options.
One, you can preserve the binary and run it with emulation. For webapps, this means preserving a deployable image. Your faddish/brittle dependencies are 100% irrelevant, because your image includes them already, right?
Or two, you can preserve the source code. Which for any project is going to involve a mess of complicated tooling that dates to when the project used to be compiled. But if you're intending to preserve something for the long term, you should preserve the dependencies too -- e.g. node modules or whatever. Or else you're gonna have to track down the packages used on a certain historical date, just like you might have to track down some random specific version of a Borland compiler that ran on a certain version of an OS.
License servers and downloadable content. Roughly 2005 is about the time when these started to become commonplace because developers began to assume always on Internet for applications that didn't have obvious network dependencies. So even if you have installation media, that media may not have everything needed and will likely not have patches for significant bugs that were discovered after it was pressed or the installer was downloaded. I think that's why the author picked 2005 as the cutoff point: prior to then, if you had the installation media / package, you could usually install and run it offline. Likewise, any subsequent updates could usually be downloaded 'outside' of the application and applied manually.
My favourite iOS game from when I was a kid is no longer actively developed and as a result it was removed from the app store because it doesn't work properly on new devices.
Its perfectly understandable why this happens but its a shame there is no way at all to play this game other than finding an old ipad that still has it installed where as old windows games still work fine.
I have a tablet I'm scared to mess with because it has a copy of the Android port of Frozen Synapse, and the game has since disappeared from the Play store.
That's the problem of DRMed stores, not a problem of older games per se. For instance, GOG specialize in restoring old games, as long as they are DRM-free. Apple simply never cared about preservation use case.
Don't support DRM with your money if you care about this.
Its not just drm in the way. Even if I had a copy of the app I wouldn't be able to use it because no device I have could run it. Its the fact that apple doesn't give 2 shits about backwards compatibility. Which is not entirely a bad thing but it means games will all eventually be unplayable.
I feel like this has happened to an entire category of games, broadly defined as "Games you can pay for and play".
Those don't exist anymore. The only games that get released now are "Free games that you pay to make less annoying, repeatedly".
There was a point around iOS8 where studios started scrambling to modify their games from the first category into the 2nd. So previously complete and balanced games like Civilization Revolution started getting new wonders and leaders that you could pay for (that the AI gets for free). Fortunately in that case, they released a completely separate Civ Rev 2 that was built with that crap from the ground up so they didn't need to finish ruining the first one.
But they certainly aren't about to release compatibility updates for those old games, so I keep an old iPad Air with a cracked screen around and carefully navigate the upgrade nag screen every single day to keep it safely on iOS8 so that the last handful of good mobile games remain playable.
One dead battery or mis-tap on the upgrade screen, and they'll be gone forever.
I bet a lot of ios games are gonna slip through the cracks. Take the general lack of giving a damn with regards to archiving their source that game companies have, and multiply that by having the games distributed entirely digitally - and limited space on phones/tablets/etc that means people tend to delete old games that don't get updated.
Also largely the reason we have such complete archives of old console games is because of piracy. Back when they were new games no one cared about copying them and building emulators for archives, they wanted to distribute them and as a result ended up with an archive. Most iOS games are so cheap that piracy is not a concern and there are so many games that your favourite one probably doesn't have a huge fanbase behind it.
As a rebellious young nerd, at some point I realized that my piracy was more akin to/aligned with collecting/preserving content as I consumed just a fraction of it but still derived joy from the acquisition and storage.
Of course, once I got a job as a developer I paid for everything (too much, really... my unplayed Steam collection keeps growing!)
I do not share your optimism. The main post says that you can do this for code up until ~2005, but not since then, and I would tend to agree. Also, many of the games require access to servers, which are no longer running, and even if you could get access to the server code, you wouldn't legally be allowed to run one yourself!
You're basically saying that preservation is easy if the original developers took preservation into account. The article is making the point that developers and ecosystems increasingly don't consider preservation ahead of time.
> One, you can preserve the binary and run it with emulation. For webapps, this means preserving a deployable image. Your faddish/brittle dependencies are 100% irrelevant, because your image includes them already, right?
And what if the software's build artifacts aren't binaries or deployable images? Many projects (most, I suspect) don't output either.
> Or two, you can preserve the source code. Which for any project is going to involve a mess of complicated tooling that dates to when the project used to be compiled.
Well sure, but some projects have more mess than others. That's kind of the point of the OP.
> But if you're intending to preserve something for the long term, you should preserve the dependencies too -- e.g. node modules or whatever.
And if you made the decision to preserve the software long after it was initially developed, what then? Most people explicitly don't put their node_modules folder in version control.
> I don't really see what's all that different.
What's arguably different is that many of the currently popular ecosystems don't really value long-term maintainability, stability, or preservation to the same extent as the popular ecosystems of yesteryear did. Projects in these ecosystems can end up broken on a much shorter timeline than in other ecosystems. Project breakage also has a way of causing cascading problems.
I'm not sure why you're confused, you seem to have a good grasp on the solutions to these problems. Perhaps you're unaware that it's common practice not to implement those solutions ahead of time, and that is exactly what the OP is complaining about?
It's not just the source code, it's also the tools to edit/build it, the directory structure, the operating environment (OS, network shares, servers) and more.
Example: You can still buy a copy of Visual Basic 6 on eBay. Does your laptop even have an optical drive to install it? Do you have the patches that were released for it?
If I wanted to preserve software, I would just upload it to the Debian archive. Then it and all of its dependencies down to the bootloader will be preserved in both source form and binaries for multiple architectures for as long as the Debian snapshot archive is around. Also, Software Heritage would archive the source code of it.
If you're trying to preserve software, you've got two options.
One, you can preserve the binary and run it with emulation. For webapps, this means preserving a deployable image. Your faddish/brittle dependencies are 100% irrelevant, because your image includes them already, right?
Or two, you can preserve the source code. Which for any project is going to involve a mess of complicated tooling that dates to when the project used to be compiled. But if you're intending to preserve something for the long term, you should preserve the dependencies too -- e.g. node modules or whatever. Or else you're gonna have to track down the packages used on a certain historical date, just like you might have to track down some random specific version of a Borland compiler that ran on a certain version of an OS.
I don't really see what's all that different.