Developers Bailing on Twitter

by Jesse Stay — published on June 19th, 2008

Hi - you seem to be new here. If you like what you see, please give back by subscribing to my RSS feed!

You can check me out on Twitter, Facebook, or FriendFeed to see what I'm up to. Thanks for visiting!

whale.pngI’ve been following various development mailing lists lately, and I’m seeing a trend of developers starting to bail on Twitter. This is a scary thought, because when the developers bail, so will the users. It all started with a conversation on the Twitter Developers’ mailing list with the subject, “Shame” by a developer named, “nath“, in which he said,

“Well, twitters always down or unusable due to the speed; the api’s
keep breaking and are down just as often; the groups now packed full
of spam which is littering my inbox.

“It’s a real shame to see such a great app crumble and die like this :(”

Alex Payne, a developer for Twitter, responded by saying,

We own Twitter’s speed a stability; my our metrics, it’s been pretty
solid over the last few days.

We do not, however, own spam prevention for this group. That’s up to
Google, and if it’s a hard problem for them, I’d imagine it’d be a
hard problem for anyone.

I go through and clear out spammy posts, but time they reach my inbox,
they’ve reached everyone else’s as well. There’s just not much I can
do about it. Please make use of Google’s “report as spam” features.

After which another developer that goes by “rlansky” responded:

Sorry, but I have to agree with the original author, it is a shame
that the service and the API are so unreliable. The potential for the
services that could be built on an API like the one offered by twitter
are endless. They really are.

Statements like this:

> my our metrics, it’s been pretty solid over the last few days.

don’t do much to boost my confidence. When you make an API available,
you are essentially saying to the world, “here’s our service, come and
build something great on top of it.” You can’t build anything of any
real value or widespread use on something that “has been *pretty
solid* over the last couple days (emphasis mine) .” You just can’t.
You need something that is rock solid all the time.

I’m not trying to start a flame war or bash twitter at all. Like I
said, I think it is a shame because the potential is so great. The
idea is great, the acceptance is great, the use is great, the
possibilities are awesome. But they just can’t be fulfilled given the
reliability of the service as it is today; try to build something on
top of the API that will see wide-spread use and you’ll find that when
you push the gas, the wheels fall off the car… at least that’s been
my experience. It’s been *extremely* frustrating and disappointing.

Peace.

After following a few threads on the Perl development library for Twitter, Net::Twitter, I recently found out that Net::Twitter’s original maintainer too has jumped ship. He has handed it over to a new maintainer, but developments like this are not a good sign for Twitter! It is very clear that frustration amongst Twitter developers has hit a maximum level and I fully expect to see this only increase in the short term.

At the same time, developers like Kee Hinckley are giving advice to Twitter, and they are graciously accepting it seems. Some great tips are being given on ways to enhance the API, and I even suggested they do a public bug tracker which they seemed to like. Twitter clearly doesn’t seem to have enough expertise in-house, although they do keep saying they are hiring. Their jobs page doesn’t seem to have any upper-management positions though which I think is really what they need right now.

I’m very worried for Twitter. As more developers jump ship and work on other platforms such as Plurk and FriendFeed (which really isn’t a direct competitor to Twitter), this great tool is going to be left in the dust with no new development and large networks of people moving elsewhere. Twitter’s largest traffic comes from the API itself, and as that traffic dies down, so will Twitter. Imagine, for instance, if Seesmic were to stop development on Twhirl due to the costs associated with keeping up with API flaws? That would be quite a chunk of Twitter’s users being forced over to the other Twhirl clients, FriendFeed and Seesmic itself - it’s such an easy transition were Twitter support to be dropped! What happens when Twhirl begins supporting Plurk?

Twitter needs to do something, and they need to do it fast. I agree they need to get their infrastructure in place, but before even doing that they really need to put every hack possible in place to keep the API up, keep it working, and work with the developers to ensure they are staying happy. A large revolution is about to take place, and I’m afraid it won’t be pretty.

UPDATE: See the little FriendFeed box below? Click “show” and join the discussion on FriendFeed about this right on my blog! Subscribe to my updates here.

This entry was posted on Thursday, June 19th, 2008 at 2:23 am and is filed under FriendFeed, OSS, Social Media, Twitter. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. .

Join the Discussion on FriendFeed:

Viewing 19 Comments

    • ^
    • v
    Interesting...
    • ^
    • v
    It definitely becomes tough to develop for a platform, not only when it's down, but also when it is constantly changing. I've gone to start a number of projects and found different behavior on the API or the web site on a daily basis. It seems Twitter approaches development the same way today as they might have when they first started in that features appear and disappear at will. Take a user's timeline which suddenly started displaying the username in front of each update. Another example is the rss view for user_timeline that now seems to ignore the count parameter and will be fixed "soonish".

    It's not easy to develop for a platform where you have to put as much effort into keeping track of that bugs of that platform as well as the bugs of your own software.

    It's really unfortunate because there are still so many Twitter projects I would love to work on, but keep getting stalled.
    • ^
    • v
    Damon, I completely agree. I'm currently coming up with alternate plans on
    everything I was developing for Twitter to ensure I have a backup should I
    end up giving up. The communication from Twitter sucks on letting
    developers know when changes are made - there is no staging area, no testing
    in place, and it's a "throw this out there and see how it performs"
    mentality. This isn't even an architecture issue - a redesign isn't
    necessary to get a simple staging and testing environment in place, and the
    fact that they aren't doing such, or appear to not be doing such (I'd like
    an explanation if they are), shows they really need some expertise at a
    higher level to get this stuff in place. Hiring more lower-level IT staff won't help.
    • ^
    • v
    isolated antidotes do not a movement make
    • ^
    • v
    anon actually has a point here. I don't know if we can quantify a mass exodus of developers from the Twitter platform at this time.

    Not only that, but there is a whole new crop of applications that are being developed for Twitter. Unfortunately, these applications are not the types of apps that Biz is going to brag about in the Twitter blog. We're talking about things such as Twiddict and the recently-announced twitabit - applications that are designed to fix major problems in Twitter. Not a good thing.

    More at this post.
    • ^
    • v
    Perhaps slowing down the developers is a good thing. I have used Twitter for what it did from the beginning and continues to do rather well ... publish a short message to those who wish to receive it and receive short messages from those people or applications I'm interested in. The basic API services continue to work well, allowing me to capture and save my utterances and those sent specifically to me.

    In comparison to the beginnings of other messaging systems on the Internet, Twitter has fared remarkably well. I remember well the pain of email in the early days; silo'd systems, unreliable delivery (it was remarkable when email was delivered faster than postal mail), ascii text only (except for IBM PROFS which, as the dominant email system, didn't work with anything else).... In fact, newsgroups were then the most reliable email system (hence the place were Spam started), and even those took days to propagate.

    I consider Twitter to be as revolutionary as email and fully expect it to have it's own severe set of growing pains. The problem with the developer community is that they want full bodied, robust architecture with every bell and whistle from the beginning and can't understand why the service provider didn't start that way. Further, they have their "very important feature" that Twitter MUST have in order to be successful, or rather, for the developer to be successful. Twitter's problem has been one of trying and accommodate every possible developer whim and getting distracted from task #1: making their fundamental offering robust at scale.

    As a Twitter user, I'm very willing to cut Twitter some slack as they take a service built on a whim (and one in which the huge popularity surge caught them by surprise) and morph it into a solid offering fully encompassing what they originally intended: a short messaging publish and subscribe system with a public timeline and a stable API.

    Meanwhile, I've subscribed to FriendFeed and find it a jumble of mostly uninteresting stuff from people I don't know and don't really care about. I pay almost no attention there as it requires almost constant attention which I'm not willing to give. Twitter, on the other hand, brings to me the important stuff. After being away for a while, it's easy to catch up. I have more receiving options with Twitter, and the organization is logical and meaningful to me. I would never have seen your message about this blog post in the jumble of nonsense on FriendFeed, but there it was on Twitter.

    As a user, giving up on Twitter is, in my opinion, a mistake. The news comes to me on Twitter. It continues to be the most reliable method for me to get the important stuff. Long live Twitter!
    • ^
    • v
    Roland, I'm not suggesting that users give up on Twitter - in fact, it's not the users I'm worried about. Twitter's biggest worry is the developers leaving Twitter. It would only take one or two major developers leaving Twitter, and then the users themselves would have no option but move elsewhere.

    Imagine, for instance, if Bear who wrote Twhirl were to develop a Plurk client in the near future. What if afterwards Bear decided to stop supporting Twitter because of the headaches and money it was costing Seesmic to stay up with the changes Twitter is putting in place without even notifying developers ahead of time. Users en masse would flock to Plurk because it would now be the best option to them through the same means they used to use Twitter. This isn't something to take lightly, and while Twitter is going through normal growing pains, I don't believe they have the right people in place to handle the pains they're going through - read the development lists and you'll find I'm not alone in this thought.
    • ^
    • v
    I thought of making an open-source twitter clone in Erlang, a language far more suited to the application than Ruby. Do you think API developers would switch/add support for it?
    • ^
    • v
    I always thought of it as a possibility but I never knew they changed their API's just like that . Moreover i am equally disappointed by their reps reply on the forum. BAD
    • ^
    • v
    Developer frustration certainly isn't a good sign for Twitter but I don't believe it's as bad as you might think -- developers represent a small fraction of the Twitter population. Twitter's biggest problem is stability. If the users can't do what they want because the system is unavailable, they will eventually start to look for a replacement and that's when it's officially the beginning of the end.
    • ^
    • v
    Bret, the users will forgive stability issues in an infancy stage such as this. The developers can't afford to - many of them are trying to make money off this API. The majority of users on Twitter use it through apps which the developers have put together. If Twitter isn't stable and developers bail, the users will have no choice but to bail as well because the developers were providing to the users the majority of the tools we are familiar with today for Twitter.
    • ^
    • v
    My social network message S:N was just horrible after sucking in things or homing them to FriendFeed (lesser extent Plaxo Pulse).

    I dropped off FriendFeed and came back to Twitter.

    For me, there was too much dialog in FriendFeed. I still like Plaxo Pulse squelch features.
    • ^
    • v
    qthurl, again, this isn't a user issue - even if Twitter fixes problems FriendFeed can't provide, when the developers leave all you will have is Twitter.com to rely on in the first place. The majority of users that use it through Twhirl, Twitterific, Ping.fm, and other sources will bail because that was the best way they had to use Twitter, and now the network you have on Twitter will no longer be as effective as it used to.
    • ^
    • v
    Well, I don't know you can rely on Twitter.com or anything free online for that matter. Rely, to me, would indicate some kind of implied SLA and expectations beyond 99.5% uptime and financial incentives to hit that mark consistently at lower price points.

    For example, I pay for both LinkedIn and Plaxo which both offer a status update service. I'd feel very justified in launching into a tirade with them since I pay for those services. If I was a developer on those services I'd expect an API envelope for acceptable use to be honored and available as well. Were I to pay and develop on that API, again, the tirade would be justified.

    I just recall that LiveJournal had major issues with uptime but the stats.bml page still shows a ravenous crowd seeking it out regardless.

    The point I failed to make is that I'm not a developer and I'm still finding my way back to Twitter because of the model. I expect a "death" is a bit much to see for Twitter but I can see a parallel to Friendster or other stumbling or painfully slow services that became less relevant over time.

    If I find an API enabled tool such as those you mention (that don't hog CPU/RAM, btw...) that provides me developer powered access to a status update service like Plaxo or LinkedIn... sure, I'm gone.

    However, I don't see other services stepping up for the microblog style and format I am accustomed to right now with Twitter.
    • ^
    • v
    Twitter is too popular and has so many vocal early adopters that they are going to face a huge challenges to meet demand. Like a great hotel or food joint, the pain to remodel gets harder the more popular it is. Someone will nail the features/functions people expect. I hope it's Twitter. If not, I expect to see users migrate where they can get the service they want. Twitter will be a great case study--let's hope it's a positive not negative ending.
    • ^
    • v
    Brad, to add to that, imagine if the food vendors to that restaurant could no longer get all their food into the restaurant because of the remodel? Also, what if they had to pick a different route, and go through all kinds of hoops just to get their food into the restaurant? Soon no one would want to supply food to the restaurant, and by the time the restaurant was done remodeling all the customers would have moved elsewhere. That's just one analogy - I'm sure there are many more, but again, the developers are key to the success of Twitter. The developers bring many of the users Twitter currently sees, and when they start bailing, so will the users.
    • ^
    • v
    This article has the best CSS for an inline picture that I have ever. seen. Gorgeous. Sorry if this isn't exactly on-topic.
    • ^
    • v
    I aim to please :)
    • ^
    • v
    My handing off of Net::Twitter (to Kee Hinckley, by the way) was a bit more nuanced than just frustration at Twitter.

    I was maintaining Net::Twitter, and I didn't really use Twitter personally. I had an account, sure, but I wasn't doing anything interesting, and certainly wasn't eating my own dogfood, as it were.

    The folks at Twitter were responsive to the few times I encountered bugs in the API, but I really didn't have the insight to recommend wholesale changes, other than "Hey, can you make it so Twitter doesn't crash and burn in a stiff breeze?"

    I also found myself struggling with the random emails I'd occasionally get from people who assumed that I'd be more than happy to teach them perl. I would get the most inane questions from people struggling with "Hello, World!" who obviously didn't have the base knowledge to handle an OO module. This is NOT, I might add, a Twitter problem.

    In the end, Kee emailed me with a list of things that he thought Net::Twitter should do, and I couldn't disagree. I knew I didn't have the "give-a-shit"-ness to make the wholesale changes he proposed, so I made him Co-Maintainer and I'd expect him to come out with Net::Twitter 2.00 at some point.

    All that said, however, I don't think that Twitter is where the "cool things" are happening. I've recently become aware of http://identi.ca/ and the open Laconica software behind it, which, while still raw, is driving this arena in ways I don't think Twitter can follow easily. They just added a Twitter API module. http://use.perl.org/~perigrin/journal/36956 Go figure.

    Laconica does not have 100% of what it needs to gain any sort of wide scale acceptance, yet. It will. It's open, it's got a voracious crew of nerds behind it, and it's coming up fast.

Trackbacks