I'm trying to see if I can lump my response to some of the responses above.
 Glad to see so much conversation around this.

We've considered setting up VMs, but even that can be quite costly,
especially if a project is or becomes dormant.  Developing a sustainable
"container" is certainly necessary.  Someone earlier said that the Library
often gets projects dumped on them to preserve longterm.  This isn't a
sustainable view of the Library.  These aren't booked dumped out of a
retiring faculty's office.  If one wants to use that comparison, then
Libraries need to assert authority to pick and choose what to maintain.
 Given that these projects usually involve actual faculty output rather
than a faculty's personal library of other people's output, that curation
needs to be more delicate.

Even exporting out of widely used applications, like Omeka, can be a
challenge.  What if it that project is using an Omeka from 4 versions
before?  Or what if the latest Omeka is supporting a lower PHP version than
the campus IT security standards allow?  This is no longer an easy problem
to solve from a technology standpoint because there, and will continue to
be, a growing number of scenarios to try to support.

I hesitate to want to use "it's broken" as a trigger to pull something down
because the impression could be that the Library can't support what it has
committed to support.  I'd rather there be term limits and re-evaluations
at a term limit.  Additionally in the face of decreasing funding, I'm not
seeing a lot of institutional prioritization that includes funding.  So the
expectation has to be support through neutral funding or less.


On Mon, May 20, 2013 at 10:06 AM, Edward M Corrado <[log in to unmask]>wrote:

> I agree with both Tom and Stuart. It is an easy problem to solve from a
> technology standpoint. It is, or least can be, a difficult one from a
> management standpoint. If institutional support is there figuring out the
> technology is easy. In this case, I'd start investigating the  technology
> part with something like Heritrix.
> Edward
> --
> Edward M. Corrado
> On May 20, 2013, at 0:58, Tom Johnson <[log in to unmask]>
> wrote:
> > That doesn't sound like an easy answer at all! Given that we all try to
> > play nice with institutional funding, all you've said is that in an ideal
> > world some other group will have a similar mandate. It doesn't get us (in
> > all seriousness) anywhere. Hopefully our institutions have higher
> > preservation goals! "collections policy" doesn't help at all--and may
> take
> > us backward.
> >
> >
> > On Sun, May 19, 2013 at 1:39 PM, stuart yeates <[log in to unmask]
> >wrote:
> >
> >> On 18/05/13 01:51, Tim McGeary wrote:
> >>
> >>> 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?
> >>>
> >>
> >> Actually, there is an easy answer to this.
> >>
> >> Make sure that the collection is aligned with broader institutional
> >> priorities to ensure that if/when staff and funding priorities move
> >> elsewhere that there is some group / community with a clear interest
> and/or
> >> mandate in keeping the collection at least on life support, if not
> thriving.
> >>
> >> Google "collections policy" for what written statements of this might
> look
> >> like.
> >>
> >> cheers
> >> stuart
> >> --
> >> Stuart Yeates
> >> Library Technology Services**library/<
> >>

Tim McGeary
[log in to unmask]
GTalk/Yahoo/Skype/Twitter: timmcgeary
484-294-7660 (cell)