This is an idea proposed in 2022 as a Cambridge Computer Science Part II project, and has been completed by Samuel Wedgwood. It was supervised by Anil Madhavapeddy as part of the Information Flow for Trusted Execution project.
In 2005, due to licensing disputes, the team behind Linux parted ways with their proprietary source management tool BitKeeper, and needed a new solution. This prompted the development of Git, an open-source decentralised version control system (DVCS), which was soon used to manage the source code of Linux. Contributions were submitted as patch files, which contained just the differences that the contribution made, to an email list, which were reviewed and applied to the central Git repository for Linux.
Git grew in popularity and other projects started using it to manage their source code. Then, in 2008, the GitHub.com platform launched, providing Git repository hosting alongside other project management tools. Notably, GitHub facilitates "pull requests", where contributors fork the repository, make changes to their fork, and then request that their changes be merged back into the central repository. As of 2023, GitHub hosts over 364 million repositories and is the most popular version control platform for both personal and professional use, followed by GitLab and BitBucket, which are all centralised version control platforms (CVCPs).
Git is decentralised by design, meaning that repository mirrors are easily made and maintained, and development and collaboration can continue even when central servers experience downtime or data loss. However, the project management tools that are provided by CVCPs are not decentralised, meaning downtime can grind many parts of development to a halt, and data loss could set projects back months.
This project demonstrates that project management tools, such as
contribution-tracking, do not need to be centralised, siloed, or proprietary,
but can instead be de-centralised, open-source, interoperable, and redundant;
so that developers can more time developing. It does this by routing collaboration
requests (such as patch exchange) over the Matrix communications protocol rather
than a centralised service. When developers wish to synchronise, they create
a Matrix channel on a variety of federated servers. When they wish to discuss
a patch, they use the messaging facilities in Matrix to revise changes. Finally,
patches can be applied directly to a remote repository by creating a modified
version of git-send-email to work with the Matrix protocol.
The dissertation PDF isn't available publically but should be in the Cambridge Computer Lab archives somewhere or on request from Samuel Wedgwood.