This is the second installment in our series on the Hydra Community Principles.
According to Al Gore, there’s an old African proverb “If you want to go fast, go alone. If you want to go far, go together.” This idea caught our attention early in the Hydra collaboration and has become the driving principle for how/why we work as a community. I think that Tom Cramer of Stanford gets credit for being the person who recited this principle the most over the past few years, but now we all find ourselves saying it. At first, it just sounded like a nice ideal that we could all nod our heads to but over time the truth of the adage has rung true.
Digital repositories address a distinctive set of use cases ranging from end-user interactions to technical preservation scenarios. As a result, developing solutions for digital repositories requires you to grapple with many complex technical challenges. Very few people in the world have deep familiarity with those issues. The Hydra community has already managed to attract an impressive number of those people. Among them are some of the top Fedora experts and some of the most experienced creators of next generation search interfaces. It’s an amazing advantage to have all of these deeply knowledgeable people contributing to the same set of designs, code, and solutions.
I’m pretty sure that no single institution could muster a team of this size and caliber to work on digital repository solutions.
Off the top of my head, here’s a list of areas that we have addressed in ways that explicitly drew on knowledge, skills and resources spread across multiple institutions:
- Data Modeling/Content Modeling
- Repository Security & Gated Discovery
- Search Interfaces (designing & implementing)
- Search Indexes (building & managing)
- Metadata Schemas (choosing & using)
- Workflow & Reusable Services
- Accessibility & Usability
- Testing & Documenting Code
- Deployment & Systems Administration
In addition to addressing these technical areas, the Hydra community has become an intense testbed of best practices for developers and managers. Even the work of building and sustaining the open source project itself has been achieved through open, iterative, collaborative process.
This only scratches the surface of the benefits that I personally see in Hydra’s collaborative model. Taking a step back, I’d say that working together as a community has allowed us to achieve a potent balance of pragmatism and long-term vision. The next two Hydra principles address these things directly.
Next Week: Making a solution that works for us.
*Image caption from CUNY course materials