Why we are integrating with Box; Part 4: The Dropbox Option

Kerika, Technology, ,

(The fourth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

As we noted in our last post, our initial preference was to add Dropbox as our second cloud platform. We had personal experience of using Dropbox ourselves, mostly to synch files across multiple personal computers and devices, and to a much more limited experience we had tried using it for collaborating with partners, mostly to share large graphics and video files.

(Particularly in the early days of Google Drive, there were limits on file sizes we would bump against, and high-resolution video files can easily be very large.)

By itself Dropbox doesn’t really provide any collaboration features: there is no contextual overlay on it, like Kerika provides on top of Google Drive.  The best use-case for Dropbox is still that envisioned by Drew Houston’s original mockup video: if you use multiple computers a regular basis, e.g. a desktop and a laptop, and you need to make sure your working files are always available on all these machines.

(The key phrase here is “working files”: using Dropbox as a “system of record” — for files that have been finalized, frozen or otherwise are in an archived state — seems less useful.  Archived files can very quickly grow in size to hundreds of gigabytes, making Dropbox a prohibitively expensive solution.)

To learn more about Dropbox, we began by attending their DBX conference in San Francisco last summer.

DBX turned out to be a startlingly extravagant affair — it made us feel quite the country bumpkins since we can’t envision any Seattle-area startup spending so lavishly on a single day’s conference!  But, it was also an excellent opportunity to meet some of their engineers particularly from their Platform Team, and to understand better Dropbox’s API and product direction.

We immediately ran into a major hurdle: it appeared that Dropbox’s API offered no way for third-party apps to create and manage nested folders.

We didn’t get discouraged immediately, since we did have an opportunity to talk to folks from their platform team.

We put together a detailed presentation on why it made sense for Dropbox to extend their API; and we supplemented this with a mockup video showing exactly how this could result in a great integration of Kerika+Dropbox, similar to what we had achieved with Kerika+GoogleDrive.

(This video hasn’t been released publicly.)

Some folks in the Dropbox platform team were clearly interested in what we presented, and felt that it presented an interesting direction for the platform to take, in order to be more competitive in the enterprise space. However, it was clear that the Dropbox API product roadmap was full up for the foreseeable future, and we were unlikely to find the platform capabilities in Dropbox that we were looking for.

It was disappointing, but not a show-stopper for us: while considering the technical strategy for a Kerika+Dropbox integration, we had also been sounding out some of current and prospective customers to see how enthusiastically they would welcome such a product, and we were getting mixed feedback: on a personal level, most folks liked Dropbox, but at an enterprise level there was much less enthusiasm.

Part of the problem may have been simply perception: Dropbox was viewed very much as a consumer product, and enterprise IT may have reflexively dismissed it as lacking in security, enterprise management, etc.

We did, however, find that some of these folks were suggesting we consider a different platform as an alternative to Google Drive: Box…

The full series: