Search
Menu
Search

Since January, when she joined CoSector – University of London’s digital research technologies team, Julie Allinson has written two blog posts about the digital repository software Hydra and the use that her team will make of it. It may surprise you, therefore, to read that Hydra is no more! But fear not, the name may have gone but the software and the community that supports it are very much alive and well under a new name: Samvera.

History of Hydra

The Hydra Project began in 2008 when a group of people came together to discuss a problem they had in common: how to build flexible digital repositories to manage the growing volume of digital assets that they were accumulating and how to make those repositories and their content sustainable into the future. At that stage, many institutions had already adopted either the DSpace or EPrints repository platforms.

But this group, consisting of the University of Hull, the University of Virginia and Stanford University, wanted to focus on the use of the Fedora repository architecture which, it seemed to us, offered more flexibility in dealing with different types of content and was designed with an eye to long-term preservation. The Fedora software team were the fourth partner in our enterprise.

Interestingly, the group’s purpose in coming together was not primarily to create an open source software solution but rather to address the issue of how to use Fedora in the best way. For example, how to build workflows that could be re-purposed for use in multiple institutions, and what software tools might be used around Fedora that would allow it to be used flexibly by institutions with quite different approaches and needs. It is important to understand that, unlike DSpace and EPrints, Fedora is not a complete repository solution; rather, it provides a robust repository ‘back-end’ over which users can layer their own workflows and interfaces.

The group of four organisations was quickly joined by a fifth, MediaShelf – a small software consultancy. Throughout 2009 we met regularly and eventually decided that to achieve our goal of using Fedora in the best way we should build a modular, open source software set of tools using ‘best of breed’ components: Ruby on Rails, Blacklight, Solr and Fedora; it was May 2010 before the first ‘Hydra’ software started to emerge. The group recognised early on that many open source projects fail through lack of a community around them and so it was always part of the plan that we should build a community that other institutions would want to join and have a stake in maintaining.

The formal role of Partner was created, bringing with it a commitment to contribute to the ongoing development of both the software and the community. By mid-2012 Hydra had 10 Partners and today the figure stands in the mid-thirties – mainly universities in the US and in the UK but also non-academic libraries and media organisations. The original ‘group of five’ now form the core of a ‘Steering Group’ with additional members added over time to reflect the developing community.

In addition to the Partners, Hydra has many adopters who use the software and contribute to the project but, for one reason or another, do not yet wish to become full Partners. Each year in the autumn we hold an international conference, Connect. Connect 2016 in Boston, MA, attracted 260 people from some 90 different institutions. We have formal licensing agreements with some 70 institutions and more than 250 software developers worldwide which potentially allow them to contribute to our code.

As we have said, Hydra was intended to offer a set of modular components with which institutions could build their own, customised, repository solution built on a solid core of community-maintained code.  This they did, but as time went on it became clear that there was a considerable maintenance overhead involved in each having significantly different installations and, as institutions came under increasing financial pressure, many found that they could not sustain the level of software development and support that they could at the beginning of the decade. The community worked towards bringing more and more functionality into a common core which could more easily be supported in the field. Further, we began to discuss what an ‘out-of-the-box’ deployment might look like, something capable of being installed and used in organisations with very little local IT support.

Hydra-in-a-box

It was timely when, in 2015, Stanford University, DuraSpace (now the parent organisation to Fedora) and the Digital Public Library of America (DPLA) were successful in obtaining a substantial grant from the Institute of Museum and Library Services in the US to work on what became known as “Hydra-in-a-Box”. Primarily this was to be a Hydra solution to support the work of the DPLA in aggregating and making available digital content from its feeder institutions, but part of the remit was to produce a near-turnkey version of Hydra capable of being hosted locally or in the cloud and which would, in the longer-term, be maintained by the community.

The 30-month grant shortly comes to an end and its result, Hyku, is the product that Julie’s team are using to build a hosted repository service which will be offered by CoSector – University of London. Many, both within our current community and beyond, are looking to Hyku as a possible solution to their repository needs at a time when local support services are increasingly stretched.  Hyku brings together all the richness of Hydra’s software development to date and the support of a large and vibrant community.

Rebranding Hydra

In 2016, recognising the potential expansion that Hydra-in-a-Box might initiate for the Hydra community, we decided that we should trademark the name Hydra and our associated logo. In so doing, we became aware of a company in mainland Europe which had a long-standing trademark on the name for factory automation software. Given that our Hydra was in a completely different area of software, we tried to reach a co-existence agreement but without success. Their lawyers gave us six months to ‘re-brand’. Rather than see the re-branding process as a setback, we determined to use it as an opportunity to reinvigorate the community and to enhance the role of our Partner institutions in maintaining it.

Members of the community were asked to propose and then vote on possible new names and eventually we settled on ‘Samvera’.  Samvera is an Icelandic word which expresses the idea of ‘togetherness’ or ‘being together’, something at the core of our community values.  (Along the way we discovered that open source software communities have a great fondness for mythical beasts: many such names, from all over the world, were proposed – the vast majority had already been used!)

Following a meeting of our Partners in March this year, they formed a working group with the specific remit to recommend how best the Partners might manage Samvera’s development going forward. We recognise that as Hyku gains traction in digital repository space, its users will expect a more professional approach to ongoing software development and the delivery of software products.

This is not to say that we have been unprofessional in the past; indeed, we have worked hard to maintain a level of professionalism in applying industry standards to what we have done. But now we need to recognise that institutions using Hyku will expect clearer information about forthcoming developments, better documentation around our software, and a community that remains as responsive to its members as it is now – even though it may grow significantly.

Nor will we forget the needs of those who still want to use our software in a modular way. At the heart of Hyku is a module called ‘Hyrax’ which represents the bringing together of some nine years’ development work; some larger institutions may still want to use this as the basis for a more customised, local version of Samvera.

The core work of Hydra, and now Samvera, has never been grant funded though we are grateful to a number of agencies for funding specific projects which have used and developed our software. Rather, our development as a product and as a community has been driven by Partner institutions invested in the idea that, by working together, we could create a sustainable solution to a common need.

We are indebted to those institutions for their contributions of staff time and other resources.

Richard Green is an independent consultant working with the University Library at the University of Hull where Chris Awre is Head of Information Services. Both are members of the Samvera Steering Group.