<!--

# Cornelia Sollfrank

# Winnie Soon

-->

<head><title>Fix My Code</title>

<p class=h2>Published by EECLECTIC</p>

INTRODUCTION

Chapter 1:

BROKEN CODE

Chapter 2:

SERVICE NOT AVAILABLE

Chapter 3:

COLLABORATIVE CREATION

Chapter 4:

CARING COLLECTIVELY

EPILOGUE

<!--

# Meta Content

-->

<head><title>Fix My Code</title>

<p class=h2>INTRODUCTION</p>

<p class=author>Cornelia Sollfrank and Winnie Soon</p>

A legendary project and its ability to connect itself again and again to ever-new discourses and thus to constantly update itself is the focus of this publication. The net.art generator (nag) is a computer program that interactively collects and recombines material from the internet to create collages. The easy-to-use program requires the user to enter a title which then functions as the search term, and to enter a name as author. The resulting images and websites are stored online in an archive where recent results can be downloaded.

Conceived by Cornelia Sollfrank in 1998, the nag has created endless texts, websites, and images, and has also generated a number of discourses – most notable in the context of authorship, copyright, and open source.1 As one of the first works of emerging net art, it was the basis for a number of spectacular interventions and is working through its program to this day: generating art and discourse.

Screenshot nag_05 interface at https://nag.iap.de

Despite its apparent simplicity, the nag is able to connect to new discourses, to exemplify them and make them graspable. In his discussion of the nag, Danish curator Jacob Lillemose has suggested the term “conceptual tool” to characterize the workings of such networked production: “Sollfrank directly invites us to continue using the tool, to continue generating images and discourse, and to realize that the tool is about generating open-ended processes, not about the production of specific objects.”2 The processes of creation involve various human and nonhuman actors, and they crystallize around the issues that capture the most energy, that is, attention at the very moment. The notion of the “thinking tool,” however, suggests an even more intended and target-oriented use. First introduced by Femke Snelting, it describes a material practice that raises fundamental questions that would otherwise remain unarticulated.3 And given the long-standing history of the nag and its involvement with so many different discourses, it could almost be thought of as “timeless,” or more adequately, as equipped with a special sensor for the contemporary moment.

Generated image: anonymous-warhol_flowers@Jan_19_21.53.44_2021

Since its launch, the nag has rendered its services faithfully. While occasional periods of unavailability have occurred, it was never the code itself that went on strike but rather its external dependencies. The internet is alive and constantly changing, which is why its inhabitants have to do the same. The most recent disruption has been related to search-engine politics. As the nag technically relies on a search engine for the collection of the material that forms the base for the newly generated collages, the interface to the search process has always been a critical issue. And while operators of commercial search engines have been generously making their search results available, for free for most of the time, consequences of a change in policy in 2015 meant that nothing worked for the nag anymore – it could no longer generate new images. In January 2017, Cornelia reached out to artist-coder Winnie Soon to collaborate on fixing the broken code. As both combine their artistic practice with a research perspective, the collaboration expanded beyond solving the technical problem to a discussion about broader cultural and techno-political issues, such as power relations in technology-based collaborative settings and the role of search engines for art projects. The process of troubleshooting, discussing, decision-making, and amending that followed, however, produced a new discourse, and on the suggestion of Janine Sack, we decided this story to be the new episode in the nag narrative and to serve as the basis for this publication.

Generated image: anonymous-Google_sucks@Aug_24_17.53.02_2017

Technical dysfunctionality was the reason for engaging in a dialogue that we continue to this day, which demonstrates once more the productive aspect of limitations. Most importantly, it made us enter and explore a layer of the project that previously has been rather unattended: its technical side including all the components involved. Departing from the broken code of the nag, caused by a Perl program that failed to request images from Google, we began our journey by exploring the basic code.

The first chapter, therefore, focuses on Perl, a once very popular programming language, and also includes a historical excursion into the early days of programming on the web. It quickly becomes obvious that the software, although a bit dated, is rather stable and that we have to turn our attention to the points where the code connects to external systems, especially the search-engine interface. This dependency in particular and the general question of digital infrastructure that the nag relies on, is discussed in chapter two. In chapter three, we explore the networks the nag is embedded in – not only the technical networks but also the human and the conceptual ones. We discuss all possible and impossible kinds of “collaboration” and connect this aspect, in which power relations play an important role, to the question of gender and technology. This all leads to the question of how a software-based work, which constantly has to evolve with the techno-political developments of the internet, can stay alive. Chapter four, therefore, addresses questions of repair and preservation, in particular the notion of care in relation to artworks that traditionally have been avoided by collections and museums owing to their fragility. As a core statement one could summarize that the nag again is about to generate another discourse, one related to the relevance and the preservation of digital artworks of our time. Who should take responsibility for them, and do we even think they are important enough to care for? While preserving what exists is one way of approaching the problem, another way would be to renew it in order to make it fit for the future.

Sketch by Winnie Soon showing the different components of the net.art generator and their interrelation.

Our journey has brought us close to a professional discourse, the one of art conservation that also gradually opens up to the challenges of digital- and software-based art. We want to emphasize that we are aware of this, to a certain degree, but in contrast to conservators who are scientifically oriented, we consider ourselves to be enthusiasts who have just jumped down the rabbit hole, letting ourselves be surprised by what and whom we meet on the way and without the ambition of establishing new preservation models. Nevertheless, if our book is able to contribute to this discourse, in the sense of “networks of care,” a phrase established by Annet Dekker for the collaboration between institutional and noninstitutional actors in the field,4 we are more than happy.

Once more, the nag lives up to its reputation! It is still a powerful conceptual tool that helps us think through some of the urgent questions of our time while doing so in a playful way. In this book, we use the nag as a tool to help us comprehend some of the complexities of post-digital culture by revealing parts of the hidden and invisible structures that make our daily lives work – until they break down.

The format of the dialogue shall help to keep the language accessible and thus motivate also nonexperts to join in and enjoy the journey. Our different cultural backgrounds and different professional experiences have turned out to be the stimulant for a productive conversation from which we both have gained a lot, and we hope this will be the same for our dear readers.

1 For more details on the project, please see Cornelia Sollfrank, net.art generator (Nürnberg: Verlag für moderne Kunst Nürnberg, 2004); and Cornelia Sollfrank, Expanded Original (Ostfildern: Hatje Cantz Verlag, 2009). Both texts are also available at http://www.artwarez.org.

2 Jacob Lillemose, “Keep on Generating: On Cornelia Sollfrank’s Multiple Authorships, in Sollfrank, Expanded Original, 46. See “Forms of Ongoingness: Interiew with Femke Snelting and Spideralex,” by Cornelia Sollfrank, Creating Commons, September 16, 2018, http://creatingcommons.zhdk.ch/forms-of-ongoingness/.

3 See “Forms of Ongoingness: Interiew with Femke Snelting and Spideralex,” by Cornelia Sollfrank, Creating Commons, September 16, 2018, http://creatingcommons.zhdk.ch/forms-of-ongoingness/.

4 Annet Dekker, “Networks of Care,” in Collecting and Conserving Net Art (London: Routledge, 2018).

Diagrams

<!--

# Fan Mails

-->

<head><title>Fix My Code</title>

<p class=h2>USER MESSAGES</p>

1) Subject: NET ART GENERATOR

Date: 22 October 2015 07:22:38 GMT-04:00

An: nag@artwarez.org

Good morning,

I love so much to create digital art with NAG, since some days it does not work, the message is “Generator process CANCELLED!”

What happens?

Thank you for your feedback,

Maria Luisa

2) Subject: NAG:Mail

Date: 4 November 2015 13:29:13 MEZ

An: nag@artwarez.org

Der Netartgenerator scheint nicht zu funktionieren? Schade.

mfg, Fritz (der Taxifahrer) aus Berlin

3) Subject: The net.art generator is down?

Date: 8 November 2015 06:17:08 GMT-05:00

An: nag@artwarez.org

Hello, let me say first that I’m a big fan of you project, the net art generator (http://nag.iap.de/)

However, when I tried to create another picture today, the generator just doesn’t work. It keeps saying that the generator process is cancelled.

Is this an error? Or has the whole project’s plug has been pulled?

If it was the first case that happens here, would you be so kind as to fix this issue?

Thanks, Malik

4) Subject: Keine Nutzung des Netzkunstgenerators möglich

Date: 10 November 2015 14:08:58 MEZ

An: nag@artwarez.org

Hallo Frau Sollfrank,

ich bin mir sicher dass Sie sehr beschäftigt sind, dennoch hätte ich einige Fragen an Sie und würde mich sehr über eine Antwort von Ihnen freuen.

Ich schreibe zur Zeit meine Bachelorarbeit und habe Ihren Netzkunstgenerator zum Thema. Nun wollte ich für meine Werkbeschreibung eine Collage generieren lassen und mich mal als „Künstlerin“ versuchen und leider zeigt er mir eine Fehlermeldung. Mich würde sehr interessieren warum das kreiren nicht möglich ist und vll ist es auch ein interessanter Aspekt den ich einbringen kann. Zum anderen würde mich sehr interessieren aus welchen Gründen Sie Ihre Quellcodes für die Netzkunstgeneratoren frei gegeben haben?

Mit freundlichen Grüßen,

Lene B.

5) Subject: AW: Net Art Generator seems to be down

Date: 13 November 2015 13:16:22 MEZ

An: nag@artwarez.org

The Net Art Generator seems to be malfunctioning.

I’m a big fan of the N.A.G. and I hope you will be able to get it back up and running soon.

Thank you,

B. Pagani

6) Subject: net.art generator nag is not working

Date: 22 November 2015 06:47:03 MEZ

NAG has been inoperable since Oct 16.

I greatly enjoy and miss that website.

7) Subject: NAG:Mail

Date: 13 Mai 2018 11:48

An: nag@artwarez.org

Hello,

I am a teacher of art in Switzerland and told my students about net art. In former times I used the work of Cornelia Sollfrank to explain. It is a pity that nag_05 will not work anymore. Can you help me?

Thank you for an answer.

Have a nice time,

Alexandra

8) Subject: nag is down?

Date: 18 Mai 2018 18:03:45 MESZ

An: nag@artwarez.org

I was wondering if nag will ever come back?

I found it really fun to use and I have a few ideas of my own I wanna put into action.

Josh

<!--

# Chapter 1

-->

<head><title>Fix My Code</title>

<p class=h2>BROKEN CODE</p>

The first chapter is dedicated to the code that is constitutive for nag. Being a so-called software-based artwork, nag is about formulating a concept of what the machine is supposed to do, about structuring this task in a series of steps, about finding the right language to speak to the machine, and eventually about codifying the task. It is a basic introduction to programming and puts special emphasis on the programming language Perl that was very popular in the early days of the internet. Furthermore, we look into code as material for artistic experiments and artistic software production.

Cornelia Sollfrank: At the heart of nag is a piece of code. It gives the computer all of the instructions necessary to search for relevant image material within the internet, bring it back to the server, recombine it, and display the result on the website. Investigating the technical level of the project, first of all, requires taking a closer look at the level of the actual code, the computer program. Therefore, let’s start with an explanation of what code is.

Winnie Soon: Basically, code (program code) comprises lines with combinations of characters, words, and numbers. Code is written by humans on a computer – with the help of a keyboard – using so-called programming language. Code contains a set of instructions for the computer of what you want it to do. Every line of code tells the computer to do something, and a document full of lines of code is called a program or script. Each script is designed to carry out a specific job (which might involve a number of subtasks).

C: Do you have an example of a simple code? What does it look like?

W: As Perl is used as the programming language for nag, maybe I just use a simple “Hello World” program in Perl.

#!/usr/bin/perl

print ″Hello World\n″;

The first line is a general instruction to tell the computer where, in terms of a directory path, the software Perl is installed. There are people who play with this line, for example, “#!/usr/bin/girl”, which signifies a geeky girl. The use of this line of code has spread widely, and was, for example, used as name of a blog, or it was printed on T-shirts, etc.

See: http://designorphan.blogspot.com/2011/08/usrbingirl.html

Then the second line of code uses the function print followed by the words “Hello World” in double quotes. This refers to the action of printing the values of expression within the double quotation marks. We have two issues here: First, the function print. In terms of human language, it usually relates to printing on paper, like laser printing. In programming, however, print refers to producing or displaying something on the screen. Second, the issue is what to print. Here the “value” is “Hello World” with the indication of a line break at the end (\n). As a result, this simple program will just show the words “Hello World” on the terminal screen.

The screen walk-through below shows you how to run the program:

1) Save the source code as a file, e.g., hello.pl (with a code editor like Atom or Notepad).

2) Open the terminal screen.

3) Type “perl”in the terminal screen and then drag the saved file there so you can locate the correct file path.

4) Run the code by pressing the enter key of the keyboard.

Running the “Hello World” program from the terminal screen

C: Why has this “Hello World” example become so iconic? The main thing I can comprehend is that there are many technical processes involved between the typing of a letter – or in this case two words – on a keyboard and this phrase appearing on my screen …

W: These kinds of “Hello World” programs (or “Hello, World!”) have a long history in computing and they are typically used to introduce programming languages to beginners. First, it is easy to comprehend in terms of length and the use of simple natural language (just one function with one line of code), and second, it can be used to make sure that the setup has been done properly (because sometimes you might not have the right server or libraries or software to run the program), and lastly, you can immediately see the feedback of the computer in turning code into action, which is very rewarding. It indicates that the computer is executing the instruction correctly. Such feedback gives you a feeling of empowerment; it produces a sense of achievement that you can control the computer and generate an expected result.

C: You mentioned the setup earlier. What is needed to run the program on your personal computer? What are the basic requirements for writing code, for running it, and how does it connect to the internet?

W: If you want to start engaging with Perl, it is pretty easy. Most computers today come with the Perl software preinstalled. You can simply write a piece of code in a notepad (or a code editor like Atom) and save the file with the extension “.pl.” Then you can run the program in the terminal window. Unlike the graphical user interface that many people are used to, terminal is a text-based interface for giving instructions in command lines and executing these instructions. An example would be the command to list all files in a directory, or copy a file from one place to another.

To check if you have Perl installed on your computer and what version of Perl, type the command below in your terminal window:

perl -v

In case it is not preinstalled on your computer, you can download it and install it yourself. See: https://tutorial.djangogirls.org/en/intro_to_command_line/

To run your first program, you can try copying the previous “Hello World” script and save it as “hello.pl.” Then go to the terminal and type (make sure the default directory of the terminal is the same as the directory that you have saved the script):

perl hello.pl

You should be able to see the “Hello World” message printed on your screen now.

Useful references for getting started:

1. To install Perl: https://learn.perl.org/installing/

2. Introduction to command-line interface by Django Girls Tutorial: https://tutorial.djangogirls.org/en/intro_to_command_line/

3. Code editor by Django Girls Tutorial: https://tutorial.djangogirls.org/en/code_editor/

C: I think, it would be nice to have a first glance at the code of nag at this point. Can you find us a good excerpt?

W: It is a rather long snippet, but if you take a closer look, there are many print functions (which you already know) and the content is something easily readable by humans. I personally find this so-called double coding very exciting: it is code readable for both humans and machines, and as a result a number of tensions arise …

if ($ilist[0] eq ″dailyLimitExceeded″ || $ilist[0] eq ″rateLimitExceeded″){ #dailyLimitExceeded/#rateLimitExceeded - msg by Google

push(@err,″<p>Thanks for using nag_05! Unfortunately, it seems as if the limit of queries has already been exceeded! </p>

<p>For our search we rely on the results of Google image search. Currently, there is a limitation of 100 requests per day as set by Google for nonpaying customers like our net.art project. </p>

<p>We do our best to keep the nag alive. However, there is no funding to pay for Google and there is no guarantee with the service due to the ever-changing terms, conditions, and policies of Google. </p>

<p>In the long run, we are working on teaching Google about how they can support art on the internet in a meaningful way, but there is a long way to go ;-) </p>

<p>For now, be patient and come back tomorrow! </p>″);

print ″<center>Generator process cancelled!</center>\n″;

print &endPanel;

}else{

...

}

The code above is about the error message that the nag receives from the Google API (Application Programming Interface, an interface to exchange data at the code level) if the number of daily requests is exhausted. The first line with the “if” statement is to check Google’s responses, and if the response is equal (“eq”) to “dailyLimitExceeded” or “rateLimitExceeded,” which is not the actual list of search results, then the program will print the error message and stop the process of image generation.

Basically, I find this piece of code to be one of the most interesting ones of the nag, because it is about checking if there are any errors related to the Google image search and if so then displaying the customized error message. In my opinion, this is the essence of the latest version of the program, nag_05b, because it is about providing a “service” that is both workable and not workable, and by doing so, revealing certain forms of network politics. By receiving this simple error message, the whole program is forced to stop; nothing can be generated and displayed anymore.

C: Actually, we have prepared four screenshots showing parts of the nag code. Let’s have a look at the next piece of code. Can you please explain what we see here? What is the instruction given in these lines?

W: The four sections I selected all show parts of the code I spent a lot of time with, trying to decipher. As you know, I started to learn Perl only when getting involved with the nag.

Code snippet: The parameters of the Search API

The code above communicates with the search engine. It describes the parameters that are passed to the search API, including the unique API key that belongs to the nag owner, and the search engine ID. There are also other standard fields, such as the search keywords that the user types as input (e.g., warhol+flowers), the search type (e.g., image), the type of image file (e.g., JPEG or PNG), and the image size (e.g., xxlarge) as well as the search safety level that is established by the platform. The final line gives the instruction to put all the parameters together in one long URL and pass it on to the platform as a “request.”

What also fascinates me as a researcher is to think about what is being returned by Google. What did the search engine choose to make available? Could we know how Google prioritizes images or calculates their relevance because this is not described in the API specification. I did separate research about the politics of APIs with my collaborator Eric Snodgrass using historical analysis and the nag as our case study to investigate the forms of control in such protocological exchanges, regarding terms of service, specific operational processes, and affordances of fetching networked data. We also give a few suggestions on how anyone working with APIs might think through certain key questions around the creation and use of APIs, particularly with regard to the parameters of openness, accessibility, and inclusivity that APIs set for practices of knowing, sharing, participation, and exchange.

For more details, see: https://firstmonday.org/ojs/index.php/fm/article/view/9553/7721

ImageMagick

W: The next screenshot is related to a Perl library called ImageMagick. It is a free and open-source software library that enables image modification and recomposition. This library has been used in all versions of nag_05, so I didn’t have to make any changes for the update. Nevertheless, this part of the code is important for me to understand – out of pure curiosity – how different images are combined to make a new collage. What’s interesting as well is why the nag can produce a different image each time, even with the same search term and the same image sources.

Code snippet: A selection of different visual effects from ImageMagick

This snippet of code shows the traces that have been left by the previous coder. The gray area from lines 27 to 32 (which is what we usually call “comment area” and what the machine will not execute) is a list of twenty-six possible visual effects that can be applied by ImageMagick. And below, in green, you can see the thirteen effects the programmer has actually chosen to work with (see lines 34 to 36). This may also imply that all available twenty-six effects had been tested and the choice of effects was made on the preference of the coder. I really like reading comments like this because they reveal a lot regarding the thinking and decision-making processes involved in coding.

This snippet of code contributes to the understanding of the larger image-generation process. For each generation process, it will randomly select an effect (such as applying color filters, composing differences, and adding/subtracting two images), and also resize the outcome (both in terms of width and height). This is quite complex already: if Google returns four images as source material, then the image processing randomly uses a different effect for every layer, which makes it rather unlikely to create the same outcome twice. In this sense, every image is an original that cannot be reproduced.

For more information on this library, see: https://imagemagick.org/

Libraries

The following piece of code is a more general one, but it is essential to understand it before setting up the development environment on your personal computer. It is about the software libraries that are being used in the program, which need to be installed on your machine in order to run or test the workings of the nag. For example, line 38 indicates that the software library ImageMagick is required. But I do not know all the libraries that are being used in the nag, as for example, POSIX, mentioned in line 39 – I have no idea what it is being used for, even though I tried to find out online.

Code snippet: Libraries used in nag_05

Another one, JSON, see line 42, is important to process the Google search API. Google will return a JSON file containing relevant information for the generating process, and this library (JSON) is used to decode the JSON objects. JSON is something like a text file but following a certain standard of data format. It is used, for example, in decoding JSON to an appropriate Perl type for further processing/parsing.

C: These libraries are really an important feature of free software, because they allow the combination of already-existing code to be integrated into the development of new programs. We will come back to that in a moment.

Perl

C: I think with these different examples we can get a good sense of how the program is working in very basic terms. As already mentioned, we need to use a programming language to communicate with the machine – a sort of a translation code between the human and the machine.

W: A programming language is a formal language comprising a set of rules that define which words and signs can be used to tell the computer what we want it to do.

C: And the programming language used for all of the five different versions of the nag is Perl, a language that was introduced in 1987 by Larry Wall.

W: What I always wanted to ask you: Why Perl? Why did you decide to use Perl in the first place?

C: I have to admit that it was not really my choice or decision. As you know, the idea for the nag was sort of a side product of an artistic intervention for which I had to produce a large number of randomly created websites to flood a competition.1 I started doing this by copying and pasting HTML code “manually,” and the results looked rather interesting – probably what people in 1997 thought net.art would look like. That made me think about using this technique for a discrete project.

At the time I had no knowledge of programming at all, but I was hanging out with people who had, for example, with a guy from Chaos Computer Club called Amok, and he suggested to automate the process by using a script. That was the first and very raw version written in Perl (and before you ask, no, I did not keep it). A bit later Karl Heinz Jeron, an artist colleague, gave me further advice. But it took a while to fully develop the concept, to think of an adequate name, and make it into a project in its own right. As I was rather inexperienced with coding, I was trying and testing and discussing with people who had more experience. Another person I need to mention is Heath Bunting. He helped me install Perl on my Mac in 1998 and showed me some basics, but I didn’t really get enthusiastic back then. At the time, I found the conceptual level of the project much more thrilling than the technical one ... After all, it was born out of an institution critical intervention.

W: So, back to Perl. In 2017 when the nag was broken and you asked me if I was interested in helping to fix it, I realized that all the versions had been written in Perl. Perl is not the programming language I usually work with, in fact, one can say, that it is not a language of the twenty-first century. We have much more contemporary tools at hand now.

C: It happened to be the case that all the people I worked with in the late ’90s suggested to use Perl. It seems Perl was not just a programming language; it constituted a whole ecosystem. The programmers felt comfortable with this culture, and they also found Perl most adequate for the purpose. In fact, most server-based creative stuff was done with Perl at the time. And it was not only used in the hacker communities, but regular businesses also used it.

W: Because of my background in information systems, I know that Perl has been one of the earliest web-programming languages, especially on the server side with which you can, for example, make requests from the user side. So, when I first looked at the nag, it was not something I was familiar with; nevertheless, it was the historical aspect that raised my interest. That is why I ended up learning Perl from scratch in 2017. It took me four months to learn (on and off) until I was eventually able to “fix the code.”

C: Your question and the kind of skepticism you expressed triggered an interest in me. As I have never been a Perl programmer myself and thus also was not member of the community, I did a little research. The name Perl was originally said to stand for Practical Extraction and Reporting Language. And I think this needs a bit of an explanation.

Logo of the programming language Perl, the camel

W: I have also done a bit of research on Perl. It seems that Perl was originally developed for the handling of text (in computing we use the term “parsing”), like extracting specific information from a text file, a certain sentence or a specific word, and then it does something in between and outputs something different (like generating a report). It seems that one of the most important purposes of Perl is to do report processing. We also have that in the nag, if you look into the top-ten features. In terms of getting the data from a text file (parsing) and extracting each individual field, such as number of clicks, author name, time stamps of the creation, first click, and last click, etc., and present the resulting information in an organized and tabular format.

The TOP10 feature on the nag website featuring the ten most popular images of the archive.

C: I think the parsing function is a very important aspect of Perl, and I would like you to explain it in more detail. Or can you give an example how this function is used in the nag?

W: Parsing is generally understood as part of the process of syntax/syntactic analysis. It is a process of analyzing and extracting meaningful information from a set of data. To give an example:

winnie-

query@Oct_9_10.38.05_2020.jpg∞2∞1602242860∞1602250368

cool-

nice@Oct_9_12.02.52_2020.jpg∞2∞1602242861∞1602250372

The above two lines are the actual data stored in the statistical text file. The program needs to open the file and extract different information from the text. For example, you can see that the data in the first line – the name “Winnie,” the keyword “query,” the creation time “Oct_9_10.38.05_2020,” and the number of clicks, “2” (the first click time stamp info is “1602242860” and the last click time stamp info is “1602250368”) – follows a similar pattern in line two.

C: Maybe it would be of interest to continue looking a bit into the Perl culture now …

W: I would like to share the following quote by Larry Wall, the guy who invented Perl:

When I started designing Perl, I explicitly set out to deconstruct all the computer languages I knew and recombine or reconstruct them in a different way, because there were many things I liked about other languages, and many things I disliked. I lovingly reused features from many languages. (I suppose a Modernist would say I stole the features, since Modernists are hung up about originality.) Whatever verb you choose, I’ve done it over the course of the years from C, sh, csh, grep, sed, awk, Fortran, COBOL, PL/I, BASIC-PLUS, SNOBOL, Lisp, Ada, C++, and Python, to name a few. To the extent that Perl rules rather than sucks, it’s because the various features of these languages ruled rather than sucked.2

C: Would you like me to comment on that? Although not being an expert, I would imagine that all programming languages steal from each other and build on each other. What is so special about Perl in this respect?

W: I can imagine that in the ’90s Perl was a very good choice compared to others, especially for building web-related applications that required a lot of client-server communication with various kinds of servers and databases and the handling of different formats and protocols.

Perhaps portability and good performance are some of the key strengths, too. It can run on different operating systems and on ordinary desktop computers, and the execution process is really fast.

Besides, Perl used to have a really good community and thousands of developers who have created different sorts of libraries and documentation within a network called CPAN (Comprehensive Perl Archive Network). The network involves contributions by companies, institutions, and individuals to keep things alive and sharable.

C: This is where one would look for the libraries that are required to run the nag, as we have seen above.

W: And here is another quote by Wall:

How does Perl put the focus onto the creativity of the programmer? Very simple. Perl is humble. It doesn’t try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn’t have any theoretical axes to grind. And where it has theoretical axes, it doesn’t grind them. Perl doesn’t have any agenda at all, other than being maximally useful to the maximal number of people, to be the duct tape of the Internet, and of everything else.3

C: This is both a bit cryptic and also polemic. Somebody praising his product to be the best, because it has the quality of … duct tape?

W: Well, I am not sure if it was the best as I don’t have an overview of what the other available options were at the time. Honestly, I feel quite confused with Perl (compared to the experiences I had with other scripting languages like ASP, PHP, Python, and JavaScript). But as I said, Perl has done a good job in terms of working on web-related interfaces at the time.

C: I was also interested in getting a better sense of what this praised Perl culture was like and made a request to my Facebook bubble. I asked if anyone had used Perl in the 1990s, what they had used it for, if they were willing to share their experiences, and why they eventually stopped using Perl (which was an assumption I made).

To my surprise, I ended up with dozens of answers and more than seventy comments. This alone demonstrates that Perl must have been, or still is, relevant to people ... And everyone was extremely helpful and keen on sharing their thoughts. I would like to thank everyone who contributed.

W: Could you summarize what the research has brought up?

C: Yes, sure. And you won’t be surprised that it has been only guys who have responded about coding – which reminds me to another quote by Larry that we simply have to insert here:

That being said, I wouldn’t mind if there would be more female programmers, especially female Perl programmers. And no, I don’t mean it like that, or my wife wouldn’t let me say it. But I think we need some spies to tell us what things in our culture appeal to women, and what don’t. And it kind of goes without saying that these spies need to be women. Well, look, the guys all have a lot of great ideas, but you know, guys tend to be rather, well, idea-oriented. In theory, Perl culture is supposed to be more cooperative than competitive, but it’s kind of hard to argue for that viewpoint when the vast majority of us are standing and pounding our chests like big gorillas. I include myself in that category. Er, the gorilla category, not the Jezebel category. Just thought I’d clear that up.4

C: Coming back to the Perl culture: The opinions ranged from “best tool at the time” to “awful” and “bad.” To quote from some of the arguments:

Perl was a very useful and widespread tool at the time with unique properties: 1) easy and sophisticated text manipulation, 2) being a scripting language, and 3) the huge library of scripts and modules to draw on.5

Odin Kröger

Perl was the free jazz of programming – no error checking overloaded operators – unique writing style – glue between everything – non-proprietary out of control – I stopped teaching it about ten years ago because for people who did not have a system-wide knowledge it was difficult as a first language.

Graham Harwood

C: I was wondering what he meant with system-wide knowledge and asked for clarification.

“System-wide knowledge”: “If you’re used to Unix (/Linux/BSD/Mac OS X) system administration on the command line, then Perl is basically just an extension of that command syntax into one self-contained language.

Florian Cramer

C: That was an important contribution because it indicates the proximity of Perl to a certain environment within digital culture. Being familiar with computer basics obviously makes it easy/easier to mess around with Perl.

Perl’s “unique selling point” in the early 1990s was the built-in “regular expressions” functionality. This also comes across in the naming of Perl, which originally was an acronym for Practical Extraction and Reporting Language as already explained. This caught my attention, because it really seems to be the outstanding feature.

Anything more complex than a simple substitution required picking apart your regular expressions.

Alex May

And this is how Florian Cramer, somebody who is working with Perl since 1996 – and still does – explains its strength:

Regular Expressions, or How to Identify Patterns in Code/Text

“Regular expressions” are placeholders for text. They are similar to, but more sophisticated than, the so-called “wildcards” we commonly use in computing and search engines, for example, when searching all JPEG image files in a folder through the wildcard “*.jpg” or, in a library database, all authors whose name starts with a, through the wildcard “A\*.”

Regular expressions allow much more specific and flexible search queries. For example, if I would not know whether a person’s first name is Cornelia or Cordelia, I could search it with the regular expression “Cor[nd]elia” (provided that the database or program I use does support regular expressions; for example, LibreOffice/OpenOffice supports regular expressions in its search and replace box, Microsoft Word only supports wildcards). If I didn’t know whether it’s Cornelia/Cordelia with one or a double “l,” I could search for “Cor[nd]e[l]+ia” and find all occurrences. And if I didn’t know whether in a text, the name occurs in a genitive form (such as “Cornelia’s”), I could search for “Cor[nd]e[l]+ia[‘s],” and if my query should also find occurrences of the name written in all caps or all small letters, then “/Cor[nd]e[l]+ia[‘s]/” would do the trick.

This search functionality was built into the Unix standard terminal command “grep” in 1974, i.e., since then, Unix and later BSD, GNU/Linux, and Mac OS X have allowed you to run the above search on a set of plain text files on your computer; and it’s been no problem to perform such a search even on a set of one thousand text files. This is why grep is often considered the mother of all search engines.

Grep is a command-line utility for searching plain-text data sets for lines matching a regular expression.

On top of that, you cannot only search, but also replace text with regular expressions. If I wanted to turn all occurrences of “Cornelia” and “Cornellia,” including those spelled in all caps or all small letters, into “Cordelia,” I could do this with the regular expression “s/Corne[l]+ia/Cordelia/i.” And I can use regular expressions to change the order of letters, for example, turning “the house of Cornelia” respectively “the house of Cordelia” into “Cornelia’s house” respectively “Cordelia’s house” by: “s/the house of (Cor[nd]elia)/\1’s house/”; with “\1” in the replacement text being the placeholder for the bracketed [=memorized] text in the search text. Now, we could extend this text replacement so that it does not only apply to the house, but to any property of Cornelia/Cordelia: “s/the (.+) of (Cor[nd]elia)/\2’s \1/,” which would turn, for example, “the project of Cornelia” into “Cornelia’s project” but also “the drink of Cordelia” into “Cordelia’s drink.”

This regular expression-based, search-and-replace function was first built into the Unix standard terminal command “sed”6 in 1974. In 1987, Perl was developed as a makeshift programming language that fully integrated the regular expression syntax of “grep” and “sed” into its own syntax. The mainstream use – then, and even more so today – for these complex and very capable search-and-replace functions (of which I just scratched the surface) is to clean up data sets, for example, of server log files, address databases, or lab measurements that were recorded in different formats and conventions.

But hackers, activists, and artists have used these functions too. For example, when Alvar Freude and Dragan Espenschied developed the project insert_coin, an internet router that swapped the addresses of websites (so that you would, for example, get Fox News when you tried to browse CNN), and even changed their content (so that all occurrences of “Angela Merkel” in the websites you browse would be replaced with “Donald Trump”), they simply used regular expression search-and-replace operations. The Yes Men’s Ream Weaver (a real-time mirror of the WTO’s website with changed text, which got them mistaken for the real WTO and invited, among others, to Davos) works the same way.

Florian Cramer

C: This is really a great explanation by Florian, and it makes easily comprehensible why Perl and this feature in particular have been of interest for artists who work conceptually.

W: Which takes us directly to the last snippet of the nag code I have selected that works with regular expressions:

Code snippet: Regular expressions in nag_05 and nag_05b

Perl is a programming language that is very good at handling and finding patterns in a text. For example, to find a certain character in a string, or to count the number of occurrences of a pattern in a text. When I first looked at the script, I saw many weird characters (those colored green) in every part of the program, and I knew this was something I had to learn first, on top of all the basic programming concepts that I already have (such as variables, loops, etc.).

So, this snippet of code deals with the parsing of the keyword search and the corresponding naming of the generated image file. The version nag_05b supports multi-languages and therefore has to relax the rule of only checking characters from a to z. Another checking logic is to check if the query contains any spaces or special characters before using it as the file name. It has a potential issue for a computer to read and process these characters.

If you want to play around with regular expression, you can try: https://www.tutorialspoint.com/perl/perl_regular_expressions.htm

As you mentioned about connecting to the internet, to run a Perl script on the internet for something like processing input data and displaying them as a web page (for example, if you want to have an interactive feature to process things like input text from a user and output something based on it on a web page) then you need a web server.

Apache is a free and open-source, cross-platform web server software that can be downloaded from the internet. You can run it on your own machine and set up the required configuration such as permissions, folder types, and the web server will render the script (with a mix of HTML and Perl) as a web page.

C: I would like to go back now to your personal history with Perl.

W: My first encounter with Perl was when I was an intern (around 1997) working for a search-engine company in Hong Kong. I was responsible for building small campaigns with Perl. I didn’t use it again until it showed up in the context of the nag. Basically, I could hardly remember anything from back then, which is why I had to relearn everything. The first thing I remember is that I needed to learn regular expressions because they have been used quite intensively in the original version of nag_05. That is why I kept some notes on the issue, and these are the things I found useful for me to understand the original version of nag_05.

Written notes by Winnie that document her learning of Perl in 2017

C: There is a lot of stuff, including the basic syntax, which is interesting and so essential; one just has to learn it ... Could you please explain the other links as well?!

W: The image shows a few links where I have learned Perl, especially a beginner’s introduction, and then I focused on files, handling strings, and regular expressions because these are the things that are essential for the nag code. Eventually, it is also about setting up the local server to get a sense of how Perl operates in a web context.

The details under “Files Study” are the notes that I took in order to get a basic idea of the syntax in Perl, such as variables, arrays, and the syntax for doing parsing (such as split and join commands).

To give a concrete example, I have this regular expression:

$line =~ /^http:.+html$/

It means that I am looking for a pattern (from a text file for example) with the starting characters “http:” that is followed by some characters until that line ends with the characters “html.” A match would be, for example, “http://www.abc.net/index.html.”

Code Poetry

C: At this point, I would like to quote another statement that came out of my research and leads us in a slightly different direction: the use of code as “material” in art.

Perl intrigued me due to its power, ease of use, and flexibility. Perl’s motto is TIMTOWTDI – There’s More Than One Way to Do It. Perl supports multiple methods for achieving the same results. What method you use will be dependent on your proficiency in Perl, your programming background prior to using Perl, and whether you’re looking to produce a polished program or a quick and dirty script for a task you need to complete in five minutes. My main attraction was the linguistic flexibility of it. You can write code that almost reads like spoken language. This prompted some to experiment with “Perl Poetry” and even led to various groups hosting Perl Poetry competitions. I experimented quite a bit with writing programs that “performed” in one way but read in a totally different way.

Pall Thayer

W: I do remember that many “codeworks” are written in Perl such as Microcodes (2009) by Pall Thayer, and it is highly interesting to see how minimal it is to run a piece of poetic code that is totally readable by humans.

Pall Thayer, Microcodes (2009), http://pallthayer.dyndns.org/microcodes/

Crazy powerful one-line syntax that you immediately forgot how you made it.

Pall Thayer

C: This is beautiful to see, and we should discuss it a bit. Taking code syntax as human readable language, making it into poetry, while at the same time, it is still machine executable code. And since we have mentioned codeworks, we should also mention that there is a whole genre in art that uses code as its material basis.

Artistic Software

Software art [...] refers to artistic activity that enables reflection of software (and software’s cultural significance) within the medium – or material – of software. It does not regard software as a pragmatic aid that disappears behind the product it creates, but focuses on the code it contains – even if the code is not always explicitly revealed or emphasized. Software art, according to Florian Cramer, makes visible the aesthetic and political subtexts of seemingly neutral technical command sequences. Software art can base itself on a number of different levels of software: source code level, abstract algorithm level, or on the level of the product created by a given piece of code.7

Inke Arns

W: To quote from the book Aesthetic Programming: A Handbook of Software Studies: “There was a series of festivals that promoted the artistic and experimental practice of software, as, for example, the Readme festivals, which took place at the Macros-Center in Moscow (2002), the Media Centre Lume in Helsinki (2003), Aarhus University and Rum46 in Aarhus (2004), and HMKV in Dortmund (2005). The associated software-art repository Runme.org was established in 2003, and many participants and people who submitted their works did not necessarily call themselves artists. Indeed, the category of art in itself becomes inadequate to cover the kinds of creative practices that have developed in the field. As an annual festival for art and digital culture, transmediale introduced the terms “artistic software” or “software art” in 2001. Many artists and researchers have contextualized and written about the genre of software art.”8

C: I remember these festivals and their publications. Interestingly, the phenomenon seems to have been limited to a certain era, say, the first half of the first decade of the 2000s. Code as an artistic material was something new back then. Of course, it still exists but for some reason the hype around it has died down. On the other hand, people like you continue the tradition, you connect to it and take it into the future, for example, with your forthcoming publication. Could you please briefly explain what the book is about and who should read it?

W: The book is titled Aesthetic Programming: A Handbook of Software Studies, and Geoff Cox and I take the inspiration from software art or “computational art” to explore the technical as well as cultural imaginaries of programming from its insides. We also extend the discussion beyond formal logic to its outside, emphasizing the usefulness of artistic practice for opening up more speculative, alternative, and messy imaginaries.

We take a particular interest in power relations that are relatively unacknowledged in technical subjects, concerning class and capitalism, gender and sexuality, as well as race and the legacies of colonialism. This is not only related to the politics of representation but also non-representation: how power differentials are implicit in code in terms of binary logic, hierarchies, and naming of the attributes, and how particular worldviews are reinforced and perpetuated through computation. We feel that it is important to further explore the intersections of technical and conceptual aspects of code in order to deeply reflect on the pervasiveness of computational culture and its social and political effects — from human-machine languages to abstraction of objects, datafication, and recent developments in automated machine intelligence, for example. The book explores the set of relations between writing, coding, and thinking to imagine, create, and propose alternatives.

And not to forget: I have also included the nag in one of the chapters under the title “Que(e)ry data” to talk about APIs, feminism, and data processing.

The book is open access and open source, and we wrote it on the GitLab platform. For updates, see: http://www.aesthetic-programming.net/; or the software repository here: https://gitlab.com/aesthetic-programming/book. The book is offered as a computational object open to modification and re-versioning. We hope that people will fork the repository and change the content, or even add a chapter that can suit their learning.

C: Coming back to artistic software: Would you consider the nag to fall into this category?

W: Oh yes, definitely, as the source code opens up many perspectives to discuss software culture – such as this book. Fixing the problem of the APIs triggers a new discourse of the nag, shifting from questioning normative authorship and copyright to politics of infrastructure, and furthering it now to the issue of caring and maintaining the project collectively.

C: This is something we will also discuss in more depth in chapter four. For now, let’s finish our section on Perl with a few more excerpts from my research. This will complete the picture of the Perl culture. I think it becomes obvious that it had something of a love-hate relationship for many programmers.

Perl was fun but ugly.

Marcell Mars

Perl is really bad.

Robert Luxemburg

Perl is indeed quite bad.

Florian Cramer

C: I guess we have an understanding now that Perl would no longer be the programming language of choice today, and we might end up with the experiment to implement the concept of the nag with a more up-to-date programming language. Why do you think it is still relevant to know about Perl today?

W: Obviously that is something you are assuming, but I agree on its historical value from the perspective of a researcher. It is relevant to know and experience different programming subcultures, such as Perl, and the specificities of the programming language. Also, the nag has such a long-standing history, and the program is not simply about generating images, but also the design, the code, and the software aspects that shape its functionality and look (for example, the use of an explicit navigation bar on the top, table blocks, and the small font size are all very special and nostalgic to me).

But if I really need to think about it, I would be interested in developing a different version of the nag using JavaScript with libraries like node.js and p5.js. JavaScript is also a very expressive language like Perl. Using a different programming language would help to think about the different code-writing styles, the logic and structure, and the related programming culture. As an example, I did a code poetry/codework about queering code in JavaScript:

See: http://siusoon.net/vocable-code/; and the live coding version here: https://dobbeltdagger.net/VocableCode_Educational/

C: The idea to continue the concept of the nag by using a more modern programming language is very exciting, but it also poses some important questions regarding its integrity and its status as an art project. We will continue this discussion in chapters three and four.

1 The name of the intervention is Female Extension, and it was the flooding of the first competition of internet art in 1997 with three hundred virtual female net artists in 1997. The project is included in Rhizome’s net.art anthology.

2 Larry Wall, “Perl, the First Postmodern Computer Language,” The Wall Nuthouse, accessed January 26, 2021, http://www.wall.org/~larry/pm.html.

3 Wall. The Wall Nuthouse

4 Larry Wall, “The State of the Onion 9,” Perl, September 22, 2005, https://www.perl.com/pub/2005/09/22/onion.html/.

5 Full thread of Facebook research to be found here: https://www.facebook.com/coco.sollfrank/posts/3178375578955161, August 13, 2020.

6 Sed is an application, and by using the command “sed” in Unix it supports regular expression to perform complex pattern matching. https://en.wikipedia.org/wiki/Sed

7 Inke Arns, “Read_me, run_me, execute_me: Code as Executable Text: Software Art and Its Focus on Program Code as Performative Text,” trans. Donald Kiraly, MediaArtNet, 2004, http://www.mediaartnet.org/themes/generative-tools/read_me/1/.

8 Florian Cramer and Ulrike Gabriel, “Software Art,” in “Codeworks,” ed. Alan Sondheim, special issue, American Book Review (2001); Olga Goriunova and Alexei Shulgin, read_me: Software Art & Cultures (Aarhus: Aarhus Universitetsforlag, 2004); and Andreas Broeckmann, “Software Art Aesthetics,” Mono 1 (2007): 158–67.

<!--

# Chapter 2

-->

<head><title>Fix My Code</title>

<p class=h2>SERVICE NOT AVAILABLE</p>

After a comprehensive and intense chapter on code, we will stay with the technical side of the nag and have a look at its technical context. Even if the code itself is a free and open-source software, it needs to be installed on a web server to function. And a web server is part of the technical infrastructure we often tend to neglect when focusing on the free circulation of digital objects, as Shusha Niederberger states in her article on infrastructure and digital commons.1 A basic definition of infrastructure says that it is a “matter that enables the movement of other matter,”2 and this is as true for water supply as it is for a web server. So without digital infrastructure, no net.art.

But this infrastructural basis is not self-preserving or self-reproducing, something we only start to understand when, all of a sudden, it fails or collapses. As infrastructure tends to disappear behind its functionality,3 its visibility is related to its dysfunctionality, something we have learned from the periods when the nag was down. We had to immerse ourselves in the network of code as a result, in practices of maintenance, power relations that regulate creation and access, and also a network of people connected to all these levels. Therefore, at the center of this chapter is the relevance of infrastructure, which we exemplify by the server on which the nag is running, and also the piece of infrastructure that allows communication between our server and the Google search engine. In addition to the discussion of these technical elements, we also make an excursion to the feminist discourse surrounding this issue.

Error message created by the system administrator Gerrit Ché Boelz, 2016

Server

C: In the context of infrastructure on which the nag is dependent, we should first look at the server and explain what a server is.

W: The Perl script of the nag we know from the previous chapter relies on a special environment to run: this is the server. We are talking about a web server here, because there are different kinds of servers, like local servers (machines) or mail servers. Basically, a server provides services by responding to requests. It is a machine connected to the internet – ideally it is online all the time – through which the communication between users and services is organized. It consists of hardware and software components that handle the requests according to an underlying technical protocol. The nag, for example, is stored on a computer in a hosting company (other people run their servers from their office or living room). Users go through the browser to the web address of the nag, https://nag.iap.de, which means they connect to the server on which the nag is installed via the HTTPS protocol.

C: HTTP stands for Hypertext Transfer Protocol, the main protocol for data transfer for the World Wide Web, to load websites into a web browser such as Firefox. And the “s” indicates that the transfer is encrypted and therefore is “secure.”

W: Once the connection is made, the user can request to generate images by entering a search term. This is one thing the server is handling. But there are also the requests to Google as well as the responses that Google returns, both of which are handled by the API. This setup is called client-server architecture with the nag being a server to its users and, at the same time, a client to Google.

C: As the server is such an essential part of the project, it would be interesting to trace back the server history of the nag, but I’m afraid this will be hardly possible. The early versions were running on the servers of the programmers who coded them, but at one point I wanted to have my own server because I was also hosting mailing lists, etc. So for a few years I had my own server, but it was a lot of maintenance work to keep it safe, and also the one generator that remained, nag_05, the image generator, was running on a company’s server anyway. This service was paid for by an art institution for a while and later sponsored by IAP, a hosting company where nag_05 has resided since 2003. This is also where we found our third collaborator on the project, Gerrit Ché Boelz, who works as an administrator with IAP.

W: The way Gerrit runs the server is quite unique. He is not just an administrator, i.e., updating and maintaining the system, but he also explored the nag in detail and took the initiative to write a new software component, the nag_extension (which will be discussed later in the chapter).

C: After the three of us had a real conversation, we came up with the idea to create our own server project in which we are going to experiment with the almost inescapable hierarchies within such a technical setting. Thinking about the inherent power relations led us to the idea to start an independent experimental server.

W: Did you ever have all the different versions of the nag running in parallel on the same server?

C: Never. This is probably because the project just evolved and there was never a master plan. But we should go a bit deeper into the server issue. There are virtual servers, where you just rent space on a machine in a server farm, and some people prefer to have their own physical machine, at home or at their office, to also have access to the hardware. But most people do not actually need a server of their own, when they just do email and rely on cloud services. The thing is, however, your email, for example, is hosted on a server where it can be accessed by the server administrator who you do not know. There are people managing the technical infrastructure who have full control over everything that is going on, and you have no clue about that. Normally they are trustworthy, but when everything is in the cloud, you realize that your control is very limited. Here we have another issue with autonomy, or the lack thereof. This is why the server has become such an issue again: it can give you back control over certain aspects of your digital life and some autonomy.

Current home of the nag, server rack at IAP in Hamburg.

W: Why do you keep the nag on the corporate server then?

C: For different reasons: As a corporate server it is well maintained, gets regularly updated and constant backups, which is convenient and safe for me. As already indicated, it is quite an effort and a responsibility to run a server, and the question is how can this be done best. At the moment, it is a pragmatic choice with the professionals running it, whom I know and can trust. Most importantly, I stayed with IAP because Gerrit is a wonderful person to work with. Over time, our business relationship has developed into a real collaboration, which will even be continued in a collaborative project, as already mentioned.

W: I know, and I am looking forward to the three of us creating the new experimental server … But let’s stay with the history for a bit. How did the nag end up being on this corporate server?

C: It is a wild story. This version of the nag was developed for a private Hamburg-based art collection who had decided in 2003 to have their own version of the nag. I was not at all excited about this idea and requested them to hire a programmer and take care of the hosting themselves. Basically, I got paid for the concept and the collaboration with a programmer, but neither the company nor the programmer were my choice. It was a deal under the condition that all the code would still be freely available. Interestingly, the collection agreed but their maintenance contract with the hosting company, IAP, ran out after five years and was never renewed. So this poor artwork was just sitting there, functioning, patiently providing its service every day, although nobody really took care of it :-)

W: And you never checked with them?

C: At one point I did, and they were generous enough to keep it running. Usually it did not require much maintenance. In 2014, I approached them again because I was interested in the archive of the images, and this is how I met Gerrit for the first time.

W: As it was functioning but, at the same time, did not generate heavy traffic, they just kept it up and running.

C: There was an exception though, in 2007. Not only did the nag not work anymore but the whole server had collapsed. I called IAP and they said that they got so many requests for the nag that everything broke down. They were able to identify that the requests originated in Denmark, but I had no idea what that was about. This happened in the evening, they rebooted, and everything came back to life. However, the next morning, the same thing happened again, tens of thousands of requests …

W: Crazy. This is so interesting. Did you find out what the reason was?

C: Yes, but only much later and by coincidence. To make it short: I gave one of the anonymous-warhol_flowers prints as a wedding gift to my friend in Scotland where her cousin saw it who is a TV presenter in Copenhagen. A few weeks later, he presented the nag on Danish TV generating images of the Queen … and everybody rushed to their computers to do the same. The broadcast was repeated the next morning …

Apart from that exceptional situation, the nag has been very stable and people used it on a daily basis, which is still the case today. We can see that in the log files.

W: When I started to work with the nag, I had a problem to set up the technical environment. I didn’t know on what operating system the server was running and didn’t have any information on specific settings. Since I didn’t use Linux at that time, the library ImageMagick was especially tricky to use with Perl. I wish I had known Gerrit earlier to clarify the file/folder structure and the server configuration.

C: Ha ha, Gerrit just sent an update with the most recent versions (November 2020). Here we go: The server is running on Debian 10, with Apache 2.4.38, Perl v5.28.1 and ImageMagick library version 6.9.10.23.

W: And to further work with Perl, the server uses libimage-magick-q16-perl for the Perl interface. You know, the different versions of the web server and the associated libraries will change the setup of the nag. So, every update and move of the nag will require adaption of the code to the new environment, which also needs to be budgeted. Maintaining a server in general, or the service of the nag in particular, requires dedication, time, and care. Furthermore, storage can become an issue, because the data is accumulating over time. It has been running already for more than twenty years now, imagine one day it will be one hundred …

C: Then we do a specific event at HKW in Berlin: “One Hundred Years of net.art generator.”

W: And Google might not exist anymore …

C: Probably not. We will be working with Chinese tech companies by the year 2100.

W: How do you imagine the nag’s future?

C: Who knows. One way of dealing with it certainly is to migrate the idea to other platforms and realize it with more contemporary programming languages. You also suggested that as an option in chapter one. This will no longer be the “authentic piece” but as the nag is also a thinking tool, a conceptual tool, it is very conceivable to transfer the algorithm to a different and more up-to-date software. This would be one way to keep it alive. Furthermore, we have many documents related to it, texts, this book, prints, a video, so the idea will remain alive. Of course, I will keep it alive as long as I can, but this will come to an end. Then you guys have to take over; in my last will, I will transfer the responsibility to you and Gerrit …

I mean, theoretically, by buying the nag_machine (server), the ZKM has also taken on the responsibility to keep the code alive. It is their task as a museum, but I also believe in distributed responsibility and collaboration (as will be discussed in the next two chapters).

W: The moment Google disappears, which will maybe happen in twenty or thirty years … there is no way that it can work.

C: There will always be search engines. There have been some in the past – for early versions we used Yahoo! and AltaVista – and there will be some in the future. But, to be honest, I am not sure if a museum, even if it is specialized in media art, is able to deal with such complexities. Remember, when we had done all the work of adapting the nag, we sent the updated version to ZKM, which was their lucky day, because they just had brought out the nag_machine from storage to make it work for the upcoming exhibition of their collection. I mean, if you just take this one work as an example to see how complex software-based works are, it is understandable that it is too much for any institution to deal with. And the nag is not just software-based but also highly dependent on external systems, which we will investigate further in chapter four.

W: It is probably just something the big institutions have to learn, to understand that it is about a different materiality and therefore requires other skill sets than classical restoration, which can also be very tedious and extensive. And I often wonder if artists themselves care any longer once they have sold their piece. Instead of spending time and resources on updating and keeping their old works alive, they are forced to make new works.

C: That is the logic of the art economy.

W: Anyway, I enjoy going back to old works, giving new contextualization to old works.

nag_machine

W: You already mentioned the nag_machine, the piece bought by ZKM. Let’s have a look now at this work that is so closely related to the nag. Basically, it is a server designed as an object to be shown at exhibitions.

C: The original version consists of technical server components built into an old wooden box. What is particularly beautiful about it is that the lid of the box is a screen that displays the log file of the Apache server. And when you open the lid, you can look inside the box.

Hardware components of the nag_machine

nag_machine, custom-made web server as an installation piece (wooden box, screen displaying the log files of the Apache server with nag_05b installed), photo: Nina Pieroth

Excerpt from the exhibition video

C: There is also a video on YouTube when it was first shown in Frankfurt as part of the 2007 exhibition Art Machines – Machine Art.

W: Can you tell the story about why you decided to make this server object?

C: In 2007 a curator of the Schirn Kunsthalle in Frankfurt, Katharina Dohm, approached me to participate in the exhibition Art Machines – Machine Art. They wanted to show the net.art generator, accessible from the museum through a computer, but I didn’t want to have a computer there with the same interface the users also have at home. Unlike around 2000 when the first exhibitions of net.art were shown, in 2007 people had computers and internet access at home, and it was not cool anymore to display a computer in an exhibition. So the idea was born to confront the visitors with an aspect they cannot see at home, to make part of the infrastructure visible in the museum, the server that usually is remote. To make it visually more interesting than the usual computer case, we decided to build the functionality of the server in this wooden box by assembling the hardware components of a server into a real object. It is lit from inside, and together with the log file of the server on the screen, the infrastructure becomes more graspable, more understandable.

W: What’s showing on the server are not error messages, but logs from the server including processes that are coded in the original nag program to demonstrate when, for example, a file is saved, an image is generated, etc. These log messages are implemented via the processing of image files from search engines. Here are some of the log messages:

doLog("Grabbing file\n");

doLog("Saving file\n");

doLog("Saving done\n");

W: I remember when I saw the actual nag_machine for the first time at ZKM in December 2017, when we did the workshop together. It was totally fascinating to touch the materials and see through the lid what’s happening behind the screen. How did you build it?

C: I did it with the help of my friend Kay Sievers, without whom it would not exist. He also had the idea to take apart a new monitor and install it as a lid on top of the box. And once it was finished, we took it on the train and traveled with it under the seat to the museum in Frankfurt. From there it went on a little journey, first to Basel and then to Karlsruhe.

The assembly of the nag_machine (Cornelia Sollfrank)

nag_machine traveling to the museum in Frankfurt by train

nag_machine (Chinese copy), exhibition We=Link: Sideways, Chronus Art Center, Shanghai, Photo: Leon Eckert

W: And most recently, it almost traveled to Shanghai …

C: Well, yes there was this request from the Chronus Art Center to include it in an exhibition, but eventually, for various reasons, they decided to build their own version of the nag_machine, a so-called exhibition copy. Having worked on issues of originality and copyright for so many years, the process of building the copy and the whole attitude behind were most astounding for me – as they express a completely different culture. But I enjoyed it very much and hope that one day I can show the two versions of the nag_machine side by side.

For further explanations of what a server is, this is a nice article: “Server Is Hard to Define” by Julia Evans.

Feminist Server

C: Before we go deeper into technical specificities, we should also mention that the server as a core component of internet infrastructure has also been a topic in feminist discussions in recent years.

W: You mean the concept of the Feminist Server, right?

C: Exactly. In 2013 and 2014, there were several meetings of feminist server groups, where also the “Feminist Server Manifesto” was written. Another outcome is this wonderful publication Are You Being Served? (notebooks).

W: Applying feminist principles to this piece of infrastructure is very fruitful, because questioning the power relations within this setting makes clear how hierarchically it is organized, and thinking about the server administration as something collaborative and distributed brings with it a number of challenges. And the question is: What are the decision-making processes behind infrastructure?

C: I really like this interplay between theoretical aspects and practical implementations. The Feminist Server involves two different aspects that often produce contradictions and confusion: First, it is a vehicle for addressing political issues around power relations embedded in technology. How would it look like to apply feminist methodology to network technology? How can the patriarchal terminology around servers and masters be deconstructed? How can the strictly hierarchical way of organizing servers be replaced by collectivity and shared responsibility? How would a server look like that is driven by the needs and desires of her users? Second, the Feminist Server is also understood as a safe space that provides services to the community, who runs it, can trust. With this second aspect, the concept can be situated in the context of counteracting the lack of autonomous infrastructure on the internet, in particular alternative server projects such as autonomous servers, art servers, etc. But often it is this need for reliability that easily interferes with the more experimental nature of the first aspect.

W: Which reminds me of the last point in the “Feminist Server Manifesto”: *she (the server) tries hard not to apologize when she is sometimes not available.

C: This is beautiful and shows that the thinking behind is not just about technology, it is about our misunderstanding that things/we always have to function – which makes us forget that we sometimes have to take/give the freedom not to function ... That dysfunctionality opens up space for thinking and exploring what is behind the surface … Spideralex, in a 2019 interview with Claire Richard, said: “A server is a service. This implies work and care, and it is illusory to think that it can always be free or that it can always be there for you, if you know the conditions necessary for a service to work.”4 And I like the fact that in the manifesto server is addressed as “she,” which allows for further analogies.

W: I’d suggest we move on a bit from there and address our server as they/them. They will have multiple or mixed genders in a fluid form, and therefore be queer rather than just feminist. This also shows how much the Feminist Server is also a project about (mutual) learning and teaching.

C: Definitely, about sharing knowledge through collaboration. In this sense, the Feminist Server is not “one” project. Having been around for about ten years, it creates a loose network of actors to collaborate and occasionally meet in the flesh. I like to think of it as an ongoing (design) fiction that has the potential to instigate discussions about the core questions at stake when it comes to feminist ways of confronting technology, while also yielding concrete manifestations at times. It is this tension between thinking and doing, between reflecting and acting that brings together a feminist tech collective that does not pretend to have easy solutions for complex and probably insolvable problems.

W: In any case, the Feminist Server is a way of being connected in a different way.

C: And as such it is a great inspiration for our own server project ahead.

API

C: Now let’s go back to the nag story and the parts of it that are related to infrastructure issues. At one point in 2015, we were confronted with the fact that the nag was not working anymore. As it was not the first time, one assumption was that it might have to do with the related search engine. And it has to be noted at this point that over time we already have used a number of different search engines.

W: In the original code version, nag_05, there was only one line that made the API request. And it was not yet an official Google API at the time.

my $req = HTTP::Request->new(GET => ″http://images.google.com/images?btnG=Search&site=images&q=″. $query);

It is simply a URL with a HTTP call, which you can copy in a web browser to search for an image. It worked in the past, but this API was discontinued by Google in 2015. Indeed, such an image search API has been officially deprecated as of May 26, 2011 (according to Google’s announcement), and Google advised their users to use the “Custom Search API” (the one that we use now in version nag_05b).

The API of version 5 was simply like a URL, and if you want to search for “warhol flowers,” for example, then you simply replace the last section with `q=warhol+flowers`. You can copy and paste the URL below manually to your web browser, and it only works with manual operation, but not when it is used in software program.

See: http://images.google.com/images?btnG=Search&site=images&q=warhol+flowers

W: This implies that Google has implemented a checking logic to bar the API access from any bots/programs. Google is able to check if you are a machine or a human that types the search. They basically want to migrate all existing users to register their “official” APIs.

C: Which does not come as a surprise.

W: But it was the reason why the nag stopped working and we had to start exploring the official Google API.

C: It was an interesting process that followed …

W: It required a new registration with a different authentication process. First, you have to create a Google account and then register both an API key and a search-engine ID.

C: API has been mentioned already few times before, but I guess, it’s time now to go deeper into the issue.

W: As introduced in the previous chapter, an API, which stands for Application Programming Interface, is used by software/programs to communicate with each other. It is usually in the form of a two-way communication: request and response. Like in the program of the nag, the code requests image-search results based on certain keywords (the server in which nag is hosted as a client), and the other side (Google as a server) will return the top results of the search.

To put it concretely: nag requests images of Warhol flowers and asks Google to return the first ten images, then Google responds with the result of the relevant ten images and some other information in a structured data file format.

C: Now we have to explain how this relates to Google’s change of policy and the nag outage.

W: To “fix the code,” the next step was to try out the official API so that a proper request could be made to Google. With the registration and authentication, Google can, of course, track what the keywords are, who makes the request, and for what usage. Most importantly, it is a way to limit the number of requests. This is the current situation of the nag, in which one can make one hundred requests per day for free, and everything on top has to be paid for, and they can charge you because through the ID and the key they have your identity.

C: So Google’s interest is first, to collect more specific data, and second, to monetize their service.

W: Exactly.

C: But let’s stay with APIs in general for a bit longer. You also wrote a research paper on the issue (see chapter one), so you spent some time digging deeper into the issue. This shows that it is not a personal problem that only affects me and my work, but rather it is a structural problem.

Basically, an API is a little application that builds connections between different technical settings. This function of bridging is quite important. Could you please elaborate a bit why it is so relevant.

W: Let’s start with an image:

An API is dealing with data, a link between query and delivery of data. Providing an API service is getting more and more common by companies because it allows data to be shared/selected easily through an automated process. It also allows different kinds of programs using different programming languages to make a request and process the response. As a consequence, the apps we see nowadays embed many different features. Another example would be the Google Maps API that helps users to find the location of restaurants and cinemas, for example, via other apps/websites.

So an API makes connections between different programs, even cross-platforms and cross-programming languages. In our case, a Perl program can talk to Google that uses other languages. The other aspect is that you can access a large amount of data that you did not create yourself; you can extract data from elsewhere for your use. On the flipside it is, of course, limited what data is made available by these corporations because for them data is about value creation. Making data selectively available is part of their business model as well as building applications based on the data they have collected.

A further aspect is how Google presents the data to you through the API. This has a number of political implications in my opinion. After an image request, say, with the search term “Warhol flowers,” there is an endless number of matches online, but how do they prioritize the presented top ten? (How do they calculate the relevancy? What are the parameters involved?) So it is about knowledge production, about epistemic power, and this is what we have to understand when we use an API: it is not just a technical object, it is as much a piece of socio-technical infrastructure.

Custom Search JSON API: https://developers.google.com/custom-search/v1/reference/rest/v1/cse/list

C: How far did you get with your investigation of the Google API in particular?

W: My collaborator Eric Snodgrass and I have used nag as our case study to look into the technical specifications of the API, into the changing policies over time, into the pricing model, and we compared it to the Google Maps API, as well as the terms of service and specific operational processes and affordances of fetching networked data.

There are a lot of different elements, but, of course, I do not have the full picture of what is going on, simply because it is treated as a business secret. We just analyzed the materials and experiences that we had to raise and discuss a number of questions that we considered relevant to the research community.

C: Let’s stay a bit with the question why APIs are so relevant.

W: While researching APIs and reflecting on the nag, Eric and I were interested in thinking about the notion of “exchange” within the context of API. How application programming interfaces can be used to develop and design technological forms of structured exchanges, allowing data to be shared, automated, circulated, and redistributed in wider computational culture. Many companies use and provide APIs, but as another part of digital infrastructure, they are not just a technical matter but also have a political dimension in their function of bridging systems. As such they form an ecology in which many developers and artists are also embedded.

In our study and the published article, we also give a few suggestions for how anyone working with APIs might think through certain key questions around the creation and use of APIs, particularly with regard to the parameters of openness, accessibility, and the terms of inclusivity that APIs set on practices of knowing, sharing, participation, and exchange.5

C: So let’s summarize what all of this means in the context of the nag. First, you have to register and with that become identifiable as a user and your use is controllable, i.e., profitable.

W: Google defines what kind of data is available and the format of accessibility as well as the scope of access. But to be more specific, the image below shows how nag_05b works exactly.

W: Perhaps it is also interesting to know that the acronym API has already been used before the internet in the 1960s and ’70s, as a way to exchange data between different applications, as an interface between different programs.

C: It shows how fundamental this feature of exchange between different environments always has been. So we should have a look how this exactly works.

Winnie Soon explaining how the API works

W: Now I have a question for you. I think it has become clear where my interest lies and why I think of APIs as politically relevant. What is your interest in APIs?

C: Related to the experience with the nag being down, it was interesting to realize that it was not the program itself that had become obsolete. The breaking point was its dependency on external factors – factors that are out of our control. The end of the fiction of autonomy, so to say. And this was a powerful experience. When it comes to technical settings, the autonomy is very limited, because to a large degree we depend on structures and infrastructures that are out of our hands and also where the effort of building alternatives has its limits. So, in the end, I am dependent on these “partners” that have the power to dictate the terms of use. This puts my own power as an artist into perspective. My work finds its limits within these technical realities. Without Google’s mercy to provide me with any data, the nag becomes almost meaningless – except the power it has as a discursive tool that can be used to demonstrate the disproportionate power relations.

W: Exactly. The symbolic power we are currently using, for example, in the error message that blames Google for being so restrictive.

The nag’s error message communicates the limitation of Google’s API

C: For me, it was an interesting process to try and find a solution for this search-engine problem. I also talked to other artists who have similar problems, without any satisfying results regarding alternatives to Google. And trying to get in touch with Google to find a solution was a story in itself. It was a whole odyssey, searching for a human to talk to at Google, finding somebody who is responsible, who can make a decision – not even Google search could help with that problem. After some intermezzo that looked promising, which was to involve a nonprofit and would mean we could use certain services for free, this option was discontinued by Google in early 2018. In the end, the options were either to pay or to live with the restrictions. As nag is not a commercial project, paying is no option. Therefore, we came up with the idea to use the error message for communicating the issue. It is displayed after one hundred requests and explains why the current Google policy is responsible for the experienced nonfunctioning.

W: How would you respond to the argument that Google is a business and that, of course, they have to charge for their services …

C: Sure in a way this is true. They provide a service, and they invest a lot of resources in developing that. On the other hand, they are fully exploiting personal user data. Google would not exist without us working for them for free. But it seems that providing the algorithms that enable us to make sense in the endless sea of data is one of the most valuable services one can provide today, and unfortunately the bigger they grow, the better the services get. But they use their power to make money, and the other way around, they use their financial power to accumulate more power. With this in mind, it appears very small-minded and cheap that they cannot share a bit more of their services, for example, for nonprofits and experimental art projects. But, of course, how should they know it is an art project?

W: They could do a Google search [laughs].

C: Seriously, I think they should not just be a business, but also involve a responsibility. This is not the case at all. So far, they are clearly taking more from their users than they are offering. Google is a problem, their power is a problem, and they are expanding with the tendency to build a new hegemony – something very big and challenged very little. Actually, the Berlin-based NGO Tactical Tech, an organization that explores the impact of technology on society, included in their research on Alphabet (the corporation Google is part of) in their exhibition The Glass Room. It shows the dimension of this giant and how much it is reaching out and intervening into all areas of life.

See: The Alphabet Empire by Tactical Tech

W: Yes, especially if you think about how the search engine has been transformed into a public service, where most people rely on it for knowledge building and searching. Google has such a great power to build the knowledge base on existing data, but their ultimate goal is profit-making through advertisements. It is true that these giant companies have to be forced to think about social responsibility. With your work, you at least point to that problem. Do you expect Google to respond to your artwork?

C: Well, I was in touch with some spokespeople; they are aware of the issue, but are not in a position to respond. The people we would need to talk to are out of reach.

What we say on the postcard with the error message is that, in the long run, we are trying to teach Google, which refers mainly to their limited understanding of art. They have not heard of software-based art and net.art, and instead put a huge effort in digitizing famous analog museum pieces and alienate them by blowing them up, making them into a Disney theme park, something these artworks were never meant to be. Also a sort of abuse of power.

See: Google arts and culture

C: When it comes to their core competence, data, code, and networks, they are simply blind to artistic work that takes place in their own arena; that there are artists working with the same digital material. I think there is a lack of imagination that art can happen on the same level as they are operating. And this is something they need to be taught. But as it says on the error message: “in the long run.” It will take some time.

W: And it is not just Google we are concerned with. A lot of artists work with Twitter APIs, for example, to build creative bots. A similar thing happened when they discontinue those accounts despite their proclamation to respect art projects and keep their services available for them. The thing is, however, that these big platforms have the power to restrict and even destroy creative processes because they don’t understand how artists use their APIs in a noncommercial and explorative way, such as the art project Queer Motto API that I have made with artist Helen Pritchard. It is about generating real-time allied mottos for various forms of struggles, refusals and resistances.

nag_extension

W: In the context of the server, I would also like to mention the nag_extension that was developed by Gerrit Ché Boelz for the 2018 show Berlin, Zentrum der Netzkunst – Damals und Heute at panke.gallery in Berlin. Thinking what might motivate people to visit a net-based artwork in a gallery, you decided to take the nag off-line for the duration of the show and just have it available in the gallery space.

C: It was the first time that the limited version with one hundred requests was shown in an exhibition, so in one way it was a public demonstration of the Google restriction. The other aspect was to create an additional value for gallery visitors and address the issue of presenting online works in a physical gallery setting. But, of course, this was more an ironic comment on the issue than a meaningful suggestion or solution. One feature of the nag_extension is that all the images produced during the show are saved in a separate folder. When the exhibition ends, there is a set of images that is directly related to this event, the site, the time. And during the time of the exhibition, these images are projected onto the gallery wall, which means the displaying grid is filling up over time.

W: This is also when Gerrit expanded his role from sysadmin to collaborator in the creative team.

C: He has been there for quite a while looking after the server, but when discussing how to show the nag at panke.gallery and thinking about making it a special experience, he suggested and wrote the nag_extension feature. The thumbnails on the grid can be opened and viewed in more details when clicking on them.

The net.art generator set up at ZKM as part of the exhibition Writing the History of the Future including the wall projection of the nag_extension images in a grid.

The nag_extension projection of thumbnails with one enlarged image.

W: It is impressive to see the grid with the large number of images, how it is growing and changing all the time. It is a very different experience to see the wall filling up with thousands of images instead of having a few prints on the wall – or the wall painting.

C: Certainly it shows the dynamics of the net and also the liveness of the project itself, but, of course, this display only makes sense for this kind of presentation in white cube settings.

W: At this point, we can also mention that all the code of the nag including the extension feature are online and open. I put all the code on GitHub, a repository for code sharing.

C: The code of the nag is also on the project’s homepage but, of course, such a platform for exchanging code makes it easier for many people to find it. But wasn’t there the issue that GitHub was sold for $7.5 billion to Microsoft? This triggered a lot of criticism with many saying that the free labor of all the people contributing was being exploited and monetized?

W: That is true, but the software remains free and it is still the most popular platform for code sharing. Also, I started using GitHub long ago, before it was sold, and it is not so easy to transfer all the code elsewhere and make the new links known. But I also shifted some of my software to GitLab, another repository that is still free.

C: I know Gerrit refuses to use GitHub and has his own platform for storing code, which is great but also questionable because the idea of a central platform makes it easier to find and share things.

The code of the nag_extension can be found here: https://lab.lostb.one/nag_extensions/gallery

W: One of the advantages of these kinds of Git platforms is that they show the version history so that you can trace all the decision points. Since the launch of nag_05b in 2017, there were again a number of updates. There is more transparency for us, the audience, future researchers, and the ZKM preservation team.

C: Obviously, another complex issue in terms of techno-politics …

W: And also a relevant part of infrastructure that has been taken for granted as a free source – until somebody made it their property and sold it.

1 Shusha Niederberger, “Feminist Server – Visibility and Functionality: Digital Infrastructure as a Common Project,” Springerin 4 (2019), https://www.springerin.at/en/2019/4/feminist-server-sichtbarkeit-und-funktionalitat/.

2 Brian Larkin, “The Politics and Poetics of Infrastructure,” Annual Review of Anthropology 42 (2013), https://www.semanticscholar.org/paper/The-Politics-and-Poetics-of-Infrastructure-Larkin/7133e9653dd6d3c77b20c650c069529ad694847d.

3 Susan Leigh Star, The Ethnography of Infrastructure,” American Behavioral Scientist 43, no. 3 (November 1999), https://booksc.org/book/18596744/09800c.

4 Claire Richard, “Pas d’internet féministe sans serveurs féministes: Entretien avec Spideralex”, Panthère Premiere 4 (Autumn 2019)

5 Eric Snodgrass and Winnie Soon, “ API Practices and Paradigms: Exploring the Protocological Parameters of APIs as Key Facilitators of Sociotechnical Forms of Exchange,” First Monday 24, no. 2 (February 2019), https://firstmonday.org/ojs/index.php/fm/article/view/9553.

<!--

# Chapter 3

-->

<head><title>Fix My Code</title>

<p class=h2>COLLABORATIVE CREATION</p>

After two chapters focusing on various aspects of the technical settings of the net.art generator, we will now have a look at the interplay of the various human and nonhuman actors involved. Collaboration is the keyword here, and we will discuss how much of it is an essential part of the creative process. The outcomes of the nag as well as its technological basis would not exist without collaborative processes. As collaboration brings with it the question of power relations, we explore the role of the different actors involved while also taking into consideration the gender aspects that eventually led us to the role of collaboration for critical research and agency in general.

Collaboration

C: The nag is one of these pieces that could not exist without collaboration. The related collaborations, however, take place on various levels and with very different people – and also nonhuman agents.

W: So shall we try to make a list?

C: I guess a list will somehow emerge anyway. I’d suggest we start by looking at a text that I published in 2004. It was written in the context of the legal discourse I had entered after first accusations of copyright infringement related to the nag led to the cancellation of an exhibition at plug.in in Basel. The text was titled “copyright©2004 cornelia sollfrank,” and it explored the question of who can be considered the author of a nag-generated image. So the focus here was not on the overall project but on the result of the generating process. As we will see, the situation concerning this straightforward question is already quite inconclusive, which suggests how complex the questions of collaboration and authorship in this project are in general.

Screenshot of the video copyright©2004 cornelia sollfrank in which Cornelia Sollfrank reads the eponymous text to the camera.

W: Would you like to summarize the text?

C: Basically, I am looking into the question of authorship based on the legal definition of authorship. The various participants in the production are examined in detail (computer program, programmer, user, original author, and the artist as the source of ideas), and various arguments are weighed against each other. Interestingly, from a legal perspective, the surprising conclusion is that I can definitively be excluded from authorship as I just contributed the idea, the concept that is not relevant for copyright protection.

W: This is weird and funny, because in the art world it is you who is perceived as the author of the project and, therefore, also the images.

C: This outcome only applies to the images. And as the intention of the whole text was to show the absurdities of legal thinking, I think it served its purpose very well!

W: Basically, you are listing five different possible “coauthors” in your text, the program, the programmer, the user, the original author, and you as the one who had the idea. I would like to add some comments to this list. Regarding the first position, the program is the Perl script we have discussed earlier. I have been thinking about that position, because the same task could be coded by a different person and in a different programming language. In my opinion, the essence is not the Perl script but the underlying algorithm. I mean the steps, the procedures, the logics that define how a program should be executed. You can easily imagine it as a flowchart. The thing is that one could consider the Perl script and the algorithm as two different things.

For programmers, there are two levels of creativity, the one concerning the algorithm and the other concerning the implementation of the algorithm. When you gave the brief to the programmers, it was you who had created it, and then the coders used their logic, problem-solving skills, and creative thinking to create an implementation. And there are so many different ways to write the program. What I am trying to say is that this position on the list is not only about the Perl script but also about the underlying algorithm.

C: How should we situate the algorithm, then, as related to the final outcome?

W: Well first comes the brief of the software idea, and then comes the design, the features and functionalities that one would like to implement. Once the idea becomes concrete and detailed enough, decisions must be made on how to structure the program, i.e., the algorithm, followed by the implementation with code/programming language. But, of course, how it is implemented also has to do with the infrastructure and environment (e.g., the operating system).

C: Then I would say that the brief, the original idea comes from me, the algorithm has been developed together with the programmers, and the implementation was done by the programmers alone.

W: In your text you also mention the search engine. While it did not deserve a place on your list, you write: “The program is not a tool as is a pencil for drawing. The program is responsible to determine which search engines will be used, what images and texts will be loaded into the pool of material to be reworked.” This directly triggers the question: Who makes the decision regarding the search engine?

C: This has been a dialogue between the programmers and me. We talked about the different options, and in the end I trust their expertise and recommendations.

W: Which means it is not the program that decides what search engine is to be used, but it is already part of the script and has been decided before.

C: Correct, and when we use Google search, its algorithm decides what material is returned to us …

W: … which is another part of the collaboration, actually a huge one with a lot of power. Google prioritizes the images from gigantic databases, and before that Google decides the specification of the API standard, on how you access the data; Google decides what is the limit of requests for using the API and related to that the charging scheme; Google decides how you register the API; and Google also decides whether you are a bot or a human user.

C: That is massive, and I understand you do not agree that I just listed this position under “program.”

W: I think, the search engine needs to be on the same level as the program because without that part nothing would work. And I am surprised you do not even mention Google.

C: Simply because we did not use Google back then. The first search engine we used was Yahoo. Basically, I decided to subsume all nonhuman actors under “program” and the other four were human.

W: I think it should be more differentiated and should also include the server and the network protocols. Is it possible that you are granting privileges to the human actors?

C: Yes, obviously. But, remember, the starting point for my discussion was the authorship question. In the legal discourse on authorship, there is a clear preference for human actors. Actually, in most legislations nonhuman actors are excluded from the authorship status. But you are right, we are talking about collaboration and not just authorship (interesting interrelation, by the way), and we should attribute to the nonhuman actors what they deserve.

W: I would also like to include here the four modules that are part of the Perl program. So, even the Perl script is not only about the one person who authored the code but also the ones who wrote the libraries and thus save a lot of work for the programmer.

C: I see your point.

W: On the basis of the search term entered, Google selects the images, prioritizes them, and provides them as raw material to the nag. But at this point, I am asking myself if Google could not even claim authorship of that process – or at least parts of it.

C: I don’t think so, but it is an interesting point that we will have to explore further. And this question not only concerns Google but also the authors/providers of the other technical systems the nag relies on. I think, we can lay out the involved technical elements in more detail. We definitely have to mention the server administrator again, Gerrit, and also the company he is working for, IAP, because they are hosting us for free, which is also an important contribution. At this point, we can also have a look at the parallels – and also the differences – to AI-based image production.

W: To start with, one of the similarities is that they are both using data but AI, in general, needs much more training data in order for the machines to learn, recognize, and predict the pattern. When we feed data into an AI system, it uses this material to automatically generate texts or images. But the level of the algorithms is very different. Prediction is in the center of AI, which is fundamentally different from nag. But for prioritizing and selecting the images Google presents to the nag, they also use AI. The main similarity is that the machines take over the process of automated creation.

C: I guess the nag is very simple in the sense that it just merges the images provided regardless of their content, while an AI system tries to analyze the content of the images.

W: And the AI system is able to learn and improve itself. What they both have in common, though, is that they depend on large numbers of images as data source.

C: Let’s come back to the other nonhuman actors. As already mentioned, today I would even consider the digital infrastructure as being an integral part of the project. The server, for example, as well as the networks that connect all the other servers we rely on. So thinking about collaboration today looks very different from my early discussion of authorship. In the sense that there would be two main categories: human and nonhuman, and both would then be differentiated into all the entities involved. Shall we continue to discuss the roles in more detail?

W: Let’s have a look at the internet as collaborator.

C: On the suggestion of the Danish curator and art historian Jacob Lillemose, I started to call the images produced by the nag “networked images.” One could understand the networked image as kind of opposite to the idea of an autonomous image or Tafelbild (panel painting). The networked image is networked through the digital network, of course, but it is also networked through its prehistory, in the case of the Warhol flowers through art history. They are networked on different levels. So the image we have is not a discrete entity, but it is part of a network, of art history, of the internet, of technological processes. And I also describe the networked image as an index that points to the process of its computational creation.

W: I am not sure how you would put this in relation to the notion of the “operational image” that was suggested by Ingrid Hoelzl and Rémi Marie in their book Softimage. There, they suggest to think about images as being part of a megastructure of operations. What kind of operations? The operations of image circulation, with an emphasis on the algorithm.

C: I thought about this concept as part of my PhD and realized that for me both levels are relevant and the ways they interplay: the content with the flowers including their whole history of appropriation. In terms of technology, Warhol appropriated the printed images and transformed them in his prints, but with that, the story ends. Only afterward they were digitized, put online, which means there are many ways they can live on and become part of other works, like, for example, they become the basis for the anonymous-warhol_flowers, which themselves live on and can become part of other production processes on a technological level, the software, the search, the underlying algorithm. And as far as I remember, Hoelzl and Marie are not dealing with artworks but look at image production in general, at new categories of images as use objects, for example, in Google Street View, etc.

For me, an important aspect really is this change of the status of an image within the art context. Will the art world, art theory be able to follow this shift?

W: Harun Farocki also talks about this idea of the operational image: “Images that do not represent an object but rather a part of an operation. The image functions as a guiding tool for target tracking and real time adjustment.”1

In any case, the internet is central in your work, because this is where the nag is situated and where the material for its operation comes from, and also the newly created images are made available on the net. Without the internet, this art project would not exist.

C: Well I guess this is the point of internet art, that it cannot exist without an internet connection, although one has to say that this was not true for many of the net.art pieces. They were often using the internet just as a distribution channel. When internet art was shown for the first time at documenta X (1997) in Kassel, the computers were off-line, because the curators were afraid that the users would just go and check their email … Funnily enough, I don’t think that the art world has a better understanding of this type of art today.

W: Internet art has never become part of the contemporary art scene. But what do you think is the reason for that?

C: There are certainly different reasons. One important aspect is the originality issue, which is still in the center of thinking, especially for the art market. Then, I guess that computers have the reputation of being cold and rational machines, machines for large calculations, office tools that in no way can have something to do with poetry or artistic expression, the alleged lack of aura. I am afraid that the materiality of the digital is not widely understood. Apart from that, the works are fragile and hard to maintain. The aspect of preservation is important for people who spend money on artworks. They do not want them to fade away or die because of a hardware problem, etc. I am sure this is another reason why so few collections and museums have decided to collect internet art. Sadly, not much has changed in that respect in the last twenty-five years but I have to say that I am very optimistic that it will happen, just as it happened with photography and video. It will just take a while, maybe until 2050? It requires a new mindset that then also will provide the resources for the respective forms of care and preservation.

W: There was this spectacular sale of AI-generated art, Portrait of Edmond Belamy, at Christie’s in 2018 for $432,500.

C: This has definitely fueled the discussion on machinic creativity. In spring 2019, we had this conference at Zurich University of the Arts where the exact same discussion on authorship that we started twenty years ago took place.2 But it was also sad to see that the reason for all the excitement came from that spectacular sale at Christie’s. All of a sudden, art historians and legal experts woke up, in the sense of: If this sells for so much money, it must be something, and how can we deal with it as it doesn’t fit our old categories?

But things have calmed down again. It seems it was a one-off success. Maybe it was even fake, a sort of PR gag to create a new market … It’s not like the art market goes crazy now for algorithm-based creativity [laughing]. But it worked in the sense that the price caused a lot of attention, which shows that in the end, the only thing that determines the value of art is the price it is sold for.

W: We already have speculated earlier about what the next episodes of the nag story could be. I mentioned that I am thinking about implementing the algorithm of the nag with JavaScript. Liveness, which is one of my main interests in computing, seems to connect to the discussion we’ve just had about artificial intelligence and the nag and could indicate a possible future direction for our project. Last but not least, AI can also be considered to continue some central aspects of generative art and the nag in particular.

C: With this we should come back to your interest in liveness and computing.

W: In my early research, I suggest liveness to be constituted of three elements: 1) generativity; 2) unpredictability; and 3) automation. If you think about generative art, there is more of a focus on chance operations, while for machine-learning (ML) the focus is on predictability and accuracy. I am interested in rethinking liveness not only to incorporate unpredictable operations but also to work against predictions in order to think through what unpredictability means. The other element is about generativity and thus directly related to the nag. The question is how generative events can be produced through algorithms. For machine learning, it also deploys different machine-learning models. And I am interested in understanding what new models of generativity exist in machine learning. What are the different models of understanding generativity in ML that constitute our understanding of liveness – or performativity? In terms of practice, I am working with code/software and data as a way of thinking and conceptualizing things.

C: I am afraid you now have to explain what ML is.

W: The ML process starts by examining big data sets, cleansing data, processing the data in order to prepare them to fit into the neural networks or the generative models to predict images, motifs such as a cat, a dog, etc. But my concern is not the quality of the prediction. I’m more interested in the process that starts with data collection, the modeling, and the questions of how knowledge is being produced, and what kind of knowledge.

C: Can you give an example?

W: In the end, it is about perception. Through ML we can learn to understand the aesthetic potential of machines, expose how they sense or make sense of the data. For example, how can we understand an image differently. How would ML processes inform our understanding of an image as an object? So far, we perceive an image only with our human faculties, but a machine can “see” and make sense of an image in a different way.

C: What is behind this excitement about sensing machines?

W: It is about liveness beyond the human register. How the machinic production constitutes liveness, how it generates the phenomenon of liveness. ML uses statistical models for that and compares algorithms to produce stuff on the fly, which is quite different from generative art that is based on clear instructions and procedures. Even computer scientists have difficulty understanding each step of the training process. This black box, the invisibility of the infrastructure, is interesting to open up and explore its implications. What happens when we shift our focus from a human register to material infrastructure to better understand things?

C: I guess here is where the discussion on new materialism should be inserted …

W: Considering nonhuman agency gives us a different understanding of how we perceive the world. It is no longer human centered, instead material agency plays an important role – which relates to what we have talked about in the previous chapter, the role of infrastructure as an important element in the collaboration.

C: In this context, we talked about the new center for the development of AI in Germany, in Tübingen, where a lot of academic and business partners will work together – including Amazon. They are on board as providers of the big data required for research and development in the field.

W: This brings the attention to the issue of resources because it is only huge institutions and corporations, such as Google and Amazon, who can work on developing AI. It requires high-processing capacities, machines, server and storage space, energy and, most importantly, big data. This makes clear who has the power and will to control the developments in the field.

C: It is a very relevant point that AI development cannot be done by small or independent research units. It means agency is shifted in one direction.

W: Only the big players are in the situation to produce knowledge, to manipulate, to own the process, and thus accumulate more power and more resources. They are the only ones to have the means to collect big data, like Google and Facebook already do today. It is IBM, Google, and Amazon who are into AI today. They are the important agents that influence the research and development in the field. And I am interested in getting involved in ML because I want to get a better understanding of this development and also explore the cultural and political issues involved.

C: New challenges have always pushed our work forward; the good thing about restrictions, errors, malfunctions is that they force us to shift to a next level, instead of just giving up on the work. As an artist, I am more interested in the conceptual side of the work, and I often rely on technologists that make an interesting relationship between the technical and the conceptual. Artists need to know about production tools; they need skills to produce things, but it can also be a trap as we have seen. You never know enough, your skills are never sufficient, this is part of the challenges of digital technology. It is important not to get lost in skill acquisition or the excitement about feasibility. Therefore, the collaboration of people with different skill sets is essential in working with the digital realm.

W: This relation between technical and conceptual aspects is also what interests me in my research. As mentioned earlier, I am currently working with Geoff Cox on the book Aesthetic Programming,3 and we are trying to bridge this gap. We explore the humanistic and conceptual aspects of doing/making things, which also implies the need to get away from a purely positivist understanding of the functionality of technology.

C: This requirement for collaboration is something I have to emphasize again. What happens in collaborations is that you start discussing and negotiating during a process of realization, which very often is also a way for improvement. And when I say collaboration, I do not mean commissioning somebody to make something for me. Even if you have something functioning in the end, the process is boring without dialogues. On the other hand, I have to admit that very often this way of dialogical working is tedious, because the power that comes with technological skills, knowing how to make something, is usually unreflected, while there is also the risk that the person who realizes another person’s idea or concept is just treated as worker/producer and is not respected or credited enough, especially in the context of art. Which again raises the question of power relation in collaborations. What kind of skills are valued higher than others?

W: And it is about the role of material and the question of materiality. Some people think coding is a craft.

C: It certainly can be – if you assume code to be a “material,” which has a different materiality, the “immaterial materiality.” I think this whole question of skills is closely related to the question of material, a basic question in the arts. What is my material as an artist? What skills do I need to express what I want to with these materials? Which always reminds of Joseph Beuys, who as an art teacher requested his students to leave canvas and paint behind because the medium of painting, using paint as material all too easily makes them believe they are real artists. Instead he wanted his students to get a deeper understanding of the relationship between idea and material. Material can be a trap, any material, also the digital.

W: But some artists are interested in exploring a specific medium, like I am interested in code/computation as material, as a way to think about the structures and power relations they are embedded in.

C: Sure, this has been a legitimate understanding of art for a long time. Beyond that, you cannot do anything without material, not even conceptual art … There always needs to be a form of implementation or manifestation.

W: What is your material then?

C: Good question. I think, the question of material is not central to my work, as it is for you. For me, it is more the conceptual aspect, certain themes that can be realized in very different media and materials. And I would say, digital materiality is one of the themes in my work, but the related works do not necessarily have to be software-based; they can also take the form of writing, performance, video, or installation.

W: We should continue this discussion that originated in your thinking about authorship and talk about our own experiences in collaboration.

C: You mean the collaboration between me and you?

W: In our collaboration, there are different aspects for me. I have followed your work over the last years, and I feel there is a trust level between us, for which the gender aspect might play a role as well. And we have experienced certain things together. You attended my workshop on coding, for example, and you were also present at the oral examination of my PhD in Aarhus. I know you are someone who is willing to listen on a personal, conceptual, and also technical level. And I feel comfortable with you, because there is no pressure from your side. In the beginning, when I told you I am not an expert in Perl, you were very encouraging; it was a real problem for me. But through your response, your tone and manner I had the feeling that there was space for me to learn and to make it happen. And I also think that you are not somebody who is exploiting other people. I think, this is a very important aspect of collaboration. And the reason why there are so few women in free software and open source: they do not feel comfortable in the communication culture that puts an emphasis on competition and functions as a meritocracy.

C: A very unpleasant topic, indeed. In fact, collaboration requires a framework of trust.

W: I also appreciate that you insist in paying me for certain works … That gives me the feeling that there is respect for the time and energy I devote to the project, even if I am not an expert. But with the trust comes the space to develop things.

C: So that’s the two of us, but we were working on completing the list of agents involved in the nag collaboration process. You joined the project rather late, in your function as a coder. I am wondering how the collaboration with the other programmers looked like.

W: Did you keep the initial brief?

C: I am afraid not. I did not keep any of the material you would be interested in as a researcher. The project just evolved, sometimes with long breaks between different steps. It was never intended to grow into such a complex project. Working with code and the internet was very playful and experimental. We did not think about preservation because it was unclear how the internet would develop … Also, the technical aspects of the project were never the central issue for me. I was always more interested in the conceptual side. This is also why it is so interesting for me to work with you: it opens up a whole new perspective.

W: Do you remember details of the collaboration with the other programmers, what their questions were? How did they approach the task?

C: It was a bit different in each case because some of them were used to working in the art context and were familiar with artists’ approaching them with weird ideas, while others were coming from the corporate world and needed more guidance into the artistic thinking. With one of them I did an interview; he got really enthusiastic about with Dada and the idea of collage, and he made a suggestion based on Markov chains. He created a very sophisticated version of the nag, but after a few years, also ran into search-engine problems and decided to drop the project altogether.4

C: To conclude, regarding our ideas on collaboration as practiced with the nag, one could say that there are many different actors involved, which might be one reason why the project is still alive despite the fact that there has hardly been any funding for the maintenance of the project. In this sense, a real collaborative achievement and a functioning “network of care.”

Gender

C: In the context of collaboration, we should also talk about gender and feminism. Not only do collaborations tend to entail hierarchies, that is, power relations that should be addressed and made visible; we find ourselves in the field of technology, a highly gendered field, as we know, which is why it is important to look at the nag and our work also through the technofeminist lens.

W: I am wondering what the feminist perspective is in Female Extension and the nag. If I am not mistaken, it all goes back to 1997 when you did a cyberfeminist intervention at the Kunsthalle Hamburg, a public museum, where the first net.art competition was held, right?

C: That is where it all started, with Female Extension. Basically, it was the hack of this competition by flooding it with almost three hundred fake net.artists, all female. The script that collects and remixes websites actually was a side product of this intervention for which I had to create hundreds of fake net.art web pages. On the occasion of its twentieth anniversary, Rhizome included it in their Net Art Anthology.

W: Why female net.artists only?

C: That has to do with the historical situation in 1997 and the net.art scene. I was somehow part of it, but I was not very pleased with the artists copying the behavior of the traditional art world, including the habitus of genius, especially of some males. This was a disappointment for me, the net.art scene trying to reproduce the habits of the traditional art world, you know, raising attention, so curators would invite them so they could become part of the art world. My interest in the internet lay exactly in its quality of being an independent space, its possibility to make work, to publish, to network, to experiment outside the paradigms of traditional art. For me, working with the internet had a lot to do with institutional critique. This was not what was driving the majority of the net.art scene. They were keen on being accepted into the traditional art world. There is this myth that net.art was critical, which I find totally ridiculous; it is part of the mythmaking of the scene. Rather it was about securing the new territory. Also, most net.art worked disappointingly close to paradigms of the traditional art world, e.g., regarding authorship, regarding the format of finished pieces, or serving the conventional artist clichés … this was all quite different from the potential I saw in this new field, or rather what I wanted it to be.

W: Would you like to describe what that was?

C: Connected and process-based work, collaborative authorship, institutional critique, etc. So you could also read the nag as a comment on the net.art scene. My slogan “A smart artist makes the machine do the work” is basically shitting on the idea of a (male) genius. The power of the creative machine would surpass the creative human [laughs].

W: In the 1990s you were a pioneer of cyberfeminism. In your recent book, The Beautiful Warriors,5 you suggested the use of the term “technofeminism” instead. What does it mean for you? Why do you need a new term?

C: I believe technofeminism works better as an umbrella term. It includes all the different versions of technology-related feminisms that have emerged in the last thirty years, including cyberfeminism. Meanwhile, I prefer the idea that cyberfeminism was a specific historical phenomenon that I date between 1991 and 2001. In 1991 VNS Matrix wrote their Cyberfeminist Manifesto for the 21st Century, and in 2001 the Old Boys Network held its last international conference.

W: So once more: What does technofeminism mean? And how is it different to cyberfeminism?

C: In order to answer that, I will have to dig a little deeper. After 2001, the focus of my work shifted to copyright and commons mainly. The whole hype around cyberfeminism had cooled down. The first invitations to speak about the cyberfeminist past didn’t arrive until 2015. Then, a new wave of interest in the field of gender and technology announced itself, and it took me a while and a number of events to understand what was going on. It clearly was something different from fifteen years before, a different generation, different strategies, different goals and habits, and, most importantly, a totally different situation regarding digital networked technology, which in early cyberfeminism was something new and promising, while in 2015 it had already shown its dystopian side. I found it absolutely essential to mark this difference and to not pretend that nothing had changed in the meantime. That is why a new term was required.

W: Can you describe what the significance of this difference is?

C: As you know, cyberfeminism in the ’90s was very playful and experimental. We refused to define the term and experimented with new aspects in gender politics and new ways of practicing politics altogether, all of which was very cool and certainly had a huge impact on how the younger generation changed their perspective on technology. Technology no longer equaled patriarchal dominance over nature and women, but was conceived as holding also emancipatory qualities. This enthusiasm, however, was followed by disillusionment. So when I came across the term “technofeminism” that was introduced by techno-sociologist Judy Wajcman, I thought that her term would be perfect to combine empirical facts such as the male domination in the technology sector with queer theory and thus lay out the ground for a new way of working and thinking, more appropriate for the twenty-first century.

W: Can you describe that in more detail?

C: Technofeminism means awareness of power relations built into and produced by technology, assuming that gender and technology mutually shape each other and therefore can comprise a whole variety of strategies – from gender-specific skills training for girls to queer performance art and everything in between. And one thing we have to consider more is that this mutual relation also has a cultural component, meaning that it shows different manifestations in different parts of the world.

W: Your thinking about power and gender relations is deeply embedded in your work and has already been present in your early works, such as Female Extension and the nag.

C: I think they are both related to a very basic feminist attitude, which is about understanding power relations, in particular the ones you yourself are involved in. As an artist, an important reference system for me is the art world. I try to understand where I am in this system, who has power over me but, also, over whom I do have power. And there is the question of where and how manipulation and other abuse of power is taking place. Do I have to do things I do not want to do? Am I excluded from something I should have access to? Why I am excluded? Are the constituting norms and paradigms transparent? This analytical exercise is something that I am constantly doing, sometimes consciously, and also sharing it with others, sometimes it is just running as a permanent background program. It is always there when I enter an art space, an academic conference, a classroom, or any form of collaboration. If one is interested in fostering emancipatory processes, this sort of analysis is fundamental.

W: And the link to the field of technology is this interest in understanding power relations and how they relate to gender. I guess this is also where your interest in forms of organization and self-organization originates.

C: I would describe my strategy as being in and out – the art world, academia, political organizations. Not in between, but taking part in the system (if possible, without becoming cynical), and also constantly working on structures and infrastructures that are more self-determined, that allow for unlearning and decolonizing the unconscious. I still believe in independent infra-/structures, not because I think that something like real autonomy can exist, no, it can’t; nevertheless, there can be niches and spaces that are safer, which can even become existential. At times they can help one to survive, as, for example, the cyberfeminist organizations in Latin America Spideralex is talking about in her text “Creating New Worlds,” and at other times they give the freedom and space to explore forms of unlearning.6

W: What would be specific examples for that in your own practices?

C: First, the various groups, collectives, and networks I have initiated and have been involved in for many years, like frauen·und·technik (women ·and·technology), -Innen, Old Boys Network, #purplenoise, then also structural projects like THE THING Hamburg or TammTamm – Artists informing Politicians.

W: So very often in your institution-critical work, gender and technology play an important role.

C: And as I said earlier, technology cannot be critically reflected on without taking gender aspects into consideration. What’s your stand in that? Do you think the “gender and technology trouble” is purely a sociological problem in the sense that equal education, participation, and equal opportunities would solve it? Everything would be fine if we would just have greater diversity in the field? Would that automatically change the quality of technology as we know it today? Which includes the question, do you assume that your work with technology is different because you are a female technologist?

W: I really don’t know if what I am doing, or how I am doing it, is related to gender. Sometimes I think I am just interested in code. Period. But then I see that what I am doing is somewhat different to what other programmers do. I do not understand code as just purely functional, as a tool to execute something, like a master and slave relationship (the master has the full control, and the tool assists the master), and I recognize the agency of technology that has a wider relation with our culture and politics. I am not sure if it is a gender issue that I want to queer code beyond the normative paradigms. Also most people prefer to work with the latest, cutting-edge technology but my interest goes deeper in thinking and reflecting on the relations and politics of technologies. I am interested in specific programming languages and the implications of their use, and I have a sensitivity for language in code, such as the master and slave concept, which somehow encodes violent thinking into computer instructions.

C: In what sense?

W: For example, when you want to end a computational process you have to write “abort.” Or think of the term “screenshot,” which is about grabbing, it also comes with a violent notion. And code is always about a particular logic, which tends to categorize and generalize things extremely. The example I often give is that of human communication where you can say, “I am bit tired” or “I am a bit hungry.” But with programming you are forced into the logic of “if” and “then,” meaning, if I am hungry, I have to eat, if I am tired, I have to sleep. With an application of such logic you get, for example, a form that you have to fill in, whereas when it comes to gender, there are only two radio buttons: male and female. This could be observed on Facebook, where in the early years, the registration page only had these two options: male/female – one/zero. Only since 2014 has it been possible to choose between different genders. There are different biases when we work with code that get implemented in the code. Basically, programming often forces us to think in a highly classified manner. This is a danger when we learn to code, this interaction between computational logic and the way we think.

But the problems lurk everywhere! If we look at GitHub, for example, which is the platform for the exchange of free software, most of the users are male.

C: The latest numbers I have seen said that 2 percent of the programmers in free software were female. And it is not because they don’t have permission to go on GitHub, be a member of CCC, etc. The problem is that the predominant culture in this tech underground makes nonwhites and non-males feel very uncomfortable. Luckily, there are efforts now by queer groups to claim some territory in which new codes of conduct can be practiced. Obviously, it is not technology as such that discourages people, it is the codes and the values practiced in the field.

When responding to your earlier question about gender and technology, I think it is more apparent in my teaching, especially when I teach coding at the University level. I am aware that those who have already come with certain technical skills (unfortunately mostly men from my experience) with much power to silence others and lead the group project in their own terms. As such, how to create a safe space is really crucial when it comes to technology. I think I can also say that because I am perceived as a “female coder”, it also helps to undo certain kinds of norms in the tech area. I received one of my students' reflection in the coding course, “code is not a gentlemen’s club that only belongs to computer scientists.”

W: Can you relate that to the nag? Is it a welcoming place or space?

C: It is hard to say, because it is not really a social space where people meet. But the way the users are “confronted” with technology is at least quite welcoming. And I know from the feedback the users give that many of them are females. You can easily get a sense of achievement, which is encouraging for many. In terms of the back end, I have to say, only two female programmers were involved. It is rare for me to find nonwhite, non-male people who are willing and able to collaborate on the code level.

W: I find it interesting what you said about power structures. What was triggering my interest in the nag in the beginning was really its dependency on search engines and the politics of the API. My interest clearly lies in the question of how power relations are executed on the code level, and on the level of infrastructure.

C: And this execution of power through code happens all the time, is everywhere. Just installing a program forces you to accept all terms of use, if you like them or not …

And I am afraid it will neither be easy to escape from the social norms that are informing our digital environments nor from these coded power relations. But engaging in a dialogue with partners and collaborators on all levels is a necessary start.

1 Harun Farocki, “Phantom Images,” in Localities, Public 29, ed. Saara Liinamaa, Janine Marchessault, and Christian Shaw (Toronto: Public Access, 2004), 12–22.

2 “Digitale Kunst – künstliche und künstlerische Intelligenzen,” March 14, 2019, https://collegium.ethz.ch/wp-content/uploads/2018/10/190314_digitale_kunst.pdf?fbclid=IwAR3rXxPLnloV_8DsToxP4Nbtd5w6mlHphW7Uofy7xDtAQxKs08vyGpI15_U

3 See info box chapter 1, p. 20.

4 “Nine Steps to Dada: Conversation between Cornelia Sollfrank and Richard Leopold,” Artwarez, 2003, http://artwarez.org/projects/nagBOOK/texte/richard_eng.html.

5 Cornelia Sollfrank, ed., The Beautiful Warriors. Technofeminist Practice in the 21st Century (New York: minorcompositions/Autonomedia, 2019), https://www.minorcompositions.info/?cat=64.

6 Spideralex, “Creating New Worlds,” in Sollfrank, 2019, 35–56.

<!--

# Chapter 4

-->

<head><title>Fix My Code</title>

<p class=h2>CARING COLLECTIVELY</p>

In this last chapter, we are going to change the perspective once again and look at the nag under the sign of preservation. As an artwork, its material basis is digital code, which in itself comes with a number of difficulties. Furthermore, the project needs a permanent internet connection, and it has an interface to a search engine whose results make an essential contribution to the outcomes of the generator process. As it has turned out over the years, the code itself is rather stable, while the breaking points are the connections to the exterior systems. In most cases where repairs had to be carried out, it was adaptions to changes in external systems. As these are out of our control and can occur any time, there must always be an expert who is responsible and response-able in the sense of analyzing the problem and developing and implementing a solution. This raises a number of questions, and some of them cannot be answered easily, thus leading to new discourses …

W: My first question to you is, how important is it that the nag is fully functional all the time?

C: This is indeed the basic question, and I found a pragmatic approach to it over time. The ideal situation is that it is working, but as it is such a long-standing project – being online now for more than twenty years – there have been times when it did not work, sometimes for long periods. But as the nag is not just a tool to make images but also a thinking tool, the times of dysfunctionality are part of the concept and can become very productive. While things are happening behind the scenes, we are communicating to the users with specific error messages. Error messages are a wonderful way to communicate, and the users respond by sending their support or complaints via email.

Postcard with current nag_05b error message (since 2017)

W: Interestingly, the questions around preservation are not unique to the nag but basically concern all code-based works. How do you situate the nag within this context, for example, the research conducted for the project Digital Art Conservation at ZKM that was dedicated to exploring strategies for the conservation of digital art? 1

C: There are a few institutions trying to develop conservation strategies, because they understand that if nobody takes care, the works of the digital avant-garde will be lost. As always, it is a question of ambition, competence, and resources. ZKM is clearly at the forefront of this development, together with a few others who were involved in the research project – but as an institution that has a huge collection of its own, they have to put an emphasis on the works they own.

W: This brings the question of ownership into the game.

C: Definitely, and when conservation remains an issue even for large institutions, you can imagine what it means to all the works that are not part of collections, for which the artists themselves have the responsibility.

W: As is the case of the nag, right?

C: As you know, the nag is under the GPL and as free software it does not really correspond to traditional notions of property, especially the ones in the art world. The idea behind free software is that is belongs to the public, and everybody who has the skills to help maintain or improve it can and should do so. This works quite well in the field of regular application software. But in the case of the nag, it is trickier because its community is not as large and although I prefer the idea of a distributed network of care, there always need to be a few people who actually take responsibility.

W: You also sold the nag_machine including the software to public and private collections, such as ZKM and also customized requests from individual customers with the anonymous-warhol_flowers prints. Shouldn’t they actually take care of it?

anonymous_warhol-flowers (prints), exhibition Automat und Mensch, Kate Vass Gallery, Zurich, 2019

C: One private collection in Hamburg has included the nag-code, regardless of the fact that it is free software, but they failed to maintain it for more than a few years. It was just abandoned. And ZKM actually did not buy the software, for obvious reasons, but the server object on which it is running, the nag_machine that we have already discussed in the previous chapter.

Installation of nag_machine, Art Machines – Machine Art exhibition, Museum Tinguely, Basel, 2008

W: This introduces a second layer: it is not just the software alone but also its material carrier. I remember when I first found out about the server box. I was thrilled, and then we were invited to run the workshop net.art generator – Generating Discourse together with the ZKM conservators.

C: It was a great coincidence: we had just finished the work on nag_05b, and I sent them the code to inform them that they have to update the nag_machine, when they brought it out of the storage to prepare it for the exhibition Writing the History of the Future, in which they show their collection.

W: It probably does not happen very often that artists do the maintenance job for the museum …

C: What we do ourselves is the maintenance and care for the code, true. And it makes sense because the code can run on many different servers and is not bound to the machine in the ZKM collection. But they also did a great job bringing the whole object to life again for the exhibition.

Installation view, nag_machine with user interface and projection of nag_extension, ZKM exhibition Writing the History of the Future, 2019/20

W: Which involved much more than code because some of the technical components of the server also needed updating.

C: We were impressed with the carefulness with which the conservators were doing their job and had the idea to ask them some questions concerning the process.

nag_machine @ ZKM

Interview with Morgane Stricot and Matthieu Vlaminck, restorers at ZKM Karlsruhe.

Questions by Cornelia Sollfrank and Winnie Soon

Q: Could you please describe the process of bringing the nag_machine out of storage. What is the basis you have worked from? Is there a comprehensive documentation that contains all the details? Please describe the first steps, your experiences, etc.

Morgane: We received a letter from you (Cornelia) at the end of August 2017. In this letter, you were informing us that the software of the nag had an update and was now running under the new Google policy.

I had just arrived at ZKM as media and digital art conservator of the collection and this letter caught my attention: the nag software had suddenly stopped working in late 2015 when Google changed its access policy for their API. You informed us that the strategy is to let the nag work with the free but limited version of the API, and to send the users a corresponding error message when the one hundred queries are reached.

You can’t imagine how amazed and enthusiastic I was when I read your letter. You were asking for our support and I therefore felt immediately involved in your battle against the giant. To be honest, I’ve been waiting for such a message by an artist for a long time. I myself was struggling to generate an awareness of Apple’s responsibility for the disappearance of artworks, as we also have AppArt on iPhones and iPads in the ZKM collection.

Your error message alerts users to the fact that there is an interface to Google and shows the problems associated with data policies and their hegemonic tendency. This problem of extremely limited access to search-engine results affects not only you but all artists working with APIs and related museums and institutions. Google has also terminated the special offer of unlimited queries for nonprofit organizations in April 2018. The problem is, therefore, also affecting museum collections and large institutions – not just individual artists.

ZKM acquired nag_05 in 2010 on a local server and is also affected by this change of Google’s terms of use. ZKM would be able to pay Google for a less limited version of the search API (“additional cost $5 per 1000 queries, up to 10k queries a day”), but as an internationally recognized museum, ZKM rather is interested in opening the debate on such technopolitical topics. Your strategy of running a limited version of the nag seems to be a good start to draw public attention. But the ultimate goal would be to also draw the attention of Google, because, obviously, Google does not yet understand its responsibility in the disappearance of a whole generation of artworks.

Matthieu: Your letter coincided with the exhibition Open Codes and my arrival as part of the “Archivist in Residence” program at ZKM. This collaboration between ZKM and HfG (Karlsruhe University of Arts and Design) found itself in its third round in October 2017. The project was coordinated by Morgane and Margit Rosen (Head of the Department of Knowledge, Collection, Research and Archives), Felix Mittelberger (staff of the ZKM archive), and the interdisciplinary team of the ZKM as well as Siegfried Zielinski (former Rector of the HfG) and HfG students.

I dealt with the still relatively young field of conservation and archiving of digital objects and artworks. In my residency, I focused on the handling of proprietary software in media artworks and was concerned with question such as: What significance does it have for the work when the software used becomes obsolete or is no longer fully available to the public? Are the works rendered faulty or completely inoperative? And what economies of data policies play a role here, and how can this be addressed critically?

When your artwork, the nag_machine, was taken out of storage, we already knew a lot about it, thanks to the comprehensive documentation by Kay Sievers, your technician for the project. On the hardware, I worked in collaboration with Kay Sievers, on the software with Winnie Soon. First, I had a look at the physical elements of the artwork in our workshop, namely, the old wooden box that contains the technical server parts. It helped to perfect my understanding of it after reading the documentation, in which I learned, for example, that each network card has a function, so you cannot just randomly plug in the network cables. Then, I did a full back up of the original hard drive for archiving and duplicated it on a newer hard drive – as they are prone to fail quickly. After doing a quick test to check if the cloning went well, I started to implement the new code version, nag_05b.

Q: You are working as restorers/conservators at ZKM with a special expertise in media artworks. What are your professional backgrounds?

Morgane: I did a master’s degree in Digital and Media Art Conservation in the Avignon School of Art, France. After two years as assistant conservator at ZKM and a short period at the Centre Pompidou in Paris, I became the head of digital conservation at ZKM. I am also a PhD candidate at PAMAL (Preservation & Art – Media Archaeology Lab) with a project focusing on media archaeological reconstruction of media and digital artworks. In 2015, I won the Leonardo Award at The Emerging Researchers’ symposium “Media Art Histories Re-create” in Montreal for my research.

Matthieu: I have a National Diploma of Visual Arts at the Avignon School of Art (where I was also studying in the PAMAL with Morgane). Additionally, I hold a diploma in programming/network and in music (cello). My current specialization is the preservation and restoration of 3D computer-generated cinema models, especially Star Trek ships. As an archivist in residence at ZKM, my research focuses on the preservation of digital art, notably on third-party products as part of artworks (maintenance/adaptation of historical and obsolete commercial software/API for the sake of art preservation), and the archiving of artworks using 3D visualization. Currently, I am working in Morgane’s team of media and digital art conservators.

Q: Can you describe what the biggest challenges are?

Morgane: Lately, it has become paramount to improve preservation approaches for media and digital artworks. We have to develop solutions as sophisticated as the problems we are facing now – or going to face in the near future. Besides the obsolescence of data formats and hardware, the interdependency of hardware and software, the dependency on third-party software and external resources remains one of the biggest challenges in preserving digital art nowadays.

Matthieu: Moreover, the planned obsolescence of the 1990s machines is nothing compared with recent products like smartphones, creating an even higher hardware-software dependency by preventing retro-compatibility or downgrading. The question really is, what we can do in the face of such hegemony? Crowdsourcing seems to be the key for us. It can take different forms like buying an Amiga computer on eBay, asking the internet community for a cracked version of Max/MSP, or call specialized hackers into our team.

Q: How would you describe the guidelines for your work?

Morgane: ZKM promotes the conservation of its digital artworks in their historical technological environment. That implies to keep the artworks within their historical software and hardware components as long as possible. Not necessarily with the computer acquired along with the artwork, it can be the same model, or at least a computer from the same period compatible with the initial operating system.

That way we do not have to make major changes of the software environment or peripherals that help to avoid incompatibility issues or alterations of the artworks’ behavior and outputs. It could be said, we have a really strong materialist approach, and we know for a fact that this decision is putting the team in difficult situations sometimes, but the historical curiosity is motivated by our belief in the non-neutrality of technology and coding. This also gives the public a chance to see concrete forms of past media in action with their related cultural, economic, and political implications.

Matthieu: To keep old artworks alive, ZKM based its preservation strategy on the motto “Lots of Copies Keep Stuff Safe” from the Stanford University Libraries. That means we are always trying to accompany the artwork with a spare ready-to-run computer and spare hardware/peripherals if needed (mouse, camera, sensor, screen, etc.). Instead of having the backups on our servers and magnetic tapes only, we additionally implement them on spare computers in order to create multiple, identical, and functional examples of the whole hardware-software environment. First of all, since we are documenting early acquired artworks afterward, this duplication is the easiest way to gather missing information. Second, this allows us to act smoothly in case of a breakdown during an exhibition, for example. Additionally, it avoids discovering unknown hardware specificities, incompatibilities, or license key issues by actually testing the backups on their assigned equipment prior breakdown and therefore removing the time-pressure.

Q: What are the most important aspects of this work for you?

Morgane: It is important to maintain a balance between accessibility and the artist’s intention as best as we can. Unfortunately, most of the time the historical versions of the artwork are only exhibited in-house for research purposes, because of their high fragility. We need our facilities, skills, resources, spares, and tools to install and maintain the artworks in exhibition. At the same time, a systematic preparation of the works’ migration to contemporary computer systems and software is carried out. Also, we do not want to prevent other museums, which might not have the same resources, to have access to our collection, nor the public. Therefore, for loan purposes and future exhibitions, we create updated versions, as close as possible to the initial version, within a newer technological environment for easier handling, installation, and maintenance. The new version is usually created with the help of the artist, while the historical version is still in working order, and if not, it will be repaired or rebuilt from scratch with historical spares. We need to have a firsthand experience of how the artwork operates and looks like in its given historical technological context. This process also allows us to learn more about the artists’ techniques and methods. Comparing the results of the updating process with the original is our way of gathering vanishing knowledge, and with the dissemination of genuine copies of artworks we contribute to the dissemination of this knowledge.

Matthieu: In order to create an updated version of an artwork, no documentation can prove to be more efficient than the initial work itself. And maintaining the historical version gives us the chance to work on an update without time pressure. This is the main point of our strategy: to take the time to preserve an artwork and reproduce something consistent in terms of look and feel, technology, and meaning. Thus, we know we can trust the updated versions at this point because they evolved in parallel during a certain time.

Q: What has been the most difficult part in fixing or showing the nag_machine again (both hardware- and software-wise)?

Matthieu: Well, there are two parts of the story. The first one was when I started to install the software version nag_05b on the local server in 2017. Google’s new API was using a plug-in that was too recent for the server’s aging operating system. I had to search the internet for an older version and compile it myself with some modifications that tricked the API to think it was using the most recent version (as the old version was actually working with this API, but Google prefers the use of the most recent stuff …).

The second part was a year later, before the opening of the first part of ZKM’s Writing the History of the Future exhibition, when you (Cornelia) gave me the gallery update, i.e., the nag_extension to implement on the local server. Everything went well until a week before the opening, when I was doing the final checkup, the server’s motherboard died. And I did not have a replacement part! I had to improvise by quickly making a new server running on a Raspberry Pi and connected it to the screen of the nag_machine to reproduce the original artwork’s behavior and look. It was the first time, I had to do an emergency/unscheduled upgrade, and what I said earlier was confirmed. Luckily, I had a reliable documentation and already a good understanding of the artwork!

Q: Preserving the nag_machine may be more than just making it work again. What has been your thinking behind the process?

Morgane: The aim was to open a collegial debate and together reflect on challenges with the nag, to develop alternative strategies for the nag in relation to the Google restrictions, and to experiment with new conservation strategies in relation to the historicity of the nag. The different versions of the nag over time are a good indicator of the profound changes in the content, the aesthetics, and politics of the WWW, and they raise questions about the archiving of the internet; whether certain things should be encapsulated or frozen. In applying the principles of media archaeology and archives, we wanted to examine this as well. So we decided to organize a workshop and a lecture during the exhibition Open Codes: Living in Digital Worlds around this case study.

The idea behind the workshop was to provoke Google and to scratch below the surface of their image (which they are trying to pollinate with Google Arts & Culture). As we were publishing on Twitter on our ongoing hack, knowing that Google can’t afford a controversy on how they destroy art, we opened topics such as freedom of use, transparency of platforms, how Google can support artistic projects beyond their confined parameters.

Q: We could work together in the process of restoring the nag_machine, because we had just released a new version of the software and could make it available to you. Is it regular procedure that the artist/team gets involved in restoring a piece from the collection, or are you usually left alone with the task? How much are artists willing and available to work on a piece they no longer own?

Morgane: We are often working with the artists/teams. They are involved at different points of the artwork’s life. When acquiring a work from a living artist, beyond the transfer of ownership, we expect the latter to give us access to the source code and the electrical/electronic plan/scheme. We also ask the source code to be commented on in an intelligible way and in correlation with the behavior of the work (cause-effect). All software parts and their interconnections must be precisely documented.

We invite the artist to come to ZKM for the first assembly or a test assembly in the workshop so that he/she/they can explain precisely the assembly/disassembly steps but also the problems that we could possibly encounter. We also ask for a certain availability during the first exhibitions of the work as well as an assiduous review of our documentation/manual. From the time of purchase until the first exhibitions of the work, the responsibility for the proper functioning of the work and its conservation is with both the artist and ZKM. As time goes by, the artist can step into the background, as we have a better understanding of the artwork. However, it may happen that he/she/they is/are involved in the conservation of the work for the rest of her/his/their life.

Q: If you could make a wish, what would that be? How would a restoration/conservation process ideally look like, and is there anything else we could contribute from our side? Will you make your process documentation available to us/the public in an open source sense, or is the information for internal use only?

Matthieu: We could go even further and use the actual work-in-progress project called Crowdapi developed by Winnie Soon in collaboration with Gerrit Ché Boelz, the sysadmin of the nag_server, which is about crowdsourcing developer’s keys from the public instead of using the ones of ZKM. This “social-hacking solution” may help to think about power relations between corporations and users. By donating their API key to ZKM or to you, users would actively help to keep the artwork alive. Such an experiment needs the agreement of the director, but I’m sure you and your team would help us to implement it. Once exhibited, the related issue could be well explained and communicated in the curatorial concept. Generally, API changes are a challenge that affects every museum and major institution. And the nag is perfect to exemplify the issue.

Code of crowdapi prototype, Cornelia Sollfrank, Winnie Soon and Gerrit Ché Boelz, 2017

Morgane: Also, in face of such challenges, we have to think as widely as possible as a response to the centralization of the companies. When I was invited as keynote speaker at the 2018 MAPS – Media Art Preservation workshop hosted in Budapest, I talked about “folk preservation” and piracy with the nag as one of my case studies. In combination with your own research, the workshop and the lecture net.art generator – Generating Discourse, and the Open Codes online exhibition, this will be the perfect opportunity to continue spreading and generating new discourses.

Matthieu: We can make the Raspberry Pi version of the software freely available (the image copy of the SD card). As for the documentation, we made it available as a case study and published it at symposia and an article on ZKM website.

Source code download: https://github.com/siusoon/n.a.g

C: Thank you very much for your time and this insight into your work.

Workshop net.art generator – Generating Discourse @ ZKM, 2017

Workshop net.art generator – Generating Discourse @ ZKM, 2017

Winnie (left) and Matthieu (right) in front of the printed and marked code of nag, 2017

Raspberry Pi install, ZKM, DB, 2018, photo: Matthieu Vlaminck

W: It was a very nice collaboration with ZKM, and it is good to see that they invest so many resources in research and digital preservation.

C: To end with, I would like to come back to our collaboration, in particular your role within the nag project as a “code fixer.”

W: Not sure if I like this term. Sounds a bit like fixing the toilet. However, my task is not to create something new, but to maintain existing code and make it work, while maintaining the traces of the original work such as keeping all the dysfunctional code and comments. The audience should experience no difference after my intervention.

C: What exactly did you do when fixing the nag after you had made yourself familiar with Perl?

W: Technically speaking, I first needed to understand what had gone wrong with the code, and to identify which parts of the code were relevant or needed to be replaced. (This also requires an understanding of the infrastructure of the nag, and how the generated images are being stored and retrieved.)

Identifying the problem with the Google API took a while, because the original URL actually worked when you manually pasted it on a web browser. It showed the search results (e.g., https://www.google.com/search?safe=active&tbm-isch&source=hp&q=wahol+flowers) but didn’t work when the request to the API was made by a machine. To understand this required some experiments in order to narrow down the options of the Perl code problem, server problem, or other related issues.

After I found that the problem lies in the interface to the Google API, I looked into the official REST API, how it can be used and what are the limitations by studying the specifications and making some experiments. But this was not simply a technical issue because then it came to the question of the specified limitation of requests and the implied costs. I started to look into options around nonprofit or educational use of the APIs, as well as other image APIs such as Bing, and further discussed with you about the pros and cons of the different APIs.

After that I had to set up the local environment with Perl and the web server to start modifying the code, and also to integrate the experiments that I have done with the code of the nag. Since the program was written a long time ago, it took a while to find the correct version of the libraries. In addition to fixing the API, I have also added some new features to the latest version, nag_05b, such as changing the welcome messages, removing the German language interface, supporting multiple languages of keyword search, etc. Finally, I worked with Gerrit, our server admin, to test the new version on the nag server and fully implement it. I have kept the log as part of the source code of nag (in the source code file: index.cgi):

Code snippet: The log and feature updates in the source code of nag_05b

C: Would you agree that fixing is a way of preservation?

W: Exactly, fixing the code is not just about repairing, but about understanding how it works and, for me, also exploring the politics behind it. This is how the nag is related to my work as a researcher. And part of that process is also to communicate the related issues to a wider audience.

C: Which is what we do with this publication! Is there anything you want to add regarding the “fixing” process?

W: Do you remember this quote by Pall Thayer, the code artist who also contributed to the Perl section: “If I was tasked with updating something in someone else’s code, I would generally need to spend at least a day deciphering their ‘style’ of Perl.” That is very telling, because that is exactly what I have been doing: updating code that was written by somebody else, and I can confirm that it was a challenge indeed, in terms of the style, as well as understanding the programmable logic (algorithms) of the nag in general and the relations of different pages/functionalities. I guess in terms of preservation, Perl code is kind of a nightmare …

Actually, this was my first time looking into other people’s code in such detail, to map and try to make sense of the technical environment and functions of the program. The challenge was that the program didn’t work, so I didn’t really have a sense of how it was supposed to work, whether there was a database or not or how the folder was organized. And although we could not get in touch with the original programmer, Panos Galanis, I actually felt that I was collaborating with him. On the level of the source code, one can see the name of the programmer. He put his name there, which is a normal thing to do, and his company contact, etc. And I added my name as coauthor – although I never talked to him.

C: That is also interesting in terms of authorship and the case of the distributed authorship we have with the nag. So what you do is definitely more than fixing.

W: I added to the code while trying to follow Panos’s style, and I tried to make the code work based on the existing structure and logics. So my role is very different from one of the other programmers. Altogether it was a very challenging process but, at the same time, interesting, especially due to my research interest related to Critical Code Studies (CCS), a field in which Mark Marino has written extensively. Marino explains that CCS pays attention to code as textual material and its main argument is that code itself can be considered as a “cultural text worthy of analysis and rich with possibilities for interpretation.” Furthermore, code allows us to reflect “on the relationships of the code itself, the coding architecture, the functioning of the code, and specific programming choices, or expressions, with that which the code acts upon, outputs, processes, and represents.” 2 As such, this project of fixing code allows me to have a deeper understanding of studying code critically and functionally and, of course, the related politics around digital infrastructure.

C: Related to the issue of preservation is also the notion of care. Caring means worrying, being ready to take responsibility, being on the lookout for new types of relations. This attitude of care also contributes to the establishment of new forms of knowledge, knowledge that is interested not only in observation and representation but also in transformation – in forging relations with things, in being affected, and thus in changing itself and the world in a process of co-transformation. Joan C. Tronto and Berenice Fisher have defined caring as a way of maintaining, continuing, and repairing our world for a better life.3 And why shall we not include our artworks in this attitude of care?

W: And this is in full accordance with technofeminist praxis. This kind of caring implies to understand technological settings not only as objects but also as nodes of social and political interests. And it is a way to intervene in the production of knowledge, science, and technology.

1 Bernhard Serexhe, ed., Digital Art Conservation: Preservation of Digital Art; Theory and Practice (Vienna: Ambra Verlag, 2013), https://zkm.de/de/publikation/digital-art-conservation-english.

2 Mark C. Marino, Critical Code Studies (Cambridge, MA: MIT Press, 2020), p. 685

3 Bernice Fisher and Joan C. Tronto, “Toward a Feminist Theory of Care,” in Circles of Care: Work and Identity in Women’s Lives, ed. Emily K. Abel and Margaret K. Nelson (New York: State University of New York Press, 1990).

<!--

# Code fixed

-->

<head><title>Fix My Code</title>

<p class=h2>EPILOGUE</p>

W: Is the nag the most successful work in your career?

C: Over time, maybe. It is accumulating success, first with Female Extension, when the generating of the websites was just a side product; from this intervention it developed into the conceptual tool we use the nag as today. Meanwhile, it has been part of over twenty exhibitions worldwide.

W: Have you ever shown or talked about the nag in contexts other than art?

C: During the time when I was doing the research on copyright, I was invited to several events and conferences in the field of intellectual property law.

W: From my point of view, there are so many relevant aspects related to it beyond art, as you said, legal aspects but also techno-political aspects. The project has been responding to the changing network culture for more than twenty years now. Just take the programming language Perl as an example, the project’s embeddedness in free-software culture, the complexities of digital authorship, the idea of machinic creation, and, most recently, search-engine politics, just to name a few.

C: Which automatically raises the question, what the next big thing will be …

W: Perhaps the next episode or version of the nag will be about rethinking generativity, maybe related to data processing in machine learning. I do think that the current debates around machine learning are connected to one of nag’s key mottos “The net.art generator automatically produces net.art on demand” – exploring automation and agency in this regard makes complete sense.

C: But it always needs a trigger to make the next move. Let’s see what that will be! But you are right, the project traveled very well through time, and it would be nice, and I also think quite unique, if it could continue. And each new layer is adding a bit more to its success.

W: I assume you did not plan that from the beginning, right?

C: Not at all, but this is the beauty of open artworks. They can always develop further. Basically, it is a responsive work. Whenever circumstances forced me to respond, the work received an extra layer. It requires awareness, the ability to evolve, and I guess this is also where it matches your interest in liveness.

W: Certainly, but the reasons for my interest in the nag also have changed over time. Back in 2016, I wanted to understand the generative aspect for my PhD. Gradually, I became interested in the feminist perspective behind this work as well as the politics around APIs. Also its function as an educational tool is relevant. I use it a lot in my classes on Aesthetic Programming and Digital Culture. But what keeps me really busy is to think of the nag as “not just art,” in the sense as elaborated by Matthew Fuller.1 Beyond its aesthetic qualities, it is a functional tool with many fans who are actually using it and loving it.

1 Matthew Fuller, Behind the Blip: Essays on the Culture of Software (New York: Autonomedia, 2003), 62.

Biographies

Cornelia Sollfrank (PhD) is an artist, researcher, and university lecturer, who lives in Berlin (Germany). Recurring subjects in her artistic and academic work in and about digital cultures are artistic infrastructures, new forms of (political) self-organization, authorship and intellectual property, techno-feminist practice and theory. As a pioneer of internet art, Cornelia built up a reputation with two central projects: the net.art generator – a web-based art-producing “machine,” – and Female Extension – her famous hack of the first competition for internet art. Her experiments with the basic principles of aesthetic modernism implied conflicts with its institutional and legal framework and led to her academic research.

In her PhD, “Performing the Paradoxes of Intellectual Property,” Sollfrank investigated the increasingly conflicting relationship between art and copyright. This led to her current research project “Creating Commons,”based at the University of the Arts in Zurich, the outcomes of which are published in Aesthetics of the Commons (Diaphanes, 2021). Her most recent artistic work, the performance À la recherche de l’information perdue, is about gender stereotypes in the digital underground with the example of WikiLeaks. The artistic research group #purplenoise, founded by Cornelia in 2018, investigates the potential of social media for political manipulation. Her book The Beautiful Warriors: Technofeminist Praxis in the 21st Century was published in 2019 by minorcompositions/Autonomedia.

Winnie Soon (PhD) is an artist and researcher, born and raised in Hong Kong. She/they have a background in Information Systems and Computing (City University of Hong Kong), Media Cultures (School of Creative Media, City University of Hong Kong), Digital Art and Technology (University of Plymouth), and has a PhD in Software (Art) Practice (Aarhus University). Her/their research and practice intersect media/computational art, software studies, cultural studies, and code practice, specifically concerning digital censorship, data politics, real-time processing/liveness, invisible infrastructure, and the aesthetics of code.

Her/their projects have been presented and exhibited internationally at museums, art festivals, libraries, universities, and conferences, including but not limited to ZKM, RMIT Gallery, The Photographers’ Gallery, transmediale, Electronic Literature Festival, ISEA, Stuttgarter Filmwinter, WRO Media Art Biennale, Roskilde Libraries, Image Galleri, Si Shang Art Museum, PULSE Art + Technology Festival, FutureEverything festival, Ars Electronica, The Wrong – New Digital Art Biennale, and Hong Kong Microwave International Media Arts Festival, among others.

Soon has been awarded the Top-Ranked LABS Abstracts 2017 by Leonardo and a Winner of the 2018 Aarhus University Research Foundation PhD award with the thesis titled “Executing Liveness: An Examination of Code Inter-actions in Software (Art) Practice.” She/They received the Expanded Media Award for Network Culture at Stuttgarter Filmwinter — Festival for Expanded Media, WRO 2019 Media Art Biennale Award and was shortlisted for the Public Library Prize for Electronic Literature, Literature in Digital Transformation in 2019. Currently, she/they is Associate Professor in the Department of Digital Design at Aarhus University, and actively provides for and maintains two ongoing software art services: net.art generator (w/ Cornelia Sollfrank and Gerrit Ché Boelz) and Queer Motto API (w/ Helen Pritchard).

Credits and Acknowledgments

Fix My Code

Cornelia Sollfrank and Winnie Soon

Proofreading: Niamh Dunphy

Design: Janine Sack

Infographic: Camila Coutinho

Images: Unless otherwise stated, all images are courtesy of Cornelia Sollfrank.

Fonts: Source Code Pro, Source Sans Pro (SIL licence)

ISBN 978-3-947295-49-4

Published by EECLECTIC, Berlin 2021

www.eeclectic.de

© 2021 Creative Commons: Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

Winnie, Coco, and Janine at our first editorial meeting in August 2019 in Celle.

Coco and Gerrit testing their new feelers.

Special thanks to Morgane Stricot and Matthieu Vlaminck from ZKM, to Dušan Barok for feedback, and a very special thanks to Gerrit Ché Boelz, our favorite system administrator.

Published with the support of Aarhus University Research Foundation.

anonymous-warhol_flowers@Jan_19_21.53.56_2021

anonymous-warhol_flowers@Jan_19_21.54.33_2021

anonymous-warhol_flowers@Jan_19_21.54.22_2021

anonymous-warhol_flowers@Jan_19_21.54.45_2021

anonymous-warhol_flowers@Jan_19_21.55.24_2021

anonymous-warhol_flowers@Jan_19_21.55.35_2021

anonymous-warhol_flowers@Jan_19_21.55.47_2021

anonymous-warhol_flowers@Jan_19_21.56.07_2021

anonymous-warhol_flowers@Jan_19_21.57.34_2021

anonymous-warhol_flowers@Jan_19_21.57.42_2021

anonymous-warhol_flowers@Jan_19_21.57.55_2021

anonymous-warhol_flowers@Jan_19_21.58.14_2021

anonymous-warhol_flowers@Jan_19_21.58.40_2021

EECLECTIC is a publishing house for digital publications in the field of visual culture.

We create and publish publications that focus on art and architecture, film and photography, net-art and drawing, city and public, politics and society, gender and feminism, Berlin and activism, commons and culture, artists’ books, and visual narrative.

Our ebooks are available in various formats (epubs, pdfs, ibooks, and enhanced epubs) that serve the demands of content and material.

EECLECTIC

DIGITAL PUBLISHING FOR VISUAL CULTURE

contact@eeclectic.de

eeclectic.de

Chinese Weave

Regine Steenbock

A visual essay on Chinese fashion and textile industries and the people involved.

240 pages, ibooks format (readable on all iOS and OS devices)

365 photographs, and 25 min. video

English, German

ISBN 978-3-947295-44-9

EUR 26.99

Buy here

My Name Is Language

Nicoline van Harskamp

In the fictive worlds represented in this book, society is not centralized, not oversized, and self-naming is brought forward as a form of self-empowerment and resistance.

Part of the series Scriptings: Political Scenarios, edited by Achim Lengerer

Approx. 200 pages, epub

68 images (photographs and video stills)

10 audio clips

1 animated gif

Arabic, Ewé, French, Hindi, German, Irish, Dutch, Portuguese, Urhobo, Croatian, English and Englishes

ISBN 978-3-947295-61-6

EUR 6.99

Buy here

Man schenkt keinen Hund

Christine Lemke, Achim Lengerer / Scriptings (Eds.)

The publication for the exhibition project “Man schenkt keinen Hund” is a collaboration with artists, authors and other interested parties, art mediators, lecturers, and course participants from “integration courses” with the prevailing integration imperative.

The e-book is a decoupling of the printed reader and contains 15 so-called (NO) image descriptions by authors and artists including Eran Schaerf, Elske Rosenfeld, and Zandile Darko, as well as interviews with Aretha Schwarzbach-Apithy and Bahati Glass.

Approx. 120 pages, epub

German

ISBN 978-3-947295-30-2

EUR 3.99

Buy here

Dit and Dah

Zingsho Vashum

These pages filled with dots and dashes will be a starting point for you to engage in a nonverbal world of communication called Morse code.

23 pages, fixed epub (best readable on all iOS and OS devices)

10 illustrations, more then 50 sounds, 3 visual-learning charts

English

ISBN 978-3-947295-31-9

EUR 3.99

Buy here

Between You and Me

Anna Selander

Portraiture as a relational exercise: while family and friends draw her portrait, Anna Selander photographs their gaze.

30 pages, fixed epub (best readable on all iOS and OS devices)

26 drawings, 26 photographs

English

ISBN 978-3-947295-25-8

EUR 4.99

Buy here