Process
Every software preservation and emulation project proceeds differently, with variables like the type of institution, type of collection and software objects, stakeholder needs, and particular use cases shaping the project plan and execution.
The early phases of a project, however, tend to look similar across collections and institutions. Through the course of the FCoP project, the cohort participants worked through a series of project phases to help scope, shape, and plan a successful software preservation and emulation project. These phases are listed below.
Phase 1: Convene a conversation
This phase involves building out the initial project scope, and beginning a conversation with the project team and stakeholders. This is an opportunity to consider who needs to be “on the bus.” Who are the stakeholders? Who are the end users? Who else needs to be involved?
Phase 2: Evaluate
This is the inventory phase. Beginning by taking stock and inventorying the current collection before reviewing capacity and gaps as they relate to software preservation, the goal of this phase is to determine what exists already and what is needed.
Phase 3: Build the use case
In the next phase, the team identifies common patterns, defines the core use case(s) to focus on, and evaluates those assumptions against a few end users. This is also a chance to build relationships with end users within the context of conservation.
Phase 4: Plan the project
In this phase, the team will be ready to come up with a project plan. The plan may include a more detailed functional analysis, and a review of the existing tools — including SPN tools — that could brought into play. In general, the plan will start from a specific use case and will go through it from beginning to end, including two tiers of activity: organizational, and infrastructure and technology.
Beyond Phase 4
After Phase 4 it becomes a “choose your own adventure” scenario. The shape of a project will depend on the type of institution, what the collection or software objects look like, and the specificity of the team’s needs, capacity, and use cases. The FCoP cohort documentation and reflections provide more detail on the particular project directions and possibilities.
Priorities for Action
Drawn from FCoP cohort final reports and reflections, priorities for action in software preservation and emulation are articulated below. These actions are followed by specific stakeholder calls to action. Please contact us if you are engaged in actions outlined below – or would like to find ways to participate.
- Build a longer-term strategy for a more resilient network of software preservation professionals.
- Create and maintain a shared body of tools, reflecting different organizational context and experience, that can be applied to decision making about investment of people, effort, and digital infrastructure.
- Coordinate an effort to produce, collect, organize, describe, make accessible and preserve essential information surrounding software use such as manuals and brief “how-to” guidance documents.
- Coordinate dialogue between creator communities of practice (ie, musicians, graphic designers, architects, lawyers, research software engineers) and digital curation professionals.
- Collaborate on research around end user experiences for researchers, staff, and students who are discovering, using, and teaching with born-digital materials, software, and emulation environments.
- Deliver stable, hosted emulation services driven by user research data.
- Demonstrate how and where to integrate and adapt existing workflows to lower the barrier to participation in software curation activities.
- Determine ways in which software preservation efforts foster intergenerational dialogue (dialogue between software creators of the past and the future).
Stakeholder Call to Action
Institutions of higher education and faculty…We need an academic program that is willing to take on software preservation as an area of teaching/training. Ideally, this training would not only emphasize the unique aspects of software preservation, but also interweave and connect how this work is related to existing strengths components in the field of information studies around description, access, curation, etc. Undergraduate programs might consider using emulation in undergraduate pedagogy, building on the well-established landscape of teaching with primary sources, adding preserved software and software-dependent environments to that landscape.
Museums and other organizations experienced in exhibit design…We need your expertise to determine how to invite our user communities to engage with the context surrounding software and digital objects that may be accessed within an emulation environment? What is the digital equivalent of exhibit labels? How do we provide metadata for software and other digital objects ALONGSIDE metadata about the means by which they are experienced?
Grantmakers, federal funding agencies, and foundations….We need formal grant programs to support software preservation project proposals that tackle specific facets of software preservation or specific software use cases. Examples include sponsoring the preservation of specific video game collections or, in the research reproducibility domain, sponsoring prizes or awards through relevant organizations (ACM or the supercomputing conference reproducibility initiative are two example), additional tool development (e.g., PresQT), and training grants. Relatedly, we need formal grant programs to support software preservation project proposals that grantees to answer the “who” question. Project proposals might include in-depth end-user studies on end user “emulation experiences.” These studies could answer some of the following questions:
- Ways of talking to software donors — what do they envision for people interacting with their software?
- Why do end-users want to use preserved software/software-dependent environments? What are their motivations in real life?
Additionally, funders can examine ways that their grantmaking requirements incentive and enforce better software development practices, that in turn enable software preservation including code sharing, code documentation standards, etc.
Public libraries…We need your expertise in documenting local history. Drawing on models such as the DC Public Library Memory Lab, consider traveling roadshows where community members can try out emulated environments, learn about software preservation, and make connections based on their personal computing histories.
Software developers and other IT professionals…We need you to consider collaborating directly with cultural heritage practitioners and organizations. With specialization comes efficiency, however, highly efficient systems can be less resilient. Software archivists and curators are not software developers and we do not expect software developers to do our work – however, given that software is a critical medium of creativity, commerce, and in some cases oppression in the 21st century, we need your partnership. In particular, be open to sharing your deep expertise regarding the design, architecture, development, and use of software in order to help collecting organizations to better understand how to draw context and documentation from the software itself. Code commenting convention and consistency vary. However, when combined with versioning systems like Git or Mercurial, there may be considerable documentation that can be extracted and parsed in ways that can aid discovery and reuse for researchers.
Computer enthusiasts and hobbyists…We need you to help us locate the vast and lovingly curated collections of documentation that you have created, aggregated, scanned, and published online. Organizations invested in software curation don’t want to “own” these collections, rather collecting organizations can be another node in the network, copying these collections in another location and helping to contribute to their long-term preservation and reuse.
Existing organizations that collect software-dependent data and software…We need existing organizations to inventory their collections, survey their departments, and check against their existing catalogs to determine which types of software documentation they already have; and we need organizations to share this information with inter-organizational networks. Additionally, we invite collecting organizations to consider different modes of documentation and how those modes enable different aspects of software curation work. For example, detailed technical documentation allows emulation service providers to understand the necessary runtime settings and dependencies needed to create an emulation environment, however, video documentation of an artist demonstrating their software-based artwork is critical to evaluate the authenticity of the emulation experience for the patron or end-user. Software manuals may also be THE basis of comparison between the intended uses of a software application and the adaptive/creative uses of a software application by an actual user – that tells an important story for researchers that are interested less in the software itself and more in a particular person or group of people.
Existing networks coordinating field-level work in software curation…We need a focused, multi-stakeholder effort that bridges communities of practice and sources of software documentation while approaching the work from a shared set of principles. This effort could help to answer two key questions:
- How much of the available software documentation is digitized or born-digital?
- What is the feasibility of developing a unified but federated search across software documentation repositories?