Good questions.
I'm a programmer for a project lasting 4 years which will create quite a
few web applications with uncertain future once the project ends.
So what I have in mind is something like "graceful degradation" of these
services. E.g. most of these apps make use of a javascript mapping library
- so once the API version they use is no longer supported, maps won't show
anymore, but the data to be mapped will still be available as geojson. Or
once the web framework is no longer supported, there should be an export
mechanism to create a set of static resources which can be hosted with just
a webserver.
So while I'm a bit sceptical about the linked open data claim that "the
next visualization of your data will be built by someone else", I want to
at least not prevent that from happening.
Of course there's also a cost attached to host static resources on a
webserver, but at least that's a scenario which is a lot better understood
and supported.
best
robert


On Fri, May 17, 2013 at 3:51 PM, Tim McGeary <[log in to unmask]> wrote:

> 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
>