Applications and data are usually tightly coupled: the format, structure, and meaning of data are almost inseparable from the application generating and using them, hindering data portability between disparate applications. Sharing data between applications entails mastering complex and proprietary APIs or export formats, and transforming output data into the necessary structure and meaning for use elsewhere. These are time-consuming and error-prone things to do.
Federation is a way to free up information from the silos of proprietary software, linking different systems together so they are 'connected, but sovereign', and so users can regain control of the data in them, and share them more easily between systems.
This Federated Task-Tracking project builds on the foundation laid in its precursor Federated Timesheets project, which successfully pioneered this approach for time-tracking data such that timesheet data entered into one system are easily made available in others. Its more generalised approach applies to a broader range of real-world scenarios, including live collaborative editing of latency-critical data shared between the systems involved.
Federation aims to provide a technical mechanism to address this misalignment of interests between commercial software vendors and users regarding control of data in their software.
There are many different scenarios making federation useful. The categories below aim to capture these, together with some real-world examples.
Federating these instances makes it possible to share data between them in a read-write fashion.
This project includes an implementation of federation between two different instances of the Tiki issue-tracker.
Federation can achieve the same goal, with the approach depending greatly on how much influence or control you have over the systems involved. The practical guide to system federation included with this project describes what to evaluate, and how to approach federation in different contexts.
The exemplar implementation in this project federates Tiki Tracker with GitHub, using BridgeBot as a proxy for the latter. See the Accessing Federation Demos for details of how this is set up.
See System Sovereignty vs. Real-Time Sharing in the Federation Guide for a deeper understanding of this.
Wherever it is possible to make changes to the same data in multiple places, conflicts are likely to occur. The project examines a variety of approaches to handling conflicts.
See the practical guide to system federation to learn how to do this.
For details of the project's original plan and structure, see the NGI Assure proposal.