Twitter's Conundrum

We all know that Twitter is amazing, that everyone is using it, and that it’s on the road to making everyone who’s involved with it rich. But if that’s the case, why are they messing around with their developer agreements at the risk of annoying their most loyal partners?

Maybe the answer is that Twitter isn’t the financial slam dunk that we all thought. The problem, I believe, goes back to a fundamental decision that they made early on, and that probably also contributed to their rapid rise. While they concentrated on their own web interface, Twitter created an elegant API which allowed others to develop first-class UIs for the service on every type of system imaginable. A nice piece by Matthew Ingram at GigaOm highlights the benefit of this approach to Twitter:

The result of this approach is that Twitter didn’t control the user interface for its own service. Of course they controlled the website, and they offered their own client, but they don’t control how Twitter content looks on other desktop clients, or on my blog, or on my non-Twitter phone app. Twitter says that over 90% of their content is viewed on their own UIs, but independent developers claim its in the 42% range (here’s a good summary on GigaOm).

Why am I dwelling on this? Because if you offer and service that doesn’t embed a commerce transaction, and you don’t control your UI, the only way you can make money is to have people pay directly for your service. You may argue with my assertion (Tim Bray and I have been going back and forth on it), but I haven’t found a counterexample.

Here’s my case. First, I included the phrase “doesn’t embed a commerce transaction” for reason. Tim’s first comeback was that Googles AdSense and AdWords APIs make money without a UI, but I categorize those as commerce APIs - they are explicitly about the exchange of money for a measurable service (showing ads).

Beyond that, there are presumably a number of ways Twitter could try to monetize their service, so lets look at each of them:

  1. They could charge a fee for using the Twitter service. I’m sure that they believe this would be suicide - that they’d quickly be replaced by some similar service that had some way to monetize itself without a subscription (or maybe just a purely free alternative - more about that in the follow-on post).
  2. They could embed ads in the results they return. Their own clients would presumably show the ads, but other UIs would naturally try to strip them out.
  3. They could protect the ads in their results through their terms of service (Tim suggested this). Maybe, but then they get into specifying how big the ads have to be, possibly splitting revenue with the other developers, etc. Once you do that you might as well….
  4. Get rid of all of the other clients so that you can control the UI and monetize it to your heart’s content.

So if you’re starting a social networking company of some kind, control your own UI. Expose select APIs which enhance the desirability of your service, but not ones which restrict your ability to monetize the users’ experience.

Finally, this whole discussion of Twitter and how it might monetize itself raises an interesting question: could someone build an open, federated alternative? I’ll explore that idea in the next post.