|
The Year in Review -- 15 minutes (9:45)
Goals for 2016 -- 1 hour (10:00)
incl Developer Commitment
Membership drive & expansion — Strategy Discussion -- 30 min (11:30)
Meetings: what Fedora-related conferences and events will happen in 2016? -- 30 min (12:00)
Training: Assessment, next plans -- 20 min
Vendor strategy: how can we get service providers into the ecosystem -- 15 min
Budget Review -- 20 min
Feedback to DuraSpace on Membership Billing -- 10 min
Fedora Leaders: Building & Keeping Group Momentum -- 20 min
Fedora website -- 20 min
Clarify Fedora’s relationship to other projects (that rely on it). E.g. Hydra in a box includes Fedora. Implications for funding and marketing.
“Year of upgrations?”
Gap analysis with longitudinal visualization to show adoption over time?
Focus not on upgrations but rather on Fedora 4 new successes?
Is there a way to bring clarity to the “kinds” of reference implementations? That focus could play out in several ways (development, marketing, use case matching).
2014-> 2015
63 -> 76 members (15 new members, 2 lost members)
$525k -> $560k (includes $115k in new funding, $80k in lost revenue from previous members)
Mostly North American.
How do we get to 100 members?
Market expansion (new geographic regions, new domains--like museums)
Need to emphasize breadth of members in communications
Have consciously tried to expand number of members at all levels; diversification of risk
Migration involves more than just Fedora
Content, front-end, data models, etc.
Maybe we need a migration-focused workshop?
Roadmap of maturity levels of dependencies (PCDM, Hydra, Islandora, etc.)
Migrations tend to be multi-year projects
Support for Hydra/Fedora 3 is fading
Maybe migrating apps like Avalon to Fedora 4 jointly would help provide stepping stones
We need to get more Fedora 4 into Hydra sprints (attending meetings, working on Fedora 4 tickets, etc.)
Fedora is an architecture. Its main benefit is set of services rather than an implementation in code.
Fedora provides 5 services aligned with broad community standards (e.g. W3C) as part of its API contract.
CRUD, using LDP
Authz, using WebAC
Fixity (checking of…)
Versioning (looking at convergence with Memento)
Transactions (some debate about this one)
Related issues...
scalability
performance
preservation
Andrew asserts;
we have consensus on these 5 API functions, more or less
we should push the development to get these done sooner rather than later
we should invest in a set of tests of the API specs
Benefits:
aligning with standards allows for potential increase in adoption -- future looking web standards
this opens up Fedora to a much broader world of those who are interested in linked data, but not necessarily in the world of repositories.
people who want an LDP store
people who want versioning
akin to IIIF (APIs, not software)
allows for multiple implementations. isolates users from implementations.
this raises branding and identity issues
what is Fedora? a layer, not a repo
are these the right 5 services? and...
how does this relate to API-X effort
invoke services
modeling digital objects
storage & lower level implementations
what does this mean for digital preservation?
another reference implementation. can we find one.
Goal of 100 members
⅓ of new members are from new markets
Suggestions
Establish regional shepherds
Northeast has not been fully explored
Helpful to have an idea of what the ideal spread across membership levels
Strategies
matching funds for new members
target new markets and sectors (museums, govt, Europe, South America, Africa, ...)
Europe
Events:
PASIG - Neil J. F4 presentation
IDCC - Neil J. and Aaron C. F4 workshop
OR2016
Digital Humanities -
F4 leaders-driven meeting focused on European expansion
D.C.
Events: what are the best events?
DC FUG - can inform strategy for getting sector engagement
Museums
We have feature and maintenance sprints
Most people aren’t interested in fixing bugs
Some of the bugs are trickier and take a lot of skill and understanding of Fedora to tackle
We need consistent involvement - bugs in the queue should be tackled within a reasonable amount of time
Possible solutions
Schedule a big developer sprint with lots of buy-in
Make bug-fixing a part of the developer training