Another guest blog post for you from Chris Awre, University of Hull:

It seems at first slightly self-rewarding to be able to use a conference blog to highlight further some of the points I made in my conference presentation.  I’m sure it is.  Nevertheless, I’d like to do so in the context of the workshop and roundtable I led on ‘Getting to the Repository of the Future‘ and the conference as a whole, which I hope places any platform plug in its proper place.

To re-cap, Hydra is a project initiated in 2008 to create a flexible framework that could be applied to a variety of repository needs and solutions.  Hydra today is a repository solution that can be implemented (based around Fedora), a technical framework that can be adapted to meet specific local needs, and, of equal if not greater importance, a community of partners and users who wish to work together to create the full range of solutions that may be required.  There are, as of August 2013, 19 current partners, with a number of others considering joining: in Europe the University of Hull is joined by LSE and the Royal Library of Denmark as partners, with use also taking place at Glasgow Caledonian, Oxford, Trinity College Dublin (for the Digital Repository of Ireland), and the Theatre Museum of Barcelona.  Not a large number as it stands, perhaps, but each exploiting what Hydra can provide to meet varied needs, sharing experiences and ideas, and demonstrating how a flexible platform can be adapted.

I’d like to pick out three main themes:

• What is Hydra?

In the Repository of the Future workshop one of the main points raised was about clarifying the purpose of a repository.  This allows it to be situated in a broader institutional context without necessarily competing with other systems.  In doing so, it suggests that repositories should focus their activity rather than suffer mission creep and dilute their core offering.  I was conscious of this as I described Hydra in my presentation as being able to manage any digital content the University of Hull wished us to.  Contradiction?  On one level, yes, and I am all too well aware of the need to clarify what the repository is actually doing so as to strengthen the message we give out: I am defining our repository service more succinctly for this reason, for the University and for library staff.  But that doesn’t mean the repository infrastructure shouldn’t be capable of managing different types of content so that when a use case arises the repository can offer that capability to address it.  Clarifying our repository’s purpose is thus emphasising that it is a service capable of managing structured digital content of all sorts, with foci around specific known collections.  Other Hydra partners have focused their developments on more specific use cases (e.g., Avalon for multimedia, or Sufia for self-deposit), albeit recognising that Hydra provides them with the wherewithal to expand this if they need to.  And if we can share the capability between us as part of a community, then we can expand functionality and purpose as we need to.

• Repository as infrastructure

I mentioned repository infrastructure in the last paragraph.  A challenge I threw out to the workshop, and throw out here, is to go into an institutional IT department and ask if the repository is infrastructure or an application.  These are treated very differently, with the former often given more weight than the latter I would argue.  I would also suggest (and I’d welcome feedback on this) that repositories are more considered an application.  However, if we are to take the management of digital collections seriously then they need to be treated as infrastructure, and the purpose of a repository built up from there.  A lot of the thinking behind Hydra is based on the repository underpinning other services through making content available in flexible ways to allow it to be used as appropriate.  Someone at the workshop referred to a repository as a ‘lake of content’.  Whatever the scope and purpose of a repository, managing that lake is an infrastructural role akin to managing the water supply network as opposed to focusing on the bathroom fittings.

• Technical support

Key to Hydra’s evolution has been the dedication of many software developers to contribute from the various institutions they are employed by – a classic open source model in many ways.  I was asked following my presentation how Hydra had been successful in getting such commitment.  One part of the answer was the one I gave, that the software choice, Ruby on Rails, had proved very amenable to agile development and frequent input, and that the developers liked using it.  Another is the further point I made, that the US libraries can sustain such projects as Hydra because they recognise the value of technology to their libraries, and are prepared in many cases to back that up with specific staffing resource.  Certainly this is most evident at the larger institutions, but it goes beyond this as well: not for nothing is there a technically-oriented national Digital Libraries Federation through which digital library initiatives can be showcased and shared, and the developer-focused Code4Lib community.   Developer staffing within libraries in the UK is there in some cases, but is not widespread.  If we consider repositories as being part of a library’s future, do we need the technical commitment to ensure they can do the job they need to?  At Hull we rely on IT department staffing, as many do.  Perfectly adequate for managing an application, but is it an indication of real commitment?  Where it is not feasible to have local technical staff, is there a model that supports dedicated developer input as part of a collaboration?  Of course, even with dedicated technical resource it may not be feasible to do everything alone – hence the Hydra model of doing things together that partners the size of Stanford and Virginia continue to value.

<setting out stall>

Of course, at the University of Hull we view Hydra as being a route down which we can get to the repository of the future.  It provides us with the infrastructure we need to establish our repository’s purpose, but adapt and grow from this as the University requires.  It also allows us to say ‘yes’ when we are asked about the ability to manage different content, even if there may be associated staffing resource issues that need resolving.  We think this will stand us in good stead moving forward.  Hydra won’t necessarily be right for others as a technology, but I hope that the community aspects of working together technically can be adapted to suit regardless of technical platform.  If interested in pursuing more about Hydra as a technical solution, though, let me know

</setting out stall>