"We need not destroy the past; it is gone. At any moment it might reappear and seem to be and be the present. Would it be a repetition? Only if we thought we owned it, but since we don't, it is free and so are we."
John Cage, Lecture on Nothing
The open source community has developed a number of tools and philosophies to assist in distributed software development. The Still Water Lab at the University of Maine believes that these tools and philosophies can be adapted to facilitate other forms of distributed creative endeavours. It has developed two tools that reinterpret the ideas used in open source software through the lenses of artistic creation and preservation: The Pool and the Variable Media Questionnaire. This article discusses how several of the ideas used in software development have influenced Still Water's approach to making tools that support artistic production.
This article was originally published in the October 2009 issue of Open Source Business Resource.
In December of 2000, game publisher Activision released Call to Power II, the sequel to its mildly successful title Civilization: Call to Power from a year earlier. Call to Power II was not as successful as its predecessor, in large part because the community that gathered around the first game, and which eagerly awaited the second, discovered a release that was full of bugs and missing several key features. Even more so than for general software, this is not an uncommon experience for computer gamers. The idea that a game can be buggy as long as it is patched after the customer pays for it has been an accepted, if resented, business model ever since Internet adoption became widespread enough to use it for patch distribution.
With Call to Power II, though, something went wrong. In a January 2001 statement sent to websites that hosted the game's community, Activision stated that the programmers and testers who were involved would be moving on to other projects and that no further patches to the title would be forthcoming. The community was predictably upset. Instead of giving up on the game, users decided that if Activision wasn't going to fix the bugs, they would. They wanted to save the game by getting Activision to open the source so it could be kept alive beyond the point where Activision lost interest. With some help from members of the development team that were active on fan forums, they were eventually able to convince Activision to release Call to Power II's source code in October of 2003.
Activision released the source code, but with every comment stripped out. Any programmer knows that trying to interpret another programmer's uncommented code is far more difficult than dealing with code that is properly documented. The problem gets worse as the scale of the program increases, and Activision had dumped nearly one million lines of code with no documentation. Upon receiving the code, the community quickly realized that they could do nothing with it as it was. Their first task was reverse-engineering the code to re-comment the entire release package. The Call to Power II community project eventually re-commented the code and produced over 800 bug fixes, new features, and updates. They have kept the game running for almost ten years, far longer than it would have lasted had Activision just patched it in 2001.
The people who worked on the Call to Power II open source project had it relatively easy compared to those who try to document or reconstruct projects in the arts. Code has a fixed interpretation because it is an entirely functional mode of communication. Given enough time, any programmer who knows the language is capable of deducing the purpose of a chunk of code. In the arts, it is not always obvious which aspects of a work are intentional constructions and which are coincidental flourishes that the artist does not care about. Interpretation also assumes that the interpreter's philosophical background places any degree of importance on what the artist thinks.
Since interpreting art is not nearly as straightforward as interpreting code, retroactively 'commenting' an artwork is problematic at best. What is needed in the arts are systems that remove the need to reverse-engineer an artwork by preserving not just the artifacts that go into its construction, but also the ideas, methods, and thought processes of the people involved in making the artwork. Effectively open sourcing artwork requires a higher level of documentation than open sourcing code.
The Still Water Lab at the University of Maine's New Media department has approached the problem of keeping art alive from two directions by producing two separate tools: one based on creation and one on preservation. The Pool applies an open source mentality to the production of art, code, and text. Originally conceived of by Joline Blais, Jon Ippolito, and Owen Smith, with ongoing development by Ippolito and John Bell, The Pool provides project-tracking infrastructure, comment and review systems, and à la carte licensing options to creative producers. The Variable Media Questionnaire, made by the Variable Media Network partnership, looks at the problem from the opposite direction by recognizing that preservation of many types of art is not as simple as putting it in a box until you need it again. Saving ephemeral, performance, or technology-based pieces requires understanding what is important about a piece, how to best capture its essential qualities, and where to draw the line when it comes to trying to save a work by transforming it.
The Pool is a system that reinterprets the open source development model and applies it to several types of creative output. Still Water's team believes that one of the most important insights of open source is its focus on welcoming contributions to a project from anybody who is capable of making them and creating community relationships based on those contributions. In the case of software, the overarching goal of a project is often set when it begins. Most communication within that community focuses on specific design questions or implementation issues. By expanding its focus beyond software, The Pool also expands the scope of the information that needs to be captured in order to document and discuss the design process.
Figure 1 provides a screenshot of the web interface to The Pool. The main interface is a graph of project titles that defaults to mapping what projects have received the most and best overall reviews, though the titles can be remapped to represent other metadata. Clicking on a title opens tabbed panels with information on the project and additional links to external files, contributor panels, and other related projects in The Pool. Different pools focus on different types of artifacts, including special "reference" pools that allow community members to use The Pool's analysis tools on projects that were not born in The Pool itself.
Figure 1: The Art Pool
The Pool facilitates development by adding structure to the creative process, breaking down projects into three stages:
Intent: this phase is literally just an intention to make something. Somebody has an idea for a useful code widget or interesting art piece and drops a paragraph about it into The Pool to see what the community thinks. Intents can be pursued by attaching approaches to them.
Approach: may be anything from a conceptual parti to a working mockup of the project. It is meant to be the beginning of a focused realization of the idea proposed in the intent stage.
Release: the approach can then be followed by a release of the project itself.
A key idea in The Pool is that anybody on the system can add new stages to what others have created, subject to the licensing terms the original creator has chosen. Like code with comments, a project that has had its complete development process documented in The Pool can be revived by anyone, at any time, because the ideas that went into its creation have been recorded.
The Pool does not assume that design is simply a linear process that begins with intent and ends with a release. Another goal of documenting each stage of development as it is occurring is to get feedback from the community in real time. Project stages are rated on a variety of axes that are specific to each stage. For instance, a release of software art can be rated conceptually, perceptually, or technically. A trust metric built into the rating system ensures that those who have received the best reviews on any given axis also have their reviews of other projects weighted most heavily.
As in any open system, intellectual property rights must be understood and respected. The Pool acknowledges that art is subject to a wide variety of attitudes toward sharing of ideas and technologies. As seen in Figure 2, creators who put artifacts in The Pool can choose to apply a number of common licensing terms instead of, or in addition to, selecting from a list of complete licenses The possible terms include one that is unique to The Pool: the registration option states that any reuse of work found in The Pool must be entered as a new project in The Pool. Combined with a set of tools that track the predecessors and descendants of Pool projects, this license term allows creators to easily see how and where the work they share gets reused. This is a different type of viral license than the GPL. It is probably closer to the meaning of viral used in viral marketing because it is a license that intends to grow and protect a specific community rather than a general philosophy.
Figure 2: Selecting a Release License in The Pool
All of The Pool's mechanics are designed to replicate the best features of open source software communities. What is interesting is the effect that applying the open source model has on artistic creation. In a 2006 study of The Pool, Margaretha Haughwout found that:
"As a project develops, users lessen the controls of attribution and non”"commercial licenses, and increase controls on no”"combinations and no”"transformations, while share”"alike remains just about the same. The reasons for this are not certain. It could be that 1) projects that have less controls have more success; 2) an attitude shift occurs when a project nears or is in fact completed; or, 3) as users work more with The Pool they become more open”"minded. The last possibility could prove to be quite compelling, given that conventional wisdom would suggest that authors should become more controlling of their work as they invest more time and effort in it".
These results are curious because they do not reflect the attitudes of either traditional art or open source software communities. Traditional art communities, heavily focused on attribution and reputation, would seem unlikely to loosen restrictions on attribution as projects reach completion and release. Open source communities are not likely to add additional restrictions on reuse and transformation as their codebase becomes more mature and more useful to other programmers. The merger of the two seems to have created an environment where attitudes toward intellectual property are distinctly different than either of its parents.
The Pool is designed to collect creation data throughout the development of a project. It is not useful in cases like Activision's code dump where an artifact arrives already finished but with no documentation. For artwork that is not created within the structured environment of The Pool, Still Water has produced the Variable Media Questionnaire (VMQ), seen in Figure 3, to assist in retroactively documenting as much as possible. The VMQ takes the same approach used by the members of the Call to Power II open source project and attempts to ascertain how the components of an artwork function and interact to create more than the sum of its parts. While The Pool focuses on creation, the VMQ is meant to aid in the preservation of existing works of art. It does so by applying one of the core tenets of open source: given enough eyeballs, all bugs are shallow.
Figure 3: The Variable Media Questionnaire
Design concepts borrowed from object-oriented programming heavily influenced the newest version of the VMQ. It introduced a shift from the previous two versions by viewing the fundamental unit of an artwork as not the artwork itself, but the pieces that go into its construction. Like a program's classes, these components have sets of characteristics that describe the function of the component within the artwork and interfaces that allow them to interact with one another in prescribed ways. Like classes, they are self-contained units that fulfill functional roles within an artwork that can be upgraded or replaced as necessary, independent of other aspects of the work, so long as they retain the same interfaces and functionality as the original components. As an example, the VMQ would recognize that a piece of video art requires some sort of media display. Unlike standard cataloging tools, it would not specify that the display be a Sony 42" plasma screen with matte black finish. The VMQ asks what should happen when the original plasma screen breaks and how it should be replaced. Figure 4 shows a sample of how an artwork can be broken down using generic class patterns. It also demonstrates the flexibility that is inherent to many preservation strategies in the VMQ: in this interview the user has chosen two answers to the same question and indicated that one is preferable, but the other is still acceptable if necessary.
Figure 4: VMQ Interview Panel
One problem with preserving artwork is that the art world places an extraordinary amount of value on original objects. Treating individual parts of an artwork as replaceable is anathema to a community that prizes unique artifacts. Despite several art movements from the last century that have attempted to devalue the prized art object, many museums and galleries remain fully committed to maintaining artifacts as one of the central reasons for their existence. Even for these institutions, the pragmatic argument that all media will eventually fail and preservation is a constant act of renewal is a persuasive one.
From a conservator's point of view, pragmatism becomes a balancing act between preservation and interpretation. Carol Stringari, Chief Conservator at the Solomon R. Guggenheim Museum, described the tradeoffs while discussing a previous version of the VMQ:
"When an artwork is restored we attempt to reconcile the change with what we know about the meaning of the work. Defining acceptable loss when we are dealing with highly intellectualized works and sophisticated technological parameters is key to safeguarding these cultural artifacts. As we move farther away from their initial concept, we may have fewer tools to reconstruct the intention. By doing this in an open forum and across disciplines, with the artist as an active participant, we can minimize the chances that we will significantly alter or misinterpret an artist's intention".
The VMQ is intended to help manage the balancing act by providing as much information as possible about the original work, including its prior showings, key concepts, and likely failure points. When a part fails, the available input from an entire community of people who are connected with the work and the complexity inherent in dealing with cultural artifacts, makes the bug more shallow.
Open source artwork is a distinctly different prospect than open source software, but many of the characteristics of a strong software project can be applied to art. Still Water has focused on trying to replicate the open source community's willingness to share their work and ideas. As important are the technologies that have been developed to facilitate documenting software development so that other programmers can easily understand the code. If the art community documents their work in a structured manner, and with the same eye toward future integration with the work of others, it will be a boon to those trying to preserve and build upon the cultural artifacts created today.
Recommended Resources