Malleable software: Restoring user agency in a world of locked-down apps

Original Article ↗ Hacker News Discussion ↗

User appetite for “malleable” vs “appliance” software

  • One camp argues the mass market has already voted for sealed appliances: they’re cheaper, easier to support, and less cognitively demanding than customizable tools.
  • Others counter that users do like tailoring when it’s easy enough (Windows themes, Office toolbars, WoW and game mods, HyperCard/Excel creations), and that current software mostly removes even tiny tweaks.
  • Several people emphasize that tools shape culture: if environments encouraged tinkering, more people would gradually do it.

Support burden, risk, and responsibility

  • A recurring objection: customization explodes support complexity. Non‑technical users change settings, break things, then blame the product and support staff.
  • This is cited as a key reason enterprises and dominant vendors prefer locked‑down defaults and minimal options.
  • Some suggest distributing support across communities (Linux distros, app communities) mitigates this, but that doesn’t fit centralized SaaS economics.

Existing precursors and counterexamples

  • Many references: HyperCard, Excel, AppleScript, COM/OLE, UNIX pipes, Tcl/Tk, Smalltalk, napari, Decker, Scrappy, Delphi/Lazarus, COM‑style automation, modding ecosystems.
  • These are seen as proof that non‑programmers can meaningfully extend tools given good abstractions, but also as examples that never crossed into mass adoption or were later de‑scoped.

AI as a change agent

  • Several commenters see LLMs already enabling “home‑cooked” apps and one‑off utilities, bypassing business models and traditional boilerplate.
  • The essay’s authors agree AI helps but argue OS and app architecture still assume “people can’t code”; real gains need systems centered on personal tools and shared data, not siloed apps.
  • Others think people will just scrape, macro, and abuse existing APIs regardless, with developers increasingly “cleaning up knots.”

Architectural and technical ideas

  • Discussion of new OS designs: shared user‑owned data backends (atproto, Solid/POD‑like ideas), local‑first storage, open file formats, version‑controlled documents, and Patchwork‑style “OS as primitives” for tools, views, and history.
  • Deep technical thread on hot‑reloading and live coding: process‑like isolation, transactional object stores, safe module swapping (e.g., Theseus OS), dynamic languages, and the tradeoff between live editability and durability/tooling around plain files.

Limits, complexity, and UI design

  • Some argue customization has exponential code‑path complexity and tends to produce clunky UIs with too many options.
  • Others stress “software that rewards learning” and progressive disclosure: like homes, most people won’t rebuild walls, but everyone rearranges furniture if friction is low.
  • There’s optimism about AI-powered natural‑language configuration as a bridge between rigid apps and full programmability.