Dropbox introduces new API features
blog.dropbox.com
blog.dropbox.com
Assuming that the "1 billion" refers to number of sync events, that statistic implies that on average, Dropbox users only make changes to ~6 files in their Dropbox per day.
That doesn't make any sense at all. Dropbox must have a massive Power Law at work.
EDIT: I might be wrong with my interpretation of "files synced": it could mean distinct numbers of files that receive a sync event atleast once per day or files added per day to a Dropbox which are then synced. In both cases, I believe the ~6/day statistic and I apologize.
I store my IM logs in my Dropbox. Every time a message is sent, 2 files are changed (the message log and the overall database). One conversation alone can fire 100 sync events.
And if you're like me and are a Ctrl+S addict when working on important papers or code, each Ctrl+S is a sync event.
That’s also more or less the default for Dropbox, that’s how it’s set up and guides its users. It’s just some folder in your user folder, not even the documents folder. By default you have to actively think to put stuff in there.
I think you might just have a wrong picture of who uses Dropbox. Storing IM conversations or even all of your documents on there is quite esoteric.
Also, if you think of a typical home computer of someone who has a job then there aren’t going to be many files on that thing. A few letters to cancel something or other (but even that is done mostly by email these days), photos, videos and maybe some music (but many people don’t put that in their Dropbox because there is just no space) … that’s not much. You don’t need to create files to go to Facebook or read the news or get weather info or watch the stocks (minus Facebook that’s exactly the stuff my dad does on the family laptop and I installed Dropbox on both PCs in their house to keep their rarely changed documents folder in sync).
Yeah, students probably have more documents but I have even seen those only use Dropbox for collaborative stuff – not all the rest they do.
It’s not that those people don’t get value from Dropbox or don’t use it, they just don’t need it that often.
Although if the behavior that you describe is the typical user behavior, then that's not a good thing for Dropbox's attempts to convert free users to paying users.
I believe it. Maybe I'm an outlier, but I usually only write to a few files from Dropbox in any given day. I read those files often, but I rarely write unless I'm doing something like uploading pictures from my camera.
Now, there's nothing in that which justifies having a developer conference. I definitely do not understand that. But the Dropbox service itself deserves the praise it gets.
I only got dropbox installed on my PC because we needed to exchange some files with an external contractor that only used Dropbox.
As soon as the project was finished I removed it from my PC.
I love the idea of cloud apps that use user-provided datastores. It makes it both cheaper for a startup (because they can crowdsource their data storage) and easier for users to control what data services have about them. Google Drive already provides a service whereby I can store a user's data in his Drive account without cluttering his filesystem with my app's metadata. Dropbox Datastores sounds like a similar feature, but it's way less appealing to me if I can't talk to it from my backend.
I look forward to kicking the tires, since I've been looking for a solid replacement for Parse ever since Facebook bought them.
From my .Net developer's point of view, I am not seeing why these aren't just weak versions of the Azure storage capabilities or Amazon's S3. It's nice to be able to target DropBox as a storage location but that's a pretty rare use-case for me. Especially since their security store is incomplete.
Of course, this is assuming you weren't using a database (even a NoSQL DB) and simply updating the changed fields, which is probably how you'd realistically handle this situation.
EDIT:
Taking a closer look, it seems like the Datastore API is more of a way to synchronize multiple databases/stores (in essence). One stored locally on a phone (that can be changed, in their example, in airplane mode), one in the cloud, and one on the desktop, or anywhere else your app runs with the Datastore integration. While there are relatively simple ways to locally queue changes made while offline, and then sync them up to a master database in the cloud when the network comes back, Dropbox's Datastore seems to do this for you without you having to worry about it.
https://www.dropbox.com/developers/datastore/tutorial/ios#co...
They have a few naive conflict resolution rules that you can choose from. The granularity is per field. They do have an option that attempts to be smart about array-valued fields.
Isn't it a platform on a platform at that point?
Dropbox has done a phenomenal job of taking a complex challenge (file sync) and making an incredibly simple user experience. Extending that strategy into other common tasks with new and purchased apps could be very successful. The big element missing is BaaS (back-end as a service) for data and events that aren't files. Given the poor track record of services like iCloud, you can imagine a lot of developers adopting the Dropbox API and in a few years most iOS devices might be running a combination of official Dropbox apps (replacements for itunes, mail, and maybe calendar) and many other essentially stateless apps that use the Dropbox API for sync and storage.
In the short term this could be very convenient for users and developers, but in the long run it creates another monolithic, centralized platform. This kind of functionality needs to be delivered as a protocol so users can choose service providers who compete on price, features, and privacy instead of being citizens of a particular platform (Facebook, Apple, Google, MSFT, or increasingly Dropbox).
How would this benefit dropbox?
- Their proprietary BaaS benefits them by consolidating all user data on their service and creates a greater incentive for users to upgrade to paying (or higher priced) plans.
- Alternatively, structuring this as a portocol (as we've tried to do with Tent https://tent.io) benefits the entire ecosystem. It's a little like asking how the web would benefit AOL. Protocols can bust monopolies but increase the overall value of an ecosystem. You might go from controlling 50% of n to controlling 10% of 20*n. Open ecosystems can encourage innovation in ways that centralized services can't, often to the benefit of the centralized players.