Twitter engineer Alex Payne sent out a prophetic tweet last month. In this message to the Twittersphere, he basically says that Twitter.com is going to be so badass and feature-rich that you’ll soon rethink your need for 3rd party Twitter clients. This caused an uproar in the developer community as many (over-reacting) people took his comments to mean Twitter was going to try & kill off the alternative clients. @Al3x and the rest of Twitter HQ went into damage control mode to explain that Twitter wasn’t attacking alternative clients and that they were still supportive of the developer community. Hugs all around, right? No. I think most people saw the writing on the wall at that point.

I know I have. So, after 2 years of developing my own Twitter clients, I’ve decided that I’m finally throwing in the towel.  Twitter has built a great web app, so there’s little need for me to continue. There’s part of me that is sad, but mostly I’m really happy for Twitter.  Also, I’m relieved as I can now focus on something else.

A little background… It wasn’t up until recently that Twitter’s own web client (Twitter.com) lacked most of the features that I wanted, so I was forced to build them on my own. I began building Tweenky almost 2 years ago and the goal was simple… create a Twitter web client that had the following features:
A) A friendly Ajax interface
B) Integrated searching
C) Groups
D) Saved searches
E) Fixed the @reply problem where replies were not visible to your replies feed unless it started with “@username”
F) Had other basic shortcut features (like retweet links)

When it was ready in the summer of ’08, I released it to the wild with the help of TechCrunch and other tech blogs, who all praised its set of features. I’m not going to claim I was the only one working on such features. Most of them were just obvious extensions to how people really wanted to use the Twitter service. They would have been implemented by Twitter themselves had the service been stable enough to add feature development resources. It’s funny to think that between 2006 and 2009 Twitter.com remained largely unchanged. Why? Because they were generating too many failwhales and fixing those was the #1 priority.

By 2009, the engineering team had rebuilt Twitter into a stable platform and they were finally able to let the front-end developers loose and start working on features. First came some ajaxy goodness, then integrated searching the replies/mentions fix. Later in the year they added Lists and the Retweet feature. At that point, I noticed Tweenky started to become less & less useful. Others did too and the userbase started to decrease.

Enter 2010… The front-end team is beginning to crank out features & tweaks at a fast pace. So far this year we’ve seen hovercards, location dectection, and integrated maps. It’s finally at the point where the speed of innovative features is out-pacing what the developer community will be able to keep up with. There are still some major clients, such as Tweetie (on the desktop) that haven’t even integrated Lists yet. I’m not going to attempt to work on the hovercards or integrated maps, not because I can’t do them, but because what’s the point? I’ve actually begun using the Twitter.com web client more than my own client because it simply lacks essential features. Sure I can add them, but once I’ve completed that, the larger-than-1-person-front-end team at Twitter will have rolled out a couple more slick features, and I will always be playing catch-up.

So here’s the point of this post… I’m done. From here on out I suspect the majority of my Twitter time will be spent on the Twitter.com web client. Don’t take this the wrong way, I’m actually really happy for Twitter and the awesome front-end/UX team they’ve assembled (which includes a number of ex-Yahoo’s =D ). They’ve implemented most of the “must-have” features that 3rd party developers have been working on for years. This is a good thing because those features are now available to the majority of the Twitter userbase instead of a small portion. I suspect over the course of 2010 and beyond, the pace that we see new features will continue to increase, and with every new release, more & more 3rd party developers will cease working on their own clients. This will be a bitter pill for some in the developer community to swallow but the side-effect is they’ll be spending less time on simple, basic features that Twitter.com should have, and instead hopefully on innovative non-client apps or things completly unrelated to Twitter.

I’m happy with this direction. The main reason I’ve developed Twitter clients is to geek around and gain experience in areas I feel my knowledge is lacking. I’ve never approached my client development as “OMG, I have to get as many people as possible to use this thing so I can make money and/or sell it!” I’ve never attempted to monetize my work. I’ve just approached it as there’s a certain user experience I want to have with Twitter, and if anyone else wants to join the fun, cool. No? That’s cool too. Work hard and good things will come.  Having converted the original Tweenky client from mostly PHP to all JavaScript, I’ve been able to gain valuable experience with jQuery, YUI3, & JS in general. To me, that is satisfying enough. All the JS, REST API, and scaling knowledge I gained through this process is one of the reasons I now have a job at Yahoo.

So what’s next? I dunno. If I’m spending X less hours per week trying to replace Twitter.com, I can now spend X hours working on something else. I’ll most certainly work on some non-client Twitter apps, but I’m hoping to spend the majority of my time on non-related Twitter projects. Maybe some much needed Node.js hacking? Maybe some WebOS apps? Hmmm… Stay tuned.

P.S. Tweenky has always been an open-source project. You can find the source code on GitHub. You can also find Tweenky’s cousin “Tweetanium” (a YUI3 rewrite) on GitHub as well.

Up until now the Twitter developer ecosystem has been very closed. Sure the Twitter APIs are as open as possible, but all the clients out there are largely closed platforms. There are a few exceptions, including Spaz and Tweenky (my client) which are open-source. It is great to have a starting point (aside from raw libraries) that gives developers a place to start with when building a Twitter application. With Seesmic Desktop invading Windows with a programmable version that you can write plugins for, this is a huge step that hopefully will push other developers/companies towards the same model.

When I launched Tweenky about 18 months ago, I hadn’t event thought about making it programmable, but pretty quickly afterwards I realized the potential it could have if it were programmable, and so I began a rewrite, and coded it in 99% JavaScript with two plugins out of the box, Twitter and Identi.ca. I had plans for other plugins (Facebook), but the problem with developing a platform, and not just an application, is that it takes a loooot of time. For one guy working in his spare time, it just wasn’t going to be possible to abstract out a platform and develop a community around it. So, I started with another rewrite and only focused support for Twitter. I still think it was the right move given the limited amount of time I can spend developing it.

What I’m really waiting for is an easy way for Twitter developers to monetize their applications. We’ve all seen what the Apple has accomplished with the App Store and the ecosystem they created overnight. While most iPhone developers have made very little, others have won the lottery and struck it rich. While Twitter (the company) has been very supportive of the developer community, they should really look at giving it a push and figuring out a way to monetarily reward Twitter developers. Nothing gets developers going like a big, fat, diamond crusted carrot dangling in front of their noses. Afterall, Twitter wouldn’t be Twitter if it weren’t for the developers. The various clients are what made the service usable for the hard-core Twitter users that create most of the valuable content.

P.S. You can still view the programmable version at beta.tweenky.com.

Rogers Cadenhead recently wrote a post “The Reason RSS Cloud Failed to Catch On“. In this he argues that RSS Cloud is not sustainable when it begins to scale to thousands of users needing to receive pings every time a post is made. While he has a point, I believe his argument is much more accurate when put into the context of 1999 as opposed to 2009, and it is even more irrelevant a few years from now. This points to one thing… RSS Cloud was ahead of its time.

Today, supporting RSS Cloud is cheap. Bandwidth is a fraction of a percent now compared to what is was 10 years ago along with cloud based virtual servers available for ~$10 / month. I’d suspect a properly tweaked VPS at the Rackspace Cloud or EC2 could handle millions of pings / day without issue. Unlike PubSubHubBub, the content of the post is not delivered with RSS Cloud, it is just a body-less ping, so bandwidth isn’t even an issue. A server supporting these types of capabilities back in 1999 would have cost thousands of dollars per month. Now? Just a few bucks. 5 years from now I suspect it will be free (example: Google App Engine is currently free and could be configured for this service).

Let’s go ahead and take into consideration the dream scenario with RSS Cloud, and that is that we have completely replaced Twitter. In this scenario Ashton Kutcher will have 5 million followers and will need to notify each of those followers when he tweets out 100 mundane posts / day. Let’s not kid ourselves and not think there is a middle man in there somewhere. These services are the “Cloud” portion of whole term. Just like Feedburner and Google Reader are proxies between publisher and reader now (by storing local caches of RSS feeds), there will be many services that would be happy to host the feeds, providing a web client to the reader and analytics to the publisher in turn receiving all the statistics they chew on. Proof? Twitter purchased Summize (search.twitter.com) and Google bought FeedBurner because they saw the value of this type of service. Afterall, the analytics portion of that is the whole business model that Twitter is rumored to be building.

But ok… let’s assume those “Cloud” services never pop up because, hell… I don’t see any reason why they wouldn’t, but let’s just imagine they don’t exist. Solution? TURN OFF THE NOTIFICATIONS! That’s the beauty of RSS Cloud feeds, it’s completely backwards compatible with non-Cloud enabled feeds. If the Cloud server fails to send out notifications, then their subscribers will simply revert back to the old method of routine polls looking for new content. But, failing to notify your subscribers of new content in a sea of real-time has drastic consequences. Even if you are the first to report information, you will always be “scooped” by others because the lag caused by your inability to notify your subscribers. That alone will be enough to even the playing field. As a compromise, you could get away with just notifying a few dozen RSS aggregators (Google, Yahoo, Feedburner) to take care of the majority of your subscribers, and those using readers you don’t notify will revert to polls.

So as you can see, RSS Cloud is currently gaining traction because it wasn’t until now that it was a viable service for the masses. Even now there is very little support within the client portion of RSS Cloud, but I suspect that will be a battleground many will fight for in the next couple years.

Twhirl is a relatively new Twitter client that packs just about everything you need for twittering into one Adobe Air based application.  While Twhirl of course handles all the basic things you need out of a Twitter client, I feel it really shines when you start using the additional features and usability enhancements.

Some of these features include:

• Runs on Windows (200/XP/Vista) and Mac OSX
• Ability to connect to multiple Twitter accounts
• Ability to simultaneously post to Twitter, Pownce and Jaiku
• Extremely easy to install and configure
• Embedded services include Tweetscan, is.dg, Snurl, TwitPic, and Terraminds
• Timeline filtering
• Automatically checks for new version
• New tweet notification windows
• Localized to English, German, Italian, and Spanish

Installation

To install Twhirl, visit Twhirl’s website and on the right side you’ll see links to download Adobe AIR and Twhirl.  If you don’t yet have Adobe’s integrated runtime environment (AIR) installed, follow the instructions you see to install it.  Once AIR is installed, click the download/”install now” link and you should see the AIR application installer begin to download and install the Twhirl application.  Follow the on screen instructions to complete.

Configuration

When you load the application for the first time, you’ll need to set up your Twitter account(s).  Enter your screen name, and another box will prompt you for your password.  You will also see a few additional tabs.  The first being “Colors” which allows you to modify Twhirl’s visual theme.  The second is “Language” where you can select between English, German, Italian, and Spanish.  And the final tab being “Update” where you can check if a newer version exists.

Sending Tweets

99% of your time using Twhirl will be spent looking at the main Twhirl screen after you successfully connect.  From this screen you will see the “river” of new tweets rolling down as they arrive.  You can also post tweets by typing your message in the input box.  Please make not of the TwitPic and “Shorten URL” icons on the right of the input box for a couple very useful tools.

Additionally, you have 9 view types that you can choose from in the drop-down.  These views range from the standard “Timeline” view with is the tweets from those you are following, viewing the archive of your own tweets, viewing your followers’ bios, searching tweetscan.com, and a few more very useful views.

Gripes & Suggestions

I’ve already covered many of the upsides to using Twhirl, but I do have a few gripes and suggestions that I hope the developer can address in future releases:

• When you lookup profiles inside Twhirl, you should be able to at a minimum, click a link that takes you to the user’s Twitter account.  Optimally, I’d like to have the information on how many followers the user has, and how many people they are following.
• When starting up the application, only notify me of direct/reply tweets I haven’t yet read, not all of them.
• Add TweetBurner.com to the list of short URLs.
• Add a Quotably link to each tweet.

Conclusion

Twhirl is my 5th Twitter client over the past 4-5 months, and really, the majority of that time has been spent on Twhirl because it has been my favorite, by far.  I have stuck with it because it offers all the essential functionality I need out of a twitter client, and then some.  It also happens to be the first Adobe AIR application I have actually had a good experience with and it gives me hope for the future for this platform.

Also, check out these reviews for other Twitter clients

• Twitterfox: A Twitterfox Review
• Twitterific: A Review of Twitterific
• TwitterBerry: TwitterBerry, combining BlackBerry and Twitter
• Twitterfeed: A review of Twitterfeed
• Twitbin: Twitter and TwitBin – Microblogging Made Easy
• The Guide to Being a Drunken, Debaucherous Twit
• Netvibes: Using Netvibes for SMO