Home - Stay N Alive

"Don’t Worry About It – It’s Going to be Awesome, and You’re Gonna Love It"

Posted on April 14, 2010 by jessestay

I’m currently sitting in the audience at Chirp, Twitter’s developer conference where they are anticipated to be revealing their plans for the future and overall strategies from here forward. One of the big announcements so far was from Biz Stone, who boasted that Twitter has over 105 million registered users. The entire premise of all talks thus far has been about these numbers. No real big announcements thus far. I’d like to focus on that number though:

Twitter boasts 105 million users, which is very accurate when you look at the unique ids for users. In my site, SocialToo’s user cache, the maximum user id that we have recorded (out of 5 million cached users) is 132,851,613. So, considering a large portion of Twitter’s users have been deleted, that number of 105 million would reflect most likely exactly the number Biz announced this morning. It’s important to note this number is not total active users like their competitors such as Facebook are announcing.

In contrast, Facebook.com, one of their biggest competitors in the status space (and social advertising space), boasts a total of over 400 million active users, which they freely announce in open form on their press website. In addition, over half of Facebook’s users log in at least once daily, which I’m pretty sure is far from the numbers Twitter is announcing. A former employee of Facebook once told me Facebook actually has over a billion records of total registered users in their database. If that is true, it would put Facebook as the single largest database of linked individuals in the world, next to the Mormon Church’s FamilySearch.org (which, a majority of that database is dead individuals). Twitter pales in comparison.

The big theme I’m hearing from developers at this conference is that Twitter needs to be more transparent. In reality, we don’t care about what Twitter’s numbers are. We don’t even care if they compete with us. We just want Twitter to be honest with us. We want full vision of where they’re going, what their real numbers are, and what we can do with those numbers. In the end, Twitter’s platform is useful because of what it contains, not how many people are using it. Padding numbers doesn’t help that.

I certainly hope there wasn’t any waving of the Jedi hand when Biz Stone said, “Don’t Worry About it – It’s Going to be Awesome, and You’re Gonna Love It”.

Twitter Testing "OAuth Delegation" With Select Partners – Genius

Posted on February 5, 2010 by jessestay

A common complaint amongst Twitter developers has been that Twitter’s OAuth, the authentication process you see when you click the Twitter login button on a 3rd party website and go to a Twitter-looking page with a “Allow” or “Deny” button, is too complicated. Mainly, from a user experience perspective, users are required to leave the 3rd party site completely in order to log into Twitter, then get redirected back to the 3rd party site again. If anything breaks along the way, the user is left wondering what to do, and valuable logins, purchases, or registrations could be lost. Facebook has solved this by enabling users to do all the login process via Javascript they provide that produces a popup. Users can log into Facebook without ever leaving the 3rd party site. It appears, based on a thread on the Twitter developers list, that Twitter is planning to one-up Facebook by allowing users to log in to 3rd party sites without ever even needing a popup or any type of redirect, and they’re already testing it with select partners.

The topic came up when other developers noticed that the site, TwitPic.com, was allowing direct Twitter logins right on their own website and somehow posts from TwitPic were showing up with the TwitPic name and link next to the post on Twitter. This normally isn’t possible without enabling OAuth login because Twitter has disabled the functionality for any non-OAuth produced Tweet. In fact they have said in June of 2010 they will be completely removing the ability to login through Twitter on 3rd party sites via plain-text authentication. So how is TwitPic doing it?

According to Raffi, an Engineer on the Twitter API platform team, Twitter is currently working on a new “OAuth Delegation” standard that will allow applications to allow users to log in via Twitter on their own sites, while still maintaining the control over Apps that OAuth gives providers and users. So, on TwitPic, for instance, you can log in to TwitPic.com with your own Twitter username and password right on the TwitPic site itself, yet you’ll still have full control on Twitter.com to revoke access to TwitPic at any time you want to. In addition, Twitter, at any time, can remove TwitPic’s ability to publish or access the Twitter API since they still have to use OAuth to make Twitter API calls.

If the hints in the developers list thread prove true, developers will be able to take the plaintext username and password, still store them somewhere, but in order to make calls through the Twitter API they’ll have to somehow send an OAuth key with their requests to Twitter along with some way of identifying the user. My guess is, in essence, the app will send a one-time login on behalf of the user to Twitter (most likely via a secure SSL encryption channel or similar), and Twitter will return to the app an OAuth token to make API requests with on behalf of that user in the future. In my opinion, this is still no different than storing an OAuth Token in a database that would give apps the same access as their Twitter username and password.

Security Concerns

While storage may be no different, I’m sure there will still be those concerned about this approach. For instance, what happens when users get used to entering their Twitter usernames and passwords on 3rd party websites and decide to do so on a malicious website? We’ve seen how used to entering Twitter credentials people get with websites that look like Twitter itself with the rampant phishing attacks recently.

Maybe Twitter is feeling comfortable enough that they can be proactive about such misuses and password collection. The risk is still there though and hopefully the OAuth Delegation Twitter is getting ready to launch will cover this problem.

Partners

Thus far, it seems TwitPic is one of the partners testing this new delegation standard Twitter is working on. Several others were mentioned in the developer discussions about this as well. For instance, Seesmic Look is also taking similar credentials without any OAuth redirect, yet still shows the “Look” source in Tweets generated with the app. One developer pointed out the information that could be retrieved from the new requests, and the security of it all is a little concerning.

Whatever it ends up being, the winners will be desktop and mobile client developers. Right now developing a mobile or desktop app involves deep integration into the browser in order to legally get the user logged into the app. It is why we see so few native desktop clients and so many AIR apps. AIR is a browser-based solution.

I’m very interested to see what happens. The Twitter team is supposed to announce more details very soon and I’d like to find out more about what this means for developers, how secure it is, and how much recoding I’ll have to do to enable it in my app. Whatever it is, you can bet it will be one step simpler than the currently more-simple solution which Facebook provides. This is getting very interesting! Let the API wars begin…

Twitter, It’s Time to Open Source Your API

Posted on December 17, 2009 by jessestay

With the recent launch of a “Twitter API” by both Automattic (WordPress.com) and Tumblr, it is evident that developers have a need to implement similar APIs, on similar platforms, reducing the effort to retrieve data from multiple platforms in a single client. With Tweetie, for instance, you can simply change a single URL to “WordPress.com” or “Tumblr.com” or “Identi.ca” and immediately be receiving updates from your friends on those services, and even post back to those services. I argue this approach is very closed though, as for each and every implementation of a “Twitter API” (which ironically has nothing to do with Twitter), the developers need to completely re-invent the wheel and copy what Twitter has done based on documentation of Twitter’s own API to access its data. Readwriteweb even went to the extent of calling this approach “open”. There’s nothing open about it. Each developer implementing their own “Twitter API” (and especially calling it such) is blatantly ripping off Twitter’s API to do so under no license whatsoever and Twitter’s just standing back and watching. I think it’s time Twitter releases their API under an Open Source license to relieve this mess and protect their IP.

Open Sourcing APIs is nothing new. Of course, Google, with OpenSocial, did it and even standardized their own API for “containers” to easily implement the same API across multiple sites. All the code was provided for developers to do this and we quickly saw sites such as MySpace, Hi5, Orkut, and others all implement the same standard, reducing the code needed to port an app from platform to platform.

Facebook did the same with their platform. A little known fact is that any developer can go to http://developers.facebook.com/opensource.php and download the Facebook Open Platform, along with many other very useful open source tools. Immediately they have access to enable FBML, FBJS, and other aspects of the Facebook API to developers on their own sites, standardizing the Facebook platform amongst sites that implement it. Bebo was one of those who took up Facebook on this offer. Others can too.

What we need now is a standardized platform for sharing micro-content. Some have proposed RSS do this, which is fine with me, but since developers already have apps built on Twitter which this would go with it makes sense to also enable a standardized platform for developers to code on for these types of apps. Such an open-sourced code-base would enable developers to not have to change their code to enable access to similar sites beyond just Twitter. Twitter right now is a closed platform, plain and simple. With the exception of OAuth, they are based on a proprietary API, do not support open content protocols, and even their real-time stream is proprietary.

A good step for Twitter would be to open source this API. Enable sites such as WordPress, Tumblr, Status.net, and others to easily integrate it into their own platformse without the need to re-invent the wheel. Put it under an open license, and then your IP remains protected. Until that point developers are going to continue ripping off Twitter’s API, and Twitter’s IP slowly starts to go down the drain. I’d love to see Twitter take a lead in this process – it took Facebook just about 6 months to open source their API. Why haven’t we seen this yet from Twitter?

Or are they the next Compuserve?

Where is Twitter’s Emergency Response System?

Posted on May 31, 2009 by jessestay

The buzz has been swirling around the Twitter developer-sphere about a bug that has been going on for almost a full day now. Louis Gray reported it first at around 12am MST last night, and the first post to the Twitter development mailing list went up at around 2am MST last night. But Twitter is no where to be found, and it’s really starting to hurt some developers. So much that the very popular TweetStats, by Damon Cortesi has completely had to shut down until the service is re-enabled.

The bug is surrounding the display of the source app via both the API and in the Web UI showing which application a Tweet has come from on Twitter. Currently, according to TweetStats, 100% of the messages on Twitter are displaying they are coming from the Web. Developers and bloggers are complaining but no one is being heard.

In fact, according to Twitter, both Evan Williams (founder of Twitter), and Alex Payne (Twitter’s API Lead) are both in Maui on unrelated trips (Alex’s is for vacation – it’s unclear why Ev is there), posting pictures of the frozen drinks they are having and talking about the massages they are getting. Alex even stated he doesn’t have his laptop with him. Of course I don’t expect him to be reading this, and I congratulate him for being able to have some very deserved time-off–but what do we do when the API goes down?

Twitter developers have asked repeatedly for a paid API service which they can be guaranteed more up-time and more API access, along with a higher tier of support. Even Iain Dodsworth, the developer behind TweetDeck has mentioned in conversations on FriendFeed that, with unlimited API access, they would be able to deliver some of their “dream functionality”, and would “pay a lot” for such. As the developer behind SocialToo, I firmly agree with his statement – it would be a cost-savings for me. Regardless, there is still no good way to get Twitter support when their API goes down. Developers need some sort of Emergency Response System, and I think Twitter should charge for this level of service.

In times where developers’ apps go down many livelihoods are at stake. Money is not being made, and with a very poor support system by Twitter as is, and no way to guarantee support during such circumstances, developers are putting a lot on the line writing for such a service. Currently, the only means is via the Developer mailing list, and as we can see there is yet to be a response from Twitter via that means, and at least one entire application has been put out of business because of the issue.

Will there be a time we can see a prioritized service from Twitter that developers can pay for and guarantee service? I think with today’s example this option has just become a lot more important. The free service simply isn’t cutting it any more.

What do you think Twitter should do?

Twitter API Lead Changes Priorities With New Book

Posted on October 27, 2008 by jessestay

UPDATE: Be sure to see Alex’s comment below for his view on this.

I am a huge fan of Twitter, regardless of what I say or ever complain about. As a developer of Twitter apps, I want to see it succeed. However, I will sound the warning bell when I see things happen that could detrimentally affect the service. A post on his personal blog today by Twitter’s API Lead, Alex Payne, has me concerned. In the post, he announces that he’s writing a book, and ironically, the book has nothing to do with Twitter development.

In the post, Alex announces he’s writing a book on a new, JVM-based language called Scala. He did a presentation on it awhile back at C4, talking about why he was supporting it and why it was a good language. Alex is a smart guy, and it would seem he’s a very appropriate author for such a book, but in his blog post he mentions nothing about what is going to happen with his work at Twitter – what are his priorities after he begins writing this book?

In development for my own site, SocialToo, I’ve dealt quite a bit with Alex, so I know he’s a hard worker. He’s answered my e-mails in the middle of the night, and even over the weekend. He’s always talking to the Twitter development list and lately seems to be doing a great job interacting with developers.

As an author of 2 books, one of them O’Reilly, I’m a bit worried Alex’s priorities may be shifting. Writing a book is no easy task, and especially not an easy task to maintain a full-time job at a very time-consuming startup that still doesn’t have its API squared away. He should expect to spend several weeks in a row, full-time, writing, editing, and re-editing the book. It’s not very easy to write a book in your spare time – he should expect his focus at Twitter to diminish. There’s no avoiding it – that’s why O’Reilly gives authors an advance, so they can support themselves during the time they are writing the book. O’Reilly has tough deadlines to get books to print in time.

So, seeing perhaps the most important player in Twitter’s API development completely shift their focus after posts like this one last week by Alex himself, I can’t help but wonder where the priorities are at Twitter and who’s actually working. Does this mean we’ll never see them open the firehose? As a Twitter developer, I’m truly worried about this announcement.

Twitter Bringing Rate Limits Back to Normal

Posted on July 8, 2008 by jessestay

On the heels of a post this morning by Biz Stone, it appears Twitter is beginning to bring the rate limit for posts through the Twitter API back to the 70 per hour it used to be. For the last several months, Twitter has brought that limit down to only 20 requests per hour. Per the Twitter developers mailing list just now, Twitter has now raised that limit to 40, and will gradually be raising it back up to 70 in the upcoming week.

This is welcome news in the week of months of API and service outages. What this means is that you, as the user will no longer see the “Rate Limit Exceeded” error you may be seeing through clients like Twhirl. In regards to the API this leaves mainly just the XMPP stream that they need to re-enable for developers – this may not be happening any time soon however, as Twitter may be looking to only enable a select few developers access to the stream.

Has this request limit affected you as a developer? How about as a user?

Twitter Continues to Fail Developers, Why They Will Still Succeed

Posted on June 27, 2008 by jessestay

I’m going to dub this Part 2 of my Twitter Love/Hate fest – this should be my last installment for awhile on this topic, I hope. In reality, I really love Twitter. I have a good network on Twitter and frankly, I wouldn’t have met many of you if it weren’t for Twitter. Twitter, in many ways, has changed my career. For that reason I really don’t want to see it fail. It is perhaps this reason that I am so critical of it at times – it’s my hope that someone at Twitter can read these and at least see what the world is really thinking, hoping, and wishing at a given point in time about how their service is performing and being perceived.

Twitter is still continuing to fail developers!

It’s examples like the one I learned about recently where the service, Gridjit, was put offline entirely because of a rash decision on Twitter’s part to remove a feature from Twitter’s API with little to no notice for the developers to respond. In the time Gridjit was down, they have since added FriendFeed support, and I’m willing to bet they have other strategies that don’t include Twitter. Now that Twitter has re-enabled that feature, they are now back up and running, but Gridjit is just another example of the frustration that is occurring amongst developers in the Twitter development community.

Just today, for example, I noticed Twhirl was no longer working with @replies. I remember seeing posts on the Twitter blog recently stating that the @replies tab would be removed, but I remember no notice to developers stating that the features that enable this on clients like Twhirl would be disabled in the API (they did let us know the API was down today though – still no notice it would be down when they took down the replies tab, and nothing to the developer mailing list that I’m aware of).

Twitter tries, but not quite enough

I mentioned last week that Twitter was hiring on their site, but it just wasn’t enough because I think the problems they have exist at the management level. True, they even hired 3 new individuals recently, but they are developers used to being managed, not managing large groups of other developers. Twitter really needs one or two individuals at the top that have true Enterprise-level experience managing these types of IT issues, and very large groups of developers. Remember, Twitter isn’t just the developers that work for Twitter, but the vast group of developers that are also writing applications for their API. The individual in charge of development and IT efforts at Twitter has to have strong experience in managing very large development teams, and working with a very large user-base, in which any change to any part of the system could effect. Twitter needs a staging environment in place, and a system of testing every single change that goes into place before it actually goes out live into the production environment.

They are showing some promise though!

Just this week Twitter announced the inclusion of 2 new investment partners in their list of investors. One of those, Jeff Bezos, does have experience managing the types of issues and large development audiences that Twitter lacks. This is a huge move for Twitter, and long overdue! Jeff will bring Amazon’s firm experience in scalable web environments, and I hope, enable Twitter to enter the cloud more than they currently are, and reduce the tough scaling issues they are experiencing right now.

You can bet you’ll see Twitter begin adopting Amazon’s AWS Cloud services here soon now that Bezos is on board. Amazon has the capability to scale almost instantly as traffic spikes hit, and they seem to be doing it better than any other right now. Twitter really needs this service!

Why I think they’ll still survive, no matter how many developers leave

Twitter is a Marketer’s Paradise. Twitter is full of content about the every-day life of millions of individuals and their friends, who they connect and communicate with, and what their frustrations and interests are. Businesses are beginning to embrace this and use services such as Summize to track information about their Brand, their image, and even their competitors that they could never track before. Businesses can finally track real people instead of just “visitors”.

This is powerful and valuable information to many businesses out there. Because of this it doesn’t matter how many times Twitter goes down or how many developers stay or go from Twitter. So long as users still have networks on Twitter and the Twitter user-base continues to rise as it appears to still be doing, businesses like H&R Block and Comcast and even NASA will still flock to Twitter as a valuable tool in gathering data about their customers and fans. These businesses have it in their best interest to see Twitter succeed, and you better bet they’ll do their best to help out in that effort. Twitter isn’t going anywhere my friends, and I still haven’t retracted from that statement.

Developers Bailing on Twitter

Posted on June 19, 2008 by jessestay

I’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.

Twitter Kills Important Features on the API With Just a Few Hours Notice

Posted on May 31, 2008 by jessestay

I saw some very concerning issues on the Twitter development list today, and my frustration has only been increased after reading some of the claims of Blaine Cooke today on TechCrunch. Yesterday, the one thing that seemed evident, and perhaps I’m wrong on this, but Ev Williams and Biz Stone do not seem to have much of a technical background. They made this clear in the interview, and there’s nothing wrong with this, assuming they have the technical staff to handle it.

Today on the Twitter development mailing list something was made apparent – experienced developers and businesses on the Twitter development mailing list cannot trust the architecture of the API that runs on Twitter. Just yesterday, a crucial feature of the API which allowed the retrieval of an individual’s friends and all of those friends’ timelines was removed from the Twitter API.

About 1 week ago, Alex Payne, the developer Biz and Ev kept referring to in the interview yesterday as having a lead role in the development, announced on the developer mailing list that this feature was going to be removed and asked if anyone was using it. With only about 5% of the applications saying they needed it, Twitter removed the method Thursday with just a notification on the developer mailing list and about 8 hours notice, no other notification elsewhere or warning that it was happening at that point.

All of the sudden, application developers everywhere were saying they couldn’t run their applications because of this change. These were applications such as Hahlo, Twitterati, Twibble, and Gridjit. What’s the issue here?

The issue is Twitter isn’t communicating effectively. We addressed this yesterday – I think they realize it, but I want to reiterate it. I can’t help but wonder if the experience is even there to be able to communicate effectively. I’ve worked as a developer in several publicly traded companies, one of them a Fortune 40, and some of the decisions the Twitter development staff have made would have gotten me fired at previous employers I have worked for. Where is the experience, and how can I, as a business and developer using Twitter trust them to build something on top of? I want to see where the experience is before I build any more on top of the Twitter API – does the Twitter staff have LinkedIn profiles?

Now, I’m not trying to criticize any individual at Twitter – I want to think they have the experience necessary to handle this, but I’d prefer they not pull the wool over our eyes if there is not enough experience at Twitter to handle the API I am trying to build a business off of. I know for a fact there are many smarter people using the API that could help analyze the experience if they need that help, but we need Twitter to communicate with us and let us help them out. Because businesses are being built on the API we want to see them succeed (I’m writing this as I wear my “Wearing my Twitter Shirt” I got from them yesterday). I think, as they said in the interview yesterday, while it could take months to get things in place, we, as businesses and developers could help them out if they just let us and communicate properly with us.

The questions I asked yesterday were centered around the developer and how we could help them. They told us to communicate with them. I really don’t know how we can communicate effectively with Twitter if they can’t be open to us back. I even posted this on the mailing list this morning, and received absolutely no response. As a Twitter API developer and business owner, I don’t know how much longer I can keep my Apps on Twitter. I know many others share the same frustration, and once the Apps begin leaving, so will the users.

I think, and hope, based on the interview yesterday, that Twitter understands this. I’m optimistic they do. However, we need an open communication channel, consolidated, and the experience to know how to manage that channel effectively with the API, or new opportunities are going to arise very quickly wich developers will leave to.

UPDATE: It appears that Twitter has a pretty experienced crew, per their recent blog post. Again, you still have to keep in mind that it may take time to fix the problems that are already there – is it worth the wait?