Acquisition workflow (Software-based artworks)

Pre-acquisition assessment (be prepared to make hard choices)

At ZKM we have an internal policy for acquiring works of a technological nature. Before acquisition, the restorers and technicians are consulted to evaluate the feasibility of the long-term conservation of the work but also of its maintenance in exhibition, in dialogue with the curatorial team.

Step 1: contact the artist to gather information

As you will see throughout the entire acquisition process, the artist will be your primary contact person. If the artist is not the one who programmed the software of the software-based artwork, then the second primary contact person will be the programmer. If the artist is dead, the heirs (who feel concerned) are a great help in some cases, as well as assistants or people who have been in contact with the work in question (curators, gallery owner or friends).

You can find below a text by Rafael Lozano-Hemmer called “Best practices for conservation of media art from an artist’s perspective”. You can send this text to the artists during the pre-acquisition process so he or she can gather all the necessary information that the conservation and curatorial team would need to make a decision about the acquisition. I find it very useful.

https://github.com/antimodular/Best-practices-for-conservation-of-media-art

As advices Raphael Lozano-Hemmer gives to artists in this paper, you’ll find for example:

Make a video of the project, ideally with you speaking over it and explaining proper functioning.
Install the project in a variety of computers, operating systems and/or devices and test for any software or hardware dependencies.
Prepare one or several flash drives with all the source code for your project.
Write a manual.
Set your computers to perform uninterrupted for a long time.

So, the first step is to contact the artist and/or the programmer to ask him/her/them if he/she/they can send some basic information about the software-based artwork (which hardware, software, how does it work, what will be provided, what you should provide etc…) and access if he/she has already or must prepare a manual, a video, make some tests etc, like Lozano Hemmer advices. It’s a good first step because you need to see these documents first before making any assessment. Sometimes, the artist will tell you that he/she will prepare them after the acquisition, this is where you say NO. I know that this is non-paid work for the artist but it is also a lot of work for the institution to make a pre-acquisition assessment. And if the pre-acquisition assessment is not made properly, the amount of work to maintain the artwork in the future would be significantly higher. Both sides must work together to make a good acquisition.

Step 2: make a pragmatic evaluation of the artwork AND your institution's commitment

Then, after contacting the artist and asking him or her all the necessary questions and documents, the restorers should develop a preservation concept for this artwork. The question you need to ask yourself here is:

Is it doable to show this artwork in the next 3 to 10 years in my institution in terms of obsolescence, manpower, costs, knowledge etc.)?

Here is it a very pragmatic evaluation of the artwork but first and foremost of your institution’s commitment. Before acquiring this type of artworks you must be prepared to take care of this work over a long time and give yourself the financial means and manpower to proactively maintain the survival of the work.

Key issues include:

access to source code: Does the artist have the sources? Which language? Does someone still have the knowledge, in your institution, elsewhere?
use of open source or commercial software: Has the software a license? Can you make an agreement with the software company for support and updates? How much the license cost?
availability of hardware: Is the material rare? Can you find spare easily? Is it easily repairable? Are there any specific devices used in the artwork? Hand-made or custom-made? does the artist have access to the schematics?
in-house knowledge/skills available to setup and maintain the work on display: Do you have the skilled people in your institution or do you have to hire these skilled people at each setup?
hardware/software interdependencies: Does the software compatible with other or newer computer, output devices?
dependency of external resources: is there any dependency to external resources (websites, data stores on external servers, updates and support for external software etc.) or is everything running locally on the computer? Can I store these data in my institution instead? How long can these external resources be available? This is very important. If some part of the software operation is located somewhere else, then you cannot control the availability of this resource.

From there, the conservator writes a recommendation to the curatorial team. The curatorial team should take in account the conservator’s point of view but not be too much disturbed by it. This is a collective decision-making: the decision should be based on a balance between conservation and art historical significance.

So the question is kind of: Is it worth investing time, people and money in the preservation of this work?

Tips for pre-acquisition:

Don’t forget that most of the artists do not make their own software. Always ask the contact of the programmer, it is paramount.
Ask the artist to send documentation about the artwork including the software installation and operation. Like this, you can assess if there is already a documentation and how complete it is.
Ask about external resources: the best is to have everything locally in the museum/institution and be dependent on nobody else.
Also, ask the artist if he|she has experience of how their software-based artwork behave during long time exhibition periods. Because often artworks are shown only one or two days during festivals and the artist doesn’t know if it will last during longer period of time in exhibition.
If the artist is dead or not available (if you are buying through a gallery for example and the artist is not interested in helping), the procedure remains the same. If we don't have enough elements to set up the work and maintain it, or if we don't have access to the source code or spare components, it will be very difficult to give a positive recommendation to acquire this artwork in your collection.
The best pre-acquisition evaluation is to exhibit the artwork in your museum prior acquisition during an exhibition for example, that way you can evaluate how good it is coping during exhibition (how many restart of the computer, maintenance work, failures, repairs, costs). If the artwork is not already exhibited in your museum prior acquisition, I would suggest to make a test setup at that point in your workshop or in the artist’s workshop if it is possible. If you are not sure that you have the capacity to exhibit, maintain or preserve the artwork in your institution, if you are not sure to understand everything, this might help.

Acquisition process (be prepared to be unprepared)

Once the contract is signed with the artist(s), you are going to prepare yourself to be unprepared. It means that you are going to gather as much information as possible, what you think is important but also what you think may be less important. You never know what you are going to need in the future.
So, during the pre-acquisition process you already made sure that the documentation is available, you might also have it already, that the source code is available as well as the material you need (provided by the artist or to be bought). But now, you are going to complete the documentation to have enough information to setup and maintain the artwork by yourself and gather every pieces of software and hardware to store it in your institution in order to preserve the artwork in the near future (with software-based we cannot make long-term plans).

Step 1: the contract

Normally, in the contract the following paragraphs should be included:

When the Work has been provided and installed, a testing period of 14 (fourteen) days or longer shall begin, during which the artist may make the final adjustments and ensure the proper operation. During this period, the artist shall be available to [the institution] to set up features or to rectify defects in the course of the following working day, if requested by [the institution].
Seller shall provide [the institution] with written information required for the installation, maintenance and, repair of the Work. He|she is willing to supervise the repair, if requested by [the institution].
Seller shall provide [the institution] with the source code and development documentation of the software created by him|her in such a condition that will allow an expert to further develop the software. Unless provided otherwise, [the institution] may use the source code and the information contained in the development documentation for software maintenance only, unless it was granted exclusive rights to use.

This requires the artist to provide you with the source code, documentation and to help you in the future. This is important that it is stated in the contract so that once the artwork is acquired by your institution, you are not finding yourself without the necessary components to preserve the artwork.

The contract should also specify the list of material that would be provided by the artist. It would be important when the artwork actually arrive at your institution for the first inventory.

Step 2: Start to write the documentation

For this, you contact the artist and/or programmer again after the contract is signed.

Non-exhaustive list sent to artists:

please specify the model of any standard electrical/mechanical/hardware components, if possible with supplier for spares, manual and datasheet
In case of programmed electronics, please provide the firmware

In case of programmable electronics (Eprom for example), please provide de data

In case of custom-built electronics/hardware, please provide a BOM (Bill of Material with designation and supplier of all the components) as well as blueprints.

In case of custom-built circuit board, please provide the CAD for the PCB, list of components on it and the options for production - layers, material, thickness, spacing, solder mask, surface finish etc…

In case of 3d-printed parts please provide the STL files with material and preset specifications (layer height, model of the printer used, profile used etc.)

In case of use of Arduino board, please provide the code to be flashed

In case of use of ESP modules, please provide the code to be loaded
Please provide us with a wiring diagram of the system
Please provide us with a block or logical diagram of the software ecosystem (UML deployment diagram for example) as well as all the necessary files (source code and development documentation of the software) created in such a condition that will allow an expert to further develop the software.
Please specify the minimum specifications of the computer or specifications of the last computer used to display the work.

Please specify the OS or compatible OS (if multi-platform compatibility) for the software environment

Please specify the software dependencies (with license provider if there is any third-party software), the drivers (and hardware dependencies) if any, the libraries, etc.

If the computer is not provided (or if you think it is necessary), please provide us with a setup guideline for the software with screenshots (if no GUI, provide the necessary command lines)

Provide the exectuable(s) for exhibition with scripts for startup or troubleshooting/Log if existing.

In case of self-written software, please provide us with any source code (with all necessary files/dependencies to recompile the software, please specify the compiler name and version). If possible provide a ReadMe file along with the source code to explain the structure and compiling steps or a commented code so that it can be further developed in the future.

In case of authoring program, please provide the source files or source project, as well as the version of the program used and potentially export specifications. Please provide the installer for third-party software if still available.

TEMPLATE OF DOCUMENTATION is based on the model created by the project Matters in Media Art, which we adapted to our needs.

Step 3: Reality check

At this point, your documentation is theoretical. It is only a retranscription of what the artist/programmer says. Now you have to test the theory against reality: it is the reality check. Because the artists know their works, they tend to forget things that they are doing automatically without even thinking about.

Now, you’ll invite the artist to come to your institution for the first assembly in exhibition or a test assembly in your workshop with your technicians to explain precisely the steps of assembly/disassembly but also the problems you might encounter in the exhibition in a transparent way. This test setup allows to evaluate again the completeness of the documentation. You can also ask the artist for a certain availability during the first exhibitions of the work (From experience, it can take up to 3 setups for an artwork to be fully documented and installed without the artist’s supervision).

Step 4: gather the sources and make a backup

During the reality check, this is time for the artist to provide you with any source code with comments of any self-programmed piece of software, or sources with the corresponding editing application, which are necessary for the operation of the work. Don’t forget that there is code not only in the computer, but sometime elsewhere like the components in the interfaces etc.
While providing the sources, the artist can explain everything, which part of the software does what, what are the necessary drivers or operating system specificities, the auto-start script or the startup script, the configurations etc.

On your side, this is very important that you do a backup of the Hard disk of the computer, it means a complete copy of the all system, also called DISC IMAGE, not just the software executable but also the operating system, drivers, software libraries, scripts, etc. An IT engineer can do this.

Here is the type of files produced for long-time archiving at ZKM:

"Unmountable" disk image: made with , for example, Clonezilla. Non-readable: accessible only by writing the image on a physical support (HDD, SSD, USB...), often using it's original imaging software. Useful for temporary exhibitions and secondary backups (Clonezilla can directly generate MD5/SHA1 checksum). >> Useful for fast and secure backups.
"Mountable" sector-by-sector disk image: made using a standard (and most of the time open-source) format. Can be read by most of the software for the open-source (.img) format OR it's dedicated software for the proprietary format (example: .tib for Acronis) by emulating the original physical support. >> Useful for archival consultation.
Extracted software: only in case of high risk of future incompatibility. Example: software can run on both Windows XP and 10 but we don't have any Windows XP-compatible machine anymore - cloning the HDD would not work in this case. Extracted software MUST include their dependencies (installers, libraries, drivers, etc...). >> To be used only if the two previous methods are not possible (mostly used for migration process)

A md5 hash is made only the sector-by-sector image.

At ZKM the original data carriers (Hard disc, Floppy disc, DAT, ZIP, USB key, SD cards etc.) are stored in an archival storage. These carriers are duplicated and imaged on servers and LTO tapes before being stored for archival purposes.
The original software environment (disc Image) + executable, source code, etc, constitute the reference for the next versions of this environment. All the versions are stored together with appropriate comments, date, exhibition and decision-making of the software changes (we needed to change such or such peripheral device or utility, the computer broke down, etc).

All the different timestamped backups are archived on servers and LTO for reversabilitily purposes (we should always be able to go back to the origin of the artwork).

Step 5: gather spare parts and store the material

In addition to the backup strategy, we create ready-to-run computers. Instead of keeping the backups on our servers and magnetic tapes, we additionally implement them on spare computers in order to create multiple, identical, and functional examples of the entire hardware-software environment. Since we often have situations we need to setup a computer quite fast after a break down, we store the whole computer. Especially if it´s a computer with extra breakout cards, or specs only needed for that special artwork.

You should also gather spare parts. The purchase of spares, either it is equipment dedicated to an artwork or part of your exhibition equipment pool, is paramount for the short and middle-terms conservation of the work. You should purchase first the devices that are the most obsolete, expected to fail or rarest to find. The spares can consist of the whole equipment (same year, model or equivalent) or parts of the equipment (hard drive, graphic card, tubes, components...).

ZKM is gathering since its opening spare parts for computers, CRT monitors, backups of old systems, equipment etc.
If a piece of equipment is not available in our storage, Ebay is our Best friend! And lately it became easier and easier to find spares for material of the 90s. Also time goes by and we have now a better understanding and overview on each devices possible failures and troubleshooting. The team has 20 years of experience with these old computers and their possible reactions, this knowledge is more then valuable for the whole community.
Recently, we started purchasing spare parts equipment before any obsolescence phenomena appears (technological watch). When a work is acquired, even if the equipment is recent, we either ask directly the artist to provide us with spare or we wait till the prices go down and buy certain models one or two years after their release.

All the complex digital artworks should be stored with their dedicated equipment to avoid dissociation (Computer, cables, peripherals, interfaces, mechanics, touch screens, tactile surfaces, sculptural objects etc.). Exception is made for non-specific projectors, monitors (CRT or TFT), light and sound equipment that are stored in the museum exhibition equipment pool and use for other artworks and exhibitions.

At ZKM, each equipment has a bar code which is linked with an inventory database.
In this database all the specifications of the equipment is indicated (Brand, Model, serial number, location etc.) as well as part of an artwork group. On the artwork entry, a tree structure allows to see all the equipment dedicated to this artwork and which piece of equipment is currently use by the artwork in exhibition. With this database, we can follow all the equipment used years after years, exhibition after exhibition, for a piece of artwork. These spares as well as the original equipment are stored together.

Certain precautions have to be taken before storing a computer to avoid it to be damaged in storage:

Remove the batteries
Remove dust clogging the vents
Remove the capacitors
Wear gloves when handling electronic components (static electricity)

Step 6: Make an interview

Since 2012, the head of ZKM conservation department, Nahid Matin Pour, understood the paramount importance of artist's interview. She created the first interview in 2013 in order to gather all the information for the conservation and maintenance plan during the exhibition. Since then, it never stops to be improved, in particular when the conservators start to use the Variable Media Questionnaire, an online tool dedicated to artist interview.
Since the end of 2013, each new acquisition of time-based media artwork has been followed by the interview of the artist.
These interviews are then transcript (when they are made by skype or in video) and analyzed. The various information coming out of this interview should appears in the conservation plan as well as in the installation documentation and are fully part of the decision-making process.

Step 7: make the artist proof-read your documentation and interview

At the end of this acquisition process, the documentation/manual is sent to the artist for proof-reading and corrections.

Post-Acquisition marathon (be prepared to be proactive)

To exhibit is to preserve. Do not hesitate to exhibit the work as often as possible as a form of technological watch. Surround yourself well and ensure the conservation and transmission of the documentation and knowledge associated with an artwork. In the event of a breakdown, call on qualified art conservators who often have a network of specialized technicians who are aware of the problems of digital art. Make multiple copies of the data, on different supports, geographically distant.

Update your documentation during all steps of the artwork’s life. Document each decision, each repair, each exhibition etc.

ZKM is using MediaWiki software like you saw during this presentation. Our wiki is hosted on ZKM servers and accessible online for collaborative documentation with the artists and external experts.

ZKM also created an issue tracking system to monitor the artworks during exhibition time (history of failure, troubleshooting, workflow and knowledge management features). This tracking system is also linked to our database. All the artworks currently exhibited in the museum are added to the system in order to be monitored by the different teams (service technicians, restorers, IT etc). Basically, when something wrong happen in the exhibition (something is out of order or broken), the technician or restorer open a „Ticket“. Then, the investigation as well as the troubleshooting with pictures are entered in the ticket. Once the problem solved, the ticket is closed and archived. Meant at first to improve the communication between the teams (the weekend team and the week team in particular), it became a real source of documentation for revision history/operational failure etc. of individual artworks of our collection. A summary of all the artworks’ tickets is added to the Wiki documentation.

To finish, don’t forget that with this type of artworks, reacting is not an option. As Bruce Sterling already pointed out in 2001: “When a piece of software decays, it does not degrade like a painting, slowly and nostalgically. When a software fails it crashes; it means the Blue Screen of Death.” Conservation of media technical artworks knows only one rule: the proactivity. It is just basic computer forensics common sense: if there is too much time between two conservation efforts, the technological gap will be too huge to fill in to make the artwork operate again: the knowledge, the skills, the people and the machines are gone. The answer to the question When should we act is simple: when everything is going well. To maintain the behavior and aesthetics of the artwork the closest to the initial version, the technological jumps have to be as smallest as possible. The loss of the initial version resulting for long period of inaction makes any conservation effort risky. Indeed, this inaction increases the risk of technological discontinuities: the incompatibilities between the two technological ecosystems constrain the conservation professionals to imitate the behavior of the artwork with contemporary technologies rather than migrate it.