CCBA – art restoration meets source code
What is CCBA?
CCBA stands for Conserving Computer-Based Art, an effort between the Guggenheim Museum and NYU that, since 2014, is dedicated to analyze, document, and preserve computer-based artworks from the Guggenheim collection.
CCBA’s goal is to preserve software-and-computer-based art, which has the following characteristics:
Software is used as artistic medium of expression, where artist code, or code commissioned by the artist, is at the core of the artwork, as opposed to just computers controlling lights/video playback.
Types of software-based art include:
Software-driven robotics (drawing machines)
Generated/randomized image/sound sequences with web content
Interactive works (artist-created video games across 8 projections)
3D animations with open-ended durations
Web-native works
NFTs
What’s cool about this org?
As software permeates and mediates more aspects of our lives and culture, we stand to benefit more and more from considering software from many different perspectives.
Software as artistic medium of expression is one of those perspectives. By preserving software art, we enable software artists to extend the lifespan of their creation journeys.
CCBA aims to surface the conservation challenges and urgency of assessing risks involved in a museum’s collections of software art. It turns out that software art needs its own set of conservation practices, its own body of work and community of practitioners.
By doing so, CCBA is implicitly saying that they value – or strive to value – software art vis a vis with all other museum art – weird web-based artworks from the early 90’s and two-year-old NFT’s sharing walls with Rembrandt, Pablo Picasso, Frida Kahlo and Georgia O'Keeffe.
And how cool is that? It’s nerdy, high-brow and niche, sure, but it’s a remarkable endeavor with all kinds of technical difficulties, curiosities and implications for art, artists and the wider public that wishes to admire software art on the same walls as a Flemish paintings of the 15th Century.
Wouldn’t it be a terrible loss for the world for art to disappear because a hard drive wasn’t backed up? Or an artist-provided computer failing to boot? Or a browser-based artwork dissolving into oblivion because it is no longer compatible with modern browsers?
It would be, and it doesn’t have to be this way! CCBA brings awareness to these questions, and the challenges in addressing the issues they surface.
What are some of the challenges? Well, at the root of it all is the fast-changing nature of technology, which means that software artworks age rapidly – 5-10 year old acquisitions are already significantly aged from the perspective of a museum curator.
How absurdly wonderful to consider that the shelf life of software art is shorter than that of traditional art; that a fragile Rembrandt painting stands a better chance of surviving another 100 years than a Java-based software artwork making it to 10 years old.


Software conservation as a public good
Imagine stepping into one such museum with “traditional” museum art as well as software artworks. In this imaginary museum, all of these artworks are valuable, and all of them are worthy of our best efforts to preserve them.
Now, consider what goes into preserving a Rembrandt portrait. Inhabit that process, from the ensouling of the dead master to the choice of tools, substances and materials, to the painstaking labor of cleaning, fixing, painting. Then consider the ethical implications of altering an artwork, and even the If you want help with imaging this, check out Baumgartner Restoration’s YouTube channel.
Only then, once you’ve done all that conjuring, consider the process of restoring software art. If you’re not a programmer yourself, that’s OK: think about having to hire a one for the job of preserving an artwork! What a wonderful proposition for a programmer who, more likely than not, is engaged in gigs where she’s pressured into shipping code to production as fast as possible, trapped in endless meetings with people trying to decide what she should work on, or engaging in archeological work to fix a bug in a 20 year old codebase.
If you want help making this image more vivid in your mind’s eye, checkout this ambitious project undertaken by CCBA to restore Shu Lea Cheang’s “Brandon,” an early web-based artwork from 1998 (thanks, Chris!).
Or you can also learn more about the restoration efforts undertaken to keep net.flag alive. net.flag is a a piece by Matt Napier, commissioned by the Guggenheim, that allows visitors to design their own “flag for the internet” by remixing and reconfiguring the shapes, colors, and insignia of existing national fags from around the world.
Here are some excerpts from the report:
The students began their research by reading through the source code and documenting it in the form of narrative reports and charts, and in some cases, by annotating a copy of the source code made for this purpose. Then they participated in an artist interview with Napier to discuss the future of the piece. Next, the students created a specification for the migration of the obsolete Java code to JavaScript so that the piece could function within contemporary web browsers.
Conservation of software-based artwork requires managing the way the artwork changes over time. Much in the world and on the internet has changed since 2002: new countries such as Montenegro, South Sudan, and Timor-Leste have been recognized, and international standards for working with text (such as Unicode) have been established. Te restoration now supports non-Latin character sets, including Arabic, Chinese, Hebrew, Korean, and many others.
I can now picture myself, in my fictional role as curator of a museum’s collection of software artworks, working alongside programmer/restorers at CCBA pouring over 60,000 lines of hand-written, web-based code that’s reliant on a technology that is no longer supported by major browsers. I think of our conversations about the source code, the text that powers this piece of art, and our exchange on the nature of changing technological landscapes.
I think of what I can learn from them during our weekly check-ins, what takeaways I might bring to programmer/artists who are engaged in building ambitious, expansive or simply weird and novel software art.
Have you considered how this piece might be impacted by technological change? Are there ways in which your software art practice can benefit from the fast-changing nature of technology? Do you choose new tools, or stick to old, reliable ones that are becoming more obscure by the day? How do you think of the significance of underlying components of your artwork, like the source code or the computer hardware it relies on?
When I leave the room, they, the programmer–restorers, must – must! – talk about the unknowable number of different ways in which you could build this web-based artwork. Some valid and justifiable, others better or worse, all of them with their own sets of trade-offs, which they can’t agree on, and they never will.
Think of the software patterns they discuss; patterns for the sake of preserving artwork that consider its context, its longevity and continuation against the backdrop – the reality– of technological advancements and what we call progress.
Of how they might approach the process of building or re-building this artwork outside of the context of in-house, corporate software systems, or the next startup claiming their app will solve an important-enough problem for millions of people. How different it is to code/restore than to code/ship, and how similar it is to fix bugs in source code, no matter what the code is for!
Oh the lessons! The humility for the programmer/restorers of the future that know that the source code runs and produces an artwork, and that the opinions they might have which nonetheless must be contextualize to this source code’s time and its purpose.
They also discuss the tools they might code for themselves, to help them analyze source code from the perspective of an artist. Also, they have discussions around ethics, of what constitutes a refactor vs. what modifies the artwork ever so slightly, for the sake of continuation.
And, surely, they discuss AI. Philosophical discussion, but also practical ones like how programmer/artists using AI might be creating insurmountable walls of tech debt for the programmer/restorers. Job security…in hell?
What a world we live in, where our most futuristic and capable technologies can be pointed at the past and the world around us, to uncover more weirdness, intricacy, beauty and complexity in Nature, Art and Daily Life.
Conservation is innovation
Conservation is its own branch on the tree of innovation and experimentation. We typically hold beliefs around conservation that are too reactionary and narrow-minded.
In a world where we are being forced to consider more “invasive” geo-engineering projects at an unprecedented scale, what we choose to “conserve” is critical. Which means that highlighting the processes and methods by which we decided what to conserve, as well as how we go about conservation efforts, can yield in a whole lot of new understandings.
Learn More
Check out the Guggenheim’s Conservation page: https://www.guggenheim.org/conservation/

