> it shouldn't take Apple/Microsoft/Google/Amazon too much work to put out a comparable product and offer it for free
I worked on SkyDrive/OneDrive for a few years. That's what we thought too. This stuff inevitably starts out with "seriously, how long is it going to take to make essentially a wrapper around rsync" and ends up with "Hey, guess what happens when you cross filesystem errors with distributed systems errors when dealing with unmergeable files?"
This is a deceptively challenging space, particularly if you want to do sharing and group work in a reasonably intuitive way. Which is why Dropbox has managed to remain a company instead of simply being eaten up the first quarter that appl/ms/google decided to get into this business. Note that all three have an offering, and at this point I know that OneDrive is actually pretty good, but for years it was kind of an uphill catchup struggle.
I am curious, why would you go into the project thinking rsync and not git? It seemed to me most of these syncing folders are really a special case of source code control.
I wasn't involved in these design discussions early on, and Skydrive certainly didn't use rsync, this was just meant as an example of "this is essentially a solved problem, we just need some UI". It isn't, and presenting it as such just gets you into a bad situation.
But Dropbox doesn't handle any merging of changes; any conflicts are left for the user to resolve. In this way it's basically an automatic version of Unison, which is exactly "some UI" around a "solved problem." Right?
It doesn't handle merging of changes within files, however, if you take a step back, consider that you're essentially merging lists of metadata (with hashes of blobs), not just uploading these blobs; and because the systems that need to be synced are distributed, not always connected, and users want to read/write all of them you get the limitations of the classic CAP theorem.
E.g. the quite feasible scenario with two computers, both partially synced, and both getting files changed/added/removed/moved while the sync is happening. Consider applications creating temporary files while a document is being edited, and expecting to be able to create those files... and then it results in some app being unable to open the same document because it's "already open" on another machine. There are all kinds of interesting conflicts and race conditions possible, and you need to resolve them all in some way that doesn't weird out the users.
Stock git explodes when dealing with binary files that are above a certain size or are changing frequently.
So forget about photo collections, shared Photoshop files, or any other non-text document formats.
The workarounds had a lot of pain points for a while (that maybe are fixed now in 2017, haven't explored that recently).
I was more thinking the concept of source code control than the specific, but used a specific since a specific file transfer program was mentioned. Some source code control programs handle binaries just fine.
I worked on SkyDrive/OneDrive for a few years. That's what we thought too. This stuff inevitably starts out with "seriously, how long is it going to take to make essentially a wrapper around rsync" and ends up with "Hey, guess what happens when you cross filesystem errors with distributed systems errors when dealing with unmergeable files?"
This is a deceptively challenging space, particularly if you want to do sharing and group work in a reasonably intuitive way. Which is why Dropbox has managed to remain a company instead of simply being eaten up the first quarter that appl/ms/google decided to get into this business. Note that all three have an offering, and at this point I know that OneDrive is actually pretty good, but for years it was kind of an uphill catchup struggle.