Travis F WFeb 16

#SoftwareFreedom I have an itch… I have long considered the *app* paradigm to be a fundamentally anti-Free way to package and distribute informatic potentiality.

The "app" leases human compute resources unfairly and unilaterally to a remote entity. This design empowers the Enshittifier. The intermediating extractive platform brokers the lease, *as if* on your behalf, but (only now, obviously) actually guaranteeing a degree of your attention to the enclosure of the monopolist.

thread TBC…

Show threadTravis F WFeb 17
The anti-Free aspects of the design of the "app" paradigm are:
Ⓐ Your screen space:
A company controls those pixels. The #desktopMetaphor is the root of this #enshittifiability, with "windows" defining a portal between your attention and the informatic space unilaterally controlled by the developer.
An alternative is how GNU and the shell work, where the human invokes the function, which humbly takes no more time than necessary and exits, leaving just what was requested.
#HCI #Informatics
Show threadTravis F WFeb 17
Ⓑ Your computer's memory is obviously allocated and used up while the app is open. Again, not necessary in the contrasting paradigm of the Linux/GNU shell.
Ⓒ Your habits. A pretty icon clutters your desktop, requires maintenance, and you feel the sap on your life with subtle information overload. Certainly businesses generally try to make it worth it. That's the sale. But then comes #enshittification once you're invested.
Show threadTravis F W
wrt Ⓒ, the Linux/GNU shell contrasts, again, by respectfully minimizing their drain on your life, becoming part of the language of computation, a bigger single paradigm, rather than requiring significant direct attention.
Feb 17 at 12:44amWeb
Show threadTravis F WFeb 17
The above is all true of "applications" before 2007, before #enshittificaton, when the platform model of intermediation hadn't geared down to tap the full energy of both sides yet.
Show threadTravis F WFeb 17
So I got started on this thread this morning about "apps," per se, because I see Freedom-aligned software development largely following the enshittification-aligned model where one's attention, pixels, ram, and habits, and sometimes data too, are handed to a developer. Even in cases of true dedication to freedom, a development effort may target an #HCI paradigm perfectly in-line with extractive business, as if to compete directly with exit-oriented libertarian-backed startups and platforms.
Show threadTravis F WFeb 17

I am talking about popular apps like LibreOffice, Blender, and Firefox, and desktop skeuomorphism implementations like GNOME and KDE and the very way that these #HCI paradigms enable building and distributing apps.

I'm pointing fingers basically everywhere.

We are acting like *them.* Pretending we can play that game better by being Free, even without the plan including money for a phase of rapid growth.

Not really by choice. People know the language. They want apps. Free apps. And yeah, good.

Show threadTravis F WFeb 17

But you know what game #SoftwareFreedom can play *better* than the exit-oriented libertarian-backed startup or platform?

The bigger game. The #HCI paradigm design game. How informatic potential finds you Free.

We are in an innovation recession. The whole startup engine is ripe for disruption. The libertarian path to dominion itself is congested and vulnerable.

Show them what they never knew they always wanted.

Want to see something cool?
Oh, and one more thing.

Show threaddorotaCFeb 17

@travisfw How do you imagine discoverability without icons and persistence without apps?

A shell is an app, just an all-encompassing one. And the typical user won't build one, either. Is your point that it could be a centralized point of customization so user control of how the executed stuff behaves?

Show threadTravis F WFeb 17

@dcz yeah you got it. I could be more direct. I'm advocating for the shell to be the Free software paradigm to compete with the enclosed software paradigm's app marketplace.

There is A LOT that could be done to improve both discoverability and persistence. Those are *really good* points, and I could talk about both of them a lot.

I want to see composable tools in shells. More kinds of shells. Graphical, approachable ones. More simple composable tools that talk to each other in pipelines.

Show threaddorotaCFeb 17
@travisfw I'm fascinated by the topic of composable tools but I missed the era of UX experimentatoin with LISP machines and Smalltalk so I struggle to imagine what they could look like beyond the shell. Unix shell is great. Unix shell sucks big time.
Show threadTravis F WFeb 17

@dcz yes and yes.

I've spent a lot of time defining and thinking through my version of this I called Spaciousness. I'll probably reboot it at some point, but I'm spending all my time on family demands so it'll be years, and I want others to go in that direction.

I really believe enclosure is integral to the definition of what an app is.

The alternative is for a shell to set a context in which specific libraries that "do one thing and do it well" can be composed. No single app for anything.

Show threadTravis F WFeb 17
Aside: this metaphor might have been too oblique. If you're driving a truck down hill, you gear *down* to limit speed. I am not a mechanic, but I think it works by literally leveraging the weight of the truck to thrash the engine oil around to the limits of its viscosity. I think it could have been a good metaphor for enshittification because with the throttle closed, you can look at the engine RPM spike, and get a sense for *how much potential energy you can waste while coasting.*