One explanation on why Twitter wants to control the User Experience

"Those who don't know history are destined to repeat it." - Edmund Burke

Ryan Sarver recently posted to the Twitter API Announcements Group some new guidance for developers in what are and what are not good businesses for third party developers to be in when building on top of the Twitter platform along with some specific Terms of Service changes to their API.  This has caused quite a bit of angst among their third-party developers.   I've followed the debate and can see the positions on both sides.

However, it all caused me to think - why would Twitter announce this in the first place?  Is there a plausible explanation beyond the fact that their investors are Venture Capitalists, not Venture Socialists?

This is all conjecture* but it would seem to me that you need to look no further than how a lack of consistent user experience in the RSS ecosystem hindered its wide scale consumer adoption.

First off, I can say with confidence that RSS is not dead.   It's a nice bit of hyperbole and  great for link bait, but it's not true. I've spent a good few years looking at the traffic graphs for both FeedBurner and Google Reader, and the traffic to and from RSS feeds continues to grow along with the growth of the internet.   It's steady growth, and not necessarily hockeystick growth, but it is still getting bigger.

In fact, as confident as I am in proclaiming RSS still alive and now just a good part of the stack of internet infrastructure, I am also confident in admitting that RSS has never, and probably never will reach that fabled escape velocity, that mass consumer adoption that the early adopters and technorati hoped it would as a first class consumption technology.

Why?

There are surely many reasons for this but one reason that has always been apparent to me is that the user experience behind RSS subscription and consumption has always been remarkably inconsistent and fragmented.  You might say it sucked.   No one controlled it.  Businesses like FeedBurner existed to try to help solve this problem, and although I am of the opinion that we certainly helped RSS gain adoption, we couldn't have every solved it because we didn't ultimately control it.   I'm not saying we should have...no no no, don't misunderstand me there, but I'm saying it was ultimately an unsolvable problem by any one company in the ecosystem.

The user experience to me was a lot like exploring a Tokyo street - lots of mysteriously marked doors for which you have no idea what you might find behind them, minus the mystery and romanticism of being in Tokyo.

You had orange icons, blue icons, rss chicklets across many version numbers, Atom chicklets, feed count chicklets, "Subscribe" links for subscription, and then on the other side of the click you had raw xml, browser friendly stylesheets, direct links to feed readers, and if you happened to get Google, a page that asked you if you really meant to go iGoogle or Google Reader.

If you did manage to subscribe to a feed, you also would have a wildly inconsistent experience.   You might just get links to headlines, you might get the full text of an article, you might get a summary of an article, and sometimes none of the above.  You would get some amazingly professional and useful applications, and applications that were five lines of code greater than Hello World.

The technically inclined (this author included) who understood the power of choice, the openness of RSS was the greatest thing ever.  We could install five different RSS readers for different purposes and spend hours exploring feed content using the myriad of tools and readers at our disposal.  I still do this on a daily basis on mobile devices as new RSS capable applications pop into the iTunes Store and Android Market every day.  It's awesome.

But for the hundreds of millions of other people out there on the internet, this was and is confusing.  It was just never a dead simple enough experience for most users.

So why, in the position that it is in with its own platform, would Twitter not want to learn from the mistakes of the past and not try to do everything possible to make sure they can reach escape velocity to ensure their own longevity?   Why not try to fix these problems of inconsistency and try the opposite of what didn't work by guiding both the user experience and the underlying protocol?

Twitter's user base has surely blown past the early adopters, and is on it's way to locking up celebrities and traditional media publishers, but for the monetization math to work, they still need to become ubiquitous and consistent on every device to end users.   However they end up monetizing the platform,  it's a classic x * y * z equation, where if x = publishers, y = advertisers, and z = end users, the number that is the most critical in this equation is z - because end users are also a subset of x for Twitter.

So they've decided to make it dead simple and consistent across all current and future consumption platforms to try to get widespread adoption.  It doesn't sound that crazy to me.  You go to a device manufacturer - say "here's the spec, build it" or "here's the implementation, embed it." And as a user moves from device to device it's all the same usage and verbiage.

I'm not really going to comment on the handling or messaging to third party developers here.  As I said, I can see both sides.

Developers creating innovative applications on the platform are all a part of increasing that end user number.  Historically though, creating vanilla RSS readers didn't turn out to be fantastic businesses either - so developers should probably look at the history there too and be driven toward developing something innovative anyway.

---

*Although I worked directly for Dick Costolo for over fifteen years across six or seven companies (depending on how you count them), I have never talked about this subject with him or any other Twitter employee.