Fans of microblogging service Twitter are apparently impervious to repeated outages and technical problems--and their enthusiasm is spreading.
Research firm Hitwise on Tuesday reported that traffic to the Twitter site increased 500 percent the week ending July 5, 2008, compared with the same period last year. That's a significant jump for a service that's continually up and down--and still lacking a clear revenue stream.
What's more, many users of the service appear to be unruffled by Twitter's technical issues. The share of returning visitors has averaged approximately 53 percent over the past four months, according to Hitwise.
Twitter also still has a leg up over its few rivals in the microblogging space. Twitter traffic last week was 12 times higher than that of Plurk and 24 times higher than FriendFeed, Hitwise says. So even though Tweeters may be getting restless, not all of them are abandoning the service in favor of similar finds.
"Despite user complaints about outages, Twitter has remained the most popular among the micro-blogging services," Hitwise said in a statement.
Earlier Tuesday, rumors escalated that Twitter was in the throes of buying Summize, a Twitter search engine. Neither Twitter nor Summize have commented on speculation of a possible merger.
Your brain lies to you, says the NY Times in an Op-ed piece about the upcoming elections. For me, the article illuminates some of the implications of the social-media world where information flies at you from every direction. You don't know what's true or false and odds are you can't handle the volume of information in a manner that lets you process it effectively.
Basically you hear or learn something, the brain processes it multiple times and by the time its fully part of your brain you've forgotten where it came from.
This phenomenon, known as source amnesia, can also lead people to forget whether a statement is true. Even when a lie is presented with a disclaimer, people often later remember it as true.
With time, this misremembering only gets worse. A false statement from a noncredible source that is at first not believed can gain credibility during the months it takes to reprocess memories from short-term hippocampal storage to longer-term cortical storage. As the source is forgotten, the message and its implications gain strength.
I find myself following my Twitter list and posting my own inanities having little to no idea if there are implications or if what anyone posts is actually true. This requires a level of diligence that the brain isn't necessarily prepared to deal with as well as a level of attention that goes beyond being a communications utility and into a part-time job.
Personally, this Twitter thing was fun for a while but it has become a burden.
As I write this, Amazon.com, like Twitter, is offline. Amazon's outage is the big news Friday morning. But what of Twitter?
I used to love Twitter. But the site's pogo status--it's up! it's down! it's up again!--is driving me away. I've removed the Twitter sidebar from the Webware home page, and I've stopped religiously updating it. Because I figure its users, and my followers, are learning to not trust it, to not bother visiting the site since it's likely to be down when they visit. Chances are fewer people are reading my Twitter posts now than a month ago.
I believe Twitter is bleeding users. Every time Twitter users go to Twitter.com or to their Twitter app and they see the "Fail Whale," an error message, or just a non-responsive site, they're that much less likely to come back the next time. Instead, they're going to FriendFeed, Jaiku, Pownce, or even the whacked-out Plurk.
Until the Twitter team can get the service working again for good, here's what they should strongly consider: Close the site. Take it offline. Put plywood over the doors and windows, as it were, with a big "We're remodeling!" sign on the front. Ask users if they want to be e-mailed when the site reopens for business and don't send that e-mail until the thing is fixed. Really fixed. Then have a grand reopening party.
It's not like doing this would cost Twitter revenue. It doesn't have any. But if Twitter is going to be online, it needs to be reliable. Twitter is not just a toy. It's a communications platform that people were just beginning to rely on before it overloaded and got flakey. Now, no one can rely on it and we're learning that at any given moment, there's a very good chance that Twitter will be offline. The more people who learn that, the fewer people will visit, and the more people will walk across the street to competing services. Remember how Friendster lost its momentum?
If Twitter can't deliver a reliable experience, I think its best bet is to close until it can. That way, we can all come back to the site at the same time, all together, instead of each of us showing up one by one and finding it deserted.
Related: Disqus' Downtime Reminds Us of Woes for Data In the Cloud, by Louis Gray.
First it started tweeting, then it bore a twin.
NASA is trying all manner of Web 2.0 software to promote its science to the tech-savvy crowd. Months ago, the media director at the space agency's Jet Propulsion Lab began sending out Twitter messages, or 140-character digital notes, about the Phoenix Lander mission to Mars. Now, NASA has created a so-called cybertwin for the Phoenix rover in the virtual world Second Life.
Even though the term "cybertwin" sounds very Web 1.0, the technology is based on techniques in artificial intelligence, such as natural language processing. Instead of tapping NASA's media director for answers, the Phoenix cybertwin calls on a database of knowledge that's been programmed by scientists from JPL. That way, people can ask questions of the Phoenix chat bot to receive quasi-personalized responses about the rover's mission. (The cybertwin was developed by Australia-based start-up MyCyberTwin.)
As you might expect, the cybertwin comes off like a robot.
Q: What is your purpose?
[16:21] Phoenix: I'll be using instruments to probe the northern polar site's soil and ice and I'm here with three main objectives: to study the history of water on Mars, to determine if the Martian arctic soil could support life, and to study the Martian weather.
Q: What is your schedule?
[16:21] Phoenix: I have some pre-programmed commands but mostly I will wait for commands from Earth that arrive in the Martian morning and send my results back in the afternoon. So far I have had commands including the deployment of my robotic arm.
It's hard to gauge whether the Second Life bot will resonate with the virtual community, considering that NASA Web 2.0 promotions can be a mixed bag. So far, the Twitter page has drawn thousands of followers, but Facebook is another story. The Phoenix Lander page on Facebook has only 16 fans. Turns out, social networks can be a lonely place, just like in space.
You can find the Phoenix cybertwin on the NASA Island in Second Life via this address.
Are Twitter's performance problems due to flimsy engineering or the choice of Ruby on Rails to build the application?
In the Twitter developer blog on Thursday, an engineer said that Ruby on Rails still rocks as a Web development platform. The service's woes are due more to a creaky architecture, he said.
Twitter performance problems have brought heaps of scorn from the busy Web 2.0 digerati. That has prompted the company to disclose more technical details like today's Q and A format blog.
Many people have questioned whether choosing to write the application using Ruby on Rails was a smart move and whether Twitter should shift to a different Web development technology.
Ruby is a scripting, or dynamic, language, which means that it can be slower than Java or C for some applications. The trade-off is that in general it's faster to write code with. Rails, meanwhile, is a Web development framework optimized for speed.
Ruby still makes sense for much of what Twitter does--essentially sending messages around the Web--but the company has left the door open to using other languages. The Twitter developer blog says this:
We've got a ton of code in Ruby, and we'll continue to develop in Ruby with Rails for our front-end work for some time. There's plenty to do in our system that Ruby is a great fit for, and other places where different languages and technologies are a better fit. Our key problems have been primarily architectural and growing our infrastructure to keep up with our growth. Working in Ruby has been, in our experience, a trade-off between developer speed/productivity and VM speed/instrumentation/visibility.
The outages and slow performance are due to "popular" members of Twitter with many followers who "tweet" a lot all at once, according to Twitter. Because of that, the company says will put some limits on what some users can do, but it should not be noticeable.
We have some limits, and we're adding more. Legitimate users should never notice them, but these new limits should help mitigate the worst case failures and attacks.
As we Twitt-iots sit around bemoaning the fact that we can't send each other useless junk on a flaky service, I thought I would take this chance to address the notion that this message-scaling problem is new.
It's not. It's very common, and it can be solved.
Scaling a messaging platform is why IBM sells a boatload of MQ series, why the AMQP protocol was developed, and why JMS is nearly ubiquitous. Pretty much every large enterprise has similar scale issues related to messaging, especially in financial services. But they don't have downtime, and if they did as frequently as Twitter, the people behind them would all get fired.
This is a topic I actually know something about. (Disclosure: my company develops an open-source enterprise service bus, or ESB, called Mule.) All of our use cases involve some kind of complicated messaging architecture, whether it be Web-service based, publish and subscribe, one to many, direct connection, etc. And most deal with data transformations and a vast array of protocols.
In my view, what Twitter needs is to adopt a bus-type of architecture that separates the transport from the application and uses a middleman to process the transactions. This is a very common enterprise scenario that needs to be applied. This is what an ESB does.
One example in the Web 2.0 world is OpSource, which is delivering billions of transactions a day as an SaaS provider using the ESB at the crux of the transactions. This is much larger than Twitter and has actual revenue impact. Maybe OpSource can host Twitter?
CNET News.com Editor in Chief Dan Farber suggests a new way for Twitter to make money: Charge for the right to "tweet." Reasonable, right? If you derive value from a service, you should pay for it, right?
Maybe not. The primary problem with this idea is that people have come to expect software and associated services to be free. They don't want to pay.
In open-source software, it's exactly the same: Tons of value, but would-be customers will pay as little as possible for it, unless forced to by a proprietary license or company policy (requiring one to pay for support).
As I noted before, we often don't want the consequences of what we want. Perhaps a consequence of no viable business model for Twitter is that it goes out of business or becomes a minor service for a major Web company. That may well be the best it can expect.
... Read moreA recent Gartner study estimates that 189 billion mobile messages have been sent by U.S. mobile-phone subscribers in 2007. It forecasts 301 billion mobile messages sent in 2008.
If correct, those figures would still account for only a small fraction of the 2.3 trillion messages to be sent across major markets worldwide in 2008 (a 19.6 percent increase from the 2007 total of 1.9 trillion messages). Asia is the biggest mobile-messaging market worldwide. China is in the lead, with approximately 560 billion SMS messages sent in 2007, followed by the Philippines' 430 billion and Japan's 190 billion.
The vast majority of the 189 billion mobile messages to be sent in the United States are expected to be SMS text messages, with an average use of about two SMS messages per U.S. subscriber per day. That is similar to the level of SMS activity in the United Kingdom in 2005 and still only at the global average of 2.1 SMS messages per day. The average number in the U.K. today is six SMS messages per day. Singapore is at 12, and the Philippines even at 15.
While the U.S. is still lagging behind Asia and Europe, its adoption of SMS is obviously accelerating. Gartner predicts that this will further propel mobile-payment solutions, as SMS will continue to be the dominant channel for mobile payments.
The analyst house believes that the number of consumers making payments using their mobile phones is set to soar from 32.9 million in 2008 to 103.9 million in 2011.
Despite the continued growth of SMS usage, however, Gartner expects growth rates to slow as direct mobile connections are becoming increasingly cannibalized by mobile-IM communities and social-network portals.
As I wrote before, there is huge potential for an elegant, seamless, cross-platform, and cross-media IM solution that enables the ideal of the "never-ending conversation."
It looks like Apple might again be the first mover here. The company is apparently developing a chat application for the iPhone, as revealed recently through a patent application that describes a "portable electronic device with a touch-screen display, comprising (a) means for displaying a set of messages exchanged between a user of the device and another person in a chronological order." That's basically the description of an UI for an iPhone IM application.
CNBC analyst Jim Cramer thinks that an iPhone IM application is going to be to instant messaging what the iPod was to the Walkman. And Ars Technica is not alone when it suspects that most of the iPhone users will probably value "a way to use instant messaging without using up their SMS message quota."
While the iPhone currently relies on SMS, Apple could add AIM, Jabber, or Twitter to the interface and thus become the de facto universal conversation enabler. However, building a native IM application (and adding third-party chat applications) could create conflicts with iPhone operators that might be concerned about losing potential SMS revenue, if users sidestep SMS by using IM programs.
We will soon find out. The momentum is building up toward a possible unveiling of the next-generation iPhone at Apple's Worldwide Developer Conference on June 9.
Editors' note: this post has been updated to reflect a new magnitude given to the earthquake. Although the earthquake was initially rated as a 7.8 magnitude, the U.S. Geological Survey updated it to 7.9 after a further review of the data.
The loss of life and damage in many cities in and around China's Sichuan province continues to grow after a 7.9 earthquake hit about 55 miles from the major city of Chengdu at 2:28 p.m. local time on Monday.
I live in Beijing, which is about 950 miles from the epicenter. Along with others, I first learned of the quake via Twitter, which has been lit up with first-, second-, third-, and many-hand information about various personal experiences, and hundreds of links to other reports. By contrast, mainstream media such as Sohu.com were partially responsible for a massive rumor mill that pervaded Beijing on Monday evening, with an apparently incorrect prediction of a quake in Beijing between 11:00 p.m. and midnight local time--right now.
Twits, as I prefer to call those who use Twitter, passed information and repeated via twitter what we heard from phone calls, SMS, IM, and e-mail with affected areas. We knew where people had felt it and had short descriptions from various locations quickly. Many soon switched to self-congratulations about how cool it was that Twitter had operated so quickly, and then that subsided for some comments about how we were commenting on our speed. Jeff Jarvis twittered that he'll be writing about this in The Guardian. It clearly is a fast-moving rhetorical space.
Meanwhile, via MSN instant messaging, mobile-phone text messages, and media such as Sohu, a rumor emerged claiming that a quake had struck in Beijing's suburbs at the same time and that some authority was predicting the big one for between 11 p.m. and midnight. As I said, that's right now, so my sense is that this is a hoax that will either be vindicated or made ridiculous in a matter of minutes.
By the time I had been repeatedly warned about tonight, I checked Sohu, which was then carrying a statement from the Chinese national earthquake-monitoring group saying there was no such prediction. Indeed, "twits" were quick to point out that although China is relatively good at predicting earthquakes, such a precise prediction is regarded as more or less impossible.
The latest word from Chengdu: "More aftershock! This is getting old now. Boring!"
My thoughts are with those in the southwest, and I do hope that skepticism takes the day on the Beijing rumor.
Update: Rick Martin at CNET Asia has more, including some good people to follow on Twitter for information.
Twitter is still an early-adopter application, and if the system is running into scale issues already it's unlikely that it will be able to keep up when mainstream adoption occurs.
Twitter appears to have a fundamental design flaw that's not easily dealt with. It was designed to be a stand-alone system functioning in a multiparty/multiprotocol world. In the current architecture Twitter is an application, where it really needs to be a distributed system.
Maybe Twitter needs enterprise service bus (ESB) functionality that runs in enough distributed locations (Yahoo, Google, Amazon.com, desktop) to ensure that messages are reliably delivered. This could be achieved in a wide variety of ways without having to maintain a massive infrastructure like the carriers do for SMS. It would also enforce pervasiveness and adoption.
The fact that Twitter is based on Ruby on Rails is probably only part of the real issue, though Ruby does require a fair amount of tweaking to run reliably. Scale issues are less likely to happen with PHP or Java, but Ruby apps are generally easier to build.
I came up with a few analogous systems that might help to explain some of the technical ways Twitter-scale could be achieved:
... Read more
