In the past decade or so, we've learned to equate the ability to collaborate with the need to be online. The advent of SaaS clearly marked the departure from a decentralized collaboration model to a heavily centralized one. While on the surface this is a very convenient delivery model, it simply doesn't fit a number of scenarios well.

As somebody once said, "you can't FTP to Mars", but we don't need to go as far. There are plenty of use cases here on Earth that are less than perfectly suited for this "online world". Lower power chips and sensors, vessel/offshore collaboration, disaster recovery, remote areas, sporadically reshaping groups—all these make use of central online services a challenge.

Another challenge with centralization is somewhat less thought of—building software that can handle a lot of concurrent users and that stores and processes a lot of information and never goes down is challenging and expensive, and we, as consumers, pay dearly for that effort.

And not least important, software in the cloud removes our ability to adapt it perfectly for use cases beyond its owner's vision, scope and profitability considerations. Convenience isn't free, and this goes way beyond the price tag.

SIT is a free, open-source project that addresses these and other concerns in software that enables us to collaborate. It allows sporadically connected parties to continue collaborating seamlessly, over just about any digital transport (ranging from a P2P network to a USB drive). At its core, it's a very small tool that records every change as an immutable, additive-only set of files and allows this information to be displayed and operated on in a familiar way, though browser-based applications or the command line.

Figure 1. SIT Issue Tracker

Although its foundation is rather generic, its first real application is in issue tracking, and it enables a lot of scenarios that were previously rather difficult to achieve. For example, if a SIT repository is committed to a project repository, this allows you to see a snapshot of all issues for any revision, making it much easier to maintain separate versions or trace changes. Another interesting feature is its merge request functionality, where a patch, by its nature, can contain file changes that affect a project's issues, giving enormous flexibility in managing dependent issues (say you developed a feature and want to attach a "to-do" list to it as a part of the patch, so those new issues will appear only once the patch has been merged—with SIT this is a rather trivial task).

SIT is still a young project, and there are still a lot of cases to figure out. It's quite interesting to see how so many assumptions are being challenged once we remove the central party from the equation.

To learn more about SIT visit https://sit.fyi/.