Projects 2003

Read-me 2.3: Hello, World (about software art with love)

Hello, World (about software art with love)

Olga Goriunova

(First published in Nifca Info 1 / 03)

Software art traces back to 90-s (net.art), 80-s (interactive art), 70-s (media art), 60-s (concept art) and 50-s (computer art) . Projects labeled as ‘software art’ (by curators and critics, not artists, which served a fruitful standing point for criticism) appeared in late 90-s and became widely discussed around the same time and later, when new ‘Software Art’ category was introduced by Transmediale that got a new director, x-member of Mikro group Andreas Broeckmann trying to change the event’s scale, audience and aims. In 2002 the first software art festival Read_me was held in Moscow, and the scene exploded: numerous software art exhibitions were held around the first world: art.bit in Tokyo, Generator (Liverpool Biennale) in GB, CODeDOC (Whitney Museum) in N-Y, and others.

The same year, working as Read_me 1.2 jury member, Florian Cramer coined the software art definition:
“… software art could be generally defined as an art:
- of which the material is formal instruction code, and/or
- which addresses cultural concepts of software…”
The most trouble software art gets come from the comparison with its closest predecessor - net.art that is often made, and not in favour of software art.

If net.art was a step in the tradition of dematerialisation of an art object, resistant to exhibitions in a traditional gallery, production in numbers, and selling, software art is materialistic: you need to download programs, install them on your hard drive, and, upon using, decide whether to delete them or store them. This last action reflects an important decision, because, for example, you can delete a momentarily free program that might become payable when you’d like to use it again , or it may disappear from the Internet altogether. In this respect one can talk about new objects and production in digital environment that does not seem anymore that fluid, flexible and open as it was celebrated in mid 90-s.

Software art projects sometimes aim at being sold (as commercial applications), and due to the way personal computers were developed (turned into black boxes, making inner machine processes inaccessible, and, thus, mystifying them) , often look good when they are exhibited. For example, displaying code that is usually hidden does not make much sense for broader public, but ‘immerses’ the ‘illiterate’ audience into the ‘magic’ of a computer inside. (There are also projects producing some ‘nice’ interface effects that look ‘nice’ as installations or screen projections. This way of presentation links software art to a viewers’ previous art-consuming experience).

Moreover, often when people with programmers’ backgrounds think about their work as ‘software art’, they would suggest it to the art system, as it is the only way they can think of through which their work can be contextualised as art.

Concerning the author and the way he/she creates, it is also significantly different from net.art: if net artists often presented themselves as filters, manipulators of information flows, refusing to produce something new, but obfuscating and playing around with existing patterns, the software art author is often regarded as a highly talented individual different from others and capable of producing a precious and unique product. This image originates from traditional art patterns reinforced by programming traditions linked to it by seminal and influential works like, for instance, Donald Knuth’s “The Art of Computer Programming” and others.
The above-described patterns and attitudes are explicable through software art interlocks with programmers’ cultures. Software art is one of the rare activities closely connected to the living cultures, the ones of programmers, which developed the instrumentarium and aesthetics software art is based on. As it is mentioned in the “about” text of the Runme.org software art repository, software art gets its lifeblood and techniques from the living software culture with all its merits and demerits.

Lastly, software art as such (in contrast to programmers’ cultures) does not have such a strong community component net.art used to have, and one of the reasons for that would be quite prosaic: net.art benefited from the first internet-enabled communication euphoria (+ east meets west utopia), and now people’s everyday lives are existing within information-noise abuse, resulting in the banal incapability of a lot of us to reply to emails in time.

However, as this article is aimed at presenting software art as interesting and attractive phenomena, it is probably time to turn from criticising to praising.

There is something very attractive in software art that makes it different from other art practices and valuable.
Software art shows that algorithms and codes that are behind systems we use every day are not neutral. By deconstructing the code, creating alternative algorithms, showing the absurdity of habitual environments and tools, software art changes the way we see, work and perceive digital environments and, thus, contributes to the liberation of our thought.

Amy Alexander describes her critical interest in software art in a Runme.org experts’ interview: “The algorithm that generates the output is an important and subjective thing, and in commercial software, it often hides behind the veil of innocent, technological neutrality. An obvious example is Google's PageRank algorithm, which determines which sites appear towards the top of Google's results, and which don't appear at all. The algorithm is very biased toward big sites, especially if they own lots of other big sites.

But in their description at http://google.com/technology, Google explains that they rely on "the uniquely democratic nature of the web" and that "Google's complex, automated methods make human tampering with our results extremely difficult." Didn't humans write the algorithm? That is a very direct example. Software artists approach the subjectivity of algorithms in different ways; some are more formal; many are more subtle. But because software art opens itself up to examination of its subjectivity, and the fact that interface is driven by human-generated algorithms, it can help us think about the broader software context.”

Software is a social construction that reveals itself not only on the level of code and algorithms (which is very important as for a long time it was disregarded), but also on the level of concepts that are accessible for larger audience. Thus, software art, being based on code and algorithm, is not only about code and algorithm and due to the different levels of literacy required to read code and interpret the output, software art can be both exclusive and inclusive.

Another interesting aspect of software art is its non-rational character. In the article I wrote together with Alexei Shulgin for the Read_me 1.2 catalogue it is noted: “…At the basis of each piece of software there are definite algorithms, but if conventional programs are instruments serving purely pragmatic purposes, the result of the work of artistic programs often finds itself outside of the pragmatic and the rational.”
Here software art follows the tradition of art as a non-working machine, the logic of software art fights against the technological logic, leads towards another direction, breaks through technological embodiment, and deconstructs digital environments.

Pit Schultz pointed out the folkloristic aspect of software art: “Software culture is the living culture of programmers and users, as active participants in a world of or mediated by software. In its heart it circumscribes the field of intensive immaterial production, if on the level of coding, use, speculation or critical reflection and at the periphery every aspect of human life which is somehow driven or controlled by software. Software art is reflecting the realities and potentials of this culture.” Runme.org software art repository suggests ‘digital folk and artisanship’ as a category .

Folkloristic aspects of software art, programmers’ cultures, and software cultures are one of the most interesting outcomes of the digital turnover and they are yet awaiting for their future researchers.
Software art can be approached from many different perspectives: as code art, as critical and activist practice, as research into digital aesthetics, as semi-practical tool-creating activity, and many others. It was widely discussed whether software art can be analysed as an art movement in its own right or not. I would refer to the ‘perspective view’ on software art that suggests that software art can be regarded as threshold, a focus, a view directory that is used to highlight projects and qualities not visible or significant otherwise .
Software art is one of the most diverse and dispersed art activities nowadays. It is both exclusive and inclusive; it is for both specialists and for everyone. It is both about code, algorithm and about surface, about beauty and about dys/functionality, about life and about itself.