First time I’ve heard of “Malleable Systems”. From what I could gather it refers to systems that permit end user programmability / heavy customisability

It seems that this is an initiative launched by @J. Ryan Stinnett who contributes to this slack every now and then.

Thanks for posting! 😄 Yes, this is a new community blog and project library I'm organising. As the home page mentions (https://malleable.systems), it's about resetting the balance of power so that users are much more in control of software. There's a large spectrum of work under this umbrella: from making parts of existing programs customisable by users through to systems where anything can be redefined by anyone. I'm hoping this new community site will get more people excited and interested in this. I'd love to have any feedback (positive, negative, anything) on this. I'm also looking for other people to contribute posts and projects, so please reach out if anyone's interested! 😄

@J. Ryan Stinnett - you might find some interesting links here which you can add to malleable systems https://www.notion.so/Building-Blocks-For-The-Future-Of-Computing-7f74066de66749d59939a91ab13ec960

Ah, thanks for passing that along, I hadn't seen that one yet. I'll look through it for projects to add. 😁 Yes, @yoshiki has a lot of great ideas in this space. Some days, I am tempted to try building each idea he tweets about. 😄

Malleable software is a pipedream. Sure, in games there will be user generated content; using the nice tools provided various games allow level creation. Some games are super creative, like Super Mario Maker. But that doesn't mean you can change the underlying game in any way. It is far too complex and would be mostly dangerous for users to modify. It would also break their copyright control on which their economic foundation rests. In the other side of the world, open source software is typically so large and complex that only a few people can modify it. The implications in terms of liability for mistakes is a big issue. Open source freeware has nobody to sue, and since it is free, you can't complain too much. Software is so intrinsically complex, that unless the complexity is drastically reduced, users are not going to have any control whatsoever, except perhaps for picking a few colors. Reducing complexity would do more to enable malleability than trying to enable more access. If it is spaghetti down there, what is the point of the trap-door letting you access it?

Well, malleable software is definitely a very different world than the one we live in today and requires new tools, different approaches for wiring things together, UI concepts that aren’t in regular use today... a long list of things that are currently missing. So, it’s certainty a lot of work that may take many years. Despite the vast amount of work required, in my view we must do it to give people (all people, not just experts) more control over software so it works in ways specific to them. I don’t want to be trapped in this world of isolated apps. The current ecosystem is not the world of computing for me, so I’m planning to do everything I can to change it.

Mel Conway pointed out (and others have I assume) that writing, arithmetic and calendar were once the "sole property of a priest class". Sure we're not going to have the masses write compilers, low level drivers for spaceships or designing billion transitor chips, but they sure could be doing a lot more than reading/writing emails and clicking play buttons. https://twitter.com/conways_law/status/1039584547178987520

The analogy I like to make is with literacy. Not everyone can write novels, but a large fraction of the population today can read novels, comprehend them, compare and contrast similarities and differences between two novels, and so on. That seems like a useful bar to aim for for software, and it seems like a very high priority. If aiming for it breaks copyright, I say we need to rethink copyright. If it creates liability, I say we need to rethink liability. (Though free software has no liability today. There's no reason we can't keep doing that. This law has no teeth at the moment.)

A program is not a passive thing like a book. A book is created by the author, and you the user run through the book at your own speed, but every word you are going to read is pre-determined, fixed, and unchanging. Software by its nature is interactive both from a data point of view, and also by the operation of the various options and commands. The more flexible and changeable the commands are, the more you will call it "malleable". Just like people add accessories to cars, there are software products most notably Photoshop, which enables thousands of plug-ins to achieve additional function. There is no reason why isolated apps have to stay isolated. We can (gasp) attempt to standardize on a protected arithmetic, and universal data interchange that is more robust than stupid JSON, which is a terribly weak interchange standard. Microsoft and Apple both put a lot of effort into intra-application communication, but unfortunately, Google and other web companies have spent most of their waking minutes trying to starve Apple, Adobe, and MS of their air supply by offering free versions of their core software with the goal of undermining their economic foundations. In essence, Google maintains a near monopoly on search and advertising revenue, and with their vast surpluses engages in predatory attacks on traditional companies, all under the banner of "Free! Free! Free!". Free until you want to get clicks for your company or service, then you find out how dear those clicks are. And now we have Amazon becoming a dominant player in cloud hosting, taking its vast surplus from selling to government extremely expensive secure racks that somehow are mandated by security regulations, and predating upon the data center market. In a recent visit to my racks in Fremont at a smaller competitor, it was half empty. I calculated that Amazon is more than 10x more expensive than doing it yourself, but now Amazon is proliferating options, and configuration tools that lock you in. So when you say malleable software, what part is malleable? It practically takes 1000 hours now just to understand Amazon's catalog. The overwhelming thrust of the current market is to increase complexity to such a ridiculous level that opening up a piece of software may not be that helpful, if you have to not only understand the code you are looking at, but also understand this tall tower of supporting tools and remote services. My point is that a dramatic simplification is the first order of business, then you can make things very malleable, and have more flexible, personally customized products. There is indeed no good reason why things can't evolve towards more malleability, but i am asserting we are heading in the opposite direction at present inadvertently due to the complexification.

I would argue that a foundation of malleability encourages simplification. If I am choosing between two software offerings, and I open one up and see it’s spaghetti that I have no hopes of interacting with, and I open the other up and see clean architecture, good documentation and sane abstractions, I’m going to pick the latter one. If I can’t look inside, though, I’m going to pick whichever one has a better looking website.

I do think that malleability and simplicity both encourage each other, whichever end you start from. And I agree with with Edward that the current momentum of software is very at odds with how simple & malleable it COULD be. (Which is also to say that most of the complexity of software is NOT intrinsic! The software world just really sucks at knowing how to keep it simple. Kay made an OS in ~20K LOC!) Code is malleable by default, because it's made of composable units (functions, classes, modules, services, abstractions, etc.). And exposing those units for inspection and composition by the user, would result in malleable software. But the status quo of most software is that those units interdepend on each other and create a tangled mess that's impossible to reason about. That has nothing to do with the intrinsic nature of software, but everything to do with a general lack of knowledge/discipline of developers as to how to create clean (aka reasonably sane) software architecture. But these are fundamental basics that any professional developer should know! But it's the horrendous failure for this stuff to taught, enforced, practiced, or even reasonably expected, that keeps software complex and fragile, and what causes many software folks to be adamantly (but very falsely) convinced that most of this complexity is just intrinsic to software. This is maddening because it's being allowed to ruin the fabric that society now runs on (users have now come to +expect+ a crappy and bug-ridden experience -- hey, that's +just+ how software is!), and ruin the potential for software to be something more amazing than it is (composable, etc.), and making my career about dealing with this nonsense that takes 10x the time and effort (and 100x the code) than is actually necessary to do anything, rather than spending that time doing amazing things for the company and our customers and our own teams. So the "inability" for software (at least at a code level) to be malleable and composable is very telling problem, because software is already that by nature! But we as an industry / profession have just mucked it up really bad! Software is a made of software-levers! That's it's defining feature / what that makes it _soft_ware!

This interview with Arthur Whitney (creator of the K language) deals with simplicity and malleability, a lot. I was fascinated to learn that Whitney reimplements the K language from scratch every 3-4 years, making the code shorter, faster, easier to understand on each iteration. https://queue.acm.org/detail.cfm?id=1531242

Potential case study in recovering malleability from existing software, @J. Ryan Stinnett: https://mastodon.social/@akkartik/103994830568601931. In general, the thing I find missing in the https://malleable.systems mission (and manifestos in general) is any mention of trade-offs. What are we willing to give up to achieve the stated goals? In this case study, malleability is only possible when we control the size and complexity of our software stacks. That might be a common compromise.

@Kartik Agaram Thanks, that's a good point. So far the mission has been focused on the ideals and goals without proscribing solutions, so I wasn't sure if trade-offs would make sense there. But indeed, there may be common trade-offs that come up across different approaches. Seems like a good subject for a new post, so I filed an issue: https://github.com/malleable-systems/malleable.systems/issues/13

Yes, trade-offs are an important point. In my guest blog post (https://malleable.systems/blog/2020/04/01/the-most-successful-malleable-system-in-history/) I point out one of them, which is responsibility for the overall system. If you let users mess around with it, you can't then let them sue the original authors if it breaks. And if you let people distribute their own add-ons, that makes three parties among which responsibility must be divided in some way. Size and complexity are also an issue, but less so if you get away from the assumption of a software stack implying vertical dependencies. Replace this by a network of modular subsystems with reasonably stable APIs, and you can have malleability for the whole system and for each subsystem. Do it recursively and you can perhaps scale to really big and complex stuff (though I am obviously speculating here). Sure, we have no technology for building systems out of modular subsystems. That remains to be done.

Anyone arguing that Emacs is a successful product is way off-base. Emacs is a disaster as a user interface. That nerds endure it is testimony to how some people have great memories and enjoy obscure powerful things. 99.9% of humanity rejects Emacs as a reasonable interface for editing. Having worked in word processing and desktop publishing for years, it was obvious from the first version of WordStar, followed by WordStar 2000, DisplayWrite, WordPerfect, then to FrameMaker, Quark xPress, InDesign, and the ubiquitous MS Word, a nice graphical interface trumped the archaic-but-powerful Emacs. AutoCad which also included LISP inside its system, is a far better example of a successful malleable product that still has a strong company (AutoDesk which has hundreds of employees and a hefty market cap). Emacs if you tried to sell it would go out of business fast.

I spent all day thinking about this, and finally found words to articulate hopefully half of what I intend to convey: https://github.com/malleable-systems/malleable.systems/issues/13#issuecomment-613900649. Hopefully I managed to walk the tightrope between showing vehemence and just being harsh.

@Kartik Agaram Thanks for taking the time to think about it. I think it conveys your perspective well, and it's a good critique of the current content, so thanks for writing it up! I think you mostly came across as passionate about the topic, so seems like you succeeded in conveying your thoughts. 😄