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.