Twitter wants a billion users, and it’s prepared to sacrifice developers to get there

With the announcement of its new API changes, Twitter did what it felt to be the absolute best thing for the vast majority of its users and for its future as a business. It swung the axe to prepare for its growth from hundreds of millions of users to billions of users.

But it did so at the expense of the third-party developers that helped build the platform, and it’s going to have repercussions that may not be immediately evident.

In many ways, Thursday’s post is actually the culmination of long months of unrest at Twitter. By accounts both first and second-hand, the picture has been painted of two factions at philosophical odds with one another.

On one hand, as symbolized by former CEO and co-founder Jack Dorsey and his fellow co-founders Evan Williams and Biz Stone, you have the people who started Twitter based on a side-project and grew it on the backs of a voracious and rapid developer community that helped define it as much as any internal engineering effort.

In an antipodal position, you have a more practical cadre exemplified in current CEO Dick Costolo. This group is all about figuring out how to ensure that Twitter survives, now that it exists. Talk of changing the world and grand gestures is at a minimum here, and discussion of media partners, user growth and leveraging the data stream for revenue are the bywords of the day.

This second group understand how rare it is that a simple, concise idea like Twitter gains traction in the way that it has and inspires millions of people to make it a part of their daily lives. Unfortunately, it also doesn’t appear to place value on just how important third-party Twitter clients were to Twitter becoming what it is today.

Third-party developers were Twitter’s equivalent of the Genesis Device, but now that the ecosystem is thriving, it’s closing it off to exact more control and fuel growth from millions of users to billions.

Here’s the kicker: I don’t think that Twitter is necessarily making a bad decision for its business. But it is going about it in a risky anti-competitive way, and one that could just as easily lead to its stagnation as its success.

A tale of two ecosystems

Twitter’s developer ecosystem basically breaks down into two halves. Those making clients that feel like ‘better’ or ‘different’ versions of Twitter like Tweetbot or Twittelator Neue, and those who integrate Twitter into their apps and services.

The rules limiting clients to 100k or 200% of their current number of users, for instance, do not apply to apps that utilize Twitter in ways that leverage its data, like Klout, promote the use of features of Twitter, like Favstar or collect Tweets in ways that display them exactly to Twitter’s standards, like Storify. There are even some clients like Hootsuite, which Twitter says falls into ‘enterprise’ use, which are deemed ok.

Note: the 100,000 access token limit in API version 1.1 applies *only* to clients. It does not apply to the rest of the ecosystem.^JC

— Twitter API (@twitterapi) August 20, 2012

Twitter is happy to have other companies be using the official data that it provides via its API, though it has constricted that data over the past couple of years, adding in high-priced service tiers for more access. It’s also fine with outside services being used to post actions and notices to Twitter, as long as they comply with its much stricter Display Guidlines, which are soon to be mandatory.

To be concise, here’s what Twitter doesn’t want: things that look like Twitter.

What Twitter does want: things that use Twitter data.

Twitter wants to control the way that you look at Tweets, completely. It wants them displayed how it wants, through clients under its command. But, in the process of gaining that control, it feels it has to axe the vibrant third-party client ecosystem completely, including already successful apps, and that’s not its best decision ever.

Developers to kill for

When a startup launches a new service, especially a social one, one of the first orders of the day is to get a working API (application programming interface) up and running. This is the socket that allows developers to plug their apps into the service, offering a variety of user experiences that iterate or improve on the original.

Twitter’s first real user interface, for instance, was a very simple web-based application that didn’t automatically refresh and featured a simple global feed of all tweets, along with some basic functions that allowed you to follow users. It existed primarily as an SMS-based service that most followed on their phones, and slowly transitioned out to the web and, eventually, to native clients for Windows, Mac, iOS and Android, all developed by third parties.

Yes, every single one of the non-web-apps that you could use to access Twitter in the early days was built by someone outside the company. They were busy trying to make sure the site didn’t come down around their ears as it grew and the development of apps was left to third-party developers who got excited about the potential of a real-time service like Twitter.

The friendly API was enticement enough for early Twitter app developers The Iconfactory to create Twitterrific for the iPhone even before the App Store existed. Within a couple years of launch, Twitter had a developer ecosystem building for it that was second to none. Eventually it would include Iconfactory’s Craig Hockenberry, Gedeon Maheux and David Lanham, Loren Brichter, of Tweetie for iOS and Mac, which Twitter would later go on to acquire. Not to mention newer entrants like Paul Haddad and Mark Jardine of Tweetbot fame and dozens more.

If you’ve been following the ongoing Twitter v. developers debate, you’ve most likely seen Hockenberry’s ‘Twitterrific firsts‘ post which lists all of the things that it did first, before Twitter even thought of them. Among those is using a bird for its logo, the first use of the word ‘tweet’, the first to completely support replies and conversations and a bunch of other stuff. Even Twitter’s beloved #hashtags, which it now uses to help monetize its service, came from third-parties.

Many of those innovations also had their beginnings in the community of users, who began playing with and hacking away at creating ways to talk to one another and to create a chain of messages that would eventually become the @reply. Yes, even the most basic granule of organized conversation on Twitter didn’t come out of the company, it came out of the community and was first supported by third-party developers.

That short list of names above includes just a small sliver of the talent that Twitter had at its disposal for improving the service and making it into something that users would come to not be able to live without. And it had all of that support for free. Some developers built the apps and charged for them, making money for their efforts, but in the end it was all to Twitter’s gain.

Any startup service today would likely kill for a group of developers as talented as those that built your favorite Twitter app to be interested in creating apps for it.

And now, with its API changes, Twitter has effectively cut off those same developers, giving their apps a certain percentage of growth to look forward to, then nothing. Yes, I know that developers have come out to say that things are ok for now, and that is likely true. The caps that Twitter has set for clients mean that most of them will be able to sell quite a few copies as of yet and could have a couple of years of growth or perhaps more still left. But that’s for existing apps, and there’s no telling how these changes will affect their business long-term. My bet is negatively.

I think that it’s important, however, to make something clear: Beyond anything in development right now, you will never be getting great consumer-oriented third-party Twitter clients again.

There’s simply no reason for any developer to go into it expecting to create a business surrounding clients any more. And that’s exactly the way that Twitter wants it.

But why?

So what’s behind Twitter’s sudden push to remove clients from its ecosystem? They aren’t actually responsible for that much tweeting, around 23% of tweets if a recent random sampling is to be believed (and we have reason to do so). And that’s tweets, the group of people pushing those tweets are probably quite a bit smaller.

But the restrictions really aren’t about posting things to Twitter, they’re about reading things on Twitter.

Twitter doesn’t care what posts to Twitter, it cares how tweets get displayed to users, and it cares for a couple of reasons. Some have a lot to do with improving the service and making it better for the hundreds of millions of users yet to come. Others have absolutely everything to do with making money.

Consistency and familiarity

The ‘delivering a consistent Twitter experience‘ announcement that Twitter’s Michael Sippey posted a few weeks ago that sparked the whole recent unrest was read as a veiled threat to third-party developers. That was accurate, but it also carried a lot of truth.

Twitter wants to continue its growth, eventually becoming the de-facto way that people discover and share real-time information on the web, period. In order to do this, it has to maintain an experience that feels and works the same no matter where you use it. If you want an example of another company using this tactic, just look to the recent changes to Apple’s OS X operating system.

Apple has taken great pains to make the Mac feel familiar and comfortable to those millions of customers purchasing iOS devices. Just look at this shot of Messages running on each of Apple’s portable computers:

Twitter has to move hard to unify the experience that people get across all of its clients, web, mobile and desktop. Users have to feel like everywhere they see Twitter, it looks like Twitter.

Unfortunately, they’ve done an intensely terrible job of it so far. The official Twitter apps for iPhone, Windows Phone, Android and Mac all look wildly different and most of them are pretty terrible, frankly. And they all look different than the web version, seen below:

This is one of the biggest sticking points to the familiarity argument for developers, by the way. What they see is that Twitter is telling them they (essentially if not technically) shouldn’t make clients anymore and that they have to follow insanely strict guidelines for displaying tweets because Twitter wants everything to look the same in all of Twitter’s various permutations and it doesn’t even eat its own dogfood.

If it wants the new Cards feature to become a real tool for advertisers, though, it’s going to need to do that, and soon. A major re-write of the official apps in all their forms is likely in order.

I’d be very surprised if we didn’t see new versions of all of the official apps built with a native ‘frame’ displaying an embedded web view of Twitter’s stream.  Don’t expect them to be suddenly awesome, however. The Facebook mobile apps suck completely and hundreds of millions of people still use them.

This would allow the timeline to be tweaked and updated live without pushing new versions of the apps out. It’s normally a markedly inferior solution to the smooth, polished feel of an app that uses native frameworks to display data, like Tweetbot or Twitterrific, but it’s ideal for a company like Twitter that is rapidly changing the way that it displays Cards and ads in its timeline.

This kind of updated Twitter app would likely rock the boat with users, and forcing artificial restrictions on how many users each third-party client can use is seen by many, a lot of them developers, as a strongly anti-competitive move. If Twitter can present its own apps as the canonical experience and there aren’t any developers with the motivation to create something better, it removes options for the user and could make the experience of using Twitter worse, especially if it can’t get its act together as far as quality goes.

The road to 1 billion

The first users of Twitter were technically proficient early adopters, but the characteristic of its user base has changed drastically over the last several years. For every brilliant comic, technically savvy analyst and insightful pundit, there are literally millions of people who use it as nothing more than another form of reality television.

And the television model isn’t a bad one to use when you’re trying to draw up a picture of Twitter’s users today, actually. Imagine the combined viewership of every Bravo, TLC, MTV and Lifetime reality show pumped into a tube and squeezed out onto the web. You’d end up with something like this:

What you see above is a random sampling of the (not so) public Twitter feed as it exists today. The public feed was once a way to check out who was using Twitter, see if there was anyone you might like to follow and even just keep up on the flow of information. That time has long passed as millions of tweets flow through it daily and it’s now private. As the ‘Firehose’ or more limited ‘Garden Hose’, it’s one of the ways that Twitter is monetizing the company, offering it to data analysis companies and media conglomerates.

The overall shape of the content being shared on Twitter has changed to the point where it’s likely unrecognizable to people inside the company. Remember that (and this is part of what’s so great about Twitter) you only see a small portion of the picture. What you see, feel and experience as Twitter exists for no one else, least of all Twitter itself.

The essential nature of Twitter as a personal experience means that you’re never going to be able to get a handle on how everyone uses it. Twitter is trying to do that when it comes to advertising, turning all of these users into enough revenue to be profitable. And the method that it has decided on is Cards.

Cards + ads = Cads

I don’t know that all that much explanation needs to be given here, as Mike Isaac did a great job going over why Twitter is betting on Cards for the future of its monetization efforts. But suffice it to say that displaying Cards properly is a top concern for Twitter, in addition to its regular timeline ads. I know that Twitter is pushing them as ways to enjoy media in your Twitter timeline, but get real: they’re ads.

No outside client currently displays the timeline ads that appear as Tweets, though there’s no technical reason why they couldn’t. Developers could have easily been required to incorporate Twitter’s ads in their timelines, a compliance method that many I spoke to would have welcomed as an alternative to being throttled as they have.

Cards, essentially expanded Tweets containing media and other content, would have been a much more technically challenging thing to push out to all clients. And if Twitter is betting as big on Cads as it appears to be, then not having these display properly in all clients was a dealbreaker for them.

And the current ruling parties at Twitter are clearly obsessed with making the business profitable without continued reliance on outside funding, whatever the cost.

So, Twitter is betting on a unified in-house client strategy to produce an experience that is appealing to the masses and is an ideal incubator for its ads. But will its bet pay off, or will its treatment of developers do it more harm than good?

More harm than good?

As of this moment, any developer working with Twitter’s API, whether it’s a client or another type of app that is currently in favor, can’t be certain about their livelihood. Sure, right now these apps may be on a path that runs parallel to Twitter’s business plan, but what happens when that path zags?

The company has already demonstrated vividly that it will not hesitate to run roughshod over the business of developers in order to do what it feels necessary to secure its future.

If this doesn’t make developers nervous, it should. “For my apps, it could have been worse,” says Manton Reece, developer of companion apps like Tweet Library and the cross-platform syncing service Tweet Marker. “The only immediate change will be to make sure I’m following the guidelines for how to display tweets. But the new cap for authenticated users shows that Twitter will use the API to limit competition, making it a completely toxic platform for developers.”

“I think we’ll look back on the last few years as an incredible time for Twitter app ideas and UI innovation,” Reece told me. “We had a good run. I won’t stop developing for Twitter tomorrow, and I’ll keep Tweet Marker running, but the platform doesn’t have a future for the kind of things I want to build.”

And his sentiments were echoed by nearly every single one of the many developers I spoke to. Even if their businesses weren’t immediately affected, they’re gunshy enough to be wary of making big bets on the platform. They’re also seeing this nervousness passed on to investors, who may even be pulling back from projects involving Twitter.

This business-oriented caddishness is exemplified perfectly in the terribly generic chart included in the recent blog post:

The chart was meant to illustrate what kinds of apps Twitter ‘approved of’ and didn’t approve of under the new API rules. It turned into a symbol of its severing of ties with developers and the startup mentality, which welcomes third-party developers as a way to spark innovation and enhance a core product.

If you’re a student of startup history then you know that this kind of cyclical API support is common among fresh companies. They offer API access at the beginning, as an enticement to get support for their apps, but then grow more strict in its use as they realize that access is hurting, or is perceived to be hurting, the way that they’re making money.

But Twitter has benefited so greatly from the work of outside developers that it feels especially callous that it’s turning its back on the most prominent types now. Now it remains to be seen just how badly losing developer confidence and passion will affect its expansion efforts.

Perhaps it won’t mean a thing to its business, and perhaps it will, but it’s a risky move. It may never make waves out in the mainstream user base of Twitter, but it does affect the most passionate proponents and users…just like the ones that built Twitter in the first place. And those users may lead the pack away from Twitter just as they led them there.

Some of those are turning to other newly minted platforms like App.net or Heello, and some of us are questioning how much Twitter can be trusted with the future of real-time communication.

What now?

Now, Twitter has its work cut out for it. It has made its bed with developers and it needs to get more vocal about its support for non-client apps and services if it wants to keep expanding. It also needs to revamp all of its apps with a quickness. It has flat-out told its users that the only way they should be reading Twitter is through an app made by the company, so producing ones that aren’t the worst is imperative.

Making Twitter profitable is a huge challenge, but so is keeping it relevant to both new and existing users. Too many changes to the core experience at once and it could shake loose the technorati, followed by the early adopters and then perhaps even ‘normal’ folks.

The beauty of Twitter is that it is what you make of it. It can be a virtual water cooler, a news service, an emergency communication line and an important source of data about the extant world and its people.

It’s a time of massive transition for the company and I hope that it continues to keep that spirit, even in the face of mounting pressure to make money.