Twitter Walking a Tightrope With Developers

The past week has seen a lot of drama around Twitter’s relationship with third-party app developers. Fred Wilson’s post about the company’s evolution seemed to touch off a powder keg of emotion about what the company’s approach to new services might be, and that was still bubbling when Twitter announced that it had bought Atebits, maker of the iPhone app Tweetie, which touched off a new round of criticism. Developers have protested on a Google group, formed a Twitter group with the hashtag #unionoftwitterapps and made caustic comments about the company in blog posts, podcasts and pretty much everywhere else.

Advertisement

Wilson’s post suggested that Twitter had grown so large and ubiquitous that it had reached an “inflection point,” where it could become the center of a developing ecosystem or infrastructure of other products and services. But the acquisition of Tweetie put a different spin on that message: the implication seemed to be that Twitter had become so large and ubiquitous that it could (and possibly should) either acquire or compete with the third-party apps that have grown up around the company. And the reason it wants to do that is pretty obvious: to own the relationship with the user.

Developer Ben Metcalfe has some suggestions about what Twitter could do next week during the Chirp conference to create opportunities for third-party developers in a number of areas, as a kind of “exit strategy.” But as Chris Dixon of Hunch points out in a blog post, the biggest remaining hurdle for both Twitter and third-party developers is the fact that neither side knows what the company’s eventual business model will be (or if Twitter knows, it isn’t saying). That vacuum is what is causing a lot of the tension, and it likely won’t go away entirely until the vacuum is filled.

Some companies might think: “Why should we care whether developers are mad at us or not? We own the ecosystem — without us, they would have nothing, so they can just sit there and take it, while we compete with them or buy one of their competitors or whatever else we want to do.” But the reality is that many of those third-party apps did provide a substantial amount of functionality that Twitter was missing, whether it was photo uploading or URL shortening or geo-location. Maybe some developers did take a ride on Twitter’s coattails — but others did add value, and as a result helped Twitter become the global phenomenon it is now.

And trying to extend some kind of olive branch to the developer community that has built up around Twitter isn’t just a nice thing to do. As large as it is, and as much money as it has now, the company can’t realistically build all the things it needs or acquire all the things it needs tomorrow. It is still going to need lots of help, and the benefits of a thriving developer ecosystem are manifold: not only does it produce valuable add-ons that might never have occurred to Twitter HQ, but it is also a very powerful form of marketing, both for the product and for the company itself.

“There’s some misunderstanding around platforms,” Evan Mr. Williams told the New York Times. “I’ve been trying to figure out how to talk to developers about this.” Hopefully the Twitter CEO has found a way, because the company’s Chirp conference is next week, and there are going to be plenty of people looking for answers.

While I really do understand developers being upset I can’t help but think that they’re overreacting to the tweetie purchase. After all, does the market really support a large number of clients that all do the same thing? And weren’t the free clients written either for exposure, for fun/challenge or perhaps in the hopes that this would happen to them?

The issue of a business model is a good one and is the one thing missing from Fred’s post. It was clear that Apple made money from selling Macs so that when Aldus created PageMaker they weren’t going to see Apple all of a sudden release a competitive product. Note, though, that Aldus created a substantial product that wasn’t merely an alternative to something Mac OS did. It wasn’t a better Print dialog, it was a way to perform a whole set of functions that were already being done by a market, but in a much less efficient, more expensive manner.

In contrast, Twitter clients are improvements on a core part of Twitter, the logged-in home page. Had Aldus created a program that was a better Print dialog for the Mac they’d have failed. THAT is the point Fred’s making – that developers who want to build real businesses in the Twitter ecosystem need to stop spending energy around providing a better X for Twitter and think about building real products that aren’t merely a tweaked version of something Twitter does. Even without knowing the business model of Twitter, it’s pretty safe to say that how people send and read tweets is something that will always be core to them so a developer who creates a client needs to be doing so either for fun, because they want exposure and have a new take on the client experience, or because their client will serve a niche that Twitter’s not interested in (the Twitter client that’s part of a SM customer service offering or that integrates other specialized info). But developing yet another Me Too client is a waste of time from a business standpoint. Then again, isn’t playing Me Too usually a waste of an entrepreneur’s time?

I’m sure that next week will clarify a few items, but not everything. Twitter-the-API & Twitter-the-platform are 2 different things.
There is some base functionality that best belongs to Twitter, and developers will have to adjust and add real value, not just features plugins. There is no business model for plugins (how many Firefox plugins make money?). Can you imagine if you could read a Google search on 25 other “client readers”? That would be a mess, and it equates to the Twitter situation today. They will definitely need to own the Twitter Homepage experience, so that they can own the end-user experience and start monetizing.