To do list: https://docs.google.com/document/d/13WdMkwzyyvSpzfMwV-XIJP5VAENsXWoKOqM7LCGDoaU/edit
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.
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:
"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:
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)?
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.
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.
The Strategic Planning for Hydra page and its associated Progress against the 2013 Strategic Action Plan are woefully out of date. Two aspects (at least) require review:
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.
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.
...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? ...?
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?
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?
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...