> Mass-produced software is too rigid
Yes, absolutely, even trivial things like colors can rarely be changed, let alone more involved UI parts.
> Inflexible electronic medical records systems are driving doctors to burnout. > When different users have different needs, a centralized development team can’t possibly address everyone’s problems.
That's not the main issue, which is that they don't address *anyone's* problems well since actual users have very little power here, and the devs are far removed from actual user experience. Like that examples of filling useless fields - that serves no one!
> when a developer does try to cram too many solutions into a single product, the result is a bloated mess.
Unless it's organized well? There is no inherent reason many equals mess or even bloat (eg, if solutions are modules you can ignore/not even install, your app with only the solutions you care about has no bloat)
But in general, very laudable goals, would be very empowering for many users to live in a dream world where software is built based on such principles...
I appreciate the idea behind the post, because certainly, we need more hackable apps now that everything is becoming a SaaS that effectively cannot be archived or hacked on (unlike, say, WinAmp or major releases of Windows and their respective fan updates, or for a more common example game mods).
Unfortunately I think that while there’s a decent number of power users and people who have the aptitude to become power users who will make use of software made to be deeply customizable, they are outstripped many times over by people who don’t see software that way and have no interest in learning about it. People are quick to point fingers about why the situation is as it is, but the truth is that it was always going to be this way once computers became widely adopted. It’s no different from how most people who drive cars can’t work on them and why few feel comfortable making modifications to their houses/apartments. There’s just a hard limit to the scope and depth of the average individual's attention, and more often than not technical specialization doesn’t make the cut. No amount of gentle ramping will work around this.
That doesn’t mean we shouldn’t build flexible software… by all means, please do, but I wouldn’t expect it to unseat the Microsofts and Googles of the world any time soon. I do however think that technically capable people should do anything they can to further the development of not just flexible, but local-first, hackable software. Anything that’s hard-tethered to a server should be out of the running entirely and something you can keep running on your machine regardless of the fate of its developer should take priority over more ephemeral options.
Give me Delphi. No, seriously, give me Delphi, but for the web and in a modern popular programming language. Python would be great, but I will not turn my nose away from TypeScript or Go or Lua.
For those who don’t know, Delphi was (is?) a visual constructor for Windows apps that you outfitted with a dialect of Pascal. It was effing magic!
Nowadays the web ecosystem is so fast-paced and so fragmented, the choice is paralyzing, confidence is low. The amount of scaffolding I have to do is insane. There are tools, yes, cookie cutters, npx’s, CRAs, copilots and Cursors that will confidently spew tons of code but quickly leave you alone with this mess.
I haven’t found a solution yet.
I've reverse-engineered a couple of programs before in order to get them to do what I want. Things like setting default options in a program that doesn't let you change the defaults, or getting older Windows programs to function correctly.
I've also patched open-source programs locally in order to get them to do what I want but wouldn't be suitable for upstreaming. For example, I've reverted the order of buttons in a "do you want to save?" close dialog when they changed in an update.
Minor stuff, but just being able to do this is amazing. The trouble is, developers - at least those of closed-source programs - don't want you to be able to do that, partially due to a lot of them relying on security by obscurity in order to earn money.
As such, it feels like the only way you're going to get developers to be on board with something like this is to be able to have them specify what people can change and what people can't change - and that's something that developers already do (whether they realise it or not) with things like INI files and the Registry.
This is why people using UNIX-based systems campaign for small programs that do one thing and do it well. Being able to combine these small programs into a pipeline that does exactly what you want? Now that's amazing.
I hope you're looking carefully at COM/OLE Automation, which achieved pretty much all of those things.
- In-process and cross-process language-agnostic API bindings.
- Elaborate support for marshalling objects and complex datastructures across process boundaries.
- Standardized ways to declare application and document object models that can be used by external applications, or internally by application add-ons.
- A standardized distribution system for application extensions, including opportunities for monetization.
- Standardized tools for binding application APIs to web services and database services.
- A default scripting engine (VBA) that can be embedded into applications.
- Admittedly primitive and mostly ill-advised support for dynamically typed objects, and composable objects.
And it provides opportunities for all of the levels of application customization you seem to be looking for.
- Trivial tiny customizations using in-app VBA.
- The ability to extend your application's behavior using addons downloadable from a marketplace WITHOUT trying to capture a percentage of licensing revenue from those who want to monetize their add-ons.
- The ability to write scripts that move data between the published document object models of various applications (and a variety of standard data formats).
- The ability to write fully custom code that lives within applications and interacts with the UI and with live documents within those application (i.e. write-your-own add-ons).
Plus it would be enormously fun to build the equivalent functionality of COM/OLE with the all the benefits of hindsight, and none of the cruft incurred by Visual Basic, with lessons in hand from some of the things COM didn't do well. (svg as a graphics transport, perhaps? A more organized arrangement of threading model options? Support for asynchronous methods? A standardized event mechanism?)
Questions that come to mind:
- What can you get away with not doing that COM does do? Not much, I think.
- How could you make it better? A bunch of ways!
There are people who like to tinker, to play with things, take them apart, learn how they work, put them back together again. Some of them go on to make new things. A few of them will make things that change the world. I'd like to live in a world that does more to encourage imagination and creativity, that lets people participate in creating their future. Software doesn't all have to be black boxes with No User Serviceable Parts Inside. We've seen what people can do with things like HyperCard, Visual Basic, Excel. And have fun doing it.
In the 'Tools, not Apps' part of the article they reference Michel Beaudouin-Lafon's talk 'A World Without Apps' which goes back in time and shows the Xerox Star operating system: https://m.youtube.com/watch?v=ntaudUum06E&t=313s
Another reference I usually bring up is Alan Kay's talk on smalltalk: https://www.youtube.com/watch?v=AnrlSqtpOkw&t=4m19s
My related comments on this, just to show other stories along this theme:
- https://news.ycombinator.com/item?id=36885940
As described in the article, sharing data between apps is currently impossible. I wish Solid/PODs had taken off, but I get the sense that project spent more time on ontologies and less on making useful things.
How can we draw apps into using a common data backend owned by the user?
> we created Patchwork—a web-based collaboration environment for malleable software... storing both user data and software code in Automerge documents. On top of that, it adds version control utilities like history views and simple branching. These tools apply to any document in the system—whether a piece of writing, or code for a software tool... Eventually we also plan to release Patchwork as an open-source tool
What milestones would you like to hit before open-sourcing it? As an outsider, it looks like it has a LOT of features, and I wonder if there's feature creep. Still, version control for everything is a tall order, so perhaps it needs plenty of time to bake.
Ink & Switch is doing great (some would say overdue) research that’s on the boundary of commercializability but outside the bounds of what the big corporates want to do with computers.
Great to see them pushing work like this, building experiments, and talking about what they’ve learned.
Though clearly imperfect video games have, at times, managed to reflect some of these principles. There was a brief moment at the peak popularity of World of Warcraft when the game was highly moddable -- if you walked up to a stranger's monitor you would not recognize the interface they were using for the game because they'd customized it so much.
The gaming audience is probably the most demanding of any regarding customization, modding, accessibility and other similar principles -- when the market forces line up and they are flush enough to offer more malleability video games frequently do.
Have you had a chance to look at atproto? I was a bit surprised to see no mentions of it. It powers Bluesky but is not coupled to it — the idea is essentially that your public data is meaningfully owned by you (can move hosting without losing identity) across all applications in a global collection, and different app backends can “derive” aggregated views (like Bluesky’s database) from the public network data of all users.
I love the optimism, but I'm a pessimist. Even at the first paragraph:
> "The original promise of personal computing was a new kind of clay—a malleable material that users could reshape at will. Instead, we got appliances: built far away, sealed, unchangeable. When your tools don’t work the way you need them to, you submit feedback and hope for the best. You’re forced to adapt your workflow to fit your software, when it should be the other way around."
I already have objections: User and businesses overwhelmingly voted with their wallets that they want appliances. The big evil megacorps didn't convince them of this - Windows was a wildly malleable piece of software in the 90s and 2000s, and it didn't exactly win love for it. The Nintendo Switch sold 152 million units, the malleable Steam Deck hasn't broken 6.
Software that isn't malleable is easier to develop, easier to train for, easier to answer support questions for, and frequently cheaper. Most users find training for what's off-the-shelf already difficult - customizing it is something that only a few percent would even consider, let alone do. Pity the IT Department that then has to answer questions about their customizations when they go wrong - user customizations can easily become their own kind of "shadow IT."
The send off is also not reassuring:
> "When the people living or working in a space gradually evolve their tools to meet their needs, the result is a special kind of quality. While malleable software may lack the design consistency of artifacts crafted behind closed doors in Palo Alto, we find that over time it develops the kind of charm of an old house. It bears witness to past uses and carries traces of its past decisions, even as it evolves to meet the needs of the day."
If you think this is okay, we've already lost. People simply will not go back to clunky software of the 2000s, regardless of the malleability or usability.
Modders tweak and change games they like pretty much all the time, whether they are malleable or not.
Decker absolutely enables malleable software: https://beyondloom.com/decker/
You can tell when a platform is succeeding at this by looking at its adoption among non-programmers.
I was thinking a lot about software malleability - but from a technical perspective. I am on the verge of building something useful - only if I could find the time to do it.
Here's my premise - if you use something like a game engine, say Unity, and Unreal, you basically have the ability to modify everything in real time, and heve it reflected inside the editor immediately - you could change textures, models, audio, even shaders (which are a kind of code), and have the editor reload just that tiny resource instantaneously.
But not code code - for some reason computer code must go through a compilation, optimization and linking process, creating a monolithic executable piece of code, that cannot be directly modified. This is even true of dynamic languages like Js/Ts, which support modification on the fundamental level, yet somehow lose this ability when using advanced toolchains.
Which is weird since most compilers/OSes support this dynamism at a fundamental level - the machine interface unit of the C compiler is a function, the replacement unit in most OSes is a dynamic library, a collection of said functions - yet changing this at runtime is almost unheard of and most of the times suicidal.
This is because of a couple problems - memory allocation - replacing parts of a program at runtime can lead to leaks if we don't clean that up, resource allocation - this once again can be solved by tying resource lifetimes to either outside factors, or the lifetime of the function or its containing unit.
A demonstrated analog of this is OS processes, which can be terminated abruptly, their binaries replaced without fear of resource leakage.
The final problem of data corruption can be solved by making such program parts stateless, and making them use a store with atomic transactions.
I have a pretty good idea on how to build such an environment on the low level, whose core idea is having process-like isolation barriers isolating small pieces of programs, and an object database-like datastore that can never be corrupted due to transactional changes (which can be rolled back, enabling stuff like time-travel debugging). Said processes could communicate either via messages/events or sharing parts of their memory.
Such a system would allow you to fearlessly change any part of the source code of a running application at runtime - even if you mess up the code of a said component - say event to a point that it doesn't compile - all that would happen would that single component would cease to function without affecting the rest of the app.
I quick shout out to a light in the dark (in the bio-imaging space)
I love napari. I remember downloading it on a whim, and while poking around, I accidentally opened its built-in python console. Half the time, if I'm writing a plugin for it, I open up the console just so that I can play around and print out stuff and try new things.
Everything, even the viewer itself, is accessible from the repl. Nothing hides behind a black box.
I wish that the first semester of programming class deliberately left code out of the material. IMHO students should start with something like this short list:
FileMaker/Microsoft Access/HyperCard (no longer exists)
Macromedia Flash (no longer exists)
Spreadsheets (like Microsoft Excel, unfortunately Airtable isn't there yet?)
Wix (maybe? surely there are better alternatives)
Zapier (or an open source version)
htmx
Firebase/RethinkDB (no longer maintained?)
Erlang/Go
GNU Octave/MATLAB
Lisp/Scheme/PostScript/Clojure
React
Ruby on Rails
Javascript (warts of the modern version with classes and async/await, not the original)
C#/Java/C++/Rust (the dangers of references/pointers and imperative programming)
iOS/Android (Swift vs Objective-C, Kotlin vs Java, ill-conceived APIs, etc)
Since we can't fix the market domination of multibillion companies who don't care about this stuff on any reasonable timescale, maybe we can pull the wool off the children's eyes and give them the tools to tear down the status quo.
I suspect that AI and geopolitical forces may take this decision away from us though. It may already be too late. In that case, we could start with spiritual teachings around philosophy, metaphysics and wisdom to give them the tools needed to work with nonobjective and nondeterministic tech that's indistinguishable from magic.
In my experience, people yearn for coding and modding. Given the tools a whole bunch of people will do domain-specific miracles using macros and other tools. I'm almost convinced that teaching programming is easier than teaching software development boilerplate.
I really love those customization power charts and really happy to see that my anecdote-based thoughts might actually have some grounding behind them.
Creating browser extensions is easy enough. It's hacky web dev which I very much enjoy. The problem relies in distribution.
I remember having this idea in undergrad in 2011. My big wish was that every app would ship with a scripting language or an api. The problem is that it’s not at all straight forward to do this. The more complex an app, the more important a facade (like a front end) becomes.
Not directly related but I'm sad when I fire up my old Windows phone that I bought for nostalgia and it doesn't work, other than the base OS maybe the old bing.
I get it too, world moved on, people have to manage APIs, updates... but yeah.
The fundamental problem with customizability is that code path complexity is exponential on branching. So it works as long as your app is sufficiently simple, but eventually, the exponents catch up and eat ur software alive.
So what is it like? VBA? Hypercard?
Most people just don’t have the skills or inclination to tinker even with ham radios or cars.
On the other hand with the right to repair, you could call a repairman. And now — an agent or robot!!
I agree with all of the assertions about what software should be.
But... I think a lot of it already is customizable, and users don't want to configure. End-users (or doctors) hate having to learn more about software than they absolutely must. Just an example, Epic (EHR from the essay) definitely has the ability to mark fields as optional/required. Someone just needs to get in and do it, and they don't want to/know how.
The inaccessibility of config to laypeople may actually be where AI shines. You prompt an in-app modal to change X to Y, and it applies the change. A natural language interface to malleability.
I made an app that lets you build one-off desktop utilities: https://viberunner.me
https://news.ycombinator.com/item?id=44236729
Ultimately I think it’s too open ended. Users got overwhelmed with a chat interface and couldn’t think of something useful to build on the spot.
Maybe a slow burn approach works best.
I do think that they are right about many things, although I have my own ideas about how to improve them (and I do not agree with all of the ways they (Ink & Switch) are doing with it).
In UNIX systems you can use pipes between programs (if the programs support that; many modern programs don't support it very well), although there are still problems with that too. (I also disagree with the idea that text (especially Unicode text, although the objections apply even without a specific character set) would be the universal format.)
My idea of a computer design and operating system design is intended to do things which will avoid the problems mentioned there (although this does not avoid needing actually good programming, and such things as FOSS etc still have benefits), as well as having other benefits.
Some of the features of my design are: CAQL (Command, Automation, and Query Language), UTLV (Universal Type/Length/Value), and proxy capabilities. (There are more (e.g. multiple locking and transactions), but these will be relevant for this discussion.)
Like OpenDoc and OLE, you can include other kind of things inside of any UTLV file, by the use of the UTLV "Extension" type. The contents of the extension would usually itself be UTLV as well, allowing the parts to be manipulated like others are, although even if the contents isn't UTLV (e.g. for raster images), you would have functions to convert them and to deal with them anyways, so it will still work anyways.
With those things in combination with the accessibility (one of the principles is that accessibility features are for everyone, not only for the people with disabilities; among other things this means that it does not use a separate "accessibility" menu) and m17n and other features, you can also do such things as affect colours, fonts, etc, without much difficulty. (They might not seem related at first, but they are related.)
I had also recently seen https://malleable.systems/mission/ which seems to be related (you might want to read this document even if you are not interested in my own comments). One part says, "If I want to grab a UI control from one application, some processing logic from another, and run it all against a data source from somewhere else again, it should be possible to do so.", and with CAQL and UTLV and proxy capabilities, this can be done easily, because the UI controls are callable objects (which can be used with CAQL) like any other one, the data source can use UTLV (which can be queried and altered by CAQL), and the interaction between them can use proxy capabilities.
After more than 2 apps get involved with anything I’m back on paper. It still works well :)
The challenges here feel insurmountable, but I can't help but feel there's a certain inevitability to the de-monolithization de-totalization of the domain of computing being ensconced so wholly as it is inside of applications, experiences purely pre-defined by a given app.
Already with AI we are seeing a huge uptick in people's expectations that agents operate across apps. The app is losing its monopoly of power, is losing its primacy as the thing the user touches. See How Alexa Dropped the Ball on Being the Top Conversational System on the Planet which is an article about a lot of factors, many more Conway's Law & corporate fiefdom oriented, but which touches repeatedly in the need to thread experiences across applications, across domains, and where the historal "there's an app for that" paradigm is giving way, is insufficient. https://www.mihaileric.com/posts/how-alexa-dropped-the-ball-... https://news.ycombinator.com/item?id=40659281
AI again is an interesting change agent in other ways. As well as scripting & MCP'ing existing tools/apps, the ability to rapidly craft experiences is changing so quickly. Home-Cooked Software and Barefoot Developers talks so directly to how this could enable vastly more people to be crafting their own experiences. I expect that over time frameworks/libraries themselves adapt, that the matter of computing shifts from targeting expert developer communities who use extensive community knowledge to do their craft, to forms that are deliberately de-esotericized, crafted in even more explicit compositional manners that are more directly malleable, because ai will be better at building systems with more overt declarative pieces. https://maggieappleton.com/home-cooked-software/ https://news.ycombinator.com/item?id=40633029
Right now the change is symbolic more than practical, but I also loved seeing Apple's new Liquid Glass design system yesterday, in part because it so clearly advances what Material set out to do: constructs software of multiple different layers, with the content itself being the primary app surface. And in Liquid Glass's case extending that app surface even further, making it practically full screen always, with tools and UI merely refractive layers above the content. This de-emphasizes the compute, makes makes the content the main thing, by removing the boxes and frames of encirclement that once defined the app's space, giving way to pure content, making the buttons mere layers floating above, portals of function floating above, the content below. In practice it's not substantially different than what came before, yet, but it feels like the tools are more incidental, a happenstance layer of options above the content, and is suggestive to me that the tools could change or swap. https://www.apple.com/newsroom/2025/06/apple-introduces-a-de... https://news.ycombinator.com/item?id=44226612
There's such a long arch here. And there's so many reasons why companies love and enjoy having total power over their domain, why they want to be the sole arbiter of experience, with no one else having any say. We've seen collapses of interesting bold intertwingular era API-hype hopeful projects, like Spotify desktop shutting down the amazing incredible JavaScript Apps SDK so long ago (2011-2014). https://techcrunch.com/2014/11/13/rip-spotify-apps-rip-sound...
Folks love to say that this is what the market wants, that there is convenience and freedom in not having any choices, in not having to compose tools, in everything being provided whole and unchanging. I'd love to test that thesis, but I don't think we have evidence now: 99.999%+ of software is built in the totalistic form, tablets carved and passed down to mankind for us to use as directed (or risk anti-circumvention felony charges!). We haven't really been running the experiments to see what would be good for the world, what would make us a better happier more successful world. Whose going to foot the bill, whose going to abandon control over their users?
And it's not something you can do alone. The really malleable software revolution requires not individual changes, individual apps adding plugins or scripting. The real malleable software shift is when the whole experience is built to be malleable. The general systems research for operating systems to host not just applications, but to host views and tools and data flow, history event sourcing and transactions (perhaps). No one piece of software can ever adequately be malleable software on its own: real malleable software requires malleable paradigms of computing, upon which experiences, objects, tools compose.
It all sounds so far off and far fetched. But where we are now is a computing trap, one posited around a philosophy of singularness and unconnectedness delivered down to us users/consumers (a power relationship few want to change!). The limitations of the desktop application model, as it's related and been morphosed into mobile apps, into watch apps, feels like an ever more cumbersome limit, a gate on what is possible. I feel the dual strongly: I'm with those pessimists saying the malleable software world is impossible, that we can never make the shift, I cannot see how it ever could become, and yet I don't think we can stay here forever, I think the limitations are too great, and the opportunity for a better opener computing to awaken is too interesting and too powerful for that possibility to lie slumbering forever. I want to believe the future is exciting, in good ways, in re-opening ways, and although I can hardly see who would fund better or why, and although the challenge is enormous, the project or rebuilding mankind's agency within the technological society feels obligatory necessary & inevitable, and my soul soars at the prospect. Malleable software: thus we all voyage towards computing.
A tool which looks at this sort of thing which was mentioned here recently:
https://news.ycombinator.com/item?id=44118159
but which didn't seem to get much traction is:
https://pontus.granstrom.me/scrappy/
but it pretty much only works for JavaScript programmers and their friends (or folks interested in learning JavaScript).
Other tools which I'd like to put forward as meriting discussion in this context include:
- LyX --- making new layout files allows a user to create a customized tool for pretty much any sort of document they might wish to work on --- a front-end for LaTeX
- pyspread --- every cell being either a Python program or the output of a program, and the possibility of cells being an image allows one to do pretty much anything without the overhead of making or reading a file
- Ipe https://ipe.otfried.org/ --- an extensible drawing program, this really needs a simpler mechanism for that and I'd love to see a tool in the vector drawing space which addressed that --- perhaps the nascent https://graphite.rs/ ?