The remaining question (posed in the top-rated answer) is: Why didn't anyone else build Dropbox first?
At the risk of shameless karma whoring, I hypothesize that the problem had to be attacked by a company of the correct size. Most bigger companies can't build Dropbox because to release a product like Dropbox one has to run a gauntlet of middle managers, and it's hard to get a roomful of software professionals to sign on to something that (a) is difficult to build and requires a lot of painstaking attention to detail, yet (b) can be described in three sentences.
It's just hard to talk about a simple, elegant mission in those ubiquitous meetings. People ask how the project is going, and you have three things you can say:
A) "No, the folder doesn't sync yet."
B) "Yes, the folder syncs."
C) "No, the folder doesn't sync because of this particular small issue with this obscure API call in this obscure library on this obscure version of Linux blah blah blah TECH TECH TECH yes I'm so sorry too much detail I will shut up now."
So pretty much all you can do is smile serenely. This is a big strategic disadvantage. Even a medium-sized company features multiple projects. The projects fight for resources: people, budget, management attention. They may fight in a very friendly and even above-board way, the way siblings fight for attention, but they do fight. And the project that tacks on more and more requirements gets to claim more and more resources, because, hey, requirements are hard! Bigger checklists require bigger teams, and bigger teams require bigger budgets, and more management attention. Add features! Attach a marketing campaign! Bolt it on to a much larger brand!
I need to go read Parkinson's Law again. A work of genius.
Anyway, Dropbox succeeded by designing a company where the mission of "building Dropbox and making it succeed" was both necessary and sufficient.
At the risk of shameless karma whoring, I hypothesize that the problem had to be attacked by a company of the correct size. Most bigger companies can't build Dropbox because to release a product like Dropbox one has to run a gauntlet of middle managers, and it's hard to get a roomful of software professionals to sign on to something that (a) is difficult to build and requires a lot of painstaking attention to detail, yet (b) can be described in three sentences.
It's just hard to talk about a simple, elegant mission in those ubiquitous meetings. People ask how the project is going, and you have three things you can say:
A) "No, the folder doesn't sync yet."
B) "Yes, the folder syncs."
C) "No, the folder doesn't sync because of this particular small issue with this obscure API call in this obscure library on this obscure version of Linux blah blah blah TECH TECH TECH yes I'm so sorry too much detail I will shut up now."
So pretty much all you can do is smile serenely. This is a big strategic disadvantage. Even a medium-sized company features multiple projects. The projects fight for resources: people, budget, management attention. They may fight in a very friendly and even above-board way, the way siblings fight for attention, but they do fight. And the project that tacks on more and more requirements gets to claim more and more resources, because, hey, requirements are hard! Bigger checklists require bigger teams, and bigger teams require bigger budgets, and more management attention. Add features! Attach a marketing campaign! Bolt it on to a much larger brand!
I need to go read Parkinson's Law again. A work of genius.
Anyway, Dropbox succeeded by designing a company where the mission of "building Dropbox and making it succeed" was both necessary and sufficient.