Fedora Strategic Planning Sub Committee Meeting

Date: Aug 4, 2022

Attendees:

  • Arran Griffith
  • Laurie Arp
  • Tim Shearer (Steering Chair)
  • Jennifer Gilbert (Chair-Elect)
  • Robin Ruggaber
  • Scott Prater
  • Thomas Bernhart
  • Heather Greer-Klein
  • Jared Whiklo
  • Kate Dohe
  • Rosalyn Metz
  • Jon Dunn

Notes from last meeting: https://wiki.lyrasis.org/display/FF/2022-07-07+Strategic+Planning+Meeting

Reminder: We completed the following ITAV Activity: https://wiki.lyrasis.org/display/ITAV/ITAViP+Toolkit%3A+Technology?preview=/225150170/225150507/ITAViP_Tech_P3_ListOfDreams.docx

Idea

Vote

  1. The fedora application would go away entirely and we would rely on the standards it is built on and ocfl-java. Fedora would become a widely adopted specification/standard like IIIF that works with many technologies on either side talking to Fedora. The fedora API would become widely adopted.  It would not be tied specifically to Fedora but instead be spun off as its own specification. Focus on being even more of a black box (plug and play in any repo system) that just works. Double down on API and specs.

8

  1. Fedora deployment and maintenance is possible without heavy developer expertise; "push button" upgrade

6

  1. Integration with digital description and preservation technologies/services- Archivematica, ArchivesSpace, ILS, APTrust,Chronopolis, etc. 

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


TOPICS:

NOTES:

Fedora API already exists

  • Digital preservation services within the broader community are always looking for an API (similar to IIIF)
  • As a community we can pay more attention to the API itself and it’s spec and do more for it
    • API hasn’t changed (much) from 5 - 6
  • Struggle is in getting maintainers/committers because the code is written in java
  • Maybe there is an opportunity to de-couple the API from Fedora itself and Fedora becomes the reference implementation?
    • Wouldn’t change the state of the API but would change the messaging around how it is implemented and works
  • Maybe this is a communication issue
    • Reframing of the community that may need to happen - Fedora community is a gathering of people around an API and there are users of the java implementation
    • Use of the term “reference implementation” has it’s own implications so want to ensure that communication is clear that the java implementation is the current only working one (is this correct??)
  • If we are shifting to the thought of focusing on the API maybe there is an opportunity to generate funding to develop different libraries
  • Active Fedora cautionary tale
  • OCFL is not part of the API


  • Still need to support the current implementation because there are many institutions using it
    • Fedora 6 is written against the Fedora API
    • Would like to see more info on what languages people with developers are working in
  • Google Summer of Code?

If there seems to be need, maybe as we consider Fedora 7 in a different language (RUST etc)

  • Community ask for $$ to make the switch
  • Grant? Funding Agency?
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.