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
[log in to unmask]
[log in to unmask]
GTalk/Yahoo/Skype/Twitter: timmcgeary