IMO the essential difficulty of malleable software now boils down to “fork maintenance”. Let’s unpack that a bit. If you want to make your own custom tools or fork existing OSS, the cost of that is headed to zero. But… often we don’t want to start from scratch! We want to remix tools others have created. We want someone else to help us maintain stuff. We want to combine our ideas with others’. Now the moment you have multiple parties both updating the software… you hit gnarly problems! In a nutshell: happens if I modded something and it no longer meshes well with the latest updates from you? This is “fork maintenance”. (Traditionally this would be a centralized model where a “dev” is maintaining the software and you, the “user” might adjust settings or patch things. But even in a more decentralized setting we want to jam with our peers on our tools.) A classic approach here is to expose a stable plugin SDK. Works great because the dev can keep the surface maintained and plugins hopefully compose reasonably…. But only works as long as the plugin surface has what you need. Sometimes you end up hitting walls. If it’s OSS you can also literally fork. Maintaining a fork and merging edits from others is a huge pain. But maybe with enough smart cheap LLMs this is more viable now. You also need to consider data, not just code. Schema migrations are already a pain in the ass with normal software; when every user is doing customizations things get extra gnarly. I don’t think that there’s a perfect solution to this yet. Ideally I’d want something much deeper and broader than a typical plugin API - eg a language or framework designed for layered additive modification (think Harel’s behavioral programming as one reference.) I find it quite poetic that collaboration and working with others is where malleability gets really good but also where it gets hard. Same as many other things in life! For more on this, we go into quite some depth on this topic here: