Google’s social failures, and how they could still win

Ars Technica has an article about Google’s failure in social, which ignores the toxic nymwars but is otherwise very insightful.

I use Google+ and Gmail. I have an Android phone. I’m subscribed to Google Music All Access (because it works in a Linux browser and pays artists the most). I’m signed up to get Google Fiber. I’m not anti-Google at all, yet it seems like they keep trying to drive me away.

I used Latitude. When it was killed to force people to use Google+ location sharing (which lacked basic functionality), I stopped using Google location services and switched to Glympse instead.

I used Reader. When it was killed to force people to use Google+, I switched to Feedly.

I used Google Play and rated apps. When they forced real name Google+ logins, I stopped rating apps.

I used Google Places and reviewed restaurants. When they forced real name Google+ logins, I stopped reviewing restaurants. When they killed Places and shoved it into Google+, I stopped using it entirely and switched to Foursquare.

I used Picasa. When they killed it off in favor of Google Plus, I turned off autobackup on my phone and I use Syncthing for that instead.

I used Google Talk. When they made Android’s Google Talk app into Hangouts and made it incompatible with XMPP, I switched to a regular XMPP application. If they ever go ahead with their apparent desire to get rid of XMPP support entirely, I’ll stop using Google’s IM entirely.

And as I say, I use Google+. But I’m not very enthusiastic about it. When the promised API failed to turn up, I decided to stop posting my own stuff there, and just use it for sharing links.

So, Google, you want a success again after so many failures? Here’s my suggestion.

First of all, forget about winning with Google+, and you can probably forget about getting any traction by reviving Reader. You’ve burned those bridges, salted those fields, and screwed those pooches.

No, you need to work on a popular product that people don’t hate you for ruining yet. So revive the investment in Google Talk. Build a best-of-breed XMPP client (eventually with video and audio chat), for Android and Web. If you are really convinced XMPP can’t be made to work, define your own open standard IM protocol, but remember, you don’t beat a walled garden like Facebook or Skype by building another walled garden. Google+ should have convinced you of that.

Here’s your minimum feature set for the IM piece:

  • TLS secured connections. (XEP-0035)
  • Multi-user chat with room names. (XEP-0045, XEP-0307)
  • File transfer. (XEP-0052)
  • vCard contact exchange. (XEP-0054, XEP-0292)
  • vCal calendar event exchange. (XEP-0097)
  • Location sharing. (XEP-0080)
  • User avatar icons. (XEP-0084)
  • User moods. (XEP-0107)
  • User activities. (XEP-0108)
  • Compression to save mobile data. (XEP-0229, XEP-0286)
  • Quickstart to save mobile data and decrease latency. (XEP-0305)
  • Actions (/me on IRC). (XEP-0245)
  • Message delivery receipts. (XEP-0184)
  • Federation with other XMPP networks so network effects work in your favor rather than against you.

As you can see from the XEP numbers, it can all be done using standard XMPP, so it should be. If you’re tempted to go NIH and build your own protocol, remember that you’ll need to implement all the above stuff from scratch to be even remotely competitive. The Hangouts guys never managed in their years of trying, so learn from that mistake. Better to implement the working standards that already exist, and then add some value doing stuff nobody else has done yet. With that in mind, here are some ideas for features competitors don’t have, that could drive adoption:

  • Get the Bump guys to work out a neat way to bump phones and automatically exchange my contact card with the other person via XMPP.

  • Ping the other person with an audible alert (subject to permissions of course). (XEP-0224)

  • Blocklists and invisibility. (XEP-0016/XEP-0126) — this’ll get women and minorities interested and give you leverage against competing systems.

  • Abuse reporting. (XEP-0236) — ditto.

  • New contact reputations. (XEP-0275)

  • Searchable public user profiles. (XEP-0154) “Who can I chat to locally about…?”

  • IoT data delivery, so you can talk to your Nest or Dropcam and have them reply. (XEP-0323)

  • Zeroconf-based serverless local IM. (XEP-0174) “Let’s see if anyone else on the plane/bus wants to chat.”

  • Roster exchange. (XEP-0144) “Oh, here’s the project team.”

  • FOAF-based spim (friend request spam) blocking, so people can require an “introduction”.

  • Personal persistent channels, so I could use the system as a work log, time recorder, or whatever.

  • Persistent published channels, so I could IM to a channel that would end up on the public web. (XEP-0277)

  • An age limit option and parental supervision settings. Kids love texting and are your future customers, so you need to build your service in such a way that parents can safely let their kids use it, yet still allow the kids some privacy from their parents. The company that cracks that problem is going to have a massive hit.

Of course, if you make the system open and standard, people will naturally build all kinds of cool stuff on top of it. Slack is built on IRC, after all. In fact, ideally I’d like to see XMPP used as the basis of something that could compete with Slack. (IRC is a crufty protocol with a network model that doesn’t scale.)

If you did all the above, Google, you’d have a kick ass IM client with social features that people would actually want to use. It wouldn’t matter that you federated with other XMPP services, because people would migrate to your client for the features even if they kept their other XMPP accounts. I haven’t seen any client out there that does all that stuff, even though it can all theoretically be done just by implementing existing XMPP standards, leveraging existing XMPP libraries and server code. And once you get people using your IM client as their primary interface all day every day, you can extend in directions like microblogging, photo sharing, video and audio chat, and so on.

If you go ahead and do this, for heaven’s sakes don’t put another Vic Gundotra in charge. You don’t want an ex-Microsoft manager; put someone in charge who uses IM and/or IRC every day, and who has done for decades. (But no, I’m not a manager and I’m not interested in relocating to Mountain View.) And obviously don’t force everyone to have a single profile with their real name that everyone sees.

There’s nothing magical or secret here. As you can see, it has all been imagined before and most of it has proposed XMPP specs. The problem is actually doing it — you need a product manager who really uses the product every day, some smart engineers who will make the servers scale, expert client software engineers for all the major platforms. You need managers who will tell them they can’t go NIH and make up their own protocols, and that they should focus their talents on things that actually add value. You need a conviction that openness almost always wins over closed and proprietary, and that you can never force people to use something.

As to how to make it pay, personally I’d have a robot show up like a person on your roster, and tell you about stuff relevant to whatever you’ve been talking about. You mentioned a TV show? Here’s an ad for another show you might like. You mentioned a car? New car ad. Just make it a channel nobody has to look at, and they’ll probably peek in every now and again out of curiosity. (And of course, they can be shown the most recent content summarized in the relevant roster slot to pique that curiosity.)

So, how about it Google? Ready to build something people want, rather than something engineers or management want to build?