What was Syncthing picked over the many alternatives?
Context
Please see: Files vs web pages. In the context of WikiSuite, we already have two other software components that manage files
- ClearOS Flexshare, which provides a standard file server, with three interfaces: 1- Web (HTTP/HTTPS) 2- FTP (FTP/FTPS) 3- File Shares (Samba)
- However it has the weaknesses of standard files and folders: no meta data, file needs to be in only one folder, or it's duplicated, hard to segment permissions, etc.
- Tiki File Galleries, which provide virtual folders and sub-folders which are web accessible. This abstraction layer permits multiple features: archives (previous versions of a file can still be accessed), check-in / check-out / lock, etc. and it leverages Tiki's multitude of built-in features: search (including file content), share secret link to file via email, permissions, etc. It's even possible to use as a field type in Tiki Trackers, a powerful and flexible database, form and report creator.
- However, it has the weakness that the only reliable interface is the web interface
By using each tool when it's appropriate, we have a good solution for most use cases. However, file sync was missing. An extensive analysis of all available Free / Libre / Open Source software was conducted, and Syncthing was deemed the best component to complete the feature set.
Beyond satisfying the usual component criteria, Syncthing's P2P design is awesome.
Why not ownCloud / Nextcloud
- This would have been easier since there was already an app for ClearOS but:
- Way too much overlap between Tiki Wiki CMS Groupware and ownCloud / Nextcloud. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
- The server and clients are different code bases, which is bigger long term workload.
- Can't do P2P sync. Everything needs to go via central server.
Why not Seafile
- Seafile is an interesting project but
- Way too much overlap between Tiki Wiki CMS Groupware and Seafile. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
- The server and clients are different code bases, which is bigger long term workload.
- Can't do P2P sync. Everything needs to go via central server.
Why not Pydio
- Pydio is an interesting project but
- Way too much overlap between Tiki Wiki CMS Groupware and Pydio. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
- The server and clients are different code bases, which is bigger long term workload.
- Can't do P2P sync. Everything needs to go via central server.
Why not SparkleShare
- SparkleShare is an interesting project but
- Way too much overlap between Tiki Wiki CMS Groupware and SparkleShare. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
- It's based on Git whereas Syncthing uses the Block Exchange Protocol which is more suited for this use case
- Can't do P2P sync. Everything needs to go via central server.
Why not LinShare
- LinShare is an interesting project but it is for file sharing and not file sync. File sharing is covered by Tiki file galleries
Why not Rsync
Rsync is to sync 2 directories. There is no 3 way sync and it can't deal with device discovery like Syncthing can,
Why not Unison
Unison is an interesting option, but compared to Syncthing:
- No Android support
- No device discovery
https://github.com/bcpierce00/unison
See also