Even GNU's philosophy has a few puzzle pieces missing from the box.
- 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.
Thanks for mentioning all these great articles and efforts! :) I hope more people will explore everything you've listed here. As you say, we need to go even further and more radical than e.g. GNU to address the tar pit we find ourselves in today, and so the more we can get people imagining what the future could be like, the better.
> (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.)
As a former Mozillian myself, I agree it's quite sad that so many paths that would have eased contribution and supported a universe of surrounding projects were sacrificed on the altar of Firefox. The management team at Mozilla doesn't seem to understand the huge impact the organisation could have had by supporting a whole ecosystem and way of building / thinking about software.
> 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.
(With my Malleable Systems Collective organiser hat on...) I think it's been a difficult year for most people, and it has been harder than I hoped to find time for this effort in 2020. Actually though, the website is a bit deceptive: while the blog has been pretty quiet, the Matrix room (https://matrix.to/#/#malleable-systems:matrix.org) has an active community regularly trading ideas in this space.
I'm hoping to have some more time and energy in 2021 for both experiments and writing that add to both the collective and the more general conversation that you are highlighting here.
>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.
jfred here from that link; thanks for putting together this summary. I'd seen some of these before (I mentioned the Malleable Systems Collective in the post) but I hadn't seen some others, and it's nice to see all of these in one place.
>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>.
GNU Guix does this to some extent. Guix packages are build definitions that refer directly to upstream source URLs rather than source tarballs or binary packages, and while there are typically binary packages available (as long as they've been built on CI, which they aren't always - resource constraints, etc) it's always possible to build any given package locally with `guix build <package name>`. The ergonomics around trying out modifications of these package definitions locally aren't as nice as I'd like, but it's been improving.
> The ergonomics around trying out modifications of these package definitions locally aren't as nice as I'd like, but it's been improving.
I'd be curious to hear what kind of modifications you do and how they can be made more comfortable. I suppose you are using object inheritance in a channel, file or manifest?
I haven't done that much, but generally those modifications are things like... adding a new package, updating an existing package, etc.
As for how, it depends on what I'm doing. If I'm modifying a single package, I might reach for inheritance first (in a file or manifest), although it depends on whether or not that package is at the end of a dependency chain. If it is, inheritance is fine; I'll inherit the upstream version first, change a few fields, and try building/installing it. If not, though, I might be trying to update a library but the program I really care about is an application further down the chain; then I'll typically work from a local Guix checkout so that I can update the library then install the application.
Regarding the ergonomics of each of these:
- If I'm doing something that involves working on a Guix checkout... well, that involves looking up where to find Guix's source code, `git clone`ing it, finding the Guix revision I'm currently on with `guix describe` so I can check out the same one for consistency's sake, `make`ing it, `guix environment guix`, using `pre-inst-env`, etc. I don't really have a problem doing this, but I've also been working with Git and GNU/Linux for years now. It's not very approachable to beginners. Don't get me wrong, it's easier to make changes to Guix than it is to most distros, but I still think it could be better.
- Inheritance can be pretty convenient, but of course when you finish working on something and want to go contribute a patch, you have to go get yourself a Guix checkout anyway and copy your changes over.
I think in my ideal world, there would be a command like `guix edit`, where `guix edit foo` would do something like... give you a local editable checkout of Guix, open an editor to the file at the line where the start of the package is, give the user a quick way to build their new package, etc. I haven't thought through exactly what the UX would be, but essentially the idea is to have the closest thing possible to an "edit source of <package>" button. Bonus points if it can walk the user through the upstream contribution process, and maybe automate the more trivial commit messages for things like adding a new package. I always have to look up that format as I don't contribute packages very often.
This is not to say that what's going on behind the scenes should be completely hidden (verbose flag that shows what commands you could have run?), but providing a simple on-ramp to contributions that doesn't require much pre-existing knowledge is huge for engaging beginners (and even non-beginners who just don't have much time on their hands).
Thanks for the detailed reply! I think most Guix hackers are so used to working directly with a git branch that we forget to cater for "power users" who just want some small edits here and there.
Guix is very hackable as you mention, but with a very different design from e.g. Gentoo, where you can easily override anything in /etc/portage.
I like your 'guix edit' idea; the command already exists, but it opens a read-only copy of the Guix source code by default... It would be really nice to add a tutorial of sorts to it and make it interactive.
I agree that the onboarding story could be better. If emacs-guix could guide a user all the way from 'guix edit' to 'git send-email' that would be nothing short of incredible.
Excellent post, with deep rich thoughts and citations, thank you for taking the time to write it all up! Especially your summaries and comparisons of points not explicitly stated in the links, they're gold. It rings true with what I learned working on TomTom Home based on xulrunner, and looking into the python/PyGTK/xulrunner/javascript integration stuff for the OLPC, used by the "Browse" activity.
Thanks, Don. I consider this high praise. I suppose I was unintentionally channelling your style. Just trying to provide synthesis and direct attention at some nuance that usually doesn't show up when this topic gets perennially brought to the fore.
Messy as my piece above is, hopefully there's enough there and/or it's received at a deep enough level for a sufficient number of folks that it doesn't smolder out. There's a flame here that I'd like to see kept alive and hopefully renewed, ideally at a frequency matching how often these discussions periodically reappear, or at a minimum some fraction of that—at least until we've arrived in utopia.
>The View Source button fn-space and some alternative key combinations in particular activities allow one to look behind the activity, peeling away layers of abstraction in order to reveal the underlying codebase which makes it tick. This feature will integrate cleanly with the Develop activity, encouraging children to view, modify, and redistribute variations on the activities they use. Through collaboration and sharing, a garden of home grown activities will begin to develop on the laptops, created by the children themselves.
> 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.
This has some resemblance to the "Capability theory" by Sen and Nussbaum in political philosophy (or development economics, or however you want to classify it). As a very short example, various political freedoms someone may have are but so many empty words on paper if said person doesn't have any practical means of exercising those freedoms.
> 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 the hardware), the Zotero build scripts instead download Firefox and then repack it, et voilà—when you open it you're running Zotero.
IIRC the plan was for Zotero to rebase on Electron, though I haven't followed how this project has proceeded.
Have you seen Morgan Dixon's "Prefab", and his ideas about pixel-based reverse engineering and modifiable user interfaces? One of his papers asks, "What if Every GUI Were Open-Source?"
Video: Prefab: What if We Could Modify Any Interface? Target aware pointing techniques, bubble cursor, sticky icons, adding advanced behaviors to existing interfaces, independent of the tools used to implement those interfaces, platform agnostic enhancements, same Prefab code works on Windows and Mac, and across remote desktops, widget state awareness, widget transition tracking, side views, parameter preview spectrums for multi-parameter space exploration, prefab implements parameter spectrum preview interfaces for both unmodified Gimp and Photoshop: http://www.youtube.com/watch?v=lju6IIteg9Q
Video: Content and Hierarchy in Prefab: What if anybody could modify any interface? Reverse engineering guis from their pixels, addresses hierarchy and content, identifying hierarchical tree structure, recognizing text, stencil based tutorials, adaptive gui visualization, ephemeral adaptation technique for arbitrary desktop interfaces, dynamic interface language translation, UI customization, re-rendering widgets, Skype favorite widgets tab: http://www.youtube.com/watch?v=w4S5ZtnaUKE
PDF: Prefab: What if Every GUI Were Open-Source? Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 851-854. https://web.archive.org/web/20141024012013/http://homes.cs.w...
>ABSTRACT:
Current methods for implementing graphical user interfaces
create fundamental challenges for HCI research and
practice. Researchers are often unable to demonstrate or
evaluate new techniques beyond small toy applications, and
practitioners are often unable to adopt methods from the
literature in new and existing applications. This position
statement examines a vision in which anybody can modify
any GUI of any application, similar to a scenario where
every GUI of every application is open-source. We are
currently working to enable this vision through our
development of Prefab, using pixel-based interpretation of
GUIs to enable modification of those GUIs without any
cooperation from the underlying application. We see
participation in the FLOSS HCI workshop as valuable in at
least two regards. First, fully realizing this vision will likely
require a community-based approach, so we are interested
in Prefab as a platform for collaboration between HCI
researchers and the FLOSS community. Second, enabling
arbitrary modification of any GUI would seem to blur many
current distinctions between open and closed applications,
introducing new research questions and further magnifying
the importance of the workshop’s focus.
- 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.