Hacker News Reader

Comment by xxpor | Hacker News Reader

I don't understand why dropbox doesn't open source their client. Their business isn't built off of their technology, which, while nice, isn't exactly novel. They make their money from selling storage. Open sourcing their client doesn't change the fundamental fact people need the space to store stuff.

View on HN

From Drew's original YC application [0]:

# Why would your project be hard for someone else to duplicate?

This idea requires executing well in several somewhat orthogonal directions, and missteps in any torpedo the entire product.

For example, there's an academic/theoretical component: designing the protocol and app to behave consistently/recoverably when any power or ethernet cord in the chain could pop out at any time. There's a gross Win32 integration piece (ditto for a Mac port). There's a mostly Linux/Unix-oriented operations/sysadmin and scalability piece. Then there's the web design and UX piece to make things simple and sexy. Most of these hats are pretty different, and if executing in all these directions was easy, a good product/service would already exist.

I'd find it hard to believe that there isn't some very tricky stuff being done in the clients which gives them a big competitive advantage over competitors that pop up.

[0] http://files.dropbox.com/u/2/app.html

Their business isn't built off of their technology, which, while nice, isn't exactly novel.

well, be careful with such claims. many technologies don't seem novel at first glance, but i'm sure there are lots of novel tricks they play under-the-hood to get their system to run quickly and reliably.

e.g., google's pagerank is now well-known and public, but i'm sure that they have lots of 'secret sauce' internal algorithms to make their search index work even better, and they definitely don't want to share those secrets

Showing it doesn't necessarily hurt Dropbox isn't enough. You have to show that it actually helps Dropbox to open-source the client. Otherwise, why should they?

2 things that I can think of immediately

1. Would increase adoption on Linux clients 2. Increased security (the whole security though obscurity doesn't work thing)

Well, I don't think the Linux market is big enough to make it a compelling argument (but I really don't know; I could be dead wrong).

As for security, I'm not sure how big a problem Dropbox has with security. And I would't open-source a client just to get better security for it, but maybe that's just me.

Open sourcing the client is betting on the fact that the client doesn't matter. Maybe it doesn't matter, but maybe it does. More importantly, maybe we think it doesn't matter right now, but we'll find out that we were wrong in 2 years, after it's too late.

Linux as a desktop client is potentially too small a market to address, I'm not sure the same could be said about the Linux server market.

Good point, I hadn't thought of that.

Are people using Dropbox on servers, though? A lot of the benefits of Dropbox don't strike me as helping for servers, for the most part. I don't have too much experience, but it seems to me servers are one place you have to actively manage your backups, and can't rely on the "it just works" philosophy of Dropbox.

I think I'm more likely to pay for a service like Dropbox on the server than on my desktop.

Reliable backups are a big deal on a server, and maybe not as much on the desktop. I mean, I'm not too fussed if my mp3 collection gets stomped by a hard disk failure (I just download it again from emusic), but if tens of thousands of forum and ticket tracker posts are lost, I'm gonna be devastated. And, having it in a shared location that makes it easy to copy the database and website to a development machine might be cool. (I'm kinda talking abstractly here, as my own products provide tools to solve all of these problems in different ways, but they're things I've had problems with in the past. And, if Dropbox had a server product, we'd probably add it as a backup target option.)

Not many are using Dropbox on servers yet, but if their users upload files, they should.

My itty bitty part-time startup has a better uploader than Flickr, thanks to Dropbox on the server. Users share a folder with the server and copy photos into it that they want uploaded. They can be choosing photos to upload even with no connection, e.g. traveling with a laptop.

That's a great idea. I wonder how many people are using Dropbox in this way, i.e. as a framework for sharing things with the server.

I think there's an audio site out there using Dropbox this way. Other than that I haven't heard of it. Maybe when their API includes folder-sharing functionality more people will do it. Right now I manually accept the shared folder request.

I share folders on server with other Dropbox users (developers, designers). For me it's better alternative than webdav, ftp or scp. They work localy and everything syncs between them and to server plus it has some version control.

I would even use it commercially in my products but API lacks ability to share folders. For now you have to do it manually.

Open sourcing the client could mean I run it off my own server, sitting in my apartment, for free. Granted, mostly geeks would be doing that, but I get the impression that many of Dropbox's user base _are_ geeks.

Like someone else said: it's not just whether or not it would HURT Dropbox (though, as I've said, I'd argue it could), but whether or not open-sourcing their clients would actually HELP them. I doubt it would.

I get the impression that many of Dropbox's user base _are_ geeks.

This is not my impression at all. Basically everybody I know uses dropbox, and very few of them are geeks. I was actually introduced to Dropbox by a non-geek boss I had who thought it was the greatest thing she'd ever used and insisted I also get it so we could share files.

Dropbox seems to have done a very good job of penetrating the general market, thanks in no small part to their pretty amazing and minimal UI. It's at the point now where I hear 'normal' people saying things like "can you share it to my dropbox" with the automatic assumption that the other person will know what it means.

I've been involved in a few consumer-oriented file synchronization projects, and I can assure you that the client technology is not at all simple or easy. Consider that all existing applications have no idea that you're changing the semantics of the filesystem, but you have to make them act in a way that makes sense to the end user (not a filesystem expert). Not to mention all the little issues of conflicts, deletion, renaming, crazy stuff that apps do for "atomic save", and on and on.

It's a combination of having to understand app-filesystem interactions as well as user expectations, both of which are largely undocumented and unspoken -- but if you mess with either in the slightest way, somebody will freak out.

> crazy stuff that apps do for "atomic save"

Care for an example?

It's been a while since I worked on this, but if I recall correctly...here's an example: Some Windows apps save by (1) writing a new file, (2) deleting the old file, (3) renaming new to old. The idea is that if it dies in the middle, you don't end up with no complete files. This sequence of events is actually recognized in the Windows filesystem code (if it happens quickly enough) and turned into a file-replace operation, which has very different semantics, particularly the effect of copying the metadata (think extended attributes) from old to new.

Actually the whole question of what to do with "advanced" filesystem semantics (like extended attributes) is pretty hard, especially if you're trying to sync across platforms where those semantics differ. You could just ignore them, but then if an app actually uses them (and why else would they exist?) then the file won't round-trip through the sync platform.

> This sequence of events is actually recognized in the Windows filesystem code.. and turned into a file-replace operation

Woah. I have quite a bit of experience digging through the crap in Windows kernel, but this seems to top all of that. Do you happen to have any references? MSDN, some forum threads, anything? Frankly I just find it hard to believe.

This is documented now, at least for creation times, short names, and file IDs. Apparently the filesystem can choose what to "tunnel" across the delete+rename.

http://support.microsoft.com/kb/172190

http://www.osronline.com/article.cfm?id=22

History: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/15/43926...

Reading... thanks.

If it's open source, anyone can run a "DropBox sever", and charge what they want. This would mean DropBox does all the hardwork and is then undercut by someone else charging less than them.

Dropbox does however have a network effect. One of the big points, at least for me and most dropbox users I know, is sharing folders. That only works if you're on the same server as everybody else is.

Reply on news.ycombinator.com