Hacker News new | ask | show | jobs
by arendtio 2767 days ago
Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).

In addition, some parts of the Dropbox sync client are open source too: https://www.dropbox.com/de/help/desktop-web/linux-commands#b...

Sure if your business model depends on selling the software then open sourcing it might be a bad idea. But if you are selling software to other companies they most likely are not interested in the software but in the service you provide, so they will require Service Level Agreements which should be the base of your business model.

However, with consumer software that doesn't work very well, since nobody gives a about service levels (even if it would solve many of their problems) ;-)

5 comments

For one, delta-sync was built into the Dropbox client from the very beginning, and I'm getting the impression from this thread that Nextcloud still doesn't have it till this day: https://github.com/nextcloud/server/issues/417

This is a major contributor to sync UX, and by no means trivial to implement.

Another example is their file stubs implementation (Project Infinite) that works across platforms, which is also no small engineering feat, that afaik no other sync software has been able to replicate yet (OneDrive has this on Windows, but no other platforms).

The Dropbox client makes just about every other sync client look like toy projects in terms of technical sophistication, reliability, and general UX. There's a reason why they're so successful. And I say this as someone who doesn't even use Dropbox on a day to day basis (I use Syncthing as my daily driver).

This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.

> This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.

In fact, I added that I never used Dropbox to give context on my perspective. I am not sure that qualifies as 'flaunting that ignorance'.

Regarding the delta-sync feature: That is, in fact, a feature neither Nextcloud nor Owncloud posses at the moment. On the other hand, it would not be that beneficial to my use-cases since I rarely have large files within my synced folders and most of the time I have a GBit connection to my Nextcloud. So I guess I am missing not that much (at least with my current usage pattern).

Granted, for some use-cases, it is essential and bringing such a feature to all major platforms is not a trivial task. Yet I still wonder if protecting the implementation is necessary since the comments in the Nextcloud issue suggest that the primary problem the availability of the developer is (who might have an easier job if he could take a look at the Dropbox code, but ultimately he would have to write an implementation that integrates with his project).

And ultimately I wonder what makes people decide which service they want to use. For many people, it sure is the little friction you encounter during the setup of Dropbox. For me, it is not that much about the features of the client software but about the features of the larger system. Being able to host my own server is essential to me. Having an open source implementation is a nice add-on, which I value and made use of already. AFAIK those features are not available with Dropbox I seriously doubt my previous comment qualifies as flaunting ignorance.

The only thing keeping me in Dropbox is the fact that I use several very important apps (one of which is an encrypted password vault) across very different OS-es -- think iOS, Android, Windows and macOS.

They offer transparent syncing so all your app instances work with the same data and sadly trying to get the developers of the apps to include self-hosted solutions (with added configuration step: the IP/port) is not happening and isn't likely to happen.

And both Apple and Google aren't open to the idea of allowing cross-ecosystem app synchronization (think game you play for an hour on your iPad but then want to play it on your specialized gaming Android device when you are out and about later; in the case of games this problem is solved by using Google or Facebook as login providers on all your devices). And until that's true then Dropbox and other popular cloud storage providers (mainly Google Drive and OneDrive) will always have a place.

LOL! I had given OP some credit and assumed that Nextcloud was a full featured competitor like Box. Whoops!
Dropbox Nautilus Extension is open source because it has to be - GNOME Files is licensed under GNU LGPL. The amount of code in that extension is minimal, the proprietary Dropbox client pretty much does all processing, the extension is only responsible for displaying icons in a file manager.
How about you use it before assertively making claims about it. Just a good practice for life.
Well, for one thing, the dropbox client has never seen fit to randomly delete my local folders, which is kind of a bad thing for a sync client to do.

As in, failing at the one thing the app is supposed to be doing...

> Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).

Writing a simple file sync utility isn't difficult, hell you could just wrap rsync and you'd be half way there. Making that open source is easy and low risk, because you haven't really invented anything.

On the other hand, if you can throw 100 developers at the problem, you'll come up with something _far_ beyond the simple case. Sure it might only be 50% faster? But that 50% makes your product "magic" when compared with other tools. This is where you get things like Project Infinite (https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...). I can imagine there are some very complex optimisations for the multitude of configurations that Dropbox runs on, that I can understand a company wanting to keep "secret" if it's so core to their business.

I think you'd be surprised at the depth to which these companies are solving problems.

> In order to innovate on the user’s experience of the file system, as we are with Project Infinite, we need to catch file operation events on Dropbox files before other applications try to act on those files. [therefore we need a kernel driver]

You can block the operation within fuse's userspace part while calling out to some helper gui program to ask for confirmation. Seems like an excuse rather than a reason to implement stuff in the kernel.