I strongly agree that the write API should be opened in a way that is convenient for users and developers. Moderation should follow the same principles like on Facebook: If I delete some posts from my timeline, the creator of these entries gets downgraded in regard to visibility (to me).

Buzz had a Write API. And it was swamped with noise as people used automated tools to cross post all their Twitter, Facebook, Friendfeed, etc etc etc posts. Google didn't really work out how to handle this before Buzz was shut although you could do things like block Twitter posts from Robert Scoble while still following his Buzz posts. I guess this left a bad taste in Google's mouth and somebody somewhere said "never again". So IMHO, they'll never open up the Write API without very careful work on spam and noise control.

I'd like to propose an alternative. A Page/Tab on the Profile for imported content with a Write API. Don't push these to the main stream, Don't push them to circles or communities. But do extent the list of links on the ABout tab to include automatically imported content from those links.

While I understand the concerns form Googles side, I must oppose this idea. Why? Look for example on Facebook. All activity is on the feed. Other sites and even the search is hardly ever used. People want it simple and simple means: one stream for everything.

But back to the original topic. Twitter, Facebook, Instagram and all other social platforms also have to deal with cross-posting. This will probably NEVER change unless there is really only ONE platform to rule them all. Which would be bad in a lot of ways. To prevent spam, Google could limit the amount of writes per user/page feed and app to let's say 3 daily. Every other responsability should be given to the users, the self-management works very good in most cases.

+Martin Müller I also think a kiss design is better, but Facebook doesn't have a single stupid feed anymore. They do collapsing, and some categorization (music, sport and game activities, for instance)

I don't get what is the deal? Why does Google have a social platform that still has no documentation for writing to the Google+ streams? You look at all of the major social platforms like Twitter and Facebook and there is much growth that can be attributed to having an API.

Orkut had it, Google+ does not.

In that whole thread there is no answer to the fundamental question of the issue, "why is there no write access to the API". It's ridiculous to have an issue that is open about such a hot topic for so long and not even give an answer to the question.

Google's mission is "[…] to organize the world's information and make it universally accessible and useful". Here are developers that are hanging to give Google information. We want to be able to feed you data, and your rejecting it.

I understand why it might not be there. Maybe Google want to stop streams becoming one big spam fest, I don't know. What I do know is that you getting a whole bunch of developers that want to integrate writing to streams, and have wanted that access for more then six months, and because of something that is happening over in the Googleplex, not one word has been said about it.

It comes down to: Help us help you make it that much more popular.

If you read my comments yesterday on Tim’s post, you’ll know that developer demand, though important, is not sufficient is isolation to get features implemented:

https://plus.google.com/u/0/100950714873798861880/posts/MA9kYepxgvC

Although developers are very important to us, and we want to respond to their needs, we have to balance the interests of developers with those of Google+ users and the Google+ product (and when push comes to shove, users come first). No matter how much developer demand there is for a feature we will only offer it if we believe that doing so is in the best interests of all three parties. This policy is actually pro-developer, because the very worst thing we can do to damage developer trust in the Google+ Platform is launch features which we later have to deprecate because they prove to be bad for users or the network.

We also have to weigh the benefit of the feature against the cost of developing, maintaining, and supporting it. The cost of developing the feature is a function of the number of impacted teams (ie. the API team and all backend infrastructure teams that the feature relies on). The cost of maintaining and supporting a feature is a function of how much ongoing work it will generate for operations teams, such as developer relations and the teams that handle abuse.

So let’s take the specific case of a stream write API and evaluate it against these criteria.

It’s important to bear in mind that we already offer a 3rd party sharebox for web, iOS, and Android, so any developer can add explicit sharing to Google+ from their app. That means that a write API is only needed if you insist on building your own share flow, or wish to share "automatically" (ie. without allowing the user to prescreen what you are sharing and submit it manually).

Developers normally want to build their own share flow either because they want a single share box that posts across multiple networks simultaneously, or because they are very possessive / protective of their pixels, and uncomfortable with UI controlled by a 3rd party being injected into their app.

However building a share box for Google+ is actually very hard to get right. This is because of all the different potential audiences and the ways they interact (circles, communities, domains, domain restrictions, etc.). In addition there are regulatory and enterprise requirements that need to be enforced, and new requirements regularly arise as the product evolves which existing implementations would fail to meet.

To enable development of 3rd party share boxes we would also need to expose circle names in the API, which carries a bunch of privacy and “transitive trust” implications. Even if we could expose circle names, we would need to honor the Google+ Sign-In controls on circle visibility and sharing audience, which would lead to a horribly broken user experience in which some of the user’s circles and friends are not visible in the audience picker, and some of the people that are visible can not be shared with.

Given all of the above, I don’t see us being able to facilitate development of private share boxes any time soon, or possibly ever. So that leaves the automatic sharing case, in which the user does not see a share box but the app just shares in the background in response to their use of the app.

There is a way in which we can enable this which avoids most of the issues listed above. This is to force the user to select the sharing audience that will apply to all automatic shares from that app during the sign-in process. The audience picker would then be controlled by Google (thus correctly implemented) and the selected audience, circle names, and other private data would be invisible to the app. The app would just say “share this post” and we would do so with the chosen audience for that app.

This was the approach we took for Wordpress. However it's not ideal from a user experience perspective when applied to other apps, because at the point of consent the user often has no idea what type of content a given app will share, and can’t make an informed decision as to what the audience should be for content shared by that app. And if they want to change that audience later they would need to do so within their Google+ settings rather than from within the app, unless the app invalidates their token and forces a reauth.

Even if we go down this route, we also need to ask ourselves whether doing so would be the right thing for our users, developers, and Google+.

There are two reasons I overwhelmingly hear for why developers want to post automatically. They are distribution (raising awareness of their app) and resyndication (cross posting content across multiple networks).

"Distribution" is (IMHO) just a fancy word for "I want to use the Google+ stream as a means of advertising my app to the friends of my users". I understand how important user acquisition is to a startup, but there is plenty of evidence to suggest that many users choose not to connect apps to their social networks for fear of this. So encouraging this is potentially user hostile.

Resyndication is more nuanced. The supporting argument is that there is a lot of great content being generated online, and with no means of posting that content to Google+, users of Google+ will miss out on it. I definitely have some sympathy with that argument, which is reflected in the work we have done to enable sharing of posts from Wordpress.

The counterargument is that it's important that Google+ develops its own identity as an engaging destination for users. If all users see on Google+ is the same content they see on other networks, what reason do they have to return to Google+? Even worse, if that content is sourced primarily from other networks, or from apps that are forced to adopt a "lowest common denominator" approach to content because they share across every network, then all of the benefits of Google+ (targeted sharing, support for long form content, style markup, etc.) are lost.

As Julian says, this was definitely an issue with Buzz, in that the network did not have time to develop its own identity and organic growth of original content before it was overwhelmed by resyndicated content from other networks. And allowing some resyndication but with daily limits will just generate user confusion, as they will believe that Google+ is “broken” if half of the content they share is mysteriously dropped.

A solution to this is not to reject high volume content from apps, but somehow ‘demote’ that content. ie. apply ranking to the stream, and rank API sourced content below content posted using the Google+ app, or the 3rd party Google+ share box. Over time learn which apps generate high quality content based on the engagement we see on posts by each app (eg. comments, reshares, +1s). Allow users to hide posts from specific apps, or report specific apps as abusive. Build reputation scores for each developer based on the behavior of previous apps they have published and use that to define the initial ranking of new apps they publish. Block developers from publishing on the Play Store if they repeatedly publish abusive apps. etc.

This is entirely feasible from a technical perspective, but it is a very large project. It would require major changes to stream ranking, the stream UX across all platforms, app management settings, plus new machine learning algorithms for building the reputation scores per app and per developer, and tight integration between the APIs Console, Play Store, and Google+.

That’s a very hard sell within Google. I’d need to persuade all of those teams to prioritize this over all of the other work they are doing, in order to support a feature of debatable value with an unavoidably poor user experience. That unavoidably poor user experience will inevitably lead to operational cost ongoing, as will the attempts by spammy apps to game the system, which only further drives up the overall perceived costs vs the (already somewhat weak) perceived benefits.

This is why I’m so keen that developers share their use cases for this feature on the issue tracker, because if I have some really killer new use cases that do not just boil down to app promotion or resyndication then I can make a much stronger case for the investment required.

Now, hopefully you can see from all of the above that, even if you disagree with the rationale or the conclusions, we’re thinking this through and trying to do the right thing given the resourcing and prioritization constraints we operate under. Please don’t make the mistake of thinking that we are not aware of the demand for this feature, are ignoring that demand, or otherwise don’t care about developers or their needs. Nothing could be further from the truth.

On a more positive note, I do believe there are steps we can take to move things in the right direction without having to bite off all of the above at once. The Domains API was the first of such steps, in that it allows posting and commenting, and exposes circle names and circle members, but mitigates the risks by constraining use to the user’s Apps domain. The Wordpress integration was another such step, in that although only available to an individual partner it allowed us to evaluate the user response to the preselected audience sharing model, and start gathering data on the relative engagement on cross posted API sourced content vs organic content unique to the network.

We have plans going forward that will continue in this vein, gradually expanding the capabilities of the API, and addressing some of the user experience issues, while allowing us to gather data on the impact, both positive and negative. But some continued patience will be necessary on your part, and you should not expect to wake up one morning to find we have launched everything you hope for at once.

Keep watching this space though, for interesting times lie ahead…

Resyndication is interesting. I generally post first on G+ and then use dlvr.it to cross post to Twitter and Facebook. I also use some home brewed php code to cross post to my own blog. Part of the reason for using dlvr.it and using my own code for the blog is because G+ still doesn't have Atom/RSS as an output format. (see https://code.google.com/p/google-plus-platform/issues/detail?id=139). Atom/RSS would make it trivial to syndicate G+ posts outwards as so many systems support Atom/RSS input. Encouraging this outwards syndication ought to appeal to Google since it avoids the issues above but also generates incoming links that will encourage engagement with the platform.

+Thor Mitchell Thank you for your thoughtful post.

Thank you for your very elaborate answer,+Thor Mitchell . I understand that Google wants to provide the best experience to the users.

I am indeed currently working on an application that represents the usecase described as "best possible scenario". Users can create rich content on a platform, spreading the best possible version to each social network respectivly. That means networks like G+ which support markup and rich content will receive the full-fledged posts while Facebook and Twitter receive a version that is missing most of the features.

Now, I could give my users a G+ share box in my application but that would differ very much from the flow for the rest of the networks. Also, it introduces a new thing to learn to my users, which (some of them) are not used to using the internet very much in the first place. But they can create great content using my WYSIWYG editor.

Maybe this example helps to understand my motivation asking for an API write access. As for te technical solution, a selection of circles on auth may be the best way indeed. This is also the way Facebook determines where apps can post. The same problem with the post rights (users have to change these settings within Facebook, not the app) exists there, too. I think most users can live with that, because they anyway would not authenticate an app to write on their behalf in which they don't trust.

I agree it's nice to hear the reasoning. But I think it's wrong headed to be looking for a "killer feature".  The killer feature is "interesting content on Google+". Which is now not the case. I don't post anything to Google+ because it is a PITA.

In fact the only times I do post to Google+ is when I'm in self-promotion mode and am hoping to get a little Google Search boost. 

For simply sharing something I find interesting, funny, insightful, expecting me to take that extra hop is just too much friction.


But let's call a spade a spade. The Google+ team has decided to let HootSuite and Buffer users post to Google+. So in effect, there is no real barrier to posting to Google+, you just need to be using a 'blessed' application. There is no protection against promotional content. There is no restriction on resyndication, because I can use those apps and get the utility that everyone here is asking for.

All we are left with is a very uneven playing field for the various services that are trying to help people use social media. Where each review of a new piece of software says:  Cons: No support for Google+    like this
http://www.pcworld.com/article/2064279/review-symphony-is-a-so-so-social-media-manager-that-does-wonders-with-pictures.html

Buffer, Hootsuite, and a small number of other brand management tool providers have access to the Google+ Pages API under a partnership agreement. This means they can generate posts, but only as a Google+ Page. They can not post on behalf of individual users.

This is a significant distinction because in general users have a less personal relationship with brands than with people. If a brand Google+ Page begins to post low quality content, the cost to you of unfollowing them is low. If however a close friend or family member starts using apps that generate a lot of low quality content, you are faced with the difficult decision of either unfollowing them, or curating their content manually.

Also, because these tool providers are partners we work closely with them, reviewing their integrations carefully and ensuring they comply with our Terms and Developer Policies (including 3b and 3j, which prohibit automated posting and repetitive or spammy posts). However that's very high touch, and not scalable to the long tail of tool providers and other developers.

As far as selecting circles goes: When authorizing an app to access the G+ api for a given user, ask the user "Which Circles can this app share with?", at which point the user is present with their circles and can select the several circles that apply to content from that app. Then, when posting in that app, the app should be required to list the circles with an additional link "Don't see the right circle? Add more circles here." which jumps to the auth page where the user can reset their circle selection for that app. I'd imagine that many apps would use a select box for that.

Or, in addition to providing a "share box" that can be integrated into apps, add a "circle selection box" that allows a user to select a set of circles to share with, then generate a token representing that circle selection, and only give the app that token, that has to be passed in with the post.

My use case? I want to build an open source hootsuite/buffer-like app as part of Neos (neos.typo3.org) to make it easy for users to post something when they make a major update to their website. Another use-case within this app: I want to target organizations that have internal content review processes (ie: you're not allowed to post this on our social media accounts until the PR people have a chance to look at it, or until a lawyer looks it over, or until some higher up management says ok, etc). That means, that both the page update, and the attached g+ post, fb post, the tweet about that page update (and potentially posts on other social networks which should each be customizable to the culture of that network from within my app) would go through the same corporate review process. Then, as soon as the app gets approval for both the social post(s) and the website update, both would get pushed live simultaneously.

+Julian Bond looks like Google is waiting with that G+ Write API until G+ is about as dead as Buzz...?

+Thor Mitchell yep, and Pages happen to be "magically" dead (sans SUL boosting) for a variety of reasons pertaining to their design/policies. They can pretty much only serve for SEO purposes anymore...

+Alex Schleber I wouldn't go that far. Buzz was horrible, Google+ is literally millions of times better then Buzz was. 

and I don't see much point of creating a page just for the point of being in the "Suggested User Lists". Especially if a brand does not post any engaging content.

+Tim Groeneveld I didn't say that G+ isn't better, only that G+ is also dying a slow death (slower than Buzz to be sure) for Google's lack of adept moves with the platform.

The Write API thing was a no-brainer to me in 2012, when everybody expected something to be announced at GoogleIO. There were people I'm sure standing ready to build some much improved clients for G+, that would have alleviated the most if the short-comings for a lot of info/text heavy users.

But nothing... by now it's basically too late. Look around, except for a few outliers (and some of that SUL x What'sHot juiced stuff), the engagement rates are trending toward between 1 in 10k and 1 in 100k... That's unsustainable for just about any user with less than 10k+ followers.

They just about never see a single plusone or comment. But even for the "bigger dogs", look closely at what is happening. Plenty people with 50k followers (even organic!), and even those with millions have more or less abandoned their accounts, or come back once a week...

Most of the communities I'm in are dying[1] as well. Not sure if that's me or what.

It's really hard to define this stuff, but there is something about the UI that is not conducive to long threads and conversations. I don't think it's the lack of threading (which I don't like or want). I just find it easier to have a long rambling conversation with 4 or 5 people on FB than G+.

It would be interesting to know what engagement figures are doing on Youtube, post the comments change.

[1](Except Cycling and SciFi. Go figure.

+Tim Groeneveld I mean this only in the sense of that having proven just about the only way that a G+ Page has gotten followership/traction. Even the very "pro-Google" crowd on here (largely SEO and/or "how to use G+ for business" crowd) has in recent weeks more or less admitted that a Page by itself is pointless unless it is being promoted/boosted by a "personal" profile and presumably that persons high-follower-count/SUL-boosted buddies.

But even then I've only seen some very tacit results. If Elgan can't get traction for TwiT, etc. then presumably it's a tough one...

I agree with you that it's been hilarious to see Google give away SUL spots to brands they wanted to glad-hand, and then those same brands turning around and not even using the account much (WSJ was such an example).

This has been going on for nearly 1.5 years BTW... plenty of these brands had 0 illusions that this was not getting natural traction (Google throwing endless amounts of new folks into the top of the funnel, and almost no one staying around as an active user - daily or at least a few times/week). So they put in a token effort at best after a few months...

+Julian Bond agreed about the YT question, hard to say on the YT end without interviewing some of the key content channel producers there.

As for G+ however, I am about 90% certain that it had a further dampening effect on overall participation by prior-G+ users here. I.e. everyone started avoiding commenting on YT content shared here for fear of being dragged into the YT commenter cesspool...

Yes, Communities, while going in the right direction as to what Google should have done to begin with, were introduced far too late in the game to make a real difference, and most of them prove to be unsustainable either due to spam, and/or due to the fact that they are buried too deep in the UI to get sufficient attention/traction (also, since most people set their community post activity to "don't show" for their profiles, and there is only a Global ON/OFF option for this, it is too difficult to find out in most cases where some of the people you're following are active).

Again, overall all way too many centripetal forces are leading to this slowly but surely "toys winding down" effect.

but will it be available to all anytime soon ? Let's hope it will get announced at Google I/O

+Laurent Dinclaux it will probably  be available to nobody ever... :)

Actually, post-Gundotra the chances may have gone up just a little.

+Naushad Ali  My application currently writes CSV files that are downloaded to the local machine, and then uses Hootsuite's import tool to pull in all of the content (they have write access to Google+... it's not like the functionality does not exist).

Not an ideal scenario, but it does work.

+Alex Schleber I agree. Strap in, the demise of Google+ will be Google's own doing. Not listening to suggestions given by users and the desire to pull all of Google's userbase into Google+ (as evidenced by the YouTube integration, Hangout integration and their lack to add features literally requested 18 months ago).

+Tim Groeneveld Write API on Hootsuite for Pages only though, no?

+Alex Schleber Yes, this is correct. Only for pages at the moment, however for my purposes this is all that I require. Google giving public access to developers for this functionality will relieve 70% of the current requests for the Google+ "write API".

I can understand Google being a bit finicky about providing write access to people's streams. Even #Facebook  has changed the way that they provide access to publishing on a user's stream, with the permission causing an extra Facebook authorisation dialog to appear, and the post getting less chance of getting organic reach. Also note what +Martin Müller stated on the first comment on this discussion about what metrics Facebook takes into account when posts are deleted from apps that post on walls.

After attempting to hit up +Thor Mitchell on Google+ and other Googlers face to face to provide this functionality, I am willing to declare to myself that this is a feature that Google feels that the community can do without.

That's sad. With Facebook dropping it's organic reach, it's no longer  useful to disseminate information on that platform, as the cost to benefit is not really there.

Here was me getting all excited about Google+. After the debacle that was Google Buzz, and Facebook taking eyes away from other Google products, I thought that the Big G would want to try and pull users to Google+.

Me personally? I use Google+ to complain about the fact that I can't post to Google+ and read longer form tweets.

Google+ had a lot of promise, but now it feels like a really noisy version of medium.com.

Good work Google.

My brands are throwing an Eat247. Except we are leaving Google+.

http://blog.eat24hours.com/breakup-letter-to-facebook-from-eat24/

I wonder if Vic G leaving will have any effect on the way that API issues and feature requests are handled. /s

As I see it, Google will use G+ only as a background platform in the future. Not only Vic left, basically all the people working on G+ have been re-assigned to other projects. So sadly we will probably never get this functionality.

FWIW, the notion that "all the people working on G+ have been re-assigned to other projects" is totally and utterly untrue:
https://plus.google.com/+MarkTraphagen/posts/GqprsA8tiY3

+Thor Mitchell Is there an issue tracker for the whole G+ platform, or only for the API? Is the feedback form the only route to offer suggestions and bugs?

The feedback link at the bottom of the main nav panel is the best form, as that's routed into a formal process of review, aggregation, and prioritisation:
http://goo.gl/O08n18

A good use case might be Livefyre's comment box, that currently allows sharing on FB, Twitter and Linkedin but not G+. In that case, user intention would be quite strong and content shared - pretty personal. While lacking such an option in Livefyre or other commenting systems that may want to use it seems only unfair to G+ users.

+Thor Mitchell You probably forget the case of push notifications. Take a movie rental that want to post when a new movie is up. This is only a re-syndication if the system is manual. Given the number of popular push notications systems (Pushbullet, Prowl, Toasty, Pushover...) this is not such an uncommon case even for a single user service.

Another way to see that would be a computer account. There the circle privacy would not be an issue as it'd not be a user's account but a corp account of a bot, represented to users like a company G+ account.

Even just for personal use - wanting to share a couple of interesting things per day to Facebook, Twitter, and G+, - manually sharing to more than one place gets rather annoying. I was surprised to learn from here that automated posts to Facebook are demoted to some degree.

I'm actually strongly considering writing a personal app for sharing automation using Capybara & PhantomJS. I know UI changes can cause breakage, so I'd like to try and mitigate this with a more human approach - running some automated test post regularly to determine when it's been broken, then presenting the UI and recording the new steps required. I'm torn about open-sourcing this...

Okay, I think after a day of reading to this discussion and several others, have to say I have enough. Dropping entire Google thing out of my application. If G+ were a girl, I would say, call me Baby when you make up your mind :)