Fedora Strategic Planning Sub Committee Meeting
Date: July 7, 2022
Attendees:
- Arran Griffith
Laurie ArpTim Shearer (Steering Chair)Jennifer Gilbert (Chair-Elect)- Robin Ruggaber
- Scott Prater
Thomas Bernhart- Heather Greer-Klein
- Jared Whiklo
- Kate Dohe
Rosalyn Metz- Jon Dunn
ITAV Facet: Technology
ITAV Activity: https://wiki.lyrasis.org/display/ITAV/ITAViP+Toolkit%3A+Technology?preview=/225150170/225150507/ITAViP_Tech_P3_ListOfDreams.docx
To Do:
- Re-word, and formalize the #1 objective (10 mins)
- Take top 3 ideas and research what it skills it would actually take to accomplish it (30 mins)
- Group 1: Scott, Jon, Jennifer (List of Dreams - Group 1)
- Group 2: Jared, Thomas, Rosy (https://docs.google.com/document/d/1o6caqQm2N0EvUoTDffnSfFUshqSb4___z8nIXdSUmjg/edit?usp=sharing)
- Group 3: Kate, Tim, Robin (https://docs.google.com/document/d/1AxjcWlO3p-SJvV3W3FSqDUEK98AYioWdBZ8y6AvrKn4/edit?usp=sharing)
- Take inventory of what skills are lacking to accomplish these things (15 mins)
- How can we recruit these skills into the community?
Idea | Vote |
| 8 |
| 6 |
| 4 |
Fedora could scale horizontally (sharded repositories, managed by a load -balancing, parallel processing capable main repo) | 4 |
Fedora would have a robust one-click install front end UI, "lite" interface that is separate from the core, but built by fedora for those who don't use or can't afford samvera, islandora, or a "fat client" local development effort | 4 |
Fedora would support high-latency (i.e. tape) storage, possibly through an S3 gateway, to enable large digital preservation use cases | 4 |
Fedora would be written to support/facilitate international adoption Multi-lingual support | 3 |
Fedora would support "side-loading" ingest mechanism for content moved directly into underlying storage (maybe someone will tell me this is already possible!) | 3 |
Make a Fedora admin UI; Fedora would provide easy access to usage and storage analytics/metrics via a dashboard and API | 3 |
Fedora would include standard deployment models for common environments, e.g. AWS, Kubernetes, etc. (maybe this is already true??) | 3 |
default behaviors/configurations that are easy to understand and adopt (while keeping the ability to configure pretty robustly for those who can dig in). Maybe a "performant" setting, a "preservation" setting, etc. | 2 |
Fedora would be tested/certified with a variety of cloud and on-premise underlying storage systems | 2 |
Relevant installation information gathering to meet privacy requirements globally | 2 |
The fedora application would be in a programming language that is more accessible to the library community. | 2 |
Fedora standards implementation remains flexible to local implementations - can opt in to LDP, or out, for example. Fedora would not be bound to the LDP (Linked Data Platform) specification | 1 |
Move to PREMIS 3 ontology | 1 |
Keep fedora current in terms of technology (I'm happy with the current feature set of Fedora) | 1 |
Fedora supports multitenant implementations | 0 |
Fedora could replace DSpace as a self-submit institutional repository system | 0 |
pre-built expression for indexing/harvesting (e.g. google) | 0 |
Fedora's admin UI meets WCAG standards | 0 |
redefine Fedora away from a piece of software, middleware | 0 |
Replace the WebAC access control (partial) specification with something...better | 0 |
Fedora embraces ethical source principles | 0 |
Apache mod_fedora plugin to integrate Apache seamlessly with Fedora | 0 |
Ability to (within the spirit of privacy, not just the law) centralize data that informs decision making (size, version, etc) | 0 |
Notes:
"Dream #1" - Overarching theme: Fedora as an API
- Idea of Fedora application “going away” - is it just that LYRASIS/Fedora program would no longer continue to exist but it would still be available within the community?
- Overhead would decrease considerably by dropping the application and devoting ourselves only to the API
- Would we just then be working ourselves out of existence
- What does Fedora offer that is compelling, that distinguishes itself from similar efforts met by other applications, standards? (OCFL, Islandora, Samvera)
- Things we need to think about - what is Fedora’s purpose or value in this new ever changing environment
- Where do we fit?
- With OCFL we know that there are institutions implementing OCFL without Fedora, so what value can Fedora offer
- Is there clear enough messaging around why you need Fedora running and what is the value of having it in the stack?
Consider Top reasons to use Fedora:
- Preservation value
- API enables you to bundle metadata and bitsreams together in to objects
- Flexibility & Data modelling
- Migration to pure OCFL seems overwhelming
- Access controls, indexing, camel toolbox and add ons that make workflow easier - may not get this from an API or persistence layer
- Managing complexity at scale
- Historical tie to the program/software - outlasted a lot of other products - “Permanence”
- If I migrate to something else, will I have to then migrate again to something new?
- Community and resources, while small, is enough to warrant staying with the program instead of trying to roll your own
- Most installations that we know of running Fedora or Fedora 3 are smaller institutions who aren't interested in API solely or don’t have the resources to run it as only as an API
- Should start considering how community can be more involved in the development cycles of partner communities like Islandora/Samvera
- Samvera Connect - presentation on migration paths or why an institution would want to consider moving to Fedora 6 (Suggestion from Heather about ways we can reach in to the Samvera Community)
- Based on the above Top Reasons to Use Fedora, what can we do better at?:
- Use at scale (UMD scaling issue)
- S3 is a problem for OCFL
- S3 performance is below on-disc performance
- Could be related to the way files have to move in OCFL causing delays (at current state, looks like this may be the only answer)
- Need to look for someone with more experience developing with the S3 client
- Put call out to the community to try and gather user stories or user need to deal with this
- Special topic Tech Meeting
- Horizontal scaling - (ex. kubernetes connectors)