Josh Babetski : Quixotic Bravado

Recent links posted to Delicious:

• Django snippets A site for users of the Django web framework to come together and share useful "snippets" of reusable code.
• Django Heresies
• jespern / django-piston / wiki / Home — bitbucket.org A mini-framework for Django for creating RESTful APIs.
  Piston is a relatively small Django application that lets you
  create application programming interfaces (API) for your sites.
• pysmell - Google Code PySmell is a python IDE completion helper.
  It tries to statically analyze Python source code, without executing it, and generates information about a project's structure that IDE tools can use.
  There is currently support for Vim, Emacs and TextMate. Feel free to contribute your own favourite editor bindings, or to improve the existing ones.
• The Best Free Web Icon Sets - WebIconSets.com

So Twitter is going to begin rate limiting requests to their API soon. Some developers are upset over this. Some of the reasons they are upset include:

• They feel Twitter should “fix” the existing API, citing it as a reason they need to make so many requests currently
• They feel Twitter shouldn’t have a rate limit at all. This is of course ignorant. Yes, let’s not safeguard against some dude’s poorly coded app and let it bring down or slow the Twitter infrastructure for other devs.
• They’re investing time and effort into building applications which depend on these APIs. As the apps gain popularity, they’ll begin or would already exceed these limits.
• They’re building a business on a service using Twitter APIs; that business is now at risk

Here’s the real reason some of them are upset:

They feel an unjustified sense of entitlement.

Twitter’s Point-of-View

Now, I’m not unsympathetic to the position this now puts many devs in. I know people who are building cool things using Twitter’s API, but I can also see things from Twitter’s perspective.

• They need to control costs. Pinging the crap out of their servers costs money and many of these services are putting heat on these servers without cutting Twitter a check or otherwise being mindful of resource consumption.
• They need to monetize their service. People are monetizing something Twitter hasn’t yet. If Twitter can’t make money, eventually neither will anyone building applications that piggyback off of them. Meanwhile, getting overhead costs under control is prudent. See above.
• They offered these developers no agreement as to how available they must make their API service and no guarantees. So you spent six months in your basement building a cool Twitter service. I sincerely feel for you, but Twitter didn’t ask you to do it. Using the Twitter API to archive your tweets is one thing, attempting to build a business on top of it is another.
• This policy change likely impacts only a very small percentage of developers.

But They Need Us

Somewhere a righteous dev is saying to themselves: “But all these applications we made helped make Twitter the popular service it it today.”

Of this I have no doubt. I’m sure the gang at Twitter HQ is aware of this too. There’s already reasonable speculation if this move will hurt Twitter’s growth, but maybe they want to now better control that growth. Still, now will begin the uneasy dance between developers and Twitter over where the ROI line is for both. Developers want to make applications built on Twitter and potentially profit. Twitter needs usage and popularity to stay high, in addition to initiating this monetization strategy we’re all curious about. Instead of complaining how devs have been wronged by Twitter, they should ask themselves some questions:

What is the value proposition of your application to Twitter?

The service is already crazy-popular so you can’t really offer the value proposition that their app will increase users substantially. I would speculate that most people onramp with Twitter on the web site, then migrate to third-party apps later. How do you help keep people using Twitter?

Is it popular enough that your users will reduce their Twitter usage, make their dissatisfaction loudly known to Twitter or not use it at all if your application went away?

Is the value of Twitter availability such that it’s worth paying to have higher rate limits? Enough users to make Twitter think twice?

If so, instead of irking the Twitter team with bitching, start a constructive dialogue with them over what kind of arrangement you can make to maintain a higher rate limit.

But the API Sucks!

It certainly can be improved, but flush with cash or not, Twitter is a start-up and focused on making that service sustainable in order to eventually return value to their investors. If you can articulate how fixing their current API accomplishes that and warrants a higher priority than other tasks in front of them, I’m sure they’ll be happy to listen to you.

Bottom Line

If you still feel so wronged by Twitter’s actions, consider it a cautionary tale and something to consider when building an application that has a dependancy on a service you’re getting for free and without an SLA.

Recent links for http://del.icio.us/quixado:

• My Git Workflow | Oliver Steele
• Barking Iguana: Getting started with Rails 2.0
• Official Google Mac Blog: App Engine Launcher for Mac OS X
• Git User’s Manual (for version 1.5.3 or newer)
• Git cheat sheet (PNG)

Develop Freely!

Today MapQuest announced a Free Edition of their platform: 6 APIs for mapping, routing, and geocoding in JavaScript, AS3 (ActionScript 3: Flash Flex, AIR), FUJAX (write JavaScript, get Flash), Java, .NET, and C++.

Check out the MapQuest Developer Blog. Here you’ll find a familiar author among all the how-tos and other useful information. Then check out the MapQuest Developer Network and go build something cool with one of the APIs. Developer Choice: we gots it. 

Recent links for http://del.icio.us/quixado:

• Social Graph API - Google Code
• Ecommerce Registration Usability Tips - Get Elastic Ecommerce Blog
• Iconfactory : Software : Iconbuilder IconBuilder is a filter for use with Adobe Photoshop or Fireworks that makes creating icons for either the Macintosh or Windows operating systems a snap.