đŸ Archived View for tranarchy.fish âș ~rowan âș writing âș ver2.gmi captured on 2023-01-29 at 03:01:28. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
<- Back to writing -- Gender Delenda Est -- Gemini
âEvery program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.â - Jamie Zawinski aka jwz
âFeature creepâ, âsoftware bloatâ, and other such problems are well known to virtually all programmers (even if they show little awareness of it), and to many lay-users of electronic systems as well. In short: existing tools and servicesâespecially popular onesâhave a tendency to accrue new features to an absurd degree. jwzâs observation might today be better put in terms of the apparently inescapable tendency of all applications to somehow integrate with the Twitter API rather than email, but the point stands.
I believe these tendencies are actively harmful to the sustainability of the cyberspace with(in) which much of our life is now interfaced, and express not merely poor practice among the engineers of these systems but are an effect of wider deleterious social systems (imperialist racial capitalism). In their ownâsometimes but not always smallâway, the problems created by unnecessarily expanding software express and perpetuate the effects of these systems. Those of us committed to opposing such social ills should recognise this and work to avoid reinforcing their effects, and to understand how to recognise and avert their logics where they might appear in our own communities and praxis.
The title of this article refers to two conventions in computing. The first is the phrase âconsidered harmfulâ, coined by Edsger Dijkstra in his 1968 memo <em>Go To Statement Considered Harmful</em>, which has become something of an in-joke method of criticising or otherwise advocating against a particular feature or practice in the field.
The second is the Semantic Versioning (SemVer) standard for version numbers, which provides an easily-interpretable format for software version numbers. In the language of SemVer, 2.0.0 indicates the first version of a piece of software that, due to some change in features or tool set, is no longer compatible with the first full/finished version of itself (version 1.0.0). Somewhere in the development of version 2.0.0 it has been decided that it is more important to transform or expand the feature set than to maintain its compatibility or original scope.
Hence âVersion 2.0.0 Considered Harmfulâ: extending software (or other tools) beyond their original scope, especially to the point at which they actually cannot reliably work with the products of their original versions, is damaging to the efficacy of the tools and the social system that uses them.
I think the most basic guard against these risks is in our choice of tools. When I wish to edit text I, where at all possible, do so in a program that allows me to directly edit the whole plain text of a document. Where I want to create some kind of formatting or structuring, I use a markup language such as Textile, Markdown, or HTML. If the exact parameters of display are important HTML/CSS or LaTeX provide plenty of flexibility in the specifics of typesetting (and Pandoc does a perfectly good job of moving between formats).
This kind of specificity is possible in all sorts of applications and is, I think, desirable. I do not want an image processor that allows me to post directly to Twitter, or GUI integration between my reference manager, my browser, and a word-processor. What I <em>want</em> is a functional, straightforward, and reasonably lightweight tool for each of these functions that uses accessible and open formats.
Open formats are desirable as they allow different software and hardware to reasonably consistently access and interpret the same information. While I have particular aesthetic and utility opinions about what I like, others might have different requirements. Even for one user, it can often be useful to have both GUI and command line tools for similar jobs. Nevertheless, it should be possible for us all to work in ways that can be interpreted with a variety of different utilities.
Of course, this means that the process of producing most materials and projects will be a multipart process, requiring a few different tools and applications, but this also means that each of these tools is far more likely to be simple, flexible, replaceable, and understandable by the user.
It is precisely this comprehensibility and modularity that has been captured and eroded by the corporations behind the modern software ecosystem. The integration of functions and the apparent simplicity of having a single application for a wide range of functions was sold as a way of making functionality more accessible but has, in general obscured things. WYSIWYG might make the results of an operation more clear, but usually obscures why those results have appeared (and how to fix or prevent undesirable results). Where the applications and tools that we use are obfuscated and enclosed it is difficult to reliably predict the result of operations and difficult to flexibly work between different tools and systems.
Proprietary formats lock whole teams and organisationsâlet alone individualsâinto using the products of a single corporation regardless of how well they suit everyoneâs needs. This is where the logics of capitalist enclosure become central: if a corporation, through integration, deals with other groups, and market dominance can force its products into enough workflows, it can begin to fully enclose the means of production of certain media. In some areas Microsoft have begun to achieve this with regard to word processing just as Google and Amazon have with much of the web. If your colleague sends the draft of the paper youâre working on around for edits as a .docx (or, worse, .doc) your ability to use much else than Microsoft Word (or, if youâre persistent and enjoy terrible UX, LibreOffice) to give them convenient feedback is limited.
These fixed and proprietary systems also enable surveillance. The dominance of a whole workflow or large space of technology (e.g. web hosting) by very few, very large entities makes it extremely easy and extremely profitable for them to accumulate large amounts of data on users both for themselves and for resale. This data is also, inevitably, available to the state, and provides the capacity for extensive and invasive control over large populations.
Rather than having the flexibility to dictate what tools we enjoy using and building our systems around this modularity and personalisation, the modern software ecosystem has been defined by a few sets of increasingly feature-heavy monolithic applications that try to do everything. In fact, they prevent users from having agency over their work and prevent everyone from having the ability to use the tools that are most useful for them. It is not desirable to have one application that âdoes it allâ, but rather to have many options and the ability to do precisely and specifically those things that we want to do.
The enclosure and monopolisation of software has also had terrible effects on the ability of most people to fix problems in their workflow. Closed source, large-scale, and non-modifiable applications make it difficult for even those with a decent level of technical knowledge to fix problems of any real complexity that might arise. Lay-users, on the other hand, are actively discouraged from developing any familiarity with the actual processes of digital (or often even physical) production, instead being made experts only in navigating corporate UI.
The Linux repository system offers an obvious example of a really-existing implementation (with the attendant flaws of real-world implementation) of a system that allows users to flexibly add and remove many different elements which can, in many instances, work together to form more complicated workflows. It, of course, does not necessarily actually clarify the operations of those components, many of which suffer from precisely the software bloat I described aboveâa true solution might never be possible, but would involve a deep rethink of how we approach the design of the tools we use for computing.
I strongly believe in the importance of building systems that can be mended and adapted by at least some significant subset of their actual userbase. Of course not everyone will understand how to fix everything, but we should at least aim to build systems that are clear about how they work and allow those with an interest to modify them. Tools made to be repaired and modified empower creativity beyond the purview of capitalist imperatives and allow independent communities of users to sustain themselves without constantly paying for upkeep or being subject to unilaterally imposed changes in workflow or functionality that could derail their practices entirely.
The role of limitations in promoting creativity is widely discussed elsewhere, however I think it provides a good starting point for my reasoning about why I think that not only does the approach to technology and tools I have outlined here make for good and sustainable workflows, but also for good art.
The bigger a tool gets, the more generalisations and approximations it tends to make about what âmost peopleâ will want from it. In some respects this can make our lives easier, but it also tends to railroad us into narrow and conventionalised practices: writing stave-notation scores is not particularly conducive to a thoughtful relationship to tunings, scale systems, or harmonies outside relatively limited western traditions. Using a set of small tools flexibly opens the possibility of creating new assemblages of creative practice that afford potentially thoroughly novel outcomes.
Even where these tools are sometimes more inconvenient to make mesh together than larger, more cohesive systems, that friction can be instructive. Understanding <em>why</em> a particular image format can or cannot be processed a particular way makes us think more deeply about the material content of the objects we construct and, possibly, from there come to new ideas about how to explore or change that content in expressive and interesting ways. Thus I believe that even where these tools are âworseâ or slower than other methods they are often all the more interesting for it.
N.B. A lot of my favourite art comes (at least in part) from this kind of introspection about media. The subtleties of a Rothko would be impossible without a deep attention to the qualities of paint.
As mentioned above, a complete or thorough implementation of these ideas is probably impossible, at least in any practical, short term sense. I do try, however, to work as closely to these principles as I can.
This means using open-source tools and doing my best to have some understanding of how hardware that I use works (which gives me a bit of a predilection for simpler, analogue technology such as film cameras). It also means trying my best to think carefully about what it is that I value in a particular tool, what features I actually want from it, and thus what implementation or version of it suits me best (rather than simply using whichever seems simplest or comes most easily to hand).
We should work where we can to ensure that participation in community does not, de facto, mean compliance with surveillance, punitive schemes of intellectual property, or even simply the constant expense of using tools designed by rent-seeking, for-profit corporations.
Of course doing this might not be possible where workflows are dictated by professional constraints, the need for rapid turnaround, or some other social/material pressure. But I am making a Utopian and prefigurative claim: a world where we are able to take the time to carefully think about what we make and how we make it, and given the agency to adjust and maintain these ourselves is a better one than this, and something worth striving for in our work.