Open Source Artist

The Open Source development model has grown dramatically in the last decade, fostered by the success of well-known projects such as Linux and Firefox. Eric Raymond used the term Bazaar style in his 1997 essay The Cathedral and the Bazaar to describe an development process where not only the source code is publicly available, but the process itself is open to the scrutiny of other developers and even end users. The two basic premises of the bazaar model: “release early, release often”, and “given enough eyeballs, all bugs are shallow”, are essential to the idea of continuous public testing, scrutiny, and experimentation.

In the relation to my own artistic project, I find open source development as methodologically and ideologically consistent with a way of work based on community collaboration and knowledge sharing.  It also resonates with the some of the concepts behind the DIY (do it yourself) movement.  There are numerous artistic tools and works which are released as open source, among which we can mention Pure Data by Miller Puckette, openFrameworks by Zachary Lieberman and Theodore Watson, and Processing by Ben Fry and Casey Reas. For more references, please check artsoftware.org and runme.org.

Open source development doesn’t necessarily equate with the bazaar model, although many open source projects adopted the bazaar style after the influential Raymond’s publication and Linux’s success. In the context of art software, it can be argued that for most projects this model wouldn’t be productive, and even feasible, since the bazaar assumes a large number of users that can contribute to the development process. Most of software art is very specific in its purpose and audience. In the case of a piece that can be also regarded as a tool with a more general user base, bazaar development techniques could be potentially useful.

There are two dificulties in the digital arts that can solved by relying on open source: limited programming practices, and prevalence of outdated software paradigms.

The first issue is mentioned by Alex Mclean in an interview by Olga Goriunova and Alexei Shulgin from runme.org:

“…making code is empowering, but generally taught very badly. The act of programming is portrayed as systematic and uncreative. This may be appropriate for working on quality assured credit card transaction systems, but why apply it to programming as a whole? Software art might give us a place to look at the creation and use of software outside of formal business constraints, and the stereotypes thereby fostered.”

With regards to the second problem, René Beekman writes in the context of video editing tools:

“Most computer software currently in use by visual artists employ interface metaphors based on analog,real world predecessors. In Photoshop, for example, the screen area where one paints is still called a canvas and painting itself is still done with brushes and pencils that replicate real world brush and pencil prints. For years there has been a war among different software companies for who could write the best plugin for charcoal with the sole purpose of replacing real world charcoal. For video software the situation is not much different, since video software still deals with strips of film stored in bins while cuts are made by virtual scissors. The implications of Marshall McLuhan’s statement, “First we shape our tools, thereafter they shape us”, seems to have become all too clear. Thus, a development like the one in electronic music over the last few decades where electronics have sparked new instruments, new forms of music and new modes of interaction between performer, instrument and audience, which could not have existed otherwise, still has to take place in digital video.”

Advertisements

About this entry