I'm interested in starting or joining discussions about best practices for on-going support for digital library projects. In particular, I'm looking at non-repository projects, such as projects built on applications like Omeka. In the repository context, there are initiatives like APTrust and DPN that are addressing on-going and long term collaborative support. But, as far as I know, we aren't having the same types of discussions for DL projects that are application driven.
Here's a couple examples (using Omeka only as an example - it could be any application): Example 1: Two professors start a new graduate program in the Digital Humanities with one class that will focus on the research process. They arrange to have a 500-item collection digitized and placed in Omeka. In each semester, individuals or groups within the class will build they own Exhibit inside Omeka based off that one collection and publish a research paper on the site with the exhibit. The Library supports this project because it promotes a Special Collection previously unavailable to users, and active scholarship is produced about the diverse nature of the collection. This class is taught for 8 semesters, and has its own Omeka instances on a virtual server. Example 2: One professor teaches an art history class, mixed between undergrad / grad students. Each student or group is responsible for building a small collection in Omeka and then a couple exhibits from that collection, each exhibit having a corresponding research paper. The professor wants to keep available the best 10-20% of the projects from any semester that support the thesis of a larger research project she is working on. Each student or group gets their own Omeka instance in an local Open Shift cloud ( https://www.openshift.com/). The projects selected to be sustain will be pointed to from the larger faculty-project on production servers in the future or perhaps be moved themselves to the production server. This class is taught one semester per year for 4 years. Challenge: Example 1 is a project that has consistent growth. When an Omeka upgrade comes out, it will be fairly simple to maintain and solve any small issues from one upgrade to another. But what happens when these professors move on to something else? They want this Omeka project to remain live, but after 2 years of inactivity, perhaps their Omeka instance breaks because we need to upgrade PHP due to a security hole discovered. There is no on-going activity, and it can be expected that resources spent to support their active effort has moved on to new projects. Example 2 presents similar challenges, but there could be a lot of little projects running on the different versions of the application. Perhaps year 1 was on Omeka 2.1 and year 2 was on Omeka 2.2, and there wasn't an effort to upgrade year 1. Suddenly year 3 comes and Omeka 3 is out, but only year 2 can be upgraded (for some reason). Or perhaps there is an incapability because the way a student used their cloud-based Omeka instance with trying to move it into the larger sustained project. There is no easy answer for this, so I'm looking for discussion. - Should we begin considering a cooperative project that focuses on emulation, where we could archive projects that emulate the system environment they were built? - Do we set policy that these types of projects last for as long as they can, and once they break they are pulled down? - Do we set policy that supports these projects for a certain period of time and then deliver the application, files, and databases to the faculty member to find their own support? - Do we look for a solution like the Way Back Machine of the Internet Archive to try to present some static / flat presentation of these project? Let's talk - I'm listening. Thanks, Tim -- Tim McGeary Director of Library & Information Technology University of North Carolina at Chapel Hill tim.mcge...@unc.edu timmcge...@gmail.com GTalk/Yahoo/Skype/Twitter: timmcgeary