Depending on who you ask, Google+ is either a thriving social network and the most important backbone of Google’s social efforts, or a deserted wasteland where a small clique of fans keeps the lights on. I tend to think it’s doing quite alright for Google, but I also know that I would use it far more if I could use a desktop client (and maybe one that combines Twitter, Facebook and Google+) to read and post updates. Google, however, has steadfastly refused to launch a full read/write API for Google+.
At I/O earlier this year, the company’s representatives said that they don’t want to “disrupt something very special” and “magical” by just letting third-party apps post to it. What Google wants to avoid, it seems, is auto-posting news updates, cross-posted tweets, and other updates it considers to be of low value to its users. Google also wants to keep full control over the Google+ user experience. While it has whitelisted a few tools like Hootsuite and Engage121 and now allows them to post to Google+, there are currently no consumer-oriented tools for directly interacting with Google+ without going to the site.
Sure, there are the Google+ buttons, a basic read API and the Hangouts API for those who want to run video chats and a few other tools, too, but unlike Twitter, which despite its recent kerfuffles with developers still enables lots of interesting third-party services, Google+ still feels very insular. If I want to post a picture to it from my phone, I have to use the Google+ app. If I want to post an update, I have to use the Google+ app. But while that app is actually quite good, I’m pretty sure we would see a lot more innovation and interesting use cases for Google+ if the company made it easier for developers to really start using it as a platform.
At I/O, Google quietly launched the Google+ History API for privately sharing updates to Google+ to your profile after the fact, but I’m not aware of any popular apps or web services that currently use this API. Throughout 2012, the Google+ team always said that it won’t release a full API until it is sure it gets everything right and won’t have to make changes later on that will upset developers the way Twitter did this year. It sure is taking its time to get things right, though, and as time passes, this argument continues to lose its power.
Maybe it’s telling then that the Google+ developer blog (the “official source of information about the Google+ platform”) has only been updated twice since the end of this year’s I/O. To be fair, the team regularly posts on Google+, but there have obviously not been many major updates to the platform in the second half of 2012. Google, it seems, really isn’t all that interested in turning Google+ into a platform. Instead, it wants it to remain as pristine and tightly managed as possible.
I often think of Google+ as a walled community with an overbearing homeowners association that wants to make sure your lawns are perfectly trimmed and the flags you hang outside your house aren’t offensive to anyone. It’s safe to let your kids play on the streets there, but it’s also a bit boring. That, it seems, is the community Google is striving for on Google+, but I can’t help but think that if it opened the gates a bit wider for third-party developers and let them innovate on top of the Google+ platform, the social network itself would quickly become far more interesting, too.