Keeping stakeholders updated with development progress is vital, but can be a difficult to thing to get right. Not only is development of large projects complex, particularly when they span across multiple libraries, but trying to communicate the nuances of development to an audience of varying technical ability is not without its challenges.

When pulling together the latest version of the SAFE Network roadmap, which can be found here, we wanted to show how all the libraries fit together, but also try to do so it in such a way that the deliverables at each stage of release are clear. For example, as you will see we are nearing the release of Dev Bundle 1 which will provide each users with:

Cross Platform (Windows, OSX, Linux) desktop Installers

Network (Crust, Routing and Vaults), running on external nodes

Remote client access and account creation

Simple vaults — LAN only

Initial Farming Rate data storage mechanism

Communication through TCP

NFS REST API exposing persistent remote storage

This means that third party developers will have access to a stable API that they can use to store data on a Local Area Network, a network that users can access via remote clients using TCP.

Dev Bundle 2 will see a significant number of new features added, such as: test safecoin, enhancements to our transport layer with UTP and the commencement of UI based applications. As we continue to iterate through each new release, we will add these to the rolling development roadmap. Please keep referring back at regular intervals to check progress, and for those looking for detailed updates we would recommend continuing to read our weekly dev update posts on the forum, as well as monitoring our Jira dashboard during development sprints (we have currently just finished a sprint and are about to get back into planning, hence the finished status of the current dash board).

It is worth noting at this point that the object of each new release will not necessarily be to add new features to the network. Some will be to improve the efficiency of the code base while reducing technical debt as we move forward.

The roadmap will be made interactive in the coming days, providing overviews, explaining the purpose of each library, while also providing direct links to the example applications for each. The different approach (in comparison to the last version) used when compiling this roadmap marks MaidSafe’s move to a much more modular development approach, reducing the coupling of components and dependencies where possible. This is to enable non specific SAFE Network libraries to be picked up and easily used by other projects.

Those that read our weekly development updates will also know that we have appointed primary and secondary maintainers for each library so that third party developers know where to go should they have specific questions. Each maintainer is listed at the top of the appropriate GitHub readme. This change allows knowledge transfer to accelerate from David to the MaidSafe engineers. Each library maintainer (and secondary maintainer) are now responsible for that library (or module) and this accountability and responsibility allows the engineers to grow and develop each part of the network. We anticipate this will allow for much greater community participation while also enabling a pace of development that has, until relatively recently, eluded us.

So hopefully this roadmap achieves what it set out to do; provide a snapshot and high level summary of our progress, articulate our delivery and ongoing plans, while showing how each of the network components come together to make something much greater than the sum of their parts.