#computing #malleable Link: https://www.inkandswitch.com/essay/malleable-software/ ## Setup - Shaping our environment is how we shape our work - In the physical world, the act of crafting our environments comes naturally, because physical reality is malleable. - We are now spending more time in the digital world, and losing our ability to adapt our environments (e.g. tasks with index cards vs. tracker software) ## Definition > We envision a new kind of computing ecosystem that gives users agency as co-creators. We call this idea malleable software—**a software ecosystem where anyone can adapt their tools to their needs with minimal friction.** > > - By “software ecosystem”, we mean the broad technical and cultural environment surrounding software and its users. Malleability isn’t a narrow technical problem. > - By “anyone”, we mean that broad accessibility is the goal. And while individual self-sufficiency is useful to cultivate, cooperating with local community is also valuable. > - When we say “adapting tools” we include a whole range of customizations, from making small tweaks to existing software, to deep renovations, to creating new tools that work well in coordination with existing ones. Adaptation doesn’t imply starting over from scratch. > - Finally, “minimal friction” is key. Editing our tools should be fast. It should feel light. At best, it should be something we can do in the moment when a need arises, so we can get back to the task at hand. ## Promising approaches - **Gentle slope from user → creator** ([[McLean 1990, User-tailorable systems]]). Start out as a passive user, and increase tailoring over time with incremental learning. This is about devising systems to smooth out the leaps between using & authoring, adding intermediate steps. - **Building tools not apps.** E.g. in kitchen, an avocado slice is so specific it's useless for anything else, vs. a knife (this is why [[Spreadsheets]] are so useful). But for this you need better ways for applications to work together (like [[Application environments]]). - Need share data (e.g. [[Filesystems]] are malleable for this reason). Low-code tools like Airtable are another approach. [[Smalltalk]] which is like [[Unternet/Web Applets/Web Applets]] in that the user works with state + code associated with that state. - **Communal software** (see [[Communal computing]]). This reminds me of what [[Boris Mann]], [[Commons computer]] & [[Hypha]] are doing, also [[Mastodon]]. Building software for “local” contexts is sometimes easier than building software for world-wide use. ## Experiments PushPin, a collaborative media canvas. > A key idea we developed in that project was “document functional reactive programming” (DFRP): representing a tool as a UI component authored in React, backed by a JSON document that was automatically persisted and synchronized through Automerge ![[pushpin.jpg]] But schema compatability was a point of frustration. So they created [[Project Cambria]]. [Farm](https://github.com/inkandswitch/farm), a way to allow you to create a peer-to-peer data storage layer that *also* included the code for the system itself, so you could push modifications to it. > Farm applications are built out of Gizmos. A Gizmo is the combination of some data with a small Elm program to render it as a Web Component. Changes to the Elm code for a Gizmo are compiled automatically into Javascript by the Farm runtime, and changes to the data document will trigger a re-rendering of the content as well. Then they made [[Patchwork, by Ink & Switch]], which is a version control system storing both data and software code, plus branching and history. They are now bootstrapping, with most of the lab's internal knowledge happening inside Patchwork. You can easily create new "tools"/"views" and share them with just a link. They found when combined with a malleable environment, AI-assisted development ([[Future of making software]]) really makes sense – it has a place to go. > Another thing we’ve found while customizing Patchwork is that **AI is a useful complement to a malleable environment.** We argued earlier that AI-assisted coding alone does not guarantee malleability. But _when combined with a malleable environment_, AI-assisted development can make it much faster to edit your tools. [[Unternet/Web Applets/Web Applets]] should probably be compatible with these sorts of malleable systems. Problems with the Patchwork model: > - **Limited branching & versioning**: Basic branching exists, but lacks support for simultaneous use, clear governance, and collaboration norms. > - **Ambiguous ownership & quality**: Unclear who leads tool development or how to signal polish vs. prototype. > - **Embedding & UI composition friction**: Tool embedding is cramped; components lack general, decoupled ways to communicate and interoperate. Some other broader challenges: > - **Privacy and security**: How do we reconcile the desire for extensible software and interoperability with the reality of bad actors? When untrusted strangers are sharing modifications to existing software that can access sensitive data, dangerous things can happen. > - **Business models**: How would developers make money from their software if they were shipping composable tools, not monolithic applications? How is support and maintenance paid for? > - **Culture**: How do we cultivate a movement towards personal agency where people _want_ to modify their environments, both digital and otherwise?