Photo of a pig race

Dropbox Problem : Beware ! The Toy may be Lightyears ahead

Recently it seems to me everybody and their dog is solving “The Dropbox Problem”. I am tired of reading about it – unless you clearly state what this means for you and how your solution addresses the problem. The word “solution” suggests to me you have come up with something ready to replace Dropbox in the enterprise – providing similar functionality, without restrictions in scope and addressing enterprise concerns on top. All tools I have tried failed when replication and sync come into play.

Definition of “Dropbox Problem”

Richard Esplin of Alfresco says:

“The Dropbox problem” is the name we give to the risks associated with using a consumer oriented storage service in an Enterprise setting.

This gives a fairly good business perspective explanation of the trouble raised by Dropbox. The key here is that most of Dropbox functionality was originally built with only one user – a consumer – in mind. Hence, there were no worries regarding ownership, responsibility, security, collaboration, processes and the like – frequent concerns in an enterprise environment.

People love Dropbox for its ease of use. Naturally, tackling the enterprise concerns opens another can of worms and introduces a new bunch of challenges. As a consequence, any solution will expose the user with additional complexity. So even if you master these challenges technically, a whole lot of care has to be taken in order not to fail acceptance from Dropbox spoiled users. Good luck with this one – seriously.

Understanding the Dropbox Solution

Before coming up with an alternative solution you should make sure to understand the very real problems Dropbox itself solves. At its core, it provides fool proof two way synchronization of files allowing connected devices to even go offline. It is this machinery solving the business problems for people : Collaboration on files.

This two way synchronization makes Drobpox applicable for a very broad range of scenarios. Assume for example you are forced to collaborate on large files using very low bandwidth. This most likely forces you to bake replication in. Can your solution help in this case or in cases where offline use of files is a must ?

How does your approach support two way synchronization and how does it deal with conflicting changes ? Do you handle them gracefully ?

All “two way sync solutions” I have tried have failed miserably for me. They did not come close and I would not dare to suggest them to anybody. Actually this was not unexpected. Look at what Dropbox does under the covers. It is not as easy as one might expect – leave alone delta sync.

Still, I would be more than happy if somebody could point me to an easy to use alternative covering the two way sync situation.

References

Andreas Steffan
Pragmatic ? Scientist and DevOps Mind @ Contentreich. Believes in Open Source, the Open Web and Linux. Freelancing in DevOps-, Cloud-, Kubernetes, JVM- and Contentland and speaks Clojure, Kotlin, Groovy, Go, Python, JavaScript, Java, Alfresco and WordPress. Built infrastructure before it was cool. ❤️ Emacs.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert