You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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 last week 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.

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.

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 

4.0 Beta (July - December 2013)

  1. Beta must address fundamental set of requirements

4.0 Final (January - July 2014)

A stable, robust and scalable platform for repository development, with a clear and well-defined migration path from Fedora 3.x to Fedora 4.0.

  • No labels