I also really like this registry idea for both the collective strategy/collective action approach. It could also be a way (thinking of building community both internally and externally) for people to see all of the ways they could contribute - like linking to manuals / documentation / archived forum threads - even if they are new to the practice or the community.
Jumping in a bit late to this conversation. I would also love some sort of coordination documentation and/or sharing forum for our strategies and workflows. Having a shared resource can also help with advocacy efforts. Thinking of a museum use case, being able to say “this is how x institutions are doing it and here’s documentation of what they are doing” goes a long way internally for seeking funding and other resources. It also takes the burden off one individual, or set of individuals, from doing all of the work.
Reflecting on today’s node call, the Computer History Museum is in a position to provide software for other institutions to use. Most of our use cases assume that the software itself is the content, not that we are using software to access other content. One of our pie in the sky dreams is to contribute to some sort of database showing what software items institutions have.
In regard to question 3, I did record some time trials related to cataloging and disk imaging software, in part to determine how much work would be dedicated to a research request. I averaged about 2 hours of work per software package (includes cataloging, flatbed scanning boxes, disk imaging, and digital repository ingestion work). We don’t have solid timetables in regard to emulation work as we’ve only emulated 3-4 software items. The only emulation work I’ve done took around 30 hours, which does not include the cataloging and disk imaging work I had done previously. This was for what I consider a straightforward interactive CD-ROM. I did include this particular piece of software in our use case so I can more directly compare the amount of time it takes to emulate something.
When accessing risk, we already consider several factors before we share disk images of the software in our collection. Before I respond to any request, I determine the copyright date, does the company still exist (if so, what is our working relationship with them), and how much of the software package does a researcher want. If a researcher only wants a file or two, I will try to get that to give to them. Especially, if they already own the software. But we are much more careful about software from companies we have or hope to have, a working relationship with. Theoretically, we could provide certain Microsoft and Apple products, but we do not, or we limit just how much of a software package we give (say something has 5 disks, but we only give a disk image of one of those disks). We heavily rely on our researcher agreement form to mitigate any risk. Unless there is an explicit agreement for access with a donor or company, we are more lax on providing access.
2 Likes
+1 for coordination documentation and sharing forum for strategies and workflows. I still remember our FCoP visit to CHM and the CHM folks going through their workflow and sharing documentation. That was extremely helpful since UArizona was just getting that work started, funding it, and testing workflows. It would be great if we could capture and facilitate that information-sharing more easily for the reasons you bring up, Elena.