Earlier this morning, Jeff Kunins posted the announcement that Messenger Connect is out of beta and available worldwide. Key excerpts from his post include

Today, we are pleased to announce that Messenger Connect is out of beta and available worldwide. We’ve gotten a great response so far: leading sharing syndicators ShareThis, AddThis, Gigya, and AddToThis have already made the Windows Live sharing badge available on more than 1 million websites (check it out now on Bing).
…
Over 2500 developers gave us great feedback during the beta, helping us to refine and improve this release of Messenger Connect. Below is a quick summary, but for all the details check out this post from Angus on the Windows Live for Developers blog. Our focus with the release of Messenger Connect was to make it easier for partners to adopt, without compromising user privacy.

• Easier to check out –We made it faster and simpler for partners to try out Messenger Connect and determine if it would be useful for their sites. For example: you can try out the real time chat control without needing to write any code.
  
• Easier to adopt and integrate– We reduced the effort needed for sites to implement Messenger Connect usefully and powerfully by providing new tools and sample code for ActivityStrea.ms template selectors and more.
  

A number of folks worked really hard behind the scenes to get us to this point and I’m glad to see what we’ve shipped today. I haven’t announced this on my blog yet but I recently took over as the Lead Program Manager responsible for our Messenger Connect and related platform efforts in Windows Live. If you’ve been a regular reader of my blog it shouldn’t be a surprise that I’ve decided to make working on building open web platforms my day job and not just a hobby I was interested in.

As Angus Logan says in his follow up blog post on the Windows Live for Developers blog; this is just the beginning. We’d love to get feedback from the community of developers on what we’ve released and the feedback we’ve gotten thus far has been immensely helpful. You can find us at http://dev.live.com/forums

PS: Since someone asked on Twitter, you can find out more about Messenger Connect by reading What is Messenger Connect?

Now Playing: Waka Flocka Flame - No Hands (featuring Roscoe Dash and Wale)

Earlier this week Facebook announced the revamp of Facebook Groups. At first I planned to avoid commenting on this release since there is significant overlap between it’s functionality and that of Windows Live Groups so it is hard for me to have an objective perspective. However this morning I saw the following tweet from a designer at Facebook

I found this a little intriguing since I was sure I'd seen the presentation from the Google UX researcher he was referencing and I couldn't see how Facebook Groups addresses the problem he pointed out. If you haven't seen the presentation there is a brief description and link to it in the VentureBeat article Google researcher says friend groups may give it a window to best Facebook. Below are key excerpts from the article which capture the key point from the presentation

Through studying the nuances of social interaction both off- and online, Google researchers found that people typically have between four and six friend groups and only between two and six “close” friends, he said. College friends don’t necessarily mix with work friends, who don’t necessarily mix with a person’s family.
…
Adams pointed out all of the different problem scenarios Facebook users run into if the different parts of their identities end up blurring. One teacher the company interviewed, for example, realized that photos of her with her close friends at a gay bar were being exposed to her 10-year-old students.

Personally, I’d always assumed this collision of friend groups would be the main challenge that would prevent Facebook from being as successful as it could be back in 2008. What I didn’t expect is that people would decide that the benefit of having access to all their friends in one place was worth the cost of having to censor themselves a little bit in their online sharing since what may be appropriate for one group of friends (e.g. your friends from the gay bar scene) may not be for another (e.g. parents of students in your middle school class). Today has grown to having 500 million users based on that fact.

The reasons for self-censorship are sometimes not so controversial. Simply posting a bunch of kid pictures can get annoying for your coworkers even though your family on Facebook loves every single one of them. For the people who find this need to censor how they share online for various reasons, the argument is that Facebook Groups solves this problem. There’s only one catch which Mark Zuckerburg brought up himself a while ago which is mentioned in the TechCrunch article Facebook Overhauls Groups, A Social Solution To Create “A Pristine Graph”

“The naive solution is to do something like Friend Lists,” Zuckerberg says. ”Almost no one wants to make lists,” he continues. He’s noted this before. “The most we’ve ever gotten is 5 percent of people to make a list. It’s pretty brutal to have to do this every single time.” He then went into the algorithmic solutions. These are helpful, Zuckerberg says, but it’s also really easy to get these wrong, he notes. There needs to be a social solution, Zuckerberg says.

Facebook Groups faces all the problems with Friend Lists that Zuckerburg mentions above. In real life, I don’t manage my different social circles at the same time. I go to work and have work friends, I have school friends I still call every once in a while and when I go to my regular poker game there I interact with my poker friends. Every once in a blue moon like at my wedding, all of these worlds collide and it is actually a little stressful to manage them in real time. In addition, when the members of these groups change I don’t have to actively manage them (i.e. when a coworker becomes friendly enough for me to hang out with them outside of work, when a poker friend stops attending the regular poker game or when a coworker switches jobs and we no longer work on related technologies). Friend Lists on Facebook make people work to keep track of changes in their social relationships which is just not how most humans work. I still have phone numbers in my cell phone for people who I was supposed to meet up with for dinner at a conference almost four years ago who’ve since left Microsoft.

Facebook Groups cranks the awkwardness of dealing with this up to 11. Let’s say I create a group for “People who work on social at Microsoft who regularly have lunch” and after a few months to years some of these people leave the company, get promoted or switch roles. As the owner of the group what do I do? Do I kick them out? Do I keep blathering on in private discussions that I know are no longer relevant for half of the recipients and in some cases actually violates work ethics since some of these people have left the company? What happens when I stop working on social at Microsoft?

Facebook Groups may solve some problems users have with Facebook but I suspect it is not the silver bullet that addresses the problem of people having friend groups that they’d like to keep separate on Facebook especially since it introduces a new set of problems for users. Time will tell if I’m right or wrong on this suspicion.

Now Playing: Yo Gotti - Women Lie, Men Lie (featuring Lil Wayne)

Software companies love hiring people that like solving hard technical problems. On the surface this seems like a good idea, unfortunately it can lead to situations where you have people building a product where they focus more on the interesting technical challenges they can solve as opposed to whether their product is actually solving problems for their customers.

I started being reminded of this after reading an answer to a question on Quora about the difference between working at Google versus Facebook where Edmond Lau David Braginsky wrote

Culture:
Google is like grad-school. People value working on hard problems, and doing them right. Things are pretty polished, the code is usually solid, and the systems are designed for scale from the very beginning. There are many experts around and review processes set up for systems designs.

Facebook is more like undergrad. Something needs to be done, and people do it. Most of the time they don't read the literature on the subject, or consult experts about the "right way" to do it, they just sit down, write the code, and make things work. Sometimes the way they do it is naive, and a lot of time it may cause bugs or break as it goes into production. And when that happens, they fix their problems, replace bottlenecks with scalable components, and (in most cases) move on to the next thing.

Google tends to value technology. Things are often done because they are technically hard or impressive. On most projects, the engineers make the calls.

Facebook values products and user experience, and designers tend to have a much larger impact. Zuck spends a lot of time looking at product mocks, and is involved pretty deeply with the site's look and feel.

It should be noted that Google deserves credit for succeeding where other large software have mostly failed in putting a bunch of throwing a bunch of Ph.Ds at a problem at actually having them create products that impacts hundreds of millions people as opposed to research papers that impress hundreds of their colleagues. That said, it is easy to see the impact of complexophiles (props to Addy Santo) in recent products like Google Wave.

If you go back and read the Google Wave announcement blog post it is interesting to note the focus on combining features from disparate use cases and the diversity of all of the technical challenges involved at once including

• “Google Wave is just as well suited for quick messages as for persistent content — it allows for both collaboration and communication”
• “It's an HTML 5 app, built on Google Web Toolkit. It includes a rich text editor and other functions like desktop drag-and-drop”
• “The Google Wave protocol is the underlying format for storing and the means of sharing waves, and includes the ‘live’ concurrency control, which allows edits to be reflected instantly across users and services”
• “The protocol is designed for open federation, such that anyone's Wave services can interoperate with each other and with the Google Wave service”
• “Google Wave can also be considered a platform with a rich set of open APIs that allow developers to embed waves in other web services”

The product announcement read more like a technology showcase than an announcement for a product that is actually meant to help people communicate, collaborate or make their lives better in any way. This is an example of a product where smart people spent a lot of time working on hard problems but at the end of the day they didn't see the adoption they would have liked because they they spent more time focusing on technical challenges than ensuring they were building the right product.

It is interesting to think about all the internal discussions and time spent implementing features like character-by-character typing without anyone bothering to ask whether that feature actually makes sense for a product that is billed as a replacement to email. I often write emails where I write a snarky comment then edit it out when I reconsider the wisdom of sending that out to a broad audience. It’s not a feature that anyone wants for people to actually see that authoring process.

Some of you may remember that there was a time when I was literally the face of XML at Microsoft (i.e. going to http://www.microsoft.com/xml took you to a page with my face on it ). In those days I spent a lot of time using phrases like the XML<-> objects impedance mismatch to describe the fact that the dominate type system for the dominant protocol for web services at the time (aka SOAP) actually had lots of constructs that you don’t map well to a traditional object oriented programming language like C# or Java. This was caused by the fact that XML had grown to serve conflicting masters. There were people who used it as a basis for document formats such as DocBook and XHTML. Then there were the people who saw it as a replacement to for the binary protocols used in interoperable remote procedure call technologies such as CORBA and Java RMI. The W3C decided to solve this problem by getting a bunch of really smart people in a room and asking them to create some amalgam type system that would solve both sets of completely different requirements. The output of this activity was XML Schema which became the type system for SOAP, WSDL and the WS-* family of technologies. This meant that people who simply wanted a way to define how to serialize a C# object in a way that it could be consumed by a Java method call ended up with a type system that was also meant to be able to describe the structural rules of the HTML in this blog post.

Thousands of man years of effort was spent across companies like Sun Microsystems, Oracle, Microsoft, IBM and BEA to develop toolkits on top of a protocol stack that had this fundamental technical challenge baked into it. Of course, everyone had a different way of trying to address this “XML<->object impedance mismatch which led to interoperability issues in what was meant to be a protocol stack that guaranteed interoperability. Eventually customers started telling their horror stories in actually using these technologies to interoperate such as Nelson Minar’s ETech 2005 Talk - Building a New Web Service at Google and movement around the usage of building web services using Representational State Transfer (REST) was born. In tandem, web developers realized that if your problem is moving programming language objects around, then perhaps a data format that was designed for that is the preferred choice. Today, it is hard to find any recently broadly deployed web service that doesn’t utilize on Javascript Object Notation (JSON) as opposed to SOAP.

The moral of both of these stories is that a lot of the time in software it is easy to get lost in the weeds solving hard technical problems that are due to complexity we’ve imposed on ourselves due to some well meaning design decision instead of actually solving customer problems. The trick is being able to detect when you’re in that situation and seeing if altering some of your base assumptions doesn’t lead to a lot of simplification of your problem space then frees you up to actually spend time solving real customer problems and delighting your users. More people need to ask themselves questions like do I really need to use the same type system and data format for business documents AND serialized objects from programming languages?

Now Playing: Travie McCoy - Billionaire (featuring Bruno Mars)

This morning I stumbled on a great post by Dave Winer titled Why didn't Google Wave boot up? where he writes

So why didn't Google Wave happen?

Here's the problem -- when I signed on to Wave, I didn't see anything interesting. It was up to me, the user, to figure out how to sell it. But I didn't understand what it was, or what its capabilities were, and I was busy, always. Even so I would have put the time in if it looked interesting, but it didn't. 

However, it had another problem. Even if there were incentives to put time into it, and even if I understood how it worked or even what it did, it still wouldn't have booted up because of the invite-only thing. It's the same problem every Twitter-would-be or Facebook-like thing has. My friends aren't here, so who do I communicate with? But with Wave it was even worse because even if I loved Wave and wanted everyone to use it, it was invite-only. So the best evangelist would still have to plead with Google to add all of his workgroup members to the invite list. The larger your workgroup the more begging you have to do. This is exactly the opposite of how you want it to work if you're in Google's shoes. 

This is an important lesson on the value of network effects on social software applications. A service that exhibits network effects is more useful the more of my friends use it (e.g. having SMS on my cell phone is only useful if I have friends who can send & receive text messages). By definition, a social software application is dependent on network effects and needs to do everything in its power to promote them. Placing artificial barriers that prevent me from actually using the product as a communication tool with my social network works against the entire premise of being social in the first place.

Google definitely learned the wrong lesson from the success of Gmail as an invite only service. Being invite-only worked for Gmail at launch because my friends don’t have to use Gmail to receive or send messages to me. So word off mouth could spread because the people who used it would sing it’s praises which caused anticipation amongst those that couldn’t. On the other hand with Wave, the people who got invites couldn’t get to the point where they could sing its praises (if there were any to be sung) because it was too difficult to get their friends on there. By the time they made the service open to all, it was too late due to what Joel Spolsky called The Segway Phenomenon

PR grows faster than the quality of your code. Result: everybody checks out your code, and it's not good yet. These people will be permanently convinced that your code is simple and inadequate, even if you improve it drastically later. I call this the Marimba phenomenon . Or, you get PR before there's a product people can buy, then when the product really comes out the news outlets don't want to do the story again. We'll call this the Segway phenomenon.

Some may point to Facebook as an example of a network that was invite-only but still managed to have network effects but there is a crucial difference in how Facebook regulated growth before opening up to all. Facebook opened its doors to entire networks of people at a time (i.e. everyone in a particular college, all college students, people from select employers, etc) not to arbitrary swaths of people on a first come, first served basis.

Hopefully more startups will keep this in mind before jumping on the invite-only bandwagon.

Now Playing: Eminem - Hell Breaks Loose (featuring Dr. Dre)

I've spent the past week going over the ideas in Chris Dixon's excellent post titled graphs and thought the ideas were powerful enough that they are worth reiterating. The thesis is simple, in recent years many have been focused on social graphs (i.e. graphs bidirectional or one-way “friend” relationships between users) but there are other ways in which users can be connected to each other besides whether they are friends or not. The key points from Chris’s post are excerpted below

Facebook’s social graph is symmetric (if I am friends with you then you are friends with me) but not transitive (I can be friends with you without being friends with your friend).  You could say friendship is probabilistically transitive in the sense that I am more likely to like someone who is a friend’s friend then I am a user chosen at random. This is basis of Facebook’s friend recommendations.

Twitter’s graph is probably best thought of as an interest graph. One of Twitter’s central innovations was to discard symmetry: you can follow someone without them following you. This allowed Twitter to evolve into an extremely useful publishing platform, replacing RSS for many people. The Twitter graph isn’t transitive but one of its most powerful uses is retweeting, which gives the Twitter graph what might be called curated transitivity.
...
Over the next few years we’ll see the rising importance of other types of graphs. Some examples:

Taste: At Hunch we’ve created what we call the taste graph. We created this implicitly from questions answered by users and other data sources. Our thesis is that for many activities – for example deciding what movie to see or blouse to buy – it’s more useful to have the neighbors on your graph be people with similar tastes versus people who are your friends.

Financial Trust: Social payment startups like Square and Venmo are creating financial graphs – the nodes are people and institutions and the relations are financial trust. These graphs are useful for preventing fraud, streamlining transactions, and lowering the barrier to accepting non-cash payments.

Endorsement: An endorsement graph is one in which people endorse institutions, products, services or other people for a particular skill or activity. LinkedIn created a successful professional graph and a less successful endorsement graph.

Local: Location-based startups like Foursquare let users create social graphs (which might evolve into better social graphs than what Facebook has since users seem to be more selective friending people in local apps). But probably more interesting are the people and venue graphs created by the check-in patterns. These local graphs could be useful for, among other things, recommendations, coupons, and advertising.

One of the things that has been interesting to watch is how many services have tried to build this other sorts of relationship graphs on top of Facebook Connect. Quora has tried to build an endorsement graph from Facebook Connect as a basis while Yelp has tried to build a location graph using Facebook's Instant Personalization and Facebook Connect as the foundation. As more of these sorts of relationships graphs between people and other entities are created it is slowly becoming clear to me that there are many scenarios where Facebook’s graph is not the best starting point.

Take this screenshot of the Facebook Friend’s Activity plugin on Engadget as an example.

What this plugin does is show which of my Facebook friends (i.e. mostly family, coworkers and high school friends) have found interesting on Engadget. I couldn’t help but think back to what Chris Dixon mentioned about Twitter being an “interest graph”. I realized that this feature would actually be more useful if it showed me what Engadget articles people I follow on Twitter found interesting rather than what my Facebook friends did.

As the utility of the social graph grows beyond providing a stream of updates from people in that graph to being reused in other contexts, the lack of universal appeal in some of these relationships will grow more obvious. Using Twitter as an example, I suspect if asked to chose between a widget on TechCrunch that shows what articles are interesting among your Facebook friends versus who you follow on Twitter a non-trivial amount of people would pick the latter.

Similarly I wonder how soon till we start seeing some of the endorsement graphs being built on services like LinkedIn and Quora being leveraged in other places where you need to vet the opinions of strangers such as Amazon or even Monster.com.

There are times I’ve debated with others whether there will be one social graph to rule them all and whether that graph will Facebook’s. Now I ‘m convinced that although their graph is likely to be the largest and most generally applicable in the long term, there is a market for social graphs based on relationship types other than whether someone is a “friend” or not which can still significantly improve the user experience on the Web.

Now Playing: Eminem - Untitled