1. For most people, this is a non-issue. I know a lot of people who actively publish the URL and location of their shared items feed. I even keep mine on my blog, including the most recent items I’ve starred. For most people, having others see the items they’ve shared is not a big deal. If you really want to keep track of stuff and not share it with the world, just create your own tag – I use the tag “followup” for interesting stuff I find but don’t want to share with the world.

Also, it’s not as if the GR team really “exposed” any private data. Your shared items feed was always publicly available – it was merely obfuscated with a long and gnarly URL.

2. “Passively social” products are going to encounter this problem time and time again. The advantage of passively social products is that they don’t actually require you to “friend up” your network to get started. In an ideal world, a passively social product will be able to infer or distill the appropriate social network with which to share your information. We’re clearly not there yet, so the only thing we’re going to get from these first generation products is a very coarse set of relationship data. Knowing that I’ve communicated with someone on Gmail is a very coarse signal – it’s better than nothing, but not enough information on which to make a high-quality decision.

As excited as I am about passively social products, it’s going to take awhile to be able to match the user experience associated with actively social products like Facebook and MySpace. Without explicitly declared (and verified) relationships, passively social products are going to need multiple signals to make good decisions about the circle of people with whom I’d like to share data. For example, if a passively social product had access to my IM, phone, email, and calendar logs, I bet it could make some really good decisions about the folks with whom I communicate and the strength of those connections. There isn’t anyone who has that information today across all those platforms. As a user, I don’t have it myself and couldn’t even turn it over to a trusted 3rd party to analyze it even if I wanted to do so. And I can’t think of a single company I trust enough to provide all of that information. I would maybe trust Google, but I’m not sure – that’s a lot of information and power to turn over to a single organization.

Tags: googlereader, web20, privacy, google, opensocial, social networking

Overall, I do agree that email inboxes do contain a lot of interesting data about people and how frequently they communicate over email and potentially IM if a vendor offers both products in an integrated fashion. That being said, I don’t see how any of the top web email providers (Microsoft, Yahoo, and Google) can use this email information to build new social networking products. There is, however, an opportunity to use that data to power other people’s applications.

What additional value would I get in using one of these systems over Facebook, MySpace, or my current social network of choice? Details on these products are sketchy at best. However, almost any social networking product worth its salt has a contact importer. Once a user imports his/her contacts, he or she can then determine who from that subset of people he/she would like to invite. Is having a machine prompt to do this for personal social networking of great value? I can see the utility of this auto-population or auto-discovery in a work context (Xobni does do a good job of showing me my own correspondence patterns and I can imagine many things you could build on top of that data – the work use case is different as I think work communication patterns tend to be more dynamic than personal ones). Nothing I’ve heard in the limited details that have come out gives me reason to think that they’re on to something bigger.

I’d also say that if “powering up” this network requires me to create a new profile page, it’s a non-started. I’m out of that business for now unless or until I see a really great application that’s worth the time.

Webmail inboxes are a mess – I have yet to use an email product that has an even decent address book. All of the email address book offerings from the Big 3 email providers feel really dated. For example, the Gmail address book does not do a very good job of de-duplicating contacts. I have folks in my address book who have multiple entries and I’m not interested in going through to manually de-duplicate them; I’m counting on a machine to do that for me.

The larger point here is that I don’t know how you can build a really good, effective social networking product on top of email if you don’t do something to put some good, quality structure around the data. Social networking services who are sucking up email addresses to match a user’s inbox with their database of contacts don’t have the same problem – you just throw away the ones that don’t match (or allow a user to invite them). It’s a very different situation if you want to build a whole new social network product with email as the foundation.

Cross-functional collaboration is not easy inside of large companies – This is a fairly obvious point, but big companies are notorious for having internal challenges when it comes to cross-product collaboration. When one of the products in question is email, I don’t imagine that will be an easy conversation – nobody wants to play around with an interface that touches tens or hundreds of millions worldwide.

Think about the refresh cycles for webmail systems. How often do Gmail, Yahoo Mail, or Hotmal get updated? Not that often, and I have to think that touching those interfaces requires a lot of signoff and a strong conviction that the proposed changes will positively impact a wide number of people. Otherwise, you might end up with angry users. I have a hard time seeing any of these companies acting aggressively with one of their web crown jewels.

The end game ought to be to make this information available to other services and make mail the data platform, not build new applications. Sadly, I don’t think that’s a very interesting business to be in – I don’t know how you re-establish yourself as a major player in social networking by simply providing the data layer that powers other applications.

At the end of the day, developers care about increasing the audience for their applications and/or making more money. At the end of the day, end-users (also known as normal people) care about a great user experience and a compelling services.

With these goals in mind, here are a few thoughts about the open social movement:
1. OpenSocial is a set of APIs, not an actual product – Despite all of the speculation about what it will be, I think the press releases are pretty clear about what it won’t be. What’s being contemplated is a set of APIs that will make integration social data easier and allow developers to pull from a wider variety of sources. It’s not actually a product or service in and of itself. The onus will still be on the community to build cool stuff that makes use of the platform. And the underlying data has to actually be useful – this alliance has to have profile data about people and entities that are actually interesting to developers.

2. Open systems tend to work best when competing against truly closed products. There are a lot of posts on the web that keep citing the “fall” of AOL and the triumph over the web. Two quick things I think bear mentioning. If being valued at $20 billion recently is a “fall” then I bet a lot of companies would be happy to fall. AOL is no longer the force it used to be, but it hasn’t exactly disappeared. A better example is the case of open source software in the enterprise. In the case of OSS, the vendors were so intent on maintaining control that there was a real market opportunity for more open entrants. Facebook is not completely open, but it’s certainly more open than MySpace. It will be interesting to see if an extremely open system can beat an open system.

3. Having open APIs does not remove the need to build really great products. Openness is a product decision. Being more open than your competitors does not guarantee success. It doesn’t guarantee adoption. I do think, though, that it gives you more flexibility to be clever about how you integrate with others. Simply opening up does not remove the requirement to build products that take advantage of that openness to build better products and services.

One of the undertones in a lot of the blog posts I’ve read is that new upstarts on the Facebook platform haven’t been able to break through to dislodge RockYou or Slide. Naturally, finding a new pasture in which to compete where you can be one of the first-mover launch applications is appealing. But at the end of the day, this open coalition has to deliver on its promises to developers (openness = more opportunity to acquire users or make money) and end-users (openness = better user experiences and more compelling applications) or it won’t work.

I think it will be really interesting to see how this all pans out. We’re clearly in the early days of this.