Want to Recruit Better Engineers? Open Source Your Code

Re:Want to Recruit Better Engineers? Open Source Your Code by danpalmer on Tuesday November 20, 2018 @06:18AM (#18493053)

> 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.

[ Parent | on HN ]

Re:Want to Recruit Better Engineers? Open Source Your Code by megous on Tuesday November 20, 2018 @07:06AM (#18493223)

> 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.

[ Parent | on HN ]