Sometimes you need to work on something for a while before you figure out what its name should be. We’re at that stage now. The official name for the project, the one that was on the grant proposal, describes the overarching objectives of the grant, but it’s anything but pithy: Fostering a New National Library Network through a Community-Based, Connected Repository System. So what should we call what we’re making? (No really—we need your ideas. Read on!)

As we’ve moved through the first year of the project, it has become clear that our effort has many facets, and choosing (and using) the right names has helped differentiate the various strands. We have identified at least five distinct components for our effort, each with its own identity and branding considerations.

1. the project. We’ve settled on using Hydra-in-a-Box or HyBox (for shorthand, and used with some reservation) for the project. The project URL is currently hydrainabox.org, and resolves to http://hydrainabox.samvera.org/. While not all of the work revolves around Samvera (there are significant tie-ins specific to DPLA hubs and DPLA metadata—see below), this name captures one of the essential goals of the effort: to produce a turnkey repository product leveraging, and embraced by, the Samvera community.

2. code components. Samvera’s technical architecture has many components and layers, and an explicit Hydra-in-a-Box goal is to contribute to the overall architecture and code ecosystem. Note that a site may choose to use these components but not run the turnkey repository application, just as many sites now say they run “Sufia-based repositories.” Under the theory that a rising tide raises all ships, the project team’s focus has been to locate functionality in the right places within the Samvera stack, and not to create a product-specific code base where we can avoid it. Accordingly, we are not using HyBox or Hydra-in-a-Box as the name of code components, in order to encourage re-use in other projects, broad adoption, and code contribution & maintenance from other Samvera efforts.
   
   Therefore, for new code produced by the Hydra-in-a-Box effort, we have first sought to locate it where it rightfully belongs in the stack (e.g., Sufia, an independent gem, or even Fedora). Our hope is that the work we’re doing is general and modular enough that other Samvera efforts can and will make use of our code components—e.g., it would be excellent for the Avalon Media System to make use of (and contribute back to!) our components when it needs similar functionality.

3. turnkey repository product, locally managed. Building on what the Samvera community has learned working to make Sufia easy to install and maintain, we expect to provide a complete, configurable, turnkey product—more akin to Avalon, DSpace, or even ContentDM. We need a name for this product analogous to those systems, and with broad market appeal and strong branding identity. We have put a lot of thought into requirements for a good name:

   • We want something clearly related to the Samvera community (formerly “Hydra project”) to build upon its brand, and to invite uptake and code contributions / maintenance. Further, we want adopters of the product to know it is part of the Samvera community effort, in order to provide an on-ramp for them to join / participate in the wider community effort.

   • We want something clearly distinct from the Samvera community & repository / application framework. (Just calling it “Samvera” wouldn’t work.)

   • Hydra-in-a-Box and HyBox both seem poor choices here: the former is clunky and overly long. The latter is perhaps too insider-y and lacks the natural power and mass-market appeal that a name like “Avalon” brings.

   • Also, Hydra-in-a-Box implies the full functionality and flexibility of the Hydra (now Samvera) technical framework is present in the product, but all nicely wrapped up in one package. This is not true, as we’ll be making opinionated selections, based on the community’s requirements, about functionality to include. As such, we’re looking for a name that connotes a particular flavor or profile of Samvera.

   • We may want to pick up on the useful trend of picking a name related to or derived from “Hydra” in some way, but distinct. Hydrangea, Hypatia, Hydraulics, Hyperspace all fall into this pattern.

   • We need to be sure to clear the obvious hurdles—no similar products with similar names, no unintentionally offensive meanings in other languages, available domain names, etc.
     
     In short, we’re looking for a product name that has strong branding potential, will have mass market appeal, and is distinct from but is easily related to Hydra.
     
     For now, we have started by creating a new component that augments the Samvera stack with turnkey features. The application is, fittingly (we think), codenamed Lerna after the lake where the mythological Hydra lived (special thanks to Rick Johnson at Notre Dame, the first person to suggest this name).

4. hosted service. One of the goals of the project is to produce a “cloud-ready” version of the repository product, so that sites can make use of the platform without having to maintain or install their own instance. The project partners intend to pilot a hosted service next year to kickstart this process. (The cloud-ready components and configurations are also open source, and a good number of other sites have been in touch about potentially hosting an instance of the turnkey repository application for local consortia.) We have time and space to think about this name, and will get there next year.

5. DPLA metadata aggregator product. While a better and easy-to-install repository is a key component of the grant, it’s not the only one. The other major technical focus is to enhance DPLA’s metadata tooling to get more, better and richer metadata flowing among systems. This will elevate DPLA, its hubs, contributing member institutions, and users by raising the bar on discovery; it will also help any environment where metadata syndication, aggregation, and indexing is an essential component for improving discovery. This product is intended to build on Krikri, a software component used to build DPLA’s metadata ingestion system. Because this will be a general-purpose tool, we expect this product to have its own name, branding, and identity (likely very strongly linked to DPLA).

So what is the takeaway? Most obviously, as we have thought about names, we have also learned more about what we’re doing; it’s not just building a repository product, but also general Samvera componentry, a hosted service, metadata tooling, and a project.

We also have learned that naming things—especially important things, and things that you love—can be hard. (This is not news to any product managers—or parents, for that matter.) Do you have a killer name for the repository product? If so, give us your idea(s)! We are gladly accepting suggestions (and inspiration) for the repository product’s name. (Free t-shirts to any winning, or funny, submissions.)