I was also a bit annoyed not to be able to share things in RO, but after using it for a couple of days, their approach is actually interesting. If a new file is created/modified on the "Master" node, it will automatically be transferred to the "Slave" nodes, even if some files have been deleted on these nodes. This is the exact same behavior than BTSync. But the advantage of this "Overwrite" button is that at any time, your Master node can simply overwrite any modification or deletion which was made on the Slave nodes. I find this approach more robust than the RO option in BTSync, which works well as long as you only delete files in your slave nodes. That gives you some control on the content of Slave nodes; with BTSync, if a file is not transferred for some reason, there is nothing you can do. However, this approach works if you have only one Master node, i.e. you cannot share a folder in RW with some peers and RO with other peers. There are of course other drawbacks to Syncthing: - more CPU consuming than BTSync (causing a drop of transfer speed especially on LAN) - encryption mandatory even in LAN - transfer of the complete file index at each connection - folder label used to identify uniquely a share (will be modified in the future) - no encrypted nodes - Golang less efficient than other languages such as C/C++ Still, this is a good alternative but maybe not yet fully ready for production. However, I don't think BTSync 1.4, is ready for production as well. You can consider charging only upgrade to "major" versions. That's what a lot of softwares are doing: you pay once, you receive bug fixing for free (e.g. Service Packs in Windows), but you need to pay to upgrade to a new version (e.g. Windows 7 to 8). The approach of a recurring payment is a bit odd since you have absolutely no idea of the new features which will be brought on a regular basis to BTSync. In the end, maybe you will end up with a recurrent payment for a software which does not evolve.