Producer : Consumer : Influencer :: Google Plus : Twitter : Facebook

Google Plus, Twitter and Facebook; all offer different ways to use social networks and yet there are very few reasons to choose one over the other. None of them seem complete and it seems pretty hard to order them in absolute terms. Here are my thoughts on why this is so.

People on social networks can be classified into three categories – Producers, Consumers and Influencers.

The Producer

The Producer, as the the name suggests, produce content. These are the sort of people that are on top of things. Voracious readers consuming a lot of information or people producing the news that the world is interested in (think celebrities, politicians etc.). These are the sort of people that would have been in the limelight even if there were no social networks. They have opinions and are not afraid to voice them. They need a pedestal to stand and deliver a speech to who-so-ever is interested in listening. The world is their audience and they look at social networks to play sport. They are not thinking of a particular person or group as their target audience, when they like, tweet or plus one a link. They are all for the world, at large. So typically, they do not want to be bothered by friend requests and permission settings. They want to let everyone who is interested in listening, follow them, and let their tweets be completely public. A bull-horn in a crowded market is what they are looking for. Enter Twitter. Seems like the ideal market. But how many producers are out there that are articulate enough to express their opinions in 140 characters or less? It might not even be about articulation, it may just be that 140 characters is just too less. For example, expressing a thought process, by definition, has to be verbose. The Harsha Bhogles and Sidins of the world are the elite few who can say a lot in 140 characters. The rest of the folk are forced to use work arounds like TwitLonger or Bitly. But, at the end of the day, that is what they are – work arounds. Enter Google Plus. You are not obligated to reply to friend requests AND you are not limited by 140 characters! I think this sets the ideal stage for The Producer to arrive. So Google Plus would (or should) look attractive to the Producer.

The Consumer

The Consumer is a passive listener on social networks. His real world is outside these networks. In fact more often than not, it is outside the Internet. He looks at the Internet like a newspaper. News, information, gossip, all there to be consumed. The discussion of these topics, for him, happens outside, in the real world. What he is looking for, is an unobtrusive way to observe the world of Producers. Twitter with its unlimited and ubiquitous software clients provides him the ideal channel to do this. A lot of short messages that he can quickly skim through for the gist of what is being said and getting into the details (thanks to the bitly’s of the world) if need be, is just what the doctor ordered. Google Plus is a little too verbose, there is no Summary => Content structure by design. Skimming though 100 tweets is far less tiresome that skimming though the same amount of Google Plus feeds. So Twitter, according to me, is suited for the Consumer.

The Influencer

The Influencer is somewhere in-between. He is not the original Producer, nor is he a passive Consumer. He feels that a sufficient percentage of his network would benefit from the gyan that he just got by reading a blog post or a news article. Re-tweeting, is his favorite feature. But in-spite of having a feature that he can connect to immediately, Twitter does not win here. The reason is that Twitter, as we discussed above, is a Producers’ market. It is designed for attracting passive consumers eagerly looking for few and far between Producers. If you don’t believe me, just take a look at the list of people you are following on Twitter and see how many of them are in your network. Put in another way, there are very few people in your first circle, who can make it to the list of people you want to follow. So, their (re)tweets never reach you. Similarly, your (re)tweets wont reach them. This means, there is little or no point in re-tweeting on Twitter unless you have a strong klout. Besides, the Twitter platform is not well suited for having a conversation. This is a very important feature, especially when there is no single authority on the topic being discussed. Enter Facebook. By making every connection go through a two way hand-shake, the Facebook platform has created a setup where everyone would be atleast in the 2nd circle of everyone else in their network (friend’s list). Also, by relegating experts to fan pages, it has made most conversations 3rd party-ish and casual in nature. Add to it a world class discussion feature and you have a winner! So the influencers (aka re-tweeters), are going to be attracted most to the Facebook platform.

The Google Plus Paradox

You could argue that an amalgamation of all three would not look very different from today’s Google Plus. But such a network would have the “chicken-and-egg” problem to overcome. Being attractive to the Producers is good, but then who would they preach to, if there are not enough Consumers and Influencers? However, Google Plus, in particular, did not have this problem. With Google already being as big as it was, you would have expected that they would take the cake and eat it too. But here is the problem: having a follow model (rather than the 2-way handshake) for building connections also means that discussions are a low priority. However, that is not the case with Google Plus. In fact, just because anybody can follow you, it also means that anybody can comment on your tweets (or posts). And therein lies the problem. Sure there are setting to disallow people from commenting, but then that is not the natural thing to do. Also, thinking about restrictions makes it look more like the comments section on a blog, rather than a discussion. So most comments are spam or go un-answered by the Producer. So, in a sense, by trying to be all-in-one, Google Plus runs the risk of being neither-here-nor-there!

Conclusion

So, there you have it, different platforms for different people. The good or the bad part (depending on the way you look at it) is that no platform can cater to all kinds of people at the same time. Atleast I don’t think so. Invariably, there are features that cater to one kind of people and are not conducive to the other two. So, every social network of the future, will have to make a choice of who they want to cater to most, bet big on them and hope the other two categories will follow. And since many of us wear different hats at different times, we benefit most by being on all three platforms.

 

Cloud deployment nirvana through Chef

I have a lot of appreciation for the amount of engineering that goes into building sophisticated tools for software deployment. A few years back, when I was working with Amazon, I learnt how large companies manage tasks like building and deploying complex and highly distributed software systems. The build system was called Bob and the deployment system was called Apollo. Though a little arcane in the beginning, after getting a hold on it, I realized how critical it was to have such a system in place, in Amazon. These two systems integrated with the development environment of the developer and exposed a seamless workflow from the time of code change till the time of production deployment. The developer checked in code with the right comments, scheduled a build and happily went on with more serious businesses (like playing TT!). Bob, took the responsibility of identifying all packages that depended on this code change and built them all on specific hardware. If nothing broke, a shiny new version number would be given to the the changed package. After this, the guy who was in charge of doing the production deployment had to ensure that the he created a version-set with this version number for the changed package. That’s it!

Well, obviously I have cut a lot of details to save space (and not get sued by Amazon!) but the behaviour was roughly that. It seems like a straight forward job, but let me tell you that when you get to Amazon scale of software development, having your systems working all the time is a mind boggling exercise. Note that by scale, I mean the sheer amount of code that Amazon has to maintain. The scale of the problems that these libraries solve is a different story altogether.

I think that you can say that a company has reached “escape velocity” when they have a good build+deploy system, that can scale, in place. Once they reach this escape velocity, they are in a much better position to develop, maintain and grow complex code.

I think Chef is helping Cloud computing reach that “escape velocity”. The escape velocity that is needed to get onto the Cloud. First, some definitions. As far as I am concerned, Cloud computing comes with two guarantees 1) Provisioning and releasing hardware is extremely quick. So, scaling up to hundreds of machines or down to 1 (or 0) machines should be extremely quick. 2) Hardware cost to company is exactly equal to what the company uses. This basically means that a company that is on the Cloud does not pay for ‘unused’ machines.

Lets take an example. Suppose I own a Media house with a popular website. On a normal day, I would get about 1 lakh visits to my site. That’s about 1 hit per second. However on a day when one of my editors have broken a sensational news, the number of visits may jump up to say, 50 lakhs (or even more if the news is exclusive!) So, how should I provision hardware for my web site? Let’s say we begin with an architecture that consists of a front-end load-balancer, 2 app servers, and a database server. Let’s say that each server is residing on a dedicated host. This is our “normal” day setup.Now, assuming that the database is never going to be a bottleneck (a huge assumption), we scale the system horizontally by throwing more app servers between the load-balancer and the database server.

A simple 3-tier architecture for a Web site

The only problem is that I need to provision extra hardware. This is the time when the men are separated from the boys! The Amazons and the Googles of the world do this with the snap of a finger, but what about me? I place a request to my provider and he says that he will get it within 24 hrs, like I am supposed to feel good about it! And even if I get the hardware, by the time I wake up my ops guy and have him reconfigure my system, the traffic would have died down!

Today’s Cloud computing providers like Amazon and Rackspace solve the first problem for me pretty well. But the second problem is still a pain in the neck unless I want my ops team to label me a “slave driver”! This is where tools like Chef come in. If you had configured your system using Chef, this is what you would do:


$> knife node create new.machine1
$> knife node create new.machine2
$> knife node run_list add new.machine1 "role[appsrv]"
$> knife node run_list add new.machine2 "role[appsrv]"
$> knife bootstrap new.machine1
$> knife bootstrap new.machine2
$> ssh root@new.machine1 "chef-client"
$> ssh root@new.machine2 "chef-client"


Thats it! Now, all that needs to be done is to tell the load balancer that there are two more app servers available to share the load. If you have a physical load balancer (proxy) doing this job for you, all you need to do is run “chef-client” on the load-balancer after changing the required configuration file.

An alternate approach would have been to create machine images, like Amazon’s AMI for EC2, after having configured a working system. But I find it tedious for the following reason:

1. It binds me to EC2 (or whoever has the image)
2. I need to take a snapshot every time my configuration files change
3. An AMI is of little use to fix problems with an existing system (e.g., if I want to “re-install” only the MySQL server)
4. I need to take a snapshot every time I upgrade some part of my software (e.g., if I upgrade to Rails ver 3.2 from ver 3.0)

Chef takes a system admin problem and converts that into a development problem. This is because Chef does its stuff using what are called “Cookbooks”. These Cookbooks have “Recipes” that describe how to go about building the system. The best part is that recipes can depend on other recipes much like the way one library can depend on another in a software application. Recipes are written in Ruby DSLs, which means that you can insert programming logic when cooking up recipes!! The best part is that Opscode (the company behind Chef) has created a platform where people can share and use other’s recipes. I think that Cookbooks and Recipes are the right abstractions for sharing system setup information. These are much more fine grained when compared to AMIs and thus more reusable. The “Configuration as Code” and sharable Cookbooks create an eco-system, that I think lends itself to some very sophisticated configuration option. The relative ease with which this sophistication is achieved will, I think, accelerate the adoption of Cloud.

 

O Application What Art Thou?

Apple and Google seem to be the two companies people look up to, when trying to find out the future direction of the Web. With Internet as the foundation, these companies dictate what gets built on top. When the iPhone came out, a lot of developers started writing a lot of Objective C code. The Android based phones had a similar effect on the more “open” developers. With iPad, Apple renewed the interest that developers had with iOS programming. The mobile device became more serious now. The games became smarter, the apps became “full-featured” and the browser became more viewable. The aspect ratio of the iPads* were good enough for users to consume serious content.

Looking at the way freelancers were making money by developing iPhone and Android apps, I was convinced that learning Objective C or the Android SDK was a worthwhile investment. But then, Google came along and released the Chrome OS. Google’s thinking with the Chrome OS confuses me. How can they firmly put their feet on two boats and expect to travel for long? If every app is supposed to be rendered through the browser, why on earth did they have us interested in developing apps for the Android OS?? Or, is it that they don’t expect people buying/renting Chromebooks to play games or edit contacts? Apple’s strategy, on the other hand, is a little less confusing. As far as the developers are concerned, their tablet strategy seems like a logical extension of their mobile strategy: “Learn Objective C first. Then learn a few libraries to be able to write apps on the iPhone. Now, learn a few more libraries to be able to write apps on the iPad.” Logical.

However, life was simpler before the iPad* for content publishers. Any content, had to be delivered in two forms, one for the PC* (with bigger aspect ratios) and other for the smart phone (with smaller aspect ratio). Whether or not you want to support the not-so-smart phones was a matter of taste (and also the demographic of your customer base). With the growing popularity of iPads and similar tablets, the content publishers are in a situation where they have to hide their cries with laughter! It is a great thing for their customers, you see. If the publishers can deliver content optimized for the iPad*, which, their new-age customers are now equipped with, they stand a chance of genuinely delighting their customers. But what happens to the tens of thousands of dollars that actually went into developing their iPhone app? Should they continue to support them? How do they make sure that all content is delivered in all three formats in a consistent way? Add to it, the multiple platforms in each format (e.g., Android and iPhone for the smart phone segment), what you have is a Royal Mess of multiple codebases! Remember that software development is not a core competency with many of these content publishers (like Media houses). They are most likely to outsource their software development work.

Viewed in this light, it seems like Google has envisioned the right approach to this problem with their Chrome OS (and the accompanying Chromebooks). Everything is now going to be delivered through the Browser. So, technically, publishing on the Browser is the only skill-set needed to deliver content on any platform. Of course, you still have to optimize the content for the specific device, but the optimizing methodology will be the same everywhere. Roughly put, the Browser is the new OS! So, back to javascript and HTML 5, you developers!!  If you find it hard to imagine glossy apps delivered through the Browser, then take a look at OnSwipe’s youtube video.

So, what is it the dominant form of application development going to be in future? Device specific development or intelligent rendering of content through the browser? Obviously, both these approaches will exist parallelly for quite some time, but if I had to bet, I would bet that a lot of applications will be delivered through the Browser in the long run, just because it is a lot less messy that way.

PC* – A desktop computer that could have a Windows, Mac OS X, or Linux Operating Systems.
iPad*, iPads* – iPad and similar devices (like Samsung Galaxy Tabs)

 

Backup, backup, backup!

A few days back a couple of computers in my uncle’s office got affected by viruses (unfortunately, I have not been able to convince my uncle to buy Macs). After about two days of effort in trying to remove them, the maintenance guy, very calmly said that the machines had to be formatted and the OS (Windows) re-installed. Remember these were machines running a licenced version of a very popular anti-virus software. At this, my uncle, after trying to hold back the choiciest profanities said that that was impossible as he had more than an years’ worth of accounts in files that he absolutely could not afford to loose. At this, the man assured that *most* of the files could be saved!

I don’t think this is a very uncommon situation. Although my research leaves a lot wanting, I would be willing to bet that most small businesses in India do away with little or no backup of their files. The best that I have heard is that everything is backed up to an external hard disk. This solution is ok when what you are backing up is a bunch of photos that you might not mind loosing.. well atleast you wont hurt other peoples lives by loosing your photos. But when your entire business depends on it, I would not be able to sleep with this arrangement. I know my paranoia crops from knowing a bit about what it takes for these disks to crash (not much!) but even without that knowledge, it is amazing to see the amount of trust people are willing to put on commodity hardware!! The truth is that it is bound to fail one day! Why is it that we (Indians) are so reluctant to using technology solutions to save ourselves from such situations? Storage space is dirt cheap. Now with “cloud” being omni-present, you just have to pay for what you use. Even when converted to rupees, its cheap. I think it would come to about Rs. 5 per GB per month! So, effectively, in less than the amount it takes to buy a cup of coffee, your data will be backed up in 3 different locations around the world! Unfortunately unless that happens, your data is not completely immune to failures!

So, all you small business owners and proprietors out there, here are a couple of solutions you must consider:
1. JungleDisk
2. Dropbox

To complete my uncle’s story… fortunately, all of his important files were restored. He has since spent about 3.5k rupees and bought an external hard disk to backup his files. He has vowed to backup regularly. I am still trying to convince him to consider backing up on the cloud!

 

Can Facebook Kill Local Listing Sites?

I think so. There are two very powerful weapons that Facebook has, to do this – LIKE and Checkin.

What do the local search/listing sites have? One, a thorough listing of the businesses in the cities that they support, two, a bunch of reviews for each of their listing sites that would act as decision influencers for their users. So, theoretically if these two were replicated in some other place, an end user would have no special incentive to go to the original site. Ok, there are is a third factor – user experience. The original site might be giving a good user experience to have their users coming back to their site. Now, how does “Facebook” sound for a competitor?! The listing sites wanting to be more “social” by adding features like “follow”, “compliment”, etc, is not helping them either. At best they look like “wannabe’s” of Facebook/Twitter when it comes to social engagement.

For businesses that are missed out by the listing sites, there are Checkins – the offline equivalent of LIKE (for practical purposes).

I think the tipping point would be when a lot of local businesses have a Fan Page on Facebook. Once they realize that their competitors are building a direct communication channel with their customers by putting up a fan page, I think it would start a Gold Rush to get a fan page up on Facebook to harvest some LIKEs or at-least mark their location on Google Maps so that their customers can Checkin.

Facebook Search Results

Here is where it gets scary (for the local search/listing sites) – once the Gold Rush is on, people would start using Facebook search to find a good local business.

The listing sites are still ok as long as people are using Google for their searches. There is the SEO route that they can use to drive traffic to their site. Unfortunately they cannot do the same with Facebook search. For now at-least, Bing results are below Facebook results. What is worse (for the listing sites) is that Fan pages are in public domain (you don’t need to have logged-in to Facebook to view a Fan page) and Google is giving a lot of respect to facebook Fan pages!

 

Why Endorse?

You see a reco for some place – say Mama’s Burger – that you know of and like, on YoYo.  The reco is given by Priya who is your friend.  What do you do? The natural thinking is – “Oh so my friend has recommended Mama’s Burger. Good, let me move on”.  But the point that you would be missing here is that activity feeds and search results on YoYo are “personalized”.  Which means that Mama’s Burger may not show to your friend, Reema the way it shows up for you.

This is especially true when Priya and Reema are not friends.  How do you transfer your knowledge of how Mama’s Burger is, to the part of your network that does not overlap with Priya’s network? “Endorse” and “I know better” are easy and effective ways to accomplish this.

Think of them as like and dislike buttons, that go a step further and enrich your network with searchable recos that are independent of the original reco.  A Facebook “like” button is similar, but you have to be looking at something to know if someone (hopefully your friend) liked it or not and so it is not aiding in solving the problem of reliable service discovery that YoYo hopes to solve.

Anyone who has tried to integrate with Facebook APIs would agree with me when I say that capturing clicks on likes is very error prone.  Also, what if the originator (Priya) deleted her reco or worse, change the thing being recommended?  Afterall, the data including the contact details of the place being recommended, is owned by her!  The information that you “liked” something would be lost or you would be shown as “like”ing something you may not really like after some time!

Endorsing and saying “you know better” is a point-in-time response to the thing being endorsed (or disliked). This means that the endorser ends up copying everything of the thing being endorsed at that point in time.  Thus endorsing serves as a better testament of something you like.

So, Why endorse? In short, you should be endorsing (and not just “like”ing) Mama’s Burger in order to benefit Reema and others who may not be friends with Priya, in a reliable way.  The reasons are similar for clicking on the “I know better” button except that FB does not have a “dislike” button.

See the post on why we chose to have “Endorse” and “I know better” buttons instead of our own versions of “like” and “dislike” buttons.

 

A case for Likes and Dislikes

Mohan and I have been discussing various features that enable actions on recos on YoYo. The obvious one was to have a Facebook ‘Like’ button. But guessing the emotion behind a ‘Like’ can be difficult. When I like a reco, was it actually the reco comment or the reco’d item that I liked? So to make it clear, we decided to have a separate “Like” button for the thing that was being reco’d. But Facebook doesn’t allow two ‘Like’ buttons to be associated with an entity – reco!  So, we came up with our own button for the thing being reco’d.  We called it the “Endorse” button. We thought that “Endorse” would convey the emotion of the clicker better than “Like”.  Its like saying “Hey I have been to this place, and I was happy with the experience” or “Hey I know this person and he did a good job”.  In fact we went a step further and made it easy for the endorser’s friends to discover the person/place being endorsed by adding it to the list of recommendations of the endorser.  So, when someone endorses something, we prompt the users for her rating and, thats it, a reco is added!

The second thing that we were debating about was the ‘Dislike’ button since Facebook doesn’t have one (bummer!) We could have written one for ourselves, but “Dislike” seemed like an incomplete gesture. Ok, I dislike this reco. So what is the person looking at the reco supposed to make out of that. A number against the Dislike button can serve as a measure of its ‘dis-reputaion’, but then the disliker’s conversation with the person viewing the reco at that time, is sort of left incomplete. Think about how the conversation would have gone in the real world:
A: Hey I reco’d “Blah” on YoYo.
B: I dislike.

The conversation ending there seems a little unnatural. Doesn’t it? Unless B just wants to cut-off A in some way, a follow-up would be a natural thing to happen.
B: I think “Blah” sucks at <bah>. I have experienced “Plah” and I think it is better.
Now, that seems a bit more likely.  Translating this to the YoYo world, we thought a user would do better if she saw a reco from the disliker (“Plah” in the above conversation), instead of just seeing the number of dislikes.  Also, it throws up a challenge to the disliker.  Its like A saying to B “Oh, you dislike, eh? So what is a better place according to you?”

It made sense to let the disliker have his say, but with a better suggestion, so that the user viewing the reco has a lead for further investigation. So, we decided to add a “I know better” button on all the recos.

Check them out on YoYo and let us know what you think!