2019-2020 Technical Roadmap
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
2017-2018 Technical Roadmap
| Expand |
|---|
Formalize the core Fedora services Application Programming Interface (API)This priority is to clearly define the core services that Fedora promises as a standards-based RESTful API, accompany this API with any necessary domain-specific ontologies, and provide a compatibility test suite. Outstanding issues can be found on GitHub. Align the current Fedora implementation with the API specificationOnce the API specification is complete, the current Fedora implementation will need to be updated to fully align with the specification. This work will result in a 5.x Fedora release based on our move to semantic versioning. Support alternate Fedora implementationsOne of the goals of the API specification is to allow the community to experiment with different back-end Fedora implementations to address different use cases. We will support and encourage community members as they experiment along these lines. |
2016-2017 Technical Roadmap
| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
|
2015-2016 Technical Roadmap
| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Previous Technical Roadmap Items
| Expand |
|---|
| Info |
|---|
See here for continuing discussion of the more immediate priority focus. |
...
|
| Integrations | Core | Non-core | Alpha | Use Cases | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hydra Integration | x | x |
| ||||||||||||||
| Islandora Integration | x | 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.
...
|