>> "Software must be as easy to change as it is to use it"
Easy is relative. I find command-line interfaces remarkably clear and easy to work with, but others might not agree with my opinions or preferences. How easy is "easy"? How do you know if software is easy enough? How can we fundamentally simplify the essential complexities of software development so that it is approachable by "the man or woman on the street"? What incentives do we have to do so?
>> "All layers, from the user interface through functionality to the data within, must support arbitrary recombination and reuse in new environments"
>> "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." source: https://malleable.systems/mission/#2-arbitrary-recombination...
If you have the software source code then this might be technically possible, but licensing restrictions may come into play. Short of the source code, the "no code" / "low code" software development pipe dream needs to become a reality and then become standardized to allow for component interoperability. It might be possible, but the question of incentives comes up again. If I were a company selling a production-quality "no code" / "low code" system, why would I make it interoperable unless I was trying to undercut a competitor?
Compare to the FSF Freedom 1: "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this."
>> "Tools should strive to be easy to begin working with but still have lots of open-ended potential"
How do you define or measure "open-ended potential" from the user standpoint?
>> "People of all experience levels must be able to retain ownership and control"
Does this imply some kind of built-in DRM or is it merely copyright and licensing? How would ownership and control be enforced?
>> "Recombined workflows and experiences must be freely sharable with others"
This nests pretty closely with the FSF Freedoms 2 and 3:
"The freedom to redistribute copies so you can help others (freedom 2)."
"The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this."
How does this principle combine with the previous principle about retaining ownership and control? How is it different from copyright and licensing that is currently used?
>> "Modifying a system should happen in the context of use, rather than through some separate development toolchain and skill set"
Using software and building software are different activities that REQUIRE different knowledge and skill sets. This is roughly the equivalent of wanting to modify your car without understanding how the drive train or transmission work. If you do not understand the underlying natural laws that govern how something works then how can you expect to make changes that do what you want? Lack of understanding leads to cargo cult reasoning and magical thinking.
>> "Computing should be a thoughtfully crafted, fun, and empowering experience"
It depends on the person, but actually learning how computers work and how to program computers can be a fun and empowering experience.