These uses aren’t surprising to Jack Dorsey, the Odeo engineer who proposed Twitter to Williams in 2006. Dorsey, now Twitter’s CEO, had always been fascinated with real-time communications and dispatching systems–the kind that send taxis around cities and ensure that ambulances quickly arrive at the right place. “Back in February of 2006, we were having a bunch of conversations about how to change Odeo into something that we loved,” he recalls. “We wanted something a little bit different. Texting was getting big, and in a meeting I brought up the idea of Twitter. It was the simplest thing we could do: send what you’re doing to your friends, and that was it. Everyone started thinking about that, and a week later Evan gave me the go-ahead to build a prototype.”
Just like Blogger, Twitter was a simple communications product salvaged from the impending implosion of a more complex project. In both cases, Williams didn’t really know what he was doing. With both ventures, his genius–if that is the word–derived from what the English poet John Keats, in a letter to his brothers, called “negative capability”: “that is when man is capable of being in uncertainties, Mysteries, doubts without any irritable reaching after fact & reason.”
With the help of another engineer, Dorsey built the basics of Twitter in about two weeks, using a popular Web programming framework called Ruby on Rails. At Twitter’s core is a simple messaging distribution machine that is, in the jargon of communications, “device agnostic.” After a twitterer composes a 140-character update and clicks a button on a Web page, in an instant-messaging program, or on a cell phone, the tweet is almost instantaneously routed to the people who have elected to receive it. They in turn will read the message on the Web, with an instant-messaging program, or on a cell phone, according to their preferences.
Crucial to Twitter’s popularity was the release in September 2006 of its application programming interface, or API, which allows outside programmers to build applications that plug into the company’s information infrastructure. Once the API was available, geeks everywhere started to create innovative Twitter tools. “A ton of our usage is through our API,” says Williams. And the API is relatively simple: “It’s not the most powerful development framework, but it’s encouraged a ton of people to play with it. This means that a ton of interfaces and tools were built and plugged into Twitter because of that simplicity.”
Among the tools that third-party developers have built are desktop interfaces. An example is Twitterrific, a downloadable program for Macs, which makes twitters pop up on the Mac OS desktop and then fade into the background. Another way people have tapped into Twitter’s code is by redisplaying the public posts in interesting ways: in a program called Twittervision, for example, a globe displays twitters as they are posted all around the world. It is the diverting spectacle of the human race (or at least that part of it that twitters) talking to itself. Bots–automated program–can also post twitters with content extracted from some information feed. There are news and weather bots, and little programs that update users with earthquake information from the U.S. Geological Survey.
By letting programmers build twittering tools that appeal to a broad range of people, Twitter has gained many more users. And this could be just the beginning. “Another way to look at it is as a platform for device-agnostic real-time messaging,” Williams says. “And that has broader implications. People have contacted us about emergency broadcasting systems. We like the idea, but we’re not anywhere near saying that we want to be counted on for that.” For emergency use, Twitter would need to be reliable, a goal that seems elusive. This past summer saw many Twitter outages, both planned and unscheduled, and it’s not uncommon to have a twitter or two dropped.