Art Meets Radical Openness as debugging together: The 2022 edition of the festival AMRO in June is dedicated to the rituals and the philosophies of debugging. This will be taken as starting point for a conversation between artists, groups and communities moving together between the fields of culture, politics and technologies. Davide Bevilaqua and the AMRO community about the wider context.
In this text we’ll unpack the festival motto debug from the technological connotation to a wider understanding in terms of knowledge sharing and community practices. Those are at the core of the Art Meets Radical Openness spirit and we are looking forward to see them happening again in Linz at AMRO22, 15th – 18th June 2022.
The various thoughts that built the skeleton of AMRO22 emerged over multiple conversation with the AMRO community and participants. Other two texts published in the current edition of the Referentin will deepen the conceptual core of debug, one connecting it to the idea of pancomputationalism, another dealing with shared, feminist server infrastructure.
When reality is shaped by tech, can we debug it?
In the long tail of the global pandemic and in the middle of a war, probably nothing needs to be said to convince the reader that we live in an era in which the effect of the networked technologies permeate more and more in the public and private spaces within our societies. Writer and artist James Bridle suggests that the much advertised networked infrastructures – in combination with the rampant destabilizing effects of climate change and the only apparently non-logical dynamics of the globalized geopolitical tensions – are mostly causing the erosion of our capacity of understanding the world around us, rather than contributing to its improvement. According to Bridle, the consequences of the widespread adoption of technologies is de facto co-responsible for the emergence of characteristics similar to the ones of a New Dark Age1, in which the complexity and concurrencies of immediate, world-scaled computation machineries push us into conspiracies or collective, cognitive misestimation. At the core of this there is a self-enforcing loop: we are lost in the ways each one of us relates to the surrounding world, and yet tent to turn to the same sources of incomprehension to make order, generating a feedback loop of mismatched readings.
The effects of climate change are warning signs of an environmentally harmful behavior; psychological and social disorders, economic imbalances, the loss of a reality system, or the potent return of history in a too-long ignored war building process. All of these can be read as signs of the end of the epoch commonly known as Western modernity, that was maybe naively thought as everlasting and that now is defenitely in a moment of crisis and shifting of values, if not more. What to do now? Even if we are not necessarily approaching the end of our epoch as the philosopher Federico Campagna echoes in Technic and Magic,2 it seems nevertheless urgent to reflect on which values to retain for the future and which ones we should abandon.
Seeing our era so influenced by faulty technological processes, we wonder if a hint for a solution might come from problem-solving practices that emerge from the same technological space. Within the festival program, we reflect how some concepts relating to debugging might help imagine strategies to deal with this scenario of constant emergency and overall uncertainty.
This is grounded on the idea that the any own instrument – from the technical till the conceptual ones – is potentially fallible, and that one can then choose to challenge that imprecision and try to overcome bugs and limits. A whole different image of technology is needed here, seeing machines as situated and needing constant care, with the practice of tool maintainance as a knowledge generation one happening in communities. Those aspects will be deepened in the various program points of AMRO22 debug.
Bugs scratch the surface of the digital
Bugs might be the causes of a program crashing or the browser window gets stuck; or when the developers’ biases come to surface or where the limits of the current infrastructure are reached. In the last months we also got accustomed to the idea that bugs emerge also due to geopolitical or company-strategic decisions, proving once more the ephemeral irresistibility of the globalized and industrialized world. Not all of these errors, unavailabilities or bad functioning are due to the presence of an engineering bug in its strict sense, yet they appear of interest and shall be included in a wider discussion dealing with debugging.
Under the eyes of radical openness, software bugs are therefore much more than simple engineering mistakes. They are the moments in which this surface-tension of perfection and infallibility of the ubiquituous machinery is broken and its inner logic gets briefly exposed – like the glitch in the matrix.
Where technology fails, computer systems appear as what they are: funky, unstable conglomerates of functions, thrown together from different people in different times, at the point that they are barely working, needing constant care and fixes. This is one of the big conceptual shifts from the most known image of the abstract and perfect technology to the one of a situated technology that is in perpetuous exchange with its surroundings, susceptible to temporal and modal changes of it. Like the famous Mark II of the University of Harvard, whose malfunctioning was due to an actual bug hidden in a relay discovered by Admiral and computer scientist Grace Hopper3; something conceptually very unexpected, but in reality quite likely to happen considering how large these machines and their electromechanical component were.
With this in mind, bugs, mistakes and crashes start looking like some of the fundamental features of the current era of ubiquitous technologies, features that contribute demistify tech and call for action and personal and communitarian engagement. Acknowledgeing the faultiness of the infrastructure is fundamental, but one should go further than superficially making glitch into an art form; rather metabolizing its fault and using that to learn and build something new.
Debugging is the line where the unknown starts and ends
In software development, debugging comprises a set of more or less formalized practices to go through computer failure and try solving it. Seeing it in a wider context, it is not such an elitary activity, but rather an everyday action taken whenever a devices does not work as expected.
Most of the times malfunctionings are in fact solved with a simple restart of the affected device, the classic turning it off and on again. Some other times, fixing it means opening the black box and checking its inner functions, and step by step excluding the working parts to isolate what needs to be fixed or removed to insure the smooth functioning of the machine – such as Hopper’s moth. And finally, some debugging strategies might imply the adoption of a completely different tool. It is not only about isolating the problem, but also recognizing what works well and finding a new workable equilibrium, maybe with a smart hack or with some freshly gathered knowledge coming from the community.
The intention of AMRO22 is to envision debugging as a larger spectrum of practices that start from the technical realm and are then applied in the form of observational strategies also in other fields4. When performed within a non-working system, debugging helps the debugger to formulate and verify hypothesis about the inner processes of the system. It does not require complicated actions, but an open spirit of observation and a system of trial and error to solve or circumvent the narrowpasses. This helps understanding debugging as a process of knowledge creation rather than one of a mere problem finding and fixing, in which information and experiences on a specific problem is tested and accumulated.
Under this light, we could also find in debugging the quality that Deleuze found in the practice of writing, that is happening on the border between ignorance and knowledge5, and specifically progressively transforming the first in the latter.
Debugging as practice of knowledge sharing
Lastly, we are interested in the ways this knowledge is shared and circulates amongst different communities.
One of the many mottos from the communities of Free and Libre Open Source Softwares is “given enough eyeballs, all bugs are shallow”, also known as Linus’s law6 – meaning that the more reviewers see a specific software problem, the quicker a possible solution will emerge. The presence of many eyes – or a community – offers the ground for a wider generation of information and the sharing of experiences. This knowledge is transmitted and can be stored for a later use of the same communities or made available for other groups; documentation of debugging practices becomes here a process of recurrent adoption, verification and validation or extension of the pre-existent notes.
The strategies through which this happens are specific and independently found for any community of interests or practice and might vary a lot in style and formats – also due to the specific case in which the notes are taken and how they should be accessed in a second moment. They can be a technical documentation on a wiki, or a cooperative text resumè in an etherpad; also a picture of a post-it wall or an artwork might help in bringing knowledge further in the future.
Here is where debugging might cease to be a mere technological problem-solving solution and becomes an attitude of radical openness; creating a social environment prone to self critique and therefore, at least in theory, a bit more protected from the dangers of the current technological-driven individualization.
Embracing the bugs appears to be therefore more important than avoiding them in the first place.
1 James Bridle, New Dark Age: Technology and the End of the Future, Verso, 2018.
2 Federico Campagna, Technic and Magic. The Reconstruction of Reality, Bloomsbury Publishing, 2018
3 www.howtogeek.com/726020/what-is-a-computer-bug-and-where-did-the-term-come-from (retrieved 12 May 2022)
4 Check The Techno-Galactic Guide to Software Observation. Methods from the Techno-Galactic Software Observatory, Constant, Brussels, 2018. www.books.constantvzw.org/home/tgso
5 Gilles Deleuze, Difference and Repetition, 1968, preface.
6 en.wikipedia.org/wiki/Linus’s_law
* commons.wikimedia.org/wiki/File:First_Computer_Bug,_1945.jpg This file is a work of a sailor or employee of the U.S. Navy, taken or made as part of that person’s official duties. As a work of the U.S. federal government, it is in the public domain in the United States.
** AMRO22 design by Juan Pablo Linares. Sujet concept was developed in a group workshop with Christoph Haag.
AMRO22 – Art Meets Radical Openness DEBUG
15th–18th June 2022
afo – architekturforum oberösterreich, Stadtwerkstatt, Kunstuniversität Linz, and more.
art-meets.radical-openness.org
