3 ms·
The Malleable software principles seem to be more of a "No Code" / "Low Code" wish list with some similarities to the Four Freedoms of the Free Software Foundat
by thesuperbigfrog 7y ago
The Malleable software principles seem to be more of a "No Code" / "Low Code" wish list with some similarities to the Four Freedoms of the Free Software Foundation.
>> "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-and-reuse 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.
- badsectoracula 7y ago> Does this imply some kind of built-in DRM or is it merely copyright and licensing? How would ownership and control be enforced? I think this refers to the user being in control (as opposed to the developer) and having ownership of their computing environment.
- thesuperbigfrog 7y agoBut in a Malleable System, the user becomes a developer or something closer to a developer. The links in the principles give more details: https://malleable.systems/mission/#4-retain-ownership-and-control https://malleable.systems/mission/#4-retain-ownership-and-co... For this principle, it says: >> "A fundamental problem of today’s software ecosystem is that we do not own or control the software that runs on our devices. In addition, much of the actual processing logic has been passed off to remote systems in the cloud, so only the inputs and outputs are observable." >> "We must ensure that malleable software approaches allow the customisations and personal workflows you create to be owned and used as you see fit. If an approach relies on some amount of remote functionality (perhaps to assist with pulling apart an application or service), we must ensure there’s a clear path for anyone interested to keep those dependencies alive so that their workflows are not disturbed if the remote service were to shut down." >> "This has many parallels with the ongoing movement towards data ownership, which is gaining popular awareness. Although the data ownership movement typically focuses on identity and social data, the programs and customisations that authors create are personal creative expressions. Authors must retain ownership of their data, programs, and customisations just as anyone would expect to have control over a book they wrote or art they created." The first paragraph definitely matches up with your point that the user should be in control of their computing environment. However the third paragraph certainly seems like copyright and licensing are implied.
- jryans 7y agoAs you’ve surmised, the user / workflow author is meant to be the same person. When it says “authors must retain ownership”, this was mostly meant as a reaction against platforms like IFTTT and marketplaces like browser extension galleries that may bring sharing restrictions, vendor lock-in, etc. So it’s trying to argue for more openness at least being available as an option to the hybrid user / workflow author. For cases where the user / author wants to be restrictive and lock down who can use the work, the mission is mostly silent on this front. Personally, I would hope most would see value in openness, and known approaches for enforcing restrictions (like DRM) are quite ... unpleasant. I am hopeful better schemes can be created for those who want such things, but it seemed a bit beyond the core focus of the mission (which is already quite ambitious). Thanks for the feedback!