I think user experience can and will be duplicated. I did post a link to an SVN front-end that has a very similar interface. Maybe the competitors are locked-in to some bad design decisions and can't quite recreate the same user experience... but that's a little optimistic.
Anyway you slice it, you need to have a profit margin. And with a commodity like storage (and the soon-to-be commodity of online storage), you have to be competitve with market prices. The reason that most YC startups can worry about user adoption is because they aren't tied down to this problem. They aren't really making commodities and the cost of makign the product isn't so suffocating.
That's why Dropbox needs to plan for moving off S3. There is so much innovation in storage backends... so much research to read. Think of Google Filesystem. It makes storage very very very cheap.
Here's a good plan for Dropbox. Use S3 as a secondary solution. The primary storage should be local to them (servers running a filesystem that takes advantage of unique properties of the workload... like Google does). When it fills up, traffic thereafter is handled by S3 instead. Then, they can relax in worrying about and scaling local storage. They can take their time buying more hardware, and rolling out software changes to the storage system. They can migrate the data from S3 to local storage at will. And now, their customers can be charged a flexible price, because they control their own expenses. In other words, think of S3 as "datacenter outsourcing".
But this might be too long-term... it might be something to worry about post-YC.
But I think it might be easy to build a storage implementation that runs local and exposes the same exact interface as S3. And, poof, we just abstract the whole backend away, and just flip a switch when we want to go one way or the other. And it reduces latency. Then you go after zero-downtime data migration from S3 to your local systems... which can be done I think... and I think you would be happy.
I'm going to respond to my own post, and add that... for the initial phase where you don't expect to make money... you have chosen a great setup. S3 is a robust , reliable, and easy way to handle the intial ramp up should hoards of users sign up, a concern I raised in another post. You probably have plans to get onto your own backend in the long-run.
It's a pretty crowded space. And XDrive gets you 5 GB for free, 50 GB for $9.95 a month. I can't expect Dropbox to charge those prices, given S3 as a backend. The margin just isn't really there, especially given the number of uses that will want free storage. And I think competitors can duplicate Dropbox's nice front end. In fact, here's an open source front end to SVN which is similar to Dropbox's:
Sorry for all the negativity, I guess I'm trying to play devil's advocate here. It's a wonderful product you got going there, but I think you will have to work really hard.
$0.15 per GB-Month of storage used.
$0.20 per GB of data transferred.
So, that means Dropbox is going to have to resell S3 at a premium for the added value of these nice Coda-like features. Would you pay a premium for these Dropbox features? Maybe, I don't know.
Also, what's the typical use case? How much bandwidth/storage are people going to consume? Because, if I store 100 megabytes... my bill will pennies every month (going on S3 prices). You cannot transact pennies per user per month. If you could, then you've cracked the micropayments problem wide open. Maybe there would be a base fee? Like $5/month or something. Would people pay that much for online storage?
I don't know how other revenue generation models can be applied. Advertising? Selling a user's data to other businesses? (What's the privacy policy?)
How are you going to scale up your storage to meet the demands of the users? Are you doing something clever, like Google Filesystem? This is not an easy problem, if you aren't prepared for it in advance. If 10,000 users sign up tomorrow... you might be very very hosed, as opposed to very very happy.
Anyway you slice it, you need to have a profit margin. And with a commodity like storage (and the soon-to-be commodity of online storage), you have to be competitve with market prices. The reason that most YC startups can worry about user adoption is because they aren't tied down to this problem. They aren't really making commodities and the cost of makign the product isn't so suffocating.
That's why Dropbox needs to plan for moving off S3. There is so much innovation in storage backends... so much research to read. Think of Google Filesystem. It makes storage very very very cheap.
Here's a good plan for Dropbox. Use S3 as a secondary solution. The primary storage should be local to them (servers running a filesystem that takes advantage of unique properties of the workload... like Google does). When it fills up, traffic thereafter is handled by S3 instead. Then, they can relax in worrying about and scaling local storage. They can take their time buying more hardware, and rolling out software changes to the storage system. They can migrate the data from S3 to local storage at will. And now, their customers can be charged a flexible price, because they control their own expenses. In other words, think of S3 as "datacenter outsourcing".
But this might be too long-term... it might be something to worry about post-YC.
But I think it might be easy to build a storage implementation that runs local and exposes the same exact interface as S3. And, poof, we just abstract the whole backend away, and just flip a switch when we want to go one way or the other. And it reduces latency. Then you go after zero-downtime data migration from S3 to your local systems... which can be done I think... and I think you would be happy.