The Rise and Fall of Chirp: An Epitaph for the Twitter Developer Community
This week Twitter shut off API access to a number of third-party apps. They claimed these apps were violating existing API rules. That turned out to be an outright lie. We now know no rules were broken, and Twitter decided to change its policy out of the blue. It would now ban apps that “attempt to create a substitute or similar service or product to the Twitter Applications.”
This meant Twitteriffric, Tweetbot and others were suddenly inoperable. The policy was officially changed on the Twitter website days after these apps became non-functional – and without notice, I should add.
This unilateral decision by a multi-billion dollar company to crush its competition didn’t come out of the blue. Users of these apps couldn’t be force-fed the same enshitifed experience as Twitter’s own app – making them a better experience. Those of us around in 2010 remember this same discussion happening.
But back then the developers won.
Twitter in 2010
Let’s travel back in time to 2010. Digg has recently taken over SlashDot as the link-finding site of choice for many geeks. Reddit is starting to gain traction after Digg’s latest redesign. Myspace ceded social supremacy to Facebook. Twitter has been around for 4 years but hasn’t broken into the mainstream or released an official iOS app yet.
They weren’t the only website without an app. The iPhone was launched without an App Store leading developers to lean into mobile-friendly websites. It was only later that the App Store opened and the app gold rush began.
The skills required to make an iOS app in 200X were wildly different from today. If Twitter wanted to build an iOS app, they’d need mobile developers fluent in Objective-C (iOS) – a very different skill set than web development. You could use something like PhoneGap, but that might not meet the iOS App Store requirements. Facebook famously released a PhoneGap app and spent the next year rewriting everything natively.
Rather than create an entirely new team and take on added risk, Twitter decided to build out a robust API and let app developers build apps for them. It saved them money while letting others take risks.
Twitter was obviously much smaller at this time. In fact, they had just hit a magic number of hires: 140, an employee for every character allowed in a Tweet. To celebrate the occasion and launch a bunch of new things, they decided to throw a conference: Chirp.
Chirp Developer Conference
Chirp, Twitter’s first developer conference, took place in April 2010. I was working at IZEA at the time building a Ruby on Rails application called “Sponsored Tweets”. Sponsored Tweets was a two-sided marketplace for influencers to get paid to Tweet about content from advertisers. At the time “influencer” wasn’t a term yet, so we used the less precise “celebrity”.
When the Chirp conference was announced my boss, Ted Murphy, saw it before me.
“What’s the username for Twitter ID 6253282?”, he asked around my cubicle in the open, concrete floor office space that showed how gritty and lean our startup was.
I opened my local terminal to the Sponsored Tweets directory and checked.
Code language: PHP (php)
$ script/console irb(main):001:0> User.find_by_username("adamfortuna").twitter_client.user(6253282) => #<Twitter::User id:6253282, username: "TwitterAPI" ...>
“It’s @TwitterAPI”, I replied.
“Ha! That makes sense. You and Eric are going to Chirp.”, Ted confirmed.
Eric Allam and I worked together for a few years at IZEA and then a few more years at Code School. When I meet amazing and skilled people, I of course want to work with them again. He’s working on Trigger.dev (YC W’22) right now. Ted is also a visionary marketer who jumped on the influencer marketing train and helped build some of the tracks used today. The more time goes on the more respect I have for him.
The captcha for Chirp registration required using the API to find the Twitter username from a Twitter ID. It was a light nod to give developers a few extra seconds head start and help focus the audience. This was before you could google for “Twitter id to username” and find a dozen tools for it.
Coincidentally, Team Treehouse was headquartered just a few blocks from where I’d end up working at Code School. I always laughed that two of the most influential interactive code education companies ended up in Orlando of all places. The tech world seems big but it’s really not.
Granting Access to Walled Gardens
Around this time on the web, there was no open standard for how to grant control of an application to another application. Some sites had APIs where you could generate a key or two, but nothing as fine-grained as permissions or the ability to revoke them.
Then OAuth came along. Thanks to the efforts of Leah Culver, Blaine Cook, Chris Messina, and others both in web standards and at Twitter, there was now a way to delegate access to your Twitter account to other apps and websites. This one change enabled 3rd party developers to create Twitter apps that reproduced the website experience.
Not long after Twitter released its OAuth API, we began working on Sponsored Tweets. We designed and implemented the basic functionality for an influencer to sign up, followed by an empty dashboard. We hadn’t built the advertiser side, so it was a job board with no jobs.
We managed to sign up a bunch of celebrities. IZEA had years of existing relationships with creators after running the marketplace for bloggers PayPerPost. It was the very beginning of sponsored content in social media and it was the wild wild west. Izea, for their part, mandated advertiser disclosures on all platforms. It was a decision that did cost the company money at times but shaped a more transparent advertising landscape.
A few weeks after the launch, when the Sponsored Tweets website was only wireframes on the advertiser side, we signed a deal to send a very expensive tweet. An advertiser was paying $20,000 for Kim Kardashian to send an ad out to her 2 million followers.
“That’s a car!”
We couldn’t believe a single ad could sell for that much. The problem was we hadn’t built any of the functionality to actually do the thing. The advertiser was supposed to write the Tweet, or provide a prompt. The influencer would approve it or write their own and have it approved by the advertiser. Once both parties were happy, the advertiser would set a time for the Tweet to be sent and Sponsored Tweets would send it (and take a 50% cut for our efforts).
But none of that was built. We had a way to log in. That was about it. Instead, an account manager at Izea, Kim (or her team) and Armani went back and forth on the 140 characters of content. Once it was finalized it was sent to me.
You see, the only way we could actually send out a Tweet under someone’s account was through the Ruby on Rails console. We had command line access to send Tweets programmatically thanks to OAuth for anyone who had signed up.
I SSH’d into the production server and pulled up Kim’s user and prepared it to send.
Code language: PHP (php)
irb(main):001:0> user = User.find_by_username("kimkardashian") => #<Twitter::User username: "KimKardashian" ...> irb(main):002:0> user.twitter_client.tweet('I don't remember the exact ad, but it had a single quote in it like this sentence. #ad')
“Can someone spell-check something for me?”, I remember worrying. She was the Twitter user with the most followers on the platform and I was preparing to send out a Tweet under her account. From the command line. No pressure.
I copied the content of the Tweet over to the console and looked it over. Daniel Goodwin, my Sponsored Tweet cofounder, looked it over with me. Dan is another great guy and dev. I’ve been very fortunate with who I’ve been able to work with.
“Is the quote in the tweet going to be messed up by the other quotes?”, he politely contributed.
“Whew, nice catch”, I said before adding a backslash to escape the quote, wondering if it should be a forward slash, checking the docs to confirm, sending the exact Tweet under my own account, verifying it went through, then hitting enter to send it from Kim’s account and seeing confirmation the Tweet was sent.
Everything had worked! Mostly. Just as we sent that Tweet, Twitter went down. The now iconic fail whale was on everyone’s screens as we tried to see if the $20k gambit would get any clicks.
Sadly because of the outage, it didn’t get sent to most people’s feeds. At that time, some Tweets could be “lost” unless you looked at someone’s timeline if they went sent around the time Twitter went down. I don’t know how Twitter worked on the backend, but I imagine a failed DelayedJob or background queue was being discarded during these times.
Later on, Kim re-tweeted (tweeted again; not retweeted. That wasn’t a feature yet) a similar ad for the same company. This time it went through. I remember seeing 300,000 click through on the ad in the first 2 hours for 2 million followers. Those are insane click-through numbers. It also made me respect Kim more for posting a second ad and giving the advertiser more value, even though it wasn’t her fault the first one didn’t work.
It’s hard to explain how much of a mindset shift OAuth was. This would allow apps to be built on top of Twitter – and any other platform that embraced OAuth. They changed from being a website to being a platform overnight.
Before Twitter could create its own mobile apps or advertising networks, entire startups were built based on getting there first. Every one of these companies knew that Twitter could pull the plug at any time. They hadn’t built trust from a decade of reliable API access, and no one knew if Twitter might move in and eat their lunch at any time.
When it comes to apps, many others got there first. Mark Jardine and Paul Haddad of TapBots created Tweetbot. Ryan Holmes created Hootsuite. atebits created Tweetie, innovating a new “pull to refresh” feature before being acquired by Twitter and turned into the official Twitter iOS application.
Since I was working on a website that was completely and utterly dependent on a single OAuth token, I knew the risks these apps were taking. Twitter could block anyone at any time – myself included.
The Big Question
Chirp, Twitter’s developer conference, was the perfect place to ask the executives “Are you going to screw us over? Or can we trust you to build a business off of your API?”.
The conference was split into two parts. Presentations were held at the Palace of Fine Arts in San Francisco. For reference, Sigor Ros played there the next day. Twitter execs presented what Twitter was working on to the developers – not customers. Well, both. Twitter understood developers were the key to growth. It was the vector that 10xd their ability to create a useful product. Anything Twitter was missing someone was ready to step in and build.
I remember waiting in line to talk to Dick Costolo, the CEO of Twitter at the time. For the entire weekend, the leadership team was available and open. I remember someone else in line asking Dave a question about other advertising networks on Twitter.
“A cancer”, he replied with a smile.
You have to remember Dave has a sense of humor. He’s credited as a co-writer on HBO’s Silicon Valley, and at times I felt I could see his influence loud and clear. His comment reminds me of my uncle’s wry humor. I didn’t take his comment to mean I was giving Twitter cancer. I interpreted it as healthy competition, but in an area where Twitter intended to win.
That entire conference was a developer’s dream. They had food trucks that had gained popularity through announcing their locations on Twitter roll up and providing lunch. Will.i.am, an early Twitter adopter, was mingling from group to group of developers (which I only realized while eating a sandwich on the floor and looking up). A Tech reporter on roller skates was whizzing around collecting interviews. And it wrapped up with a hack day featuring the Twitter API and Paul Graham as a judge.
Eric and I spent most of the hack day building a real-time Node.js search engine that would auto-refresh the latest results for searches using Twitter’s newly launched streaming API. It was more a proof of concept than a business, but the energy of coding in that warehouse pier on the San Francisco Bay was magnetic.
During Chirp Twitter launched Promoted Tweets, their first attempt at monetization. They also announced the acquisition of Tweetie, possibly the most popular iOS Twitter client. They hadn’t outright banned their competitors, but they let us know we’re now all playing the same game. They had every right to cut us off if they wanted. It’s their garden, we’re just all playing in it.
Instead, they assured developers that they would not go after any existing apps that followed the rules. They couldn’t predict the future, but for now, anyone building on Twitter’s API was safe.
Then they held a Will.I.Am concert for devs at 2 am in downtown San Francisco. I had to coat-check my laptop and backpack. It was wild.
I walked away from that conference thinking that Twitter was perfectly OK with the developer community figuring out what businesses the API could support. Some apps would be banned (Jooicer, I’m looking at you), but most kept humming along. Successful apps might have to compete against Twitter. But the competition would be a mostly fair one.
Twitter could and would compete with some apps, but most weren’t worth the effort. The goodwill they received outweighed the tiny gains in revenue for changing their rules and making enemies. Plus, the developers of those apps helped Twitter grow! They were some of Twitter’s loudest cheerleaders.
On the last evening of the conference, Twitter execs went up one by one to play Keynote Roulette. They would have 5 minutes to give a presentation created by someone else with automatically advancing slides.
His entire presentation was themed around Twitter’s secret evil plan to use developers to flush out which markets were worthwhile to build in, then copy those apps and ban them. It was what every developer feared, but it was said to raucous laughter. Costolo proved he knew exactly what the developers most cared about, and how to best make them laugh with a wink and nod while calming their fears.
There is No War in the Twitter Kingdom
The Developer kingdom and Twitter kingdom lived harmoniously for many years. Although there were squabbles at times, the two kingdoms co-existed. I left Sponsored Tweets a few years later to work at Code School, but Twitter of 2010, the Twitter Developer Community, and Chirp stood out as a highlight moment for a company embracing developers as collaborators.
Until the Musk kingdom invaded.
The Cold Winter
In the summer of 2022, Twitter announced they were going to host a 2nd Chirp conference for developers. Even though I hadn’t worked with the Twitter API in years, I considered going for the nostalgia of it.
I’m glad I didn’t get my hopes up. In November 2022, a few weeks after Elon Musk took over, the 2nd Chirp Conference was canceled.
We’re currently hard at work to make Twitter better for everyone, including developers! We’ve decided to cancel the #Chirp developer conference while we build some things that we’re excited to share with you soon.@TwitterDev Tweet
When I saw this conference was canceled I immediately flashed back to those discussions with executives at the first Chirp. Entire businesses built around shifting rules could be out of business tomorrow if Elno deemed it so.
It only took another two months for Twitter Developers to feel the weight of the acquisition. On January 12, 2023, without notice, Twitter revoked API access for a number of apps. Some of these apps helped Twitter get to where they are today. Some were possibly more popular than the official Twitter clients in the early days.
For their part, these developers have had a rough week. TapBots, the company behind TweetBot, has already pivoted to building a Mastodon client they’re calling Ivory. The reception has been so resounding that people have compared getting into the beta with getting Taylor Swift tickets.
What’s clear is the relationship between Twitter and the developer community has been fractured. Building a company based around Twitter API access today is possible, but Elno could change the rules and revoke access at any time.
Startups need to make a choice of which platforms to build on. Do they choose Mastodon, an open-source platform with almost 10 million users and no central authority? Or do they stick where the money and numbers are and continue building on Twitter with a sickle hanging over their head ready to fall at any moment?
For my part, I hope they choose Mastodon. My last 3 months on there have reminded me of Twitter from 2008 again. People are supporting each other, creators are finding new audiences and we’re all starting to realize what life is like without an algorithm dictating where our attention should be.
Similar to Twitter in 2008-2010, I don’t think most people know where the Fediverse (the umbrella term for Mastodon and similar services) will evolve, but I’m excited to see what it becomes. You can count me in for the next Mastodon developer conference – just don’t call it Toot.
The header image was generated using the MidSummer API with the string “Sad Twitter fail whale thrashing in ocean waves, while being dragged down under water by a dozen orange cables connected to a dozen huge bright orange batteries, weighing the whale down and dragging the whale down under the sea by the batteries, ominous, flat design, simple design, 2d design, with a #6dc7c5 background.”
The Musk Kingdom image was generated with the string “the musk kingdom preparing to attack the peaceful twitter software developer kingdom, flat design –no text.”