Collapse the distinction between user and programmer
The apartment-house tenant must have the freedom to lean out of his window and as far as his arms can reach transform the exterior of his dwelling space. And he must be allowed to take a long brush and - as far as his arms can reach - paint everything pink, so that from far away, from the street, everyone can see: there lives a man who distinguishes himself from his neighbors, the pent-up livestock! He must also be allowed to cut up the walls and make all kinds of changes, even if this disturbs the architectural harmony of a so-called masterwork, and he must be able to fill his room with mud or children’s modeling clay.
But the lease prohibits this!
The time has come for people to rebel against their confinement in cubical constructions like chickens or rabbits in cages, a confinement which is alien to human nature.
Friedensreich Hundertwasser, 1958
Mouldiness Manifesto Against Rationalism in Architecture
A delightful provocation. What kind of architecture might emerge from this ideology? A colorful patchwork riot.
There is something human about this dream of having read/write access to your environment. It opens up risks, and also possibilities — the possibility of self-determination, to build for your own needs. It is an evolutionary, anarchic, messy mode of living. It also feels like a spiritual cousin to Ivan Illich’s notion of convivial tools.
What else can we say about this Hundertwasser flavor of design?
The resident has access to the same tools as the architect.
Everything is writeable, everything is rewriteable.
People can solve their own problems.
Unexpected solutions can emerge. Solutions can be evolved for local fit. New ecological niches can be constructed. Categories can be defied, invented, and reinvented.
The result feels messy, but also lively, and lived-in.
The resident has access to the same tools as the architect. This feels like the key enabling condition for Hundertwasser. It collapses the distinction between resident and architect.
What if Hundertwasser, but for software? A few examples I can think of…
SmallTalk emanates powerful Hundertwasser energy. Everything in SmallTalk is composed of programmable objects, all the way down to the operating system primitives. A user can pop the hood on anything—application, window, button—and modify the underlying behavior. New apps can be constructed by forking and modifying old apps.
HyperCard was a hypertext system with a card-and-deck metaphor. Cards could contain scripts that would allow you to define new behaviors. These simple primitives allowed users to construct for themselves anything from CRMs to RPGs.
HyperCard shipped in 1987, a few years ahead of Tim Berners-Lee’s first web browser, in 1991. It had some similarities to browsers, and a design that assumed end-users would be both using hypercard decks, and building their own decks. Yet, it was local-only, and decks were distributed on floppy disks, rather than over a network. Hypercard inventor Bill Atkinson:
I thought everyone connected was a pipe dream. Boy, was I wrong… I have realized over time that I missed the mark with HyperCard. I grew up in a box-centric culture at Apple. If I'd grown up in a network-centric culture, like Sun, HyperCard might have been the first Web browser.
A wonderful alternate universe to imagine!
Spreadsheets were one of the first breakthrough software tools, and continue to be critical software infrastructure. Spreadsheets don’t have much opinion about how they should be used. They offer only a small alphabet of features: cartesian grids, and formulas. This simple alphabet has a spectacular range of motion. It powers our financial system, and anarchist mutual aid networks, too. I wonder how much of the total value generated by computers is attributable to spreadsheets?
Minecraft is built around one ideas: blocks. Every block is the same size, and they can be composed in two ways:
You can place blocks on other blocks to build structures
You can craft blocks with other blocks, to create new kinds of blocks with new properties.
The first kind of composability allows players to build structures together.
The second kind of composability allows players to unlock new behaviors. Although the set of block types is finite, they interact in different ways (water douses fire, etc). Together, these interactions create an interaction language that players can use to build surprising interactive systems.
Minecraft’s designers pushed this idea to its wonderful logical conclusion, with redstone, a type of block that acts as a switch, and can be pieced together to form logic gates, and functional in-game computers.
Modular synths construct music by composing sound wave transformations. Each module transforms the sound wave in a different way. By plugging modules together with wires, you can build up incredible sounds, even systems that generate music by themselves.
A few more: CAD, Blender, Roblox, Scratch, MaxMSP, many “protools” for audio production, video production, 3D.
What patterns can we see in these examples?
First, each of these examples gives users access to building materials that are open-ended enough to allow for the construction of new workflows.
Each also supports composition. A sequence of actions can be combined into a new feature through some sort of composable interaction alphabet:
Modular synths can be composed through sockets and wires.
Spreadsheet ranges can be composed through formulas
HyperCard features can be composed through end-user programming.
This is a level of expressivity beyond the limits of a typical GUI, which constructs workflows through sequences of discrete user actions over time, and has no mechanism of composition.
At the furthest end of open-endedness is software, like SmallTalk, that gives users access to the very code used to construct the system. This shift has similar implications to Lisp’s powerful notion of homoiconicity:
One advantage of homoiconicity is that extending the language with new concepts typically becomes simpler, as data representing code can be passed between the meta and base layer of the program.
Likewise, when a system is defined in terms of itself, it is possible for those living within the system to rewrite the system to meet their needs. When a system is defined in terms of itself, it becomes maximally open-ended.
To build maximally open-ended software, collapse the distinction between user and programmer until these labels no longer make sense.