Why are we collecting source code?

(via https://rekall.tumblr.com/post/92033337743)

(via https://rekall.tumblr.com/post/92033337743)

Part of what we continue to work on in parallel to the opening of Cooper Hewitt is capacity building for the museum to collect ‘the present’ – which includes the code that underpins and makes functional much of the ‘designs’ of the modern world. That means all the interactive, networked design ‘objects/works’, not just on screens but also those embedded in products, services and systems. I’m not just interested in this for ‘digital preservation’ reasons, but also to help us come up with new ways to interpret, contextualise and communicate the ‘how and why’ of these objects (and the choices the designers made) to our visitors.

Aaron liked what I wrote to a designer with whom we are working with on collecting some interactive pieces, and thought it made sense to share it in a redacted form. Sometimes it is nice to be asked to be explicit about why the underlying code matters – and so here’s what I wrote.

As the (publicly-funded) national design museum, one of the reasons we are interested in acquiring the underlying code and data is that allows the museum and future scholars and researches to explicitly explore and interrogate the choices and decisions made at the time of a work’s creation in response the the technological constraints of the time, as well as the adjustments made through a work’s creation to make it better respond to the needs of users. In the case of Planetary this is why we acquired the entire Github repository – the versioned codebase.

Approaching your choices of language and platform as ‘materials’ that were shaped by the period in which the work was made, as well as your decisions in the code itself, is extremely useful for interpretation and future scholarship. Nick Monfort & Ian Bogost’s book on the affordances of the Atari 2600 platform, Racing the Beam, is just one example of the kind of scholarship we foresee as being possible when code and data is acquired with works. This sort of exploration – of decisions made, and the technological and social constraints encountered – is key to Cooper Hewitt helping the public to interrogate and understand works in the collection and the work of designers as more than just aesthetic experiences.

Increasingly when we are acquiring interactive works we are also interested in how users used and reacted to them. In these cases we would also consider acquiring user research, user feedback and usage data along with a work – so that future scholars and visitors could understand a work’s success in achieving its stated goals. In terms of product design collections this is often reduced to ‘market and sales performance’ but we feel that in the case of works on the internet there is far more potential opportunity to explore other more complex and nuanced measures of relative ‘success’ that reveal the work that interaction designers and the choices they make.

In respect to [redacted] specifically, it helps visitors understand that you made this work in a particular way when you did because that’s how the technology and access to data was at the time. And that if that it was to remade now in 2014, there might be a multiplicity of new ways to do it now and we can explicitly talk about the differences.

The other reason is that the underlying code and data better enables the museum to preserve these works as part of the Smithsonian’s collection indefinitely in the public trust – and perhaps exhibit them 100 years from now.

Discuss.

2 thoughts on “Why are we collecting source code?

  1. desigonzalez

    Great post for many reasons. I’ll just tell you one of my immediate reactions:

    “user research, user feedback and usage data”

    !!! That’s brilliant and something I had never considered before. For me, it brings up many questions: where does a (digital, but also non-digital) object begin and where does it end? Is usage data the product/object/work, or is it information about the work, sort of like knowing about an artist’s process or how people have responded to the work? Should user research and feedback be treated more as archival material that informs us about the work (much in the way museum archives keep things like press about and correspondence with an artist or creator)? What about works/objects with user-generated content—is that content/data part of the original work, and should it be collected and preserved along with the object? (This last question also has ethic and intellectual property-related implications.)

    Reply
  2. Matt Popke

    I like the idea of collecting user research and feedback, as gathered by the original designer(s). We’ve heard it said so many times (or should have, at least) that design is the expression of intent. Seeing how a designer reacts to specific user feedback really helps us get to the heart of their intent, rather than guessing at it based on the manifestations of that intent or their stated intent. It also helps us understand if the result matched their intent (the success of the design).

    It’s like knowing the historic and political context for the works of Jacques-Louis David. It’s not part of the work itself, but it informs the work and the artist’s intent. The user research, developer documentation, wireframes, source, etc. all help us tease apart the intent of the designer, and whether the final product of their efforts effectively expresses that intent.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *