- Adam Wead, Rock & Roll Hall of Fame
- Anders Conrad, KB
- Claire Steward, Northwestern
- Declan Fleming, UCSD
- Jon Dunn, Indiana
- Rick Johnson, Notre Dame
- Ed Fay, LSE / Open Planets Foundation
- Mike Giarlo, Penn State
- Karen Cariani, WGBH (regrets)
- Mark Bussey, DCE
- Bess Sadler, Stanford
- Richard Green, Hull
- Lynn McRae, Stanford
- Jonathan Markow, DuraSpace
- Andrew Woods, DuraSpace
- Robin Ruggaber, Virginia
- Tom Cramer, Stanford
- Rob Sanderson, Stanford (facilitator)
Google Doc for Power Steering collaborative work
Draft agenda items - unordered
- Fleshing out Partners v. Users further (
NOT FRAMED BELOWSOME FRAMING BELOW - PROBABLY ADDRESSED) should we require a cCLA before granting full Partnership to an institution?(ADDRESSED AT THIS POINT, NO? We fudged it a bit, but yes.)
- Is it time to centralize organizationally? (SOME FRAMING BELOW)
- what would centralization mean?
- what about Hydra's positioning relative to Avalon? Hydramata? Sufia? HydraDAM? HyHull?
- how would this change governance structure?
- would more formal organization help skeptics see Hydra as more "serious"?
- What would Hydra do if it had $? (
NOT FRAMED BELOWSOME FRAMING BELOW)
- how would Hydra hold $
- related: what is our policy if a Hydra Connect meeting makes a profit?
- with or without funding, how can we improve the professionalism of our marketing materials and technical documentation?
- What is our grants strategy? Could we use a formal grants framework?
- Hydra positioning relative to RDF? (NOT FRAMED BELOW)
- How is this positing similar to/different from our positioning relative to XML?
- Hydra positioning relative to Fedora? (NOT FRAMED BELOW)
- do we need a meta Tech Board? council of architects? (RELATED TO "EVOLUTIONARY CHANGE IN HYDRA CORE", BUT NEEDS MORE FRAMING)
- is gemification working?
- is release management working?
- What is the desirable relationship between regional, Partner and Connect meetings?
CAN SOMEONE MAKE A PROPOSAL FOR CONSIDERATION? OR IS IT BETTER SERVED BY OPEN DISCUSSION? (I've added a para below - but essentially i think this is open discussion - R)
- Update and review of Strategic Plan
- What are we doing in relationship to a technical roadmap or release schedule?
- These topics bear drilling down:
- Strategy 4 & 5: Training & Documentation
- Strategy 6: Evolution of the Tech Core / Gemification / Hydra / RDF / Fedora / connectors / digital preservation
- Strategy 7: Community framework: users/partners/steering
- Strategy 8: Marketing
- Marketing Questions (CAN THESE RELATED TOPICS BE PULLED TOGETHER INTO A BLOCK?)
- Connect as a marketing tool
- Is the term "Project Hydra" becoming a hindrance?
- With or without funding, how can we improve the professionalism of our marketing materials and technical documentation? (x-ref with $ question, above)
- Has Hydra a way of responding to a tender request? (Filling in the tick box form etc.)
- Who are we marketing to?
- Do we need different messages for different audiences/levels?
- How do we effectively market a dev framework and development community vs. a set of applications?
- How does Hydra marketing interface with / relate to solution bundle marketing (Avalon, Hydramata, etc.)?
- should we start adding / prioritizing standard "ecosystem" connector functions to the Hydra stack, to make it more powerful and palatable in today's environment?
- e.g., ResourceSync, IIIF, OAI-PMH, <SHARE Notification>, etc.?
- what would/could Hydra leverage in Fedora 4? 2 one hour brainstorms
- are we doing collaborative, interinstitutional development in a "Hydra way" at this point with Avalon, Hydramata, Sufia, Spotlight? if so, what is it? can we identify, replicate and extend it ?
- Fedora 4
- digital preservation
"Is this time for a revolutionary change in Hydra core?" - Robin
I raise this topic due to enhanced Fedora4 features, individual Hydra core components in question for replacement (e.g. see list for OM for Happymapper or query a few partners that have avoided OM), problems people are having developing gems to operate in concert for a complex Hydra application which may call for changes in Hydra core. Fedora came to a point where we knew we needed to step back and assess. I think this year may be the start for the same with Hydra core and it may prove useful before we move into collaboration with other services.
Digital Preservation & Alliances - Tom (after a conversation with Ed)
Many Hydra / Fedora have adopted the stack because it is digital preservation-friendly. This has historically been a compelling feature set for both Hydra and Fedora, and something that distinguishes them from other DAM or electronic content management systems. The Open Planets Foundation is a digital preservation organization--largely European based--that provides a home to the tools, services and digital preservation utilities that emerge from Euro-funded digital preservation initiatives. Much of their focus has been on cultivating good open source development practices for developers embedded in research universities or national libraries, and they have succeeded in cultivating a very Hydra-like ethos and community of practice. Some key questions emerge from this parallelism:
- Is digital preservation and object durability a compelling Hydra functionality, and something we want to invest in?
- Does the Hydra architecture, and push towards gemification, offer the potential to plug in OPF or other preservation tools and utilities as standard, modular components?
- How can the answers to the above inform Fedora 4 development, and how Hydra leverages and influences its direction?
- Specifically, might OPF Hack-a-thons provide fertile ground for finding Hydra adopters in Europe? Might Hydra events in the US provide a channel for airing and use of OPF digital preservation tools and utilities?
- More generally, do synergies with OPF suggest that for the next phase of Hydra development the project would be well served by trying to cultivate alliances or sister-organizations / projects? If so, which organizations, and what form might those alliances take?
Formal Hydra Grants Framework
"Could Hydra formalize a framework for identifying, proposing, and executing grants, and then disseminating their output, in such a way that Partners gain a competitive edge in proposals, and the project as a whole benefits from the grant work?"
...and if the answer to this is "Yes", then the follow on question is "what would this look like?"
...and then, if that is concrete enough "should we start to actively pursue grant making & partner matching in areas of key interest?"
As background to consider:
- granting agencies are increasingly looking for collaborative projects, to ensure that the focus and benefits of any grants are not overly parochial by being limited to an individual institution's priorities. Notre Dame's ORCID grant is an obvious illustration of how a single institution in short order received multiple offers of collaboration and support.
- granting agencies are increasingly looking for broad-based impact on their investment. Funding Hydra activity gives them a built in audience of potential adopters--now in the dozens--that can benefit from the work done by their fundees.
- granting agencies often look for cutting edge methods for executing work that not only accomplish a given task, but build capacity in doing it. Indiana and Northwestern's adoption and application of agile methodologies in Avalon is a good example of this. Hydra has a good reputation and concrete methodologies it can point to to demonstrate this.
- granting agencies are looking to fund projects that can sustain themselves after funding ends. Hydra gives a built in community of adopters and developers who poised to take on any successful work that benefits their local institutions and only requires a small increment of energy to adopt and maintain.
- granting agencies look for complementary teams and partners. The HydraSphere is now broad enough that partnerships can readily be assembled that address multiple forms of diversity: geography, size, academic disciplines, content types, archives v. libraries v. research organizations, those that are engineer heavy with those that are analyst heavy and those with project management competencies, etc.
It seems to me that Hydra offers fertile ground that funders would find attractive. We also perhaps have examples of what makes a successful grant-funded project in the HydraSphere (in terms of identifying a need, formulating partnerships, project transparency, structure, form of deliverables, etc.), some project infrastructure that would aid a project (regular face to face meetings with a wider community; a built in training program; an IP framework; ready contributors, project advisors and adopters), and things we might ask of a project should they get "official" project support, like distributing code under a Hydra license, or committing to make the grant output compatible with the latest elements of the Hydra stack.
Related Question: Are there any grants that we want to pursue right now (in 2014 / 2015)?
Licensing - Declan
GIVEN RECENT ADVANCES ON THIS FRONT, IS THIS STILL RELEVANT?
I'd like to discuss the work Tom and I have been doing surrounding the Hydra Apache 2.0 license and the difficulties it has given us (and other UC schools) with the contribution agreement. I'd like to understand the up and down sides of possibly changing the Hydra licensing.
What is the desirable relationship between regional, Partner and Connect meetings?
The recent discussion around a regional Hydra meeting in the NE USA raises again the question of how Hydra should deal with multi-layered meeting schedules (regional v. Partner v. Connect). Whilst regional meetings are an obvious and natural development of Hydra's community structure it would be in everyone's interests to ensure that they reinforce the community in a positive way and that there are no unintended negative effects. We should aim to understand the likely formats of each of the three meeting types and ensure that they are complementary. And how does LIB/LAMDevConX fit in? It's supposedly not a Hydra meeting but an awful lot of Hydra business seems to happen there (See for instance LibDevConX breakout on "Are we sharing properly?)?
I think we have a feel for what we present at Connect. We assume a blank page for tire-kickers, limited knowledge for new users and much better knowledge amongst Partners and we try to balance the varied needs of attendees as best we can. I'm (Richard) more concerned about Partner meetings v Regional meetings. If, say, a big regional meeting has a mega-demo or two those folks won't want to repeat that at a Partner meeting, yet those who weren't there might be crying out for such. Also I wouldn't want a Regional meeting that attracted a lot of Hydra's power players to become a de-facto Partner meeting to which others didn't come; that way lies a splinter group? I'm probably unnecessarily concerned, but I think we should air these concerns at least briefly - if only to dismiss them.
Hydra Strategic Plan
- are the elements of the strategic action plan still valid?
- should some be modified or deleted in the light of developments over the last year or more?
- are there elements that should be added?
- the target dates require revision
In doing this work, SG should consider why we didn't hit the targets and what, if anything, can be learned from that analysis.
It is suggested that we not review each item in the strategic plan, however that we review the list of open action items to see if any merit proposing as an individual topic.
Connect as a marketing tool
Hydra Connect is, to some extent, a marketing tool. A number of tire-kickers came to San Diego, I believe. We should maybe have a relatively brief strategic discussion about the ideal makeup of Connect content to make sure we get the tire kickers on board. How much of a Hydra overview should there be, what should it cover? How important is it for the tire-kickers to see state-of-the-art demos, or solution bundles, or embedded, stable institutional heads? Content for Managers v Developers? Content for newbies v old hands? This would be good timing ahead of starting on the program for Connect #2.
Is the term "Project Hydra" becoming a hindrance...
...because we're not really a "project" any more (which implies a level of immaturity)? Should we start to transition to something more solid? Hydra Repository System? HydraSoft? ...?
Should we start adding / prioritizing standard "ecosystem" connector functions to the Hydra stack, to make it more powerful and palatable in today's environment?
Vivo represents their project as four things: software, community, ontology and data. We currently position Hydra as two of these. Should we start building in standard connectors and APIs (e.g., ResourceSync, BagIt, IIIF, OAI-PMH, <SHARE Notification>, etc.?) so Hydra adopters are networked data stores accessible via standard methods, and can hook up automagically with big community initiatives like schema.org, LOD, DPLA, DPN, SHARE, IIIF, OAIster, etc.? If so, which connectors are most important? And how would this work technically? And how would it work in terms of resourcing?
Is it time to centralize organizationally?
What are the advantages to Hydra's distributed, decentralized organization structure? What are the disadvantages? As we consider the strategic plan and the tasks before us, are we better served with the current approach, or with some degree of centralization? What kind of project do we want to be in 5 years?
What would Hydra do if it had $?
Specifically here: "what is our policy if a Hydra Connect meeting makes a profit?" which directly ties to "how would Hydra hold $"
" It is increasingly obvious that setting the price for Connect "tickets" is an inexact science and thus organizers will wish to err on the side of caution. The upshot is that future Connects are likely to make a small profit. What are we going to do with the money? (FYI Connect #1 made a small loss which DCE kindly covered.) We are going to find ourselves in the same situation as another organisation well known to us that has accumulated a surplus but, not being a legal entity, can't bank it but has it "held in trust" by a University. Whilst this is a solution it can be an awkward one but at least it protects against accusations of money laundering. We've set our faces against a 501c3 because of the paperwork etc. Have we another solution (we're likely to need one in about six months' time)?
But of course, also, if Hydra had non-trivial amounts of money, what would we want to do with it?
Fleshing out Partners v. Users further
I (Richard) think this is largely addressed by an item in the Strategic Plan to create, and try to maintain, a list of adopters who are not Partners. This has been done. Users get invited to Connect, Partners additionally get invites to Partner meetings and early security notifications and...