Jack Dorsey, the man behind Twitter, first thought of the service as quick way to connect humans with each other. He did not think of it as a way to connect virtual pets. But in early 2008, it was Tamagotchi that accounted for about 30 percent of Twitter traffic. That’s right: real people were signing up their virtual pets for actual Twitter pages. Dorsey took notice, and the Japanese version of the service launched that April. Twitter, the company, is based in San Francisco, but Japan is arguably Twitter’s second home. Japanese is the second most used language on the service.

Of course, virtual pets are not the only reason for Twitter’s Japanese success. Japan’s famously adventurous mobile phone users have also contributed, helping make Japan a test bed for new Twitter ideas. A country full of adventurous Twitter users would seem like a good place for developers to create new Twitter applications. Kevin Makice thinks so, too. He told the Tamagotchi story in his book, Twitter API: Up and Running: Learn How to Build Applications with the Twitter API (O'Reilly Media, 2009). Makice argues that the best people to write new Twitter applications are not necessarily full-time developers, but active members of the Twitter community who see a good idea worth pursuing. Web site developers, who are often in a good position to see how people interact online, are most definitely qualified. Makice’s book is addressed to casual programmers who want to try.

By some estimates, there are already more than 50,000 Twitter applications created by third-party developers. Twitter has done its part here by not competing with them. The company’s unadorned website leaves developers plenty of opportunities for innovation. Twitter was also smart enough early on to provide an API, the essential toolkit for anyone building a Twitter application. It’s perhaps not a coincidence that the only company Twitter has acquired did not make applications, but an API for searching?which Twitter now offers directly to developers. Makice writes that Twitter’s decision to open up the service to third-party development was “⁠brilliant⁠”⁠ and a key to the company’s early success. He calls the API simple and well-conceived, opening the door to new developers with good ideas. In turn, new Twitter users have signed on because some application has made the service more meaningful or accessible. Makice predicts that for Twitter, the company, 2010 will be the year of developer.

Makice is working on a PhD. at the Indiana University School of Informatics, focusing on how technologies can connect people in what must now be called “⁠physical communities⁠”⁠ (as opposed to the virtual ones). Twitter, of course, is a part of that.

Yours is the first book on the Twitter API. How did you come to write it?

I had been using Twitter since early 2007 when my wife and kids went away to the beach for spring break. She wasn’t going to have Internet access, but she did have a cell phone, which she set up to tweet through the text. So I was getting some hands-on experience on how Twitter can connect people. Meanwhile, a couple of publishers approached one of my professors, Jeff Bardzell, to write about Twitter. He had written about Adobe Macromedia and Flash, but was now focused on his research. So he recommended me.

The Twitter API is a tool for application development. What role have applications played in Twitter’s popularity?

Twitter wouldn’t be Twitter without the application ecosystem. I would probably not be using Twitter, even today, if I had to go to the Twitter website for it. I first used an early program, Twitterific, because it brought tweets to me, rather than forcing me to go out and get them. That mattered even when my wife and I were communicating that spring break. Now, of course, there are other desktop clients that have that function and more. Which you choose is a matter of personal preference and working habits. These days, I use Tweetie, but I’m also looking at Qfeeder, which is still in beta. I like that it’s going to be more contextual in the way that it notifies you and summarizes the conversation.

What should website developers consider in using the Twitter API?

The first step for developers is to find an unfulfilled need that can really benefit the community?or create an application that helps expand Twitter’s base by bringing in new people. In other words, they should consider how the Twitter ecosystem works?and how they can improve it. A lot has been done, but there are still plenty of niches that can be addressed.

How much development activity is going on?

In the second half of 2009, the number of applications more than tripled. There are so many applications that we are now seeing tools to help people sort through them. For example, one website, oneforty, was created by Laura Fitton, author of Twitter for Dummies, and resembles the iPhone App Store, only for Twitter applications. They’ve got more than 2,000 apps registered. They take a cut of the payment, allow people to post reviews, and make it easy for developers to monetize their work. For new developers, this is also nice resource to see what’s already out there. But even if the idea has been done, you might still have a better one. I’ve noticed that there’s a limited life cycle for some of these applications. They come and go.

In your book, you list several categories of Twitter applications, including publishing, search, and aggregation statistics. Where are the opportunities?

I’m surprised that there hasn’t been more done with Avatar pictures for profiles. The API now shows you changes in profile information, including the profile picture. So I thought for sure there would be a whole suite of applications around managing your picture. But that didn’t happen. Last spring, I worked with a local business on an idea of allowing you to change your picture based on kind of tweet you were posting, or on your mood, or even on the time of day?so you could have a different picture depending on whether you were at work or home. Since then, a new application, Moody Tweets, has surfaced that does some of that. I haven’t seen any other application that comes as close.

Another gap is in having a tool directory for developers. For example, there are a number of libraries to help you integrate your chosen programming language with the API. But programmers can’t always find them?even though there’s a list on the API’s wiki site. Developers need something friendlier. There’s also a need to create mentoring relationships, so that people with a lot of experience with the API can help newer programmers. I’m encouraged by the initiative Twitter announced at LeWeb last December to put the ecosystem front and center in their organization plans. Ryan Sarver announced a number of plans, including an official developers conference in March and an online site devoted to this very problem. That doesn’t mean third party developers can’t help support that effort through their own projects.

There’s also a need for better analysis. The Twitter API supports a number of methods that show basic statistics: the number of followers, the number of updates, and the number of people you follow. These were the stats most applications focused on early in the ecosystem growth, but they only give part of the picture, especially in terms of determining value. You can’t really say that somebody with a large network is more important, or is even getting a better experience, than someone with a smaller network. The smaller network may be more focused and more meaningful. I’d like to see more variety in the way tools interpret Twitter data to better reflect the actual value people are receiving. A lot of this may come from focusing on local groups or some other subset of the entire network.

So there’s a need for a “second generation” of statistics with more sophisticated analysis.

Right?people are looking for information that is less obvious. The traditional way of evaluating what one site calls “⁠your global significance⁠”⁠ is to value things like retweeting. Even before Twitter institutionalized it, a lot of people had concluded that the ultimate goal of Twitter is influence: which means to get your tweets retweeted. Retweeting is nice because you are sharing information with large networks of people, but that’s not going to be appropriate for everyone. You may be valuable in a narrower sphere of interest, such as your local community. That counts, too.

So I think developers should look at other ways to go about assessing value. One good example is MrTweet, which calls itself a “⁠personal networking assistant.⁠”⁠ The site tries to show you people you should follow, people you can point to, and ways to get discovered?based on your own activity and the information people feed into the site. Some people now focus on the lists compiled by influential members of the community, like the ones Robert Scoble curates. You could do this at the local level, as well. In using the API, developers may find other ways of combining the list methods to create something of value. It’s an area worth looking into.

What technologies are useful for Twitter application development?

One of the most important is OAuth, a protocol for users to share contact lists, photos, and other personal information. OAuth is a better alternative to basic authentication, which requires disclosing your user name and password. But if you change your password for one application, that breaks the relationship for all of them. OAuth uses tokens instead, which means you aren’t handing out private account information?and you control the relationship of your account for each particular application. OAuth is now recommended by Twitter for performing authentication with the API. By mid 2010, it will be required.

What programming “best practices” would you suggest?

There are a few of these. For example, it’s really good practice for your app not post things without your knowing about it. You give an application authorization to access your information, and the next thing you know, it’s tweeting in your stream without your permission. That may be a good thing from the standpoint of the application developer?a way to spread the word?but I don’t like it when I’m not asked. Personally, I won’t use any application that does that.

Also, be aware of new updates to the Twitter API. If you aren’t, your application may start breaking or become inefficient. For example, there’s a tool called Qwitter that notifies you when somebody stops following you?something Twitter itself doesn’t do. I profiled Qwitter in my book, but since then, people started complaining that Qwitter’s reporting wasn’t working. Into that gap came TwitDiff. They took advantage of new API methods that weren’t there when Qwitter got started. The API updates meant you could do the job with just two calls, rather than having to loop through several different requests.

You should also be aware of third-party Twitter-related APIs. A good example doing this is Topify, which replaces the standard Twitter notification you get when you have a new follower. A Topify notification may include the follower’s profile information and most recent tweets. Topify also mixes in data from MrTweet, if the new follower has an account there. That’s possible because MrTweet has its own API. These third-party APIs are both an opportunity and a service. As a developer, they’re an opportunity to access a broader set of data. And if you create your own API, that’s a great way to give back to the community. Having your own API also allows you to make connections that may lead to future development partnerships, co-marketing, and other good things for your business.

What about data security for Twitter applications?

That’s definitely a part of best practices on Twitter. You build it in and test for it. If security is not your strength, then make sure you get a security expert to review your code before you launch it.

The other important thing is to participate in the community. For English-language developers, there is a Google group worth following, which is also available as a daily summary. You may find that people are discussing issues that are tripping you up too. I fully expect Twitter’s emphasis on developer support in 2010 will bring better resources to all levels of developers and to different languages.

Speaking of changes, what do you think the API’s geotagging support?

I think that geotagging in Twitter is fundamentally different than with other services because you are not just letting friends know where you are, but the world at large?and potentially, at frequent intervals. Maybe that doesn’t matter to you, but I’m not sure what I’m going to do. I’ve jumped into things like the Foursquare service that lets you see friends⁠’⁠ locations on your phone. But that works through check-ins, which means that I determine whether or not I want to report in from any particular place.

But Twitter is different because it is so much a part of my life. I often tweet several times a day at different locations, and I don’t know if I want every one of those to reveal where I am at that moment. Twitter has done the right thing by making geotagging opt-in: users have to specifically enable it. Twitter is also asking developers to make it very clear to users that their location is being attached to a given tweet. It helps that the API provides a Boolean flag that let’s developers know if a user has enabled geotagging or not.

I think other people have the same hesitations. Which means that as a developer, you should know that your dataset will initially be skewed toward people who are more inclined to share this information. Not everyone has a smart phone, to make the sharing of location easy. What’s not clear is whether these are early adopters, or whether they will forever remain a small subset of Twitter users. Maybe a year from now, with smart phones growing ever more popular, more people will be interested. But for the time being, I’m not sure what the value is. Here in Bloomington, Indiana, we have about 1300 people using Twitter right now, most coming on board over the past year. But my guess is that if I wrote an application for my community that relied on geotagging, only 100 or so would enable the service and show up. That’s not the kind of payoff I would want.

The Twitter API has been a bit confusing?because it has actually been two discrete APIs.

That’s true, and it’s important to know that. Originally, Twitter didn’t have its own search engine. So in July 2008, Twitter made its first and only purchase of a third-party developer, acquiring Summarize and its search tool. Summarize had its own API, as well, and that became Search API. If you look at the Twitter API documentation, there are two sets of methods: “⁠Search API⁠”⁠ methods and “⁠REST API⁠”⁠ methods. Twitter is working to fully integrate the two. I’m guessing it will happen sometime in early 2010. There has already been some movement to make the error codes behave the same.

Meanwhile, are there pitfalls for developers?

Potentially. For example, for a long time, if you deleted a tweet using the REST API, it could still be found in the search engine. I think Twitter has now fixed that. The larger problem is that you really are using two completely different APIs, which requires two different ways to parse the information, and the information you do get is a little different.

The API is also confusing because it hasn’t been stable. The ground keeps shifting under you. So keep checking the API changlelog, which gives a complete list of the changes made to date. If I were to do an update of my book, that’s where I’d start. I’d look at what changes have come up since the book left off, and that’s what I’d update first. For developers, the same thing is true. Your program might be done and tested and well used?but the Twitter API is still going to change. It’s a moving target.

You wrote in your book that you didn’t have to be a programming expert to create good Twitter applications.

Right. I wrote the book for people who have great ideas for Twitter applications, not necessarily full-time professional programmers. So I included some basics, like information about the API wiki and where to find the libraries. An experienced programmer would already know that.

I do assume you have some understanding of basic programming. The book is based on a suite of sample applications that you can download and install. For those, I use PHP, MySQL, HTML and CSS. Dusty Reagan is working on another book, Twitter Application Development for Dummies that despite its title is geared toward more advanced programmers. I think he’ll be giving more specifics about different types of languages, about writing for the desktop versus the Web, and about other ways besides XML to get data from Twitter. There’s also a book coming out by Mark Hawker on the APIs that might be worth a look in 2010.

Where is Twitter application development headed?

I think there are still lots of opportunities. More people are using Twitter?and in more places around the world. With that global focus, there are international issues?politics and economics?that Twitter is well suited to helping people connect. And there are new applications related to e-commerce and electronic banking?though personally, I’m not sure I’m ready to do that over Twitter.

Not every idea will work. There was a cool site called TipJoy that attempted to help people to contribute to good causes through micropayments. But the site went under?its co-founder now works for Facebook. Maybe this was an idea ahead of its time, and with more e-commerce now going through Twitter, someone else will try it. PayPal now has a robust API, and some developers are integrating that payment system with Twitter. But the lesson is that a successful application requires not just good use of the technology, but that people be comfortable with your idea. Sometimes, that cultural acceptance comes later.

I’m most interested in how Twitter helps local communities?and in that respect, I find geotagging an interesting development because it shows Twitter too is recognizing the importance of local communities. There are a lot of opportunities here. So I’d say to developers?don’t try to be everything to everybody. If you think at the community level, you have the opportunity to create applications that will make a difference to the people around you.