Candidate Features for Fedora 4.x

4.0 Beta (July - December 2013)

Beta must address fundamental set of requirements, including:

• Authorization
• Policy-driven storage and asynchronous storage systems
• Durability
• Performance for large scale ingest
• Auditing
• On-the-fly configuration

During this phase, the project team will also work closely with several early adopter institutions to ensure Fedora 4 supports their needs.

At the end of this phase, the project team should deliver a stable, ready-for-testing Fedora 4 "beta". The beta should implement all core Fedora principles, a near-final REST API, support Hydra and Islandora use cases, support the "80%" use case for Fedora, and have a clear candidate migration path from Fedora 3.

At DLF 2013, the software should be ready for institutions to begin evaluating the software as a replacement for a Fedora 3 install, and provide meaningful feedback about enhancements, consistency, and deployment woes for the next phase of the project. 

4.0 Alpha (January - July 2013)

Select a platform for Fedora 4 development. 

Define Success Criteria for Fedora 4, particularly:

• Robust, modular, minimal Core Fedora.
• Considers the digital preservation/durability interest and balances that against other interests, such as scalability.
• Flexible, Extensible, Durable Architecture is the foundation.
• Able to describe to a CIO why Fedora needs to be a foundational component of the enterprise system.
• Preliminary architectural ideas appropriate to the architectural roadmap for 3.x+4 by the end of June

Develop and validate features around Fedora 3.x pain points, including:

• Horizontal scale-out

• High Availability

• Web-friendly APIs 

At the end of this phase, the project team should deliver an alpha-level prototype of Fedora 4. This prototype should demonstrate the core Fedora 4 principles, API design, and support for the hybrid use case. In addition, Hydra and Islandora should have functional builds that work against the Fedora 4 API. 

At Open Repositories 2013, the software should be in a state that external developers can successfully install the software and provide meaningful feedback about additional user stories and technical requirements for the next phase of the project.

Fedora Futures Requirements Gathering (through December 2012)

Many members of the Fedora community- - both developers and stakeholders - -have expressed a desire to refresh the product's vision, and to produce an evolutionary short- and mid-term development roadmap for the repository. While Fedora's conceptual architecture is proven and still sound, the underlying technology needs to become more responsive to a wide range of current and emerging requirements, more performant and scalable, and capable of advancing in a more agile development framework. The feeling is that this work would require considerably more effort and a different approach than is possible using our current model of volunteer developer contributions led and coordinated by the DuraSpace organization.

At OR12, a group of Fedora stakeholders self-organized to plan some post-conference, informal discussions about "Fedora Futures". That group, encompassing representation from some large institutions, major projects like Hydra, Islandora, APTrust, and eSciDoc, plus DuraSpace, met in September 2013 for an initial conversation to explore these topics.  The outcome was very positive,  the group found a lot of common ground and interest on possible approaches to improving Fedora. 

Initial use cases and user stories that we want to ensure Fedora 4 will be prepared to address were collected at Use Cases. The Phase I team synthesized the collected use cases into a series of user stories for alpha development.

• Hybrid Use Case
  • Policy-controlled storage
  • Repository supports Amazon Glacier, or other asynchronous storage services
  • Use Case: Storing heterogeneous research data
  • Mass Object Creation
  • Scale for High Volume Read Access

These use cases were compared against a set of functional requirements (Fedora 4 Core vs External Functionality), prioritized, and grouped into core, necessary functionality and external services.