[Wiggins]: Even thinking of a binary artifact, you've got a compiled executable, you can download it, you don't need to the dependencies, you don't need the compiler chain and I think there's the feeling that “shouldn’t that work forever?”. But of course as you said it sits within this context of the system: if it's accessing files on your file system, it's calling out to APIs on the network, it's accessing APIs in the operating system. Even something like it just makes assumptions about what kind of hardware exists, the keyboard and mouse has being standard input devices that exist and then you go onto a touch device and those aren't there. So over time, those fundamental assumptions and apis and the system changes around it and I think that's gotten dramatically more so with the internet, where you might call out to even something as simple as a static website, that has a Google Maps embed, well, now a big portion of that website is dependent on this exact integration to the service and that service is still online. So I think that the one-off binary build, shouldn’t-it-work-forever does make some sense in, for example, games, which don't have as many hooks (let's say just like a single player game, not some complicated cooperative thing) as it tends to have very simple inputs and outputs, displays things on the screen, maybe it needs to save a high-score file to the disc, as opposed to productivity software where all those little integration points: you drag and drop and how do you open a thing in the browser and all the different apis that are used to be a good citizen on the system, and those change all the time - they should with an operating system that's growing and improving and evolving - but then that means the apps have to keep up with that. And if they don't, they fall out of date. And eventually either become somewhat irrelevant or more commonly just stop working. [McGranaghan]: Yeah, I think this idea of the complexity of the surface area and the APIs is very important. You mentioned games: I think we actually had it much easier back in the good old days of games where we had keyboard input, mouse input, you draw to a pixel buffer, and that's it. The issue with games now, in addition to stuff around networking and multiplayer is that the graphics pipeline is incredibly complex, and unless you end up emulating earlier versions of graphics pipeline there's little chance this stuff rolls forward, whereas you could plausibly roll forward writing into a pixel bus offering. You kind of go the other way - you can emulate a pixel buffer with our advanced graphics APIs today, but there’s no chance of going the other direction. I think this generalizes to API complexity broadly and it's one of the reasons why it's so hard for software to persist Wiggins and McGranaghan, Metamuse Episode 49, Software Longevity, 13:12, https://open.spotify.com/episode/1DCNy94TBt3aoGbM8PNlRv?si=ST_DRl-YQ3W4nxTMYYOD3w

[Wiggins]: Now another one from games that maybe is your roll-forward idea, I really like what id Software does, which is they take their classics - Doom, Quake and so on - And after I don't know if they're 20, 30 years old, something like that, they open source of them, and that creates this interesting effect where maybe it's less that people are playing the original, although I'm sure that happens, but then it becomes fun to just port it to weird places. Like you've seen Quake that's been ported to be 100% ASCII. I also saw a Twitter thread recently where someone managed to open one of these digital pregnancy tests, realize that it had a reasonably good processor and display, and decided to get Doom running on it. […] So in a way that has turned this over to remix culture and the internet and so it gets rolled forward and become something that maybe people will experience not in its original form necessarily, but becomes woven into the cultural tapestry let’s say through these fun little projects. [McGranaghan]: I think this also speaks to the importance of that API environment they were talking about earlier being specced or at least speccable for the software to be rolled forward or actively preserved. […] Old-timey games, that's a pretty speccable environment, like needing to be able to compile C, and relatively straightforward input and output system, and even if the games weren't designed specifically with a really clean interface there you can basically back it out after the the fact, and then do the porting. Books and paintings, by the way, are examples of analog things that are very speccable: they map down to text streams and bitmaps respectfully. But stuff like modern software is much more difficulty being specced, and so it becomes harder to do that sort of rolling forward act of preservation. Wiggins and McGranaghan, Metamuse Episode 49, Software Longevity, 16:40, https://open.spotify.com/episode/1DCNy94TBt3aoGbM8PNlRv?si=JYEnhTUbSPCutemfh9wI-A

One thing we've alluded to is idea of narrow-defined APIs, because your software has to run in something, and the broader, the more complex, the more ill-specified that environment is, the harder it's going to be to do this job of keeping the software running. And this would include things like taking on few dependencies, minimizing weird binary dependencies that are hard to compile, limiting the APIs that you access, things like that. McGranaghan & Wiggins, Metamuse Episode 49, Software Longevity, 26:39, https://open.spotify.com/episode/1DCNy94TBt3aoGbM8PNlRv?si=-2-SDcZXSUaI6iFWTO7eDg