I would like to say something from a somewhat disillusioned "FOSS agnostic" perspective. It's not about the cost or workload, but the imagined premise: that we

I would like to say something from a somewhat disillusioned "FOSS agnostic" perspective. It's not about the cost or workload, but the imagined premise: that we are making software that "the user controls". Well, we already failed at the user being in control if the software developers are being asked to do things all the time. Or rather, the control experienced is either "the developer is servile" or "the user goes out of their way to make modifications". The balance most often struck when the project has full-time maintainers is "a corporation, not a human, is the user". Further, there is an overwhelming tendency for the software stack to move directionally around a few of the largest dependencies. Old FOSS software can be downloaded and often built, but it becomes obsolete in subtle ways as the ecosystem assumptions change - dependencies deprecate in newer versions, protocols and interfaces change. And the more the software tries to leverage open ecosystems at the top of the stack, the faster it is likely to fall out of date. Languages are adopted not because of the language but because of a library that solves a hair-on-fire issue. The herd is stampeding. Put in other words, there's a growing tension between "open" software qualities and "archival" software qualities, which has gotten me more engaged with retrocomputing again. I've picked up Forth, this time not to make a Forth(the common mode of engagement) but with an eye to doing small applications in it and using its compilation abilities to create precisely the abstractions I need; my goal is to stop talking to other software so much and to talk to I/O more. If I stick to that, and write a system that only builds from the tiny core that is "the computer language" (as Chuck Moore calls it), the software will archive easily. There are some key limitations to the Forth model, where it rubs up against modern protocols, which, to the Forther, are always gratuitously complex. But addressing this limitation in the moment is mostly a matter of walking over to the stack de jure and writing the same clumsy glue code everyone else is writing every day. There is an additional problem of there being no guarantee that I'd end up with a system that the user agrees that they can control - a common complaint levelled at Forth, Lisp and other "extensible" systems - but this is potentially a good application for generative AI. Provided I can sufficiently instruct the AI in the system's operation, it can satisfy both minor maintenance and documentation roles.