- JordiGH's "Exercising software freedom on Firefox" <http://jordi.inversethought.com/blog/exercising-software-fre...>. Jordi spends a lot of time dealing with the infuriating reality of what it takes to build Firefox. The punchline (not stated in the post) is that Firefox uses an Emacs-like architecture, so basically none of these frustrations or the time wasted on them were actually necessary; the code Jordi wanted to twiddle require no/little actual building. The Firefox team (particularily given how well-funded they are) could enable a contribution path where making an improvement to Firefox is about as easy as opening up an elisp file and making the requisite tweaks, but they don't. Related, and I've mentioned this before—the Zotero app is built on XULRunner/Gecko, but XULRunner was killed by the big brained folks who had the power to do so in an attempt to free up resources for their totally successful designs for the future. Rather than throwing Zotero contributors under the bus and into a potential quagmire of dealing with C++ and Rust compiler output that they don't care about on failed builds, and costing them hours for successful builds (if a successful build is even possible for that contributor's hardware), the Zotero build scripts instead download Firefox and then repack it, et voilà—when you open it you're running Zotero. (Side note: former Mozillian here, and there's no real excuse for why the Firefox contribution process itself hasn't worked like this for the last 10 years except for Mozilla's infamously poor competence at almost all things re project management.)
- In "Open Source is not enough" <http://web.archive.org/web/20150828195814/http://adamspitz.c...>, Spitz succinctly lays out the problem. Open source may remove legal barriers and some of the practical ones, but not enough of the practical ones to actually enable the sort of mastery and control that is often talked about when people describe FOSS. (Spitz uses the term "open source" throughout, which is unfortunate, because Spitz's overall motivation has a lot in common with the GNU philosophy and serves as an incidental critique of the GNU project's actions which perpetuate a world with less of the "software freedom" that it advocates. A casual reader might mike the mistake of thinking that Spitz's essay either treads the same ground as Stallman's Why "Open Source" misses the point of Free Software, or that it is endemic of the problem that Stallman's essay exhorts people to acknowledge [and where the prescription is prioritizing GNU-style "software freedom" over "open source" ideals], although it's neither.)
- The ind.ie folks (now the Small Technology Foundation) attempted(?) to build some mindshare around their Ethical Design Manifesto <https://2017.ind.ie/ethical-design/>. I think this, too, makes an unfortunate choice of words, but despite the name, I see it as aligned with what Spitz and others are trying to shed light on. Funnily enough, I recently contacted one of the Small Tech folks about a simple error on one of their pages, where the fix for it was straightforward—fixing a typo, or fixing a broken link or removing it or something like that. The response was essentially an acknowledgement of the problem and an admission that it wouldn't be fixed immediately, as a nod to how mildly cumbersome it would be go in and make the change. Deep lessons about malleability and habitability (see below) lie here, waiting to be absorbed.
- In "Free software is not enough" <https://jfred.dreamwidth.org/479.html>, jfred relies unknowingly on an eerily similar hook as the one from Spitz's take. The problem described is the same, but jfred goes on in more detail, with references to Smalltalk and OLPC, and to its further benefit does so by referring throughout to "free software", thus avoiding the pitfall in Spitz's piece. jfred also introduces something that will probably prove useful in the long run if we are to actually address this problem: the notion of what he calls practical user freedom, nudging us to discuss it in the same terms. (I know at least one other person, Mike Gerwitz, who's claimed to at least have used or thought about using the same term privately.) Also of interest is that jfred uses modifying one's web browser as an example as well.
- Independently, on the mailing lists for IceCat—the official project to maintain a FSF-approved fork of Firefox—there are occasional mentions of folks' inability to get the thing to build. I suspect there are many more private failures than public mentions, maybe even 10 to 1. In fact, in the past, I've explicitly referenced the problem here on HN and elsewhere of what is probably tens of thousands of potential contributors who quietly drop out after a private bout of trying to do basic things that any given project's own maintainers and existing contributors take for granted, like just achieving a successful build from source. I'm fond of referencing Soledad Penadés's post "How to keep contributors when they are not even contributors yet" <https://soledadpenades.com/posts/2015/how-to-keep-contributo...>, although granted I do so much for the title than the content, really. In that vein, more recently I've taken to pointing people towards Maxime Chevalier-Boisvert's "They Might Never Tell You It's Broken" <https://pointersgonewild.com/2019/11/02/they-might-never-tel...>. Considering GNU's advocacy and messaging about what the IceCat project means for software freedom, in contrast to the reality of the situation, this is a problem. When I take this in at the same time as contemplating what has to be mountains of unactualized talent and aborted attempts to expand software freedom in light of so many people quietly scuttling their work after a failure reach the most basic milestone of being able to reproduce the conditions for a successful build and then to achieve one, I can't help but think about Feynman's comments wrt the oil drop experiment and his exhortations about what not to "fool ourselves" about. It doesn't quite fit, but the connection is there in my mind.
- More recently, I've re-visited Kartik Agaram's essay on "habitability" <http://akkartik.name/post/habitability>. Most people have failed to achieve systems that exhibit habitability. Not just ordinary non-programmers of the sort that would first come to mind when you read an essay like "An app can be a home-cooked meal" <https://www.robinsloan.com/notes/home-cooked-app/>, but as shown in the Small Tech and IceCat examples, the principled FOSS types fail to achieve it for themselves, too. So how can they hope to achieve it in systems that other computer operators are supposed to be able to inhabit?
- The Malleable Systems Collective <https://malleable.systems/> was introduced this past spring, but seems to have fizzled since then, possibly due to COVID-related dampening effects. I think the term is a useful one, although I'm still seeking something that fits in between "habitability" and "malleable" but manages to be something like 5–10x more useful because of its "obvious" meaning. I suspect that in the meantime I will get a lot of mileage by relying for now on terms like "practical software freedom" and others' being adequately initiated to be able to understand what that means.
- Stanislav at Loper OS lays lays down his Seven Laws of Sane Personal Computing <http://www.loper-os.org/?p=284>. Each one is interesting and worthy of consideration, but what I see as the most pressing matter is Law IV - Preserves meaning. What I see as a major problem is the continued use of 1980s-era infrastructure and practices. Compilers conceived originally as a tool to enable "autocoding" to a given machine's instruction set gave way to the now-familiar division between source code and the "binary" executables that are produced by mangling the source code. By now, doing away with traditional compilation entirely should be feasible by JITting everything—or caching the products but in such a way that the average programmer cares about them and deals with them no more than the typical programmer cares about and deals with the actual machine instructions that the compiler's code generator stuffs into the binary. That's one way to go, and probably what we should ultimately aim for. Another way to would be to adopt "non-destructive compilation" techniques to bring about a world where "package distribution is source distribution" at least in the interim <https://wiki.triplescripts.org/wiki/SDIPD>.
To summarize, part of a reason why the enemy that GNU seeks to take down manages to persist is due to a failure to acknowledge the circumstances that allow it to, and a failure to look back, see where and how the current strategy has failed, is continuing to fail, and indeed sometimes exacerbates the problem, and adjust accordingly.
I think it should be clear by this point, but none of the above is meant to say anything like, "The GNU philosophy is bad; choose BSD/MIT/ISC instead", a conflict which the GNU Project unfortunately directs too much attention to. You can just look at history and even the comments on this post to get a feel for how much human attention and energy has been wasted in that vein. So I add this only as a pre-emptive attempt to ward off low-effort and ill-considered potshots, because what I'm saying is very much the opposite—GNU doesn't go far enough.