In their bib⁄Manifest for Maintenance Art, Mierle Ukeles opposes development and maintenance:
Two basic systems: Development and Maintenance. The sourball of every revolution: after the revolution who’s going to pick up the garbage on Monday morning?
Development: pure individual creation; the new; change; progress, advance, excitement, flight or fleeing.
Maintenance: keep the dust off the pure individual creation; preserve the new; sustain the change; protect progress; defend and prolong the advance; renew the excitement; repeat the flight.
www⁄Permacomputing looks at computational systems from the perspective of the maintainer. It mirrors the prefix “perma-” from permaculture, an approach to agriculture that focuses on the health and resilience of a whole ecosystem, over long spans of time, in contrast to narrower measures of productivity such as output volume that encourage unsustainable practices in the long run. From a computational perspective, this entails “the maximizing of hardware lifespans, minimizing energy use and focusing on the use of already available computational resources.”
This logic can be extended from hardware to software. Not only can software be efficient in its use of energy, it can also aim to be portable and hence maintainable. Software must be executed on a substrate, a computational abstraction on top of hardware. If that substrate shifts from under the software, the software stops running. It must be “ported” to new hardware via a new abstraction. Longevity thus implies constant maintenance.
The easier to port, the more resilient software becomes. Sometimes porting becomes impossible, and then software dies. This is what happened to Adobe Flash, until it was ported to the internet browser (flash.pm). Choosing a simple abstraction on top of hardware, despite being inefficient in short run, is justified from the permacomputing perspective. This is the approach taken by www⁄100 rabbits with Uxn. They write:
Uxn was created explicitly to host software on pre-existing platforms, the design was advised primarily by relative software complexity, not by how fast it could run on new hardware standards. Features were weighted against the relative difficulty they would add for programmers implementing their own emulators.
This philosophy of maintenance-centric software development was best articulated by bib⁄Richard P. Gabriel through the concept of “worse is better”. Simplicity was positioned over correctness, consistency, and completeness, primarily through the lens of long-term sustainability.