In early 2009, just months after Drew Houston and Arash Ferdowsi launched Dropbox, a service that promised to sync users’ photos, music, and documents across computers, Apple’s MobileMe team suggested the pair come by for a chat. The two MIT-schooled twenty-somethings knew they were in for some discussion about how their little startup was competing with the computing giant, but they were not prepared for what was first off the block:

How did you get in there?

The question was about Dropbox’s integration into the Finder — something Houston and Ferdowsi accomplished by hacking their way in. In order to get highlighted text to accompany a file that had been updated within Dropbox, the founders had to break into the Finder’s processing server and insert their own code.

But despite the breach, the Apple inquiry wasn’t an aggressive interrogation. It was actually an honest inquiry. Even though Apple’s Finder team was working under the same roof for the same company, MobileMe was refused access. Houston’s response came with a smile: “Yeah, it’s kind of hard to do.”

“We had to solve a lot of pretty tough technical problems,” recounts Ferdowsi. Houston is a little more emphatic: “We had to reverse engineer without source code — basically open heart surgery on the Finder to discover the assembly language routine that draws icons — and then squeeze in our little icon. You have to do similar but different things on Tiger, on Leopard, on Snow Leopard, on Lion, thirty-two bit, sixty-four bit — every presentation. It is exhausting.”

From the very beginning, the founders of Dropbox knew they needed to tackle a set of massively complicated problems — problems that had flummoxed computer scientists for four decades and complicated the lives of computer users for as long as they’d had access to more than one workstation. Getting a set of files on one computer to match the files on another seems, on the surface, to be a simple enough task. But actually accomplishing it means scaling an established list of academic thought problems and rabbit hole engineering challenges.

For starters, how do you get files to look and act the same on platforms that don’t want to work together? Then, how do you make sure all copies of the same file are identical if multiple people are working on it simultaneously? What if there’s no internet? How do you get access to files in the cloud when you’re not connected to it? And even once you’ve scaled those significant hurdles, how do you tuck away all that hard work and make the experience nearly invisible for the user?

In just a year and a half of late-night coding in crappy apartments and small, smelly offices, Houston and Ferdowsi had checked off the whole list. By collecting and tweaking existing solutions to a disparate range of computing problems, they created a package that could be bundled into a clean and lean release. The result is a service that has gained 45 million users since its September 2008 launch, providing a solution for people that didn’t even realize there was an alternative to packing thumb drives and e-mailing files to oneself.

But Dropbox’s success is now at a critical moment. Providing a way to give users access to everything they do on a computer from everywhere has become the brass ring for digital services. And Dropbox is the one to beat. After years of remaining largely below the radar of the world’s biggest computing companies, Dropbox is now faced with a host of very prominent competitors. The most immediate, of course, is Apple, whose iCloud service launched in October.

iCloud hits Dropbox hard on the simplicity and ease of use fronts because Apple has been working in this space from the beginning. iCloud may be cross platform averse, but its automatic syncing slices seconds from Dropbox’s drag-and-drop approach. And then there’s mounting competition from a whole slew of young companies also willing to give up sleep and a social life for a piece of Dropbox’s $4 billion valuation.

Dropbox can credit its success to a lot of hard work, certainly, but Houston and Ferdowsi also stepped into the game at a crucial moment. Houston started coding his software on a bus from Boston to New York in November of 2006. Just two months later Steve Jobs announced the iPad, a device that would put a computer in the hands people never tempted by a smart phone before. For those who already worked from both a home and a work computer, the iPhone made three. Today over a third of American adults own a smartphone, according to Pew Internet — a number that will only get bigger.

Other things fell into place, too. By the fall of 2008, almost every major computer manufacturer had a netbook on the market for $400 or less. Smartphones made thumb drives an inadequate solution, and e-mail wasn’t set up for the kind of heavy lifting the new computing landscape required. Benjamin Pierce, a computer scientist at the University of Pennsylvania explains, “The need for replication technology has gotten absolutely urgent.”

Dropbox found a wide audience just beginning to understand that they required something better. Dropbox snagged 70,000 signups overnight when they posted a video demo to Digg in March 2008. “Arash and I were sitting across from each other doing database queries, and there were hundreds of people signing up per minute,” says Houston. “We watched it hit the front page of Digg. Then the top 10. We were thinking, holy shit, what did we do here?”

By their launch six months later, they had 100,000 users had signed up. What had happened was that the first wave started sharing Dropbox files with their coworkers, friends, and family, hooking an extended network into the service. Almost immediately, those who didn’t actively search out the solution outnumbered early adopters.

Growth continued to ramp up exponentially. Fifteen months later they had 4 million registered, and 15 after that they had 25 million.

The users had declared a solution.

Drew Houston was running around Cambridge with two years of startup sweat stored on a thumb drive in his pocket. It was 3 gigabytes’ worth of planning and architecture and strategy for an SAT prep service that he started while he was still a computer science student at MIT. It was late nights of reading how-to books on the roof of his fraternity and early mornings coding in his boxers with a friend in the then-Cambridge-based Y Combinator.

Once he’d almost left it at Starbucks. Another time he yanked it from his pocket to find that he’d bent the connector. If it weren’t for a flash of panic as he approached the door or a careful bit of manual coaxing, all his work would have vanished with the integrity of the object itself. He was in a precarious situation — basically one spin in the washing machine away from losing his company.

It was a particularly vexing situation for Houston because it was a new one. While at MIT, his stuff was always available to him through Athena, the campus’s so-called distributed computing system. All he had to do was log in to any connected workstation (his own included) and every one of his papers and proofs would be there waiting for him. No loading files onto an external thingamabob or e-mailing documents to himself, MIT’s goddess of wisdom promised take care of his.

But with a cap and a diploma in 2006, his access to everything from everywhere was gone. Even though Athena was sprouted from a system developed 20 years prior at Carnegie Mellon, it was tied to an institution — and one he was no longer a part of. While Houston was at MIT he had cobbled together some code that would handle his backup needs, but the quick fix wasn’t sturdy enough to handle, by this point, years of his work. His best option became physically hauling files from one location to another on a plastic and metal stick — a string tied around the finger as a reminder that there should be a better way.

Fed up with the burden, Houston did what most of us would have done. He Googled it. What he found was a grab bag of semi-solutions. “There were the backup guys. There were other services that let you upload files to a website. There were other tools to sync things across your computers. There were other tools to share files or send big files. What do people use for this? It’s a hundred different things.” And none met his fledgling company’s needs.

At the same time Houston was getting antsy for another reason; despite taking a year off from MIT to work on his SAT prep service and then taking it on like a second full-time job after he graduated, the startup was lacking traction. Y Combinator wasn’t interested in funding it. And that friend that he was coding with into the wee hours of the morning? “He got his startup further off the ground in four months than I had in a couple of years.”

Houston’s earliest memory of job lust was wanting to own a business. He had been coding since he was five. Perhaps, he thought, he could hack his way out of the problem.

In the spring of 2007, after three months of intense focus and fervent coding, Houston submitted his second application to Y Combinator. But there was only one problem: He didn’t have a co-founder — a mandatory requirement for gaining entry to the boot camp and funding that would surely follow.

Unbeknown to Houston, a third-year at MIT named Arash Ferdowsi was also antsy to put his coding skills to work on something big. A good friend of his named Kyle Vogt had recently quit MIT, moved to California, and was having tons of success with a video streaming service called Justin.tv. Justin.tv was covered in the San Francisco Chronicle and invited onto the Today show. Meanwhile Ferdowsi was sitting in his MIT dorm room taking a distracted stab at a problem set and wondering what the hell he was doing there.

Cloud-like software trickled to market in the ’90s and 2000s, but these tools failed because they were either too complicated to use, tied to a single platform, or both

Ferdowsi wanted to get into the details of what happens when services break big — shooting up to tens or hundreds of millions of users. “I was fascinated by the scale that Facebook was operating at, and similarly the things that Kyle was doing at Justin.tv.” So he filled schedule with classes about the database management and “making things like attributed systems work well.” He’d also lined up an internship at the world’s largest social network for the summer after his junior year.

Houston was also watching Vogt’s impressive Silicon Valley climb. The two had met a couple of years earlier in an entrepreneur club on campus. When word got out that Houston was in need of a partner, Vogt connected the dots. Houston brought the initial idea, a mockup of the service, and the business experience, and Ferdowsi had the desire and interest in the backend to tackle a problem of scale that had eluded services past.

The match took, and the pair walked into their Y Combinator interview only having met for the first time two weeks prior.

The interview was a slam dunk, largely because Houston’s application to the program had laid out a strikingly clear vision for what Dropbox would become — an all-in-one synchronization, backup and collaboration tool that “just works.” In fact, it’s now the stuff of tech entrepreneur lore, one of the folded and coffee-stained printouts that young founders pin to cheap bulletin boards.

Y Combinator’s 2007 demo day delivered Dropbox $1.2 million in funding. Ferdowsi dropped out of MIT with only one semester left until graduation. Now with money and time, the hard work began. They had to find a solution to a problem that had resisted one for decades.

In 1982, a computer science professor at Carnegie Mellon University named Jim Morris wrote a manifesto about connectivity and collaboration. “The primary goal,” he wrote, “should be to broaden, deepen, and improve the communication among students.” The way to do that was to create a computing environment where information could be shared. So together with IBM, Morris set out to create the kind of network at Carnegie Mellon he predicted would be ubiquitous in the future. By tethering $3,000 workstations together with IBM’s state-of-the-art wiring, Morris created the Andrew Project, and within it the Andrew File System, or AFS. AFS was the first safe and efficient distributed computing system, available to both students and professors on campus.

It was a clear precursor to the Dropbox-like software packages today. First, it was a big step toward getting your files to be everywhere at once. Though files were stored on central servers, AFS created the illusion for the user that they were local. The first time a workstation wanted access to an AFS file, the computer would go fetch it from the server. But once retrieved, the computer would cache the file on its local disk, so the next time someone wanted to pull it up from that location, the file would be available locally.

Still, a decade later, students complained that the system was too slow. Part of the problem was that files were sent from server to client and back to the server whole. Every time a file needed updating, even if only a single word had changed, the entire document was re-sent — and sent over a maddeningly slow Ethernet connection. By 1996, Carnegie Mellon had figured that sending only relevant chunks back and forth would save time and bandwidth, but communication speeds had yet to make that change truly valuable.

There were also issues with the way the Andrew File System got along with the software. AFS rendered some Unix applications, like the mail delivery system Sendmail, unreliable. The computer’s applications “were not written in the expectation that basic file system operations or close system calls could fail,” wrote Nathaniel Borenstein, one of Andrew’s principle designers. And when they did fail, the programs couldn’t rebound.

Nonetheless, AFS made massive leaps in distributed computing. Over the course of its 30 years, it was tweaked and streamlined and revamped a hundred times over. MIT picked it up for its distributed computing network not long after AFS got up and running. MIT’s version, called Athena, allowed students (like Drew Houston and Arash Ferdowsi) access to all their stuff from any connected computer.

Good for those institutions, but not for the rest of us. Until recently, distributed computer clusters have huddled around a central server managed by an organization. Companies and universities maintained their own server space and dedicated IT team to manage it. That works well internally, but getting files to a machine outside the network turned basic computing into a key-fob initiated, slow-motion train wreck.

Decade depending, the floppy disk, CD or thumb drive were tasked with picking up the slack. They didn’t provide the most elegant fix, but they were an effective way to port data from one station to the next. But for figuring out what version of a document was last updated and by whom, you were on your own.

University-led programs like the Coda File System out of Carnegie Mellon in 1987 aimed for something not so dependent on a single organization. Because Coda was open source, it could be pushed beyond the work of a single design team. Coda was kind with bandwidth before broadband made the client-to-server connection easier, and it was also generous with offline access, providing cached copies of files when the Internet was out of reach. When disagreements between files occurred — a problem that has such deep roots it took a half-hour conversation with Mahadev Satyanarayanan, Coda’s project lead, to explain — issues were mediated with a set of application-specific plug-ins, some acrobatic hand waving, and, ultimately, some damage control that looped in the user.

But in the end, Coda was never commercialized. It wasn’t a light piece of software that could be sent to the masses. It required substantial work on the users’ part to get up and running. Satyanarayanan admits the system is “complex both to implement and for the user to think about.” And besides, his job is to lay out a high level proof of concept, not to dig into gritty startup details.

Still, the average computer user was left without an effective way of getting their work from one computer to the next. Software finally aimed at that audience finally trickled to market in the ’90s and 2000s, but these tools failed because they were either too complicated to use, tied to a single platform, or both.

Unison, a manual syncing tool developed by Benjamin Pierce at the University of Pennsylvania, was one of the first cross-platform services. “Unison goes through an enormous amount of trouble to do the right thing cross platform,” explains Pierce, “but it’s extremely hard.” The difficulty showed in the software’s interactions with the operating systems. And it didn’t function in the background, quietly coordinating matching files. If you wanted the software to do its job, you had to prod it to do so. Unison, though on somewhere between 100,000 and a million computers, still needed to be more user friendly to edge out the humble thumb drive.

Commercial applications even five years ago showed some serious character flaws. Halfhearted attempts by Apple and Microsoft refused to cooperate with other operating systems, so Mac users at home who sat at a PC at work were out of luck. And issues with reliability and accessibility blocked widespread adoption.

Other programs were just too clunky and slow to be worth the effort. Backup programs like XDrive, was not able to cross the space from client to server gracefully. Their systems transferred data chunk by chunk every time you needed it — something akin to moving across country by driving one box across at a time. The application’s protocols — the way the computer talked to the server — were caught off guard by this coast-to-coast trip. The sluggish pace tripped up operating systems not expecting the lag.

A handful of issues made the user experience, in all cases, unbearable. It was high time for someone to swoop in and do syncing right.

Pages:12 View All