The release roadmap for OODT aims to provide cutting edge features in data archiving, cataloging, search, and retrieval for science, business, and beyond, and all as free, open source software.

This release roadmap attempts to formally define what the OODT project hopes to achieve, however, as an open source project, decisions are made by the OODT team combined with input from the open source community at large. Therefore, these plans are subject to change.

Future Releases

Current plan:

The current plan was incepted and discussed on list after a public telecon announced to all PMC members and flushed back to the list for discussion and eventual decisions. Some of the below road map are in process, others are still being thought of.

• Stability to the codebase. Tests must pass before we can reliably move forward. This is especially troublesome since there are new features we do want to implement, yet our confidence level of not breaking existing function is low since the tests just don't work.
• Upgrade OODT's outdated components. A number of parts within OODT has ossified and become brittle (XML parsing, for example). As the (mainly Java) ecosystem has matured, these components have not, and they continue to be "software hangnails".
• End-to-end story-driven testing. While we'd love to see more and more unit testing, complete integration testing is also vital. OODT is a large and complex system, and ensuring all the parts work in a story-driven manner is important.
• Changing 5 to 10 config files to get OODT just to work is terrible. And worse, they're largely XML configuration files. OODT needs to get-up-and-go out-of-the-box.
• Documentation and website movement to Apache CMS-based tech. The static nature of the OODT website is a barrier to updates. We'd like for updates to frequent and timely.
• Make OODT more of a product, less of an architecture. It's difficult for new users to approach OODT since it's presented mainly as a software architecture that has some software. If we could change it into a product (by providing sensible defaults, IoC, etc.) it could have a lower barrier of entry.
• Remove PHP. OODT requires a Java servlet container for its core function, so why bring in yet another technology for the Balance components? This increases the exploitable surface of an OODT server as well as making adoption of OODT trickier.
• XML specification and/or schema so you can know what can be where. For these XML configuration files, the lack of a schema means it's difficult to tell what elements and attributes go where, which are required, which are optional, etc. With a schema (and an XML-aware editor) this becomes easier to do—and gives validation-before-run as a bonus.
• Where and what are the extension points? This needs to be clearly documented and highlighted.
• Tutorials are static and don't allow for community updates. We need them on the wiki instead so everyone can help. Leave a "getting started" tutorial on the main website, but move everything else to the Apache Confluence wiki.
• Put Jenkins build status on the OODT website!
• Videos (screencasts). But keep them upbeat. Edit them carefully so users aren't watching slow typists backspacing over mistakes repeatedly.
• Regular release cycle. Four times a year. This gives "liveness" to the project, but also gives confidence to new users knowing that a certain bug or new feature will be addressed in an upcoming release.
• Report list subscription numbers in board reports, not # of messages. This is a more interesting metric since it demonstrates the breadth of OODT adoption, which is orthogonal to the amount of discussion which can be dominated by one or two members.
• Release version 0.8 before ApacheCon NA in April 2015.

Current Releases

0.7
We have released Apache OODT 0.7 and it can be downloaded here (direct link) or from our Downloads page.