Malleable Software

Software the user can reshape — not only configure, but bend, recombine, and re-author — long after the original developer has stopped paying attention. The opposite of the sealed app.

Spreadsheets are the strangest piece of software most people use. A secretary in 1985 with no programming background could open a blank grid and, by the end of the afternoon, have a working invoicing system that her employer depended on for the next decade. The thing she built was not a report or a document. It was an application — small, ugly, exactly fitted to her work — and she did not need permission, an SDK, or a release cycle to make it. Whatever it is that lets a spreadsheet do this, almost no other class of software has it.

I want a name for the property the spreadsheet has and most other software lacks, and the one I have settled on, following Ink & Switch, is malleability. Their essay Malleable Software is the cleanest recent statement of the problem, and Geoffrey Litt’s earlier work on Wildcard and end-user web customisation gives it practical edge. The longer history runs through Smalltalk, HyperCard, Emacs, Lisp machines, Engelbart’s NLS, and the early visions of Ted Nelson and Alan Kay — most of which imagined an ordinary computer as something the user could open up, modify, and put back together while it was running.

What “malleable” picks out

Malleability is not configuration. Configuration is choosing among options the original author anticipated. A truly malleable system lets the user do things the author did not anticipate — add a column the schema did not plan for, write a small rule that fires when an event the author never named occurs, glue two unrelated tools together by treating both as material rather than as products.

Nor is malleability the same as being open source. A program can be nominally hackable — the source is on GitHub — and yet require so much context, build infrastructure, and architectural archaeology to modify that the average user never will. Malleability is open source you can exercise without leaving the running program. It is what HyperCard had, and what most “extensible” SaaS products notably do not.

The cleanest test I know is this: can a user who is not a professional software developer, but who is fluent in her own work, change the behaviour of the system in a way the system’s author did not foresee, in the same session in which she noticed the need? When the answer is yes, the system is malleable. When the answer is no — and for almost all contemporary software it is no — the user is at the mercy of a roadmap she does not own.

Why software became rigid

The slide from malleable to sealed is not, I think, a story about malevolence. It is a story about incentives, security models, and the particular shape of the cloud era.

Mass-market software needs to be supportable, which means its surface area must be small enough for a support team to know. SaaS economics push software toward a single canonical version controlled by the vendor, which in turn pushes user customisation off the device and into the vendor’s configuration screens. Mobile sandboxes, with good reason, made it hard for one app to reach into another. Each of these pressures is defensible in isolation; together they have produced a generation of software that is intimate without being yielding — present in every part of life, but rigid as glass.

The result is that a programmer in 2025 has a more malleable computing environment than her users do, and a programmer in 1985 had a more malleable computing environment than the programmer in 2025. The arc has not bent the direction one might have hoped.

Why now might be different

The most immediate cause for cautious optimism is Local-First Software software. Once an application’s canonical state lives on the user’s machine in a format she can inspect, the door to malleability is at least propped open: she does not need the vendor’s permission to point another tool at her own data, and she does not need to be online to do it. This is not yet malleability, but it is the substrate without which malleability is not really possible.

There is a second shift, more recent and more uncertain. The cost of writing small programs has collapsed. Large language models are mediocre at building cathedrals and surprisingly good at building shacks — the kind of three-line script, ten-cell spreadsheet, or one-screen tool that an ordinary person used to need a friend who programmed in order to obtain. If a user can describe the rule she wants in plain language and get a working approximation back, the question of malleability shifts from can she program to will the software let what she programs in. The bottleneck moves from the user’s skill to the host’s hospitality.

Open questions

I am most interested in the design of host environments — the spreadsheet, the document, the workspace, the personal database — that explicitly reserve room for end-user authorship without becoming professional development environments in disguise. The spreadsheet’s genius was not its formula language; it was that the formula language lived in the same place as the data, ran immediately, failed visibly, and could be ignored entirely by users who did not want it. Almost every later attempt at end-user programming has missed at least one of those properties.

One question is about the structure of the extension surface itself: how to keep it stable enough for users to rely on, without freezing the underlying system that the surface depends on. A second is about errors — what good messages look like when the author of the offending code is the user herself, mid-task, and the goal is to recover rather than to debug. There is a transmission problem too: how should a small user-built tool travel to a colleague without the friction of shipping software, and without falling out of the host environment that gave it its meaning? The new authorship surface raises its own version of an older worry — can AI-assisted writing of small tools preserve the spreadsheet’s transparency, where the user can always read the rule she asked for, or does the model become another opaque layer between her and her own work? And there is a question I think about least clearly: what a return path from an end-user tweak back into the upstream product would look like, so that good local fixes could become good global ones rather than dying with the workspace they were made in.

The harder questions are political rather than technical. A genuinely malleable platform changes the bargaining position between vendor and user, and vendors do not, in general, like that. Working out which kinds of malleability are compatible with sustainable businesses, and which are not, is part of the research, not a distraction from it.※The honest answer may be that some categories of software cannot be both malleable and rentable, and we will have to choose.

A working stance

I am not nostalgic for HyperCard, and I am skeptical of any pitch that asks the average user to become a programmer in the formal sense. The goal is not to turn everyone into a developer. It is to widen the strip of territory in which an ordinary person can act on her own software the way she already acts on a notebook, a kitchen, or a garden — adjusting, improvising, repairing, rearranging. This is, in the end, a Personal Computing question wearing different clothes: whether the machine can be a place she works with rather than a product she works inside.

Software does not have to be a finished product handed down from a vendor. On its better days, it can be a material. The work of this area is figuring out what it would take, now, to put that material back in the user’s hands.