The awful practice of cross-pollinating status updates
If there is one thing that has gone awfully wrong with the open APIs for pushing and pulling data into various online communities, it is the horrible practice of plugging one thought stream through the API into another in an automated manner.
What exactly is a thought stream? Well, thought streams are more frequently updated status messages. They have been around for years known as custom status messages on instant messengers, which got spun around, made over and turned into a superstar product by the guys at Twitter. These days, status messages are there in every online networking product -- be it Linkedin, Facebook, Orkut, Hi5.
Which is all fine. A few more wisecracks a day does not really make the world a better or suckier place. What does make it suckier is that cross-pollination of these messages often lead to broken conversation threads, misplaced context and other byproducts of the law of unintended consequences.
In real life this is how it happens: You can plug in your Twitter stream to update your Facebook status message. But your replies to the Facebook status message remains within Facebook. So you post a message to Twitter, this gets replicated on Facebook. Someone replies to that update on Facebook, but unless you are a Facebook maniac (a dying breed, if you ask me, these days), odds are that you won't see the response till much later.
Killing the conversation: The primary issue this cross pollination creates is that it breaks the conversation. While the tiny updates are the core functionality of Twitter, it is not the case with the larger networking sites like LinkedIn and Facebook. When you plug in the updates from one product into another, it is hard to know, at face value, where that update originated from, leading to instances where the message origin and message response belong to different networks. The end result? Death of the conversation.
LinkedIn is worth more than $1 billion
So, LinkedIn has been valued at $1 billion and there are questions being raised about it. I think it is quite a fair valuation, in fact, I think it is a bit on the lower side, especially when you compare it to Micorsoft's crazy $15 billion valuation of Facebook and the reasons are as below.
1) The most important asset any online operation has is data and how clean that data is (of spam, spammers and user details). Linkedin pretty much has the purest piece on that count available anywhere on the internet. Almost nobody puts 'Timbuktu' as their location on LinkedIn. They also have pretty accurate data about companies, their size and also the segments the companies are involved in.
2) Community: This is perhaps the least appreciated facet of LinkedIn. They may not have the volume of Yahoo! answers, but the quality and value of answers that are found in LinkedIn is worth a lot.
3) Last one is a no-brainer: They've been profitable for a while now.
Slides from Social Media and Blog Camp
Gave up my long-standing aversion to public speaking and had an interesting day at the Social Media and Blog Camp today at the Indiatimes building in Gurgaon. I had a mini session on participatory media and our experiences with it. The slides have been uploaded here. Too tired after driving much more than I really should since last evening. So, take a look and let me know what do you think.
Scaling Twitter and revenues
Om Malik has posted an entry on how Twitter could monetize and make money off their service, especially from the ultra-power users like Robert Scoble and Leo Laporte. But there are a couple of points that he has gotten wrong there.
- His hypothetical 30 GB of data transfer for Scoble alone does not take into account what is Twitter's major problem: tracking. Scaling for known relationships are relatively easy, because you are dealing always with a finite number and you are also dealing with spikes that can be guessed to a great extent. The case is entirely different with keyword tracking.
- It ignores Twitter's Jabber problems, which will gradually grow to eclipse the problems it is having with API, which is throttled anyway at 70 (60, says Aditya in the comments) requests in an hour.
Realistically, I don't think Twitter can continue the Jabber service the way it is being run right now. They will need to limit tracking per user to maybe a maximum of five, so that the entire tracking mess can be brought under control. If you want to track more than that, you need to pay. And people who normally track more than four or five terms are likely to be PR or other professionals who can afford to pay for the service. This one avenue for them to get some money back into the system.
There needs to be a premium API endpoint, which does not have the 70 requests per hour limit attached to it. The current API client experience is very laggard and there is an opportunity there to scale the API much easier than scaling either Jabber or the tracking service. Once you kill the Jabber service, the premium API becomes the only available service from which you can get a user experience that is closest to the IM-based interface to Twitter.
Short Notes: Quantitative Hedge Funds, Google App Engine, DTH, itimes
I know the Google App Engine just took over the interwebs. We will get to that, but, later. Alpha Magazine has a nice write up (a bit all over the place in terms of direction, but very rich in terms of content) on quantitative hedge funds who marry cutting edge research from various faculties in science and marry them with the normal hedge fund business.
It is quite a long article, but is well worth the time you spend on it, if numbers, markets, arbitrage, learning (artificial and natural), behaviour and systems design are things which make you salivate more than blondes and brunettes. In a somewhat-related topic we have a fascinating entry on search algorithms that also mentions Pareto in the same breath. Most of the math in it flies like a supersonic above my head (confession time, I absolutely suck at math, go figure!), but do stick with him till the point where explains why there is no "best" search algorithm.
