Wave Postmortem

August 19, 2010

Naturally, I was off on vacation and away from most of the Internet when the news broke that Google was going to cancel Wave As We Know It.  (I love my Android phone, but it’s not really the tool for serious blogging.)  Lots of people have written about the topic, mostly along the lines of, “Wave was always a piece of junk”.  They’re wrong, but the fact is that Google managed to screw this one up in a lot of ways.  Let’s go through some of the problems, and their implications.

Lack of Patience: From what I can tell, Wave has been tossed to and fro based on management whimsy and panic; there doesn’t ever seem to have been a properly designed plan.

It was released very prematurely, when it was barely alpha-grade (and I suspect well before the engineers wanted it released), apparently because they wanted something to show off at Google I/O.  This meant that the development team had to spend the entire past year mostly firefighting, instead of doing the sort of hard and principled sanity-checking and redesign that it needed before public rollout.

And now they’re killing off the public project after scarcely a year: ridiculously too quickly for a product that they had sold as revolutionary.  Twitter is the exception, not the rule: most revolutions take years to percolate before finding mass-market acceptance.  (Think about ICQ, or Friendster, or Mosaic — the first version of a revolutionary idea is usually several years before it hits big.)

I’m coming to the conclusion that Google’s biggest problem right now is that they are being surprisingly clueless about how to manage new products.  Wave is a great product at its core, and Buzz a decent one, but both rollouts have been mismanaged on an epic scale.  If Google needs to fix one thing about the company, this is it.

Identity Integration: Everyone treats this as an afterthought, sometimes even something to be avoided for pure business reasons.  But it’s a huge problem, and Wave demonstrated why.

At initial rollout, Wave didn’t work with any existing identity system, not even Google’s own: you had to get a new “@googlewave.com” address to use it.  Even when they started to open things up, it only worked with Google IDs.

Frankly, this is dumb.  I understand Google’s motives for doing so — it’s technically a hair easier, and it encourages people into Google’s ecosystem — but it’s a foolish hurdle to put in front of a radical new tool that you are trying to get people to use.

The public is suffering a really bad case of identity fatigue: too many incompatible logins to manage.  Each one is a minor thing, but each one leads to an additional reaction of, “What, again?” when folks have to create another one.  In a perfect world, Wave should have been built on a generalized concept of identity that accepted, eg, Facebook logins, but at the very least it should have worked with OpenID and the rest of the open stack.  I remain extremely disappointed that Google put far less thought and effort into this problem than I did on my own for CommYou — you just can’t keep pulling this on the public and expect to win.

Lack of a Killer App: The biggest complaint about Wave has been the constant question, “What is it for?”, and I have to lay a lot of blame at Google’s feet for not answering that more clearly.

The thing is, Wave has multiple killer apps.  It is a brilliant co-editing system, easily the best tool I’ve ever encountered for group document development.  And while it’s a bit overweight, it is in many ways the best conversation tool I’ve found to date (aside from CommYou, of course), mixing realtime and asynchronous conversation smoothly.  In general, it’s a fine collaboration mechanism.

Either of those (and probably other stories) could have been a fine selling point — but Google dropped the ball.  Instead, they simply tossed it out with a vague and confusing “It will replace email!” (what?), and never pushed any motivating examples properly.  So it never developed the core audience that any tool needs in order to survive.

My sometime CTO Chris Herot has occasionally lectured me about the problem of Crossing the Chasm — taking a tool that is great and making it successful.  A key element of that is always the killer app: showing at least one core group of users that they can’t live without this thing.  Google simply assumed that others would do that job for them.  That was arrogant, frankly, and it didn’t work.

Bloated and Slow: Mind, this is a hard problem, and it’s a damned sophisticated tool.  But seriously: Wave runs kind of slowly even on Chrome, and doesn’t run at all on Internet Explorer.  (No, Chrome Frame is not an answer.)

That’s just plain unacceptable for a current web-based tool — again, it was kind of arrogant on Google’s part.  It’s especially unacceptable for a social tool, because social tools are all about critical mass.  If a large fraction of a community is unable to use the tool, that’s an enormous handicap, usually an insuperable one.  And much though Google might wish otherwise, a large fraction of the world is still IE-based.

I can sympathize with Google here, and cutting out IE6 is entirely reasonable at this point.  But not supporting at least the same browser set as Gmail was a serious mistake.  They need to trim down and optimize the UI to the point where it will run acceptably on the full range of modern browsers, if they actually want this stuff to ever be real; anything else is simply wishful thinking.

(The engineers in the audience might want to take note of a general lesson here.  Successful products usually follow the path of starting with a simple tool that implements a great idea, and then slowly expanding from there.  Wave did the opposite: it has a lot of pretty innovative ideas, but has proven to be a bit too ambitious for its own good, putting features ahead of the basics like broad compatibility.  I’d bet that, if you teased Wave apart into its component parts, there are half a dozen great products to be had there, that would be more successful.)

No Mobile Support: Similar to the above, but worth calling out separately, is the fact that there hasn’t yet been any practical way to interact with Wave on a smartphone.  Nowadays, that’s pretty much unacceptable.  I mean, how can you claim to be a replacement for email and not have a mobile solution?

Now let’s be clear: this is hard.  Really hard.  It’s arguably a fundamental design problem — the way Wave works, it really wants both a powerful machine and a big screen, because there is no obvious way to do the co-editing thing without it.

But really — Wave is, as much as anything, a conversation tool, and it is ridiculous that there is no lightweight and easy way to interact with the conversation.  Indeed, if Wave has a killer flaw, this is it.  The conversation mechanism looks and feels great (okay, I’m biased — it’s identical to CommYou), but is fundamentally tied into the co-editing.  A conversation is basically just a document that a bunch of people are co-editing together, and that means that there is no way into the conversation without all that co-editing weight.

This could probably be retro-fitted.  There needs to be a standard robot that monitors your waves and provides a two-way conversational bridge for them, an API for interacting with that, and an Android app that knows your Wave identity and talks to that robot.  A third party could have built that, and still could.  (Indeed, bits and pieces exist.)  But why would they?  This is core functionality, to make Google pieces talk to each other.  Google should have built it and publicized it properly, so that the hardcore members of the Google ecosystem — the sort of people who are mostly likely to use both Wave and Android — could work in a natural way.

Poor Business Support: I’ve spent most of the past year wishing desperately that I could use Wave at work.  Not a week goes past without us getting into some ridiculously nested email conversation with ten participants, where everybody is commenting on each other’s comments, nested five levels deep, using every color of the rainbow to try to distinguish each new set of comments from each other.  It’s idiotically painful, and Wave is precisely the right tool to do this instead: it excels at deep group conversations on a complex topic.

But I’ve been unable to even suggest that we use Wave: there’s no way it would fly.  Let’s get into some reasons why:

  • No SLAs: serious businesses require service-level agreements.  We need to be able to count on a tool that is reliable, and Wave is nothing of the sort.  This isn’t surprising — it was released at alpha-quality, and even today it’s basically a beta.  But it’s no wonder that the business community hasn’t flocked to it, if we can’t take it seriously.
  • No security assurances: I’m an engineer, and I get that nothing online is ever totally secure.  But Google hasn’t been willing to even put a stake in the ground about protecting my intellectual property, even to the degree that Salesforce does.  Without that, there’s no way I can go to my bosses and say that we should hold even casual business-related discussions there.
  • No identity integration: okay, yes — it’s probably hopeless to wish that Google would provide a way to integrate with Active Directory.  But really, it’s a huge issue.  The above problems aside, my IT department is quite reluctant (with good reason) to add a completely parallel user-management system for the company: it’s a recipe for security problems, as well as simply a maintenance headache.

Of course, little of this is unique to Wave: these are common complaints about the Google ecosystem in an enterprise environment.  But it’s particularly acute this time around, because Wave is something new.  No Microsoft-centric shop is likely to use Gmail seriously, since MS is pushing Exchange at you so hard.  But MS has nothing even remotely like Wave, and it is a great business tool, so this would have been a great opportunity for Google to get their foot in the door.  Unfortunately, I think it’s been pretty much flubbed.

Next Steps: okay, so enough about the mistakes.  What comes next?

I’m going to stick my neck out and say: Wave is dead (well, dying); long live Wave.  There are actually a bunch of reasons for optimism.  Google has said that they will be repurposing the technology elsewhere, and that’s appropriate — most of the interesting bits of Wave are infrastructure.  I’ve argued for months that combining Wave’s conversational strength with a social network (eg, Buzz) would produce the first serious competitor to the LiveJournal platform.  So I hope that Google is smart about that: that they are finally getting serious about the crossing-the-chasm problem by integrating the Wave technology inside real apps.

On the downside, if they don’t replace the Wave Inbox in some smart way, that’ll hurt.  Inbox is one of Wave’s quiet strengths: a concise and very effective way to catch up on what’s been going on, whether you’ve been off having dinner or on vacation for weeks.  I do worry that, if Google uses the Wave infrastructure without providing Inbox or something like it, the system will lose half its usefulness.

Also, there’s probably a bit of brand poisoning here.  Frankly, Google handled this a bit clumsily: by killing off the main Wave project so publicly, I think they’re going to associate the whole thing in the public mind as a failure.  That would be a damned shame, since so many of the individual pieces are so right: the failure has been mostly a management one at Google, failing to put it all together correctly.

But the underlying Wave protocol is open, and I think is here to stay.  Competitors like Novell are already adopting it, as are open-source projects using Wave.  I hope that projects like the Wave Forum (an open-source effort I’m helping with, to build a truly great forum system on top of Wave) will simply change gears a bit and move forward whether Google is pushing things or not.

So: opinions?  Counter-arguments?  What are the problems that I’ve missed above?  What pieces of Wave do you think can and should be pulled out and reused?

Okay, say it with me: Comments *are* Actions

May 21, 2010

So the good news from yesterday is that Google Buzz has opened up a bunch of APIs.  It’s officially a Labs project, so they’re doing it kind of tentatively (having been bitten in the ass by releasing Buzz itself too quickly and broadly), but by and large the new API looks pretty good.

But to my disappointment (although completely *not* surprise), it bakes flat commenting right into the data model.  If I’m reading this right, you can have “activity” objects (like a post), each of which has exactly one Comment Collection associated with it.

Why does this matter?  Because it makes the usual mistake of thinking about an “action” and a “comment” as completely different things.  They’re not, and it’s pretty broken to think about them that way.  In the larger online world, they’re just elements in the larger conversation that we are each having with our friends.

In practical terms, there are lots of implications here.  For example, by structuring things this way, it means that threaded discussions are right out — currently ruled out by the data model, and never likely to work quite right.  On the flip side, it has no concept of the other ways that an Activity can itself be a Comment — for example, a video, or another discussion, or something like that which is spawned off from a previous one.

None of which is new and different, mind.  It’s just a little depressing to see Google (which often does a good job of analyzing problems) making the same mistake that so many other sites have done.  That’s doubly true now, after Wave did a pretty good job on this.  (Although Wave then tried to do *so* much in the UI that it comes out as a little intimidating.  Their mistake was the opposite: trying to expose every conceptual detail to the user too quickly.)

The conclusion is that, while Buzz is decent at light-touch social-grooming sorts of communication (like Facebook), it’s not likely to ever be good at deep conversation (like LiveJournal) unless they wise up and fix this conceptual problem.  That’s a pity: the world needs more social networks that have a clue about how serious conversations really work…

Crowdsourcing can only take you so far

May 17, 2010

Interesting article here on ReadWriteWeb, about Facebook’s approach to banning.  It’s a bit hyperbolic, but assuming it’s correct (and really, it wouldn’t surprise me), it implies some dangerous naivete on Facebook’s part.

The high concept is that banning on FB is somewhat crowd-sourced — if a lot of people complain about someone, FB auto-bans them.  FB is claiming that this isn’t true, that all bans are reviewed; putting all the stories together, my guess is that the auto-ban *is* true, but that FB then reviews them after-the-fact.  That’s a plausible approach, but not a good one, since it means that a vengeful crowd can at least partly silence their detractors.

Mind, like I said, I don’t think it’s surprising: when you’re dealing with millions of users, including a fair number of trolls, and you have limited staff, you need *some* way to make things manageable.  But a simple numeric auto-ban (which this may well be) is too easy to abuse.  In our modern, polarized world, almost anybody who says anything really interesting is likely to have a crowd against them.

None of which means that an automated solution is impossible or evil — it just means that you need to be smart.  The story implies, quite plausibly, that there is a Facebook page dedicated specifically to listing people to attack with complaints, to get them kicked off.  If so, a smart network-detection system can pick it up.  If twenty completely random people complain about someone, the target is probably a troll.  If the *same* twenty people complain about person after person, then it’s much more likely that the complainers are the trolls (or at least, are abusing the system) — and *they* are the ones who should be banned instead.  At the least, it indicates that something suspicious is going on here, and the automated systems shouldn’t be trusted to make a decision without a human looking into it in detail.

Social networks are bigger and in some ways more complex than anything else the world has ever tried to grapple with.  That demands both cleverness, and openness about how you are managing them so that people can poke at those management techniques and find their holes.  I suspect Facebook is failing on both counts.

How would you deal with this?  Do you think automated mechanisms are even legitimate for deciding who to ban?  What tweaks should such a system put into place, to make it harder to abuse?

The little problems of coarse-grained privacy

May 14, 2010

I have to admit that I’m taking twitter a lot more seriously than I used to — at Arisia this year, @shava23 convinced that me that, if you manage your flist very carefully, it can be an extremely useful information feed.  Yes, many people still post too many “I’m eating waffles!” tweets, but if you ignore those and focus on friending people who mainly post content, it can be concisely useful.

(There are lots of folks who use Twitter for socializing.  Honestly, I don’t get that: even Facebook is a lot better at it than Twitter is.)

But it’s still got real problems, and one of those problems is its ridiculous all-or-nothing privacy model.  In most social networks, you choose on a post-by-post basis which items are locked and which are public; in the good ones, you can design highly customized filters for who will get to see what.  But in Twitter, either your entire feed is public, or it’s all locked — there’s no in-between.  That made sense when all posts were via SMS, but I think that stopped being the case quite some time ago.

This has some serious mal-effects — and one of them relates directly to that usefulness thing.  Consider: Twitter is most useful if you limit your following to people whose post information you find useful.  It’s still a social network, though, so unfriending is fraught — I’m sometimes forced to do so, in the interests of keeping that filter narrow, but it’s not something to do casually.  And if somebody’s feed is locked, I can’t see anything they say until *after* I friend them and they allow me in.

The result is that I find myself leery of friending anybody whose feed is locked.  Before I friend them, I can’t see what it’s like, to figure out if it’s information-rich.  And I’ve been doing social networks for long enough to be just a little nervous about the potential drama if I follow somebody, see that they’re posting way too much, and immediately drop them.  So I wind up not reciprocating a bunch of follows, which hurts the social network.

(Yes, it’s now possible to use lists to limit who I am actually reading.  In the long run, this may ameliorate the problem.  But third-party support for lists is still often crappy, so I’m not using them as much as I might wish yet.  Someday…)

And speaking of Twitter, let’s talk Metadata

April 19, 2010

Another Twitter topic for today, possibly even more interesting: they’ve finally woken up to the value of metadata.

This one’s not a surprise to me at all — it was in the plans for CommYou, and I’ve always thought that it was necessary.  The thing is, when you’ve got a service like Twitter, that is fundamentally about Text Dammit, you have to wrestle with the question about what to do with the rest of the world.  I mean, there is a lot more to a modern online conversation than just text: pictures, video, even embedded games and such can matter enormously.

There are a variety of ways to deal with this — for example, Wave chose to define an open API so that, if you format your other stuff properly, it can be embedded inside a wave no matter what it is.  Twitter is going a different and arguably more open route, pretty much the same one I was planning on: let people embed whatever metadata they want inside the conversation, and let the Twitter clients decide what to do with it.

(For the non-programmers out there: “metadata” is mostly just a fancy way of saying “other stuff that is attached”.  The formal term in the Twitterverse is “Annotations”.)

We’ll see how they implement it, but I like the general approach.  The implication is that they aren’t particularly trying to control the attached metadata — they’re just going to allow developers to put stuff into Tweets, to use as they see fit.  As this post discusses, that’s potentially problematic, especially if all the developers go haring off in different directions.  But I don’t actually expect that to happen: frankly, the obvious thing for most sensible developers to do is to develop mime-type standards for the various kinds of metadata, so that it works pretty much the same way email does.  Indeed, I’ll be very surprised if we don’t see mime-based metadata extremely quickly after the Annotations feature rolls out, sometime in the next few months.

Impressions?  What uses do you see for this feature?  What dangers do you see?  (It *is* a potential malware vector, but given the diversity of Twitter clients I actually don’t expect that to be an immediate crisis.)

ETA: I just came across this Ars article, which points to this posting, which gets into more detail about how Annotations will work.  Summary: they’re very open-ended, but small.  You can’t actually embed much in the tweet itself (annotations probably capped at 512 bytes initially, 2k in the long run).  That makes lots of sense, but means that we’ll quickly see an ecosystem evolve around linking things *from* tweets.  For example, I give it weeks, at most, before we see clients integration photo sites with tweets, so that you can do something like take a picture from your phone and just tweet it, with the client saving the photo to a site, putting a link into an annotation, and compatible clients pulling that out and displaying it as if it was simply embedded inside the tweet…

Twitter makes a grab for namespace dominance

April 19, 2010

Twitter has been in the news a bunch lately, especially due to their new deal with the Library of Congress to archive the entire public feed of all tweets.

(And that is worth a brief tangent: what do people think about this?  Is a permanent archive of Twitter actually worthwhile in isolation?  How many conversations occur solely on Twitter, and how many are bouncing between that and other social and online media?  I sort of wonder if future historians are going to find this feed incredibly frustrating — basically getting to read half a conversation for the entire world.  But I digress…)

Anyway, today’s main Twitter topic is their new @Anywhere service, which is looking pretty clever.  It’s their equivalent of Facebook Connect, and many of the features are similar — for example, it allows you to log into Twitter via a third-party site and do Twitter-ish actions from it, lets the site do some actions on your behalf, and so on.

But the really intriguing bit that I note in their documentation is that, if you put a little @Anywhere Javascript into your site, it will scrape the page and hook up all @-tags for you.  That is, if someone refers to @jducoeur on the page, it’ll show up as a live Twitter link to me, with a popup card, a link to my Twitter feed, and so on.

This is smart and forward-looking, and recognizes that namespace matters.  Most services today still have completely flat namespaces, where everyone gets a unique moniker.  (With the conspicuous exception of Facebook.)  You can make arguments about whether that is good or bad (and I suspect most serious computer geeks would argue that it’s a horrible idea), but it’s damned convenient to have that global handle for yourself.  It’s not at all unusual for people at high-tech meetings these days to put their @-tag on their name badges, since it’s a convenient shorthand for finding them later.

But of course, there are a hundred disjoint services out there, each of which has its own namespace.  So what is your “real” handle?  Twitter wants to make that your Twitter handle — your @-tag is the center of your universe, from which people can get to the rest of your social world.  They’ve recognized that the @-tag is one of their key bits of intellectual property, and they’re starting to leverage it.

(I’ll note that Google Buzz is already doing some fancy and smart things with their own @-tags, having picked the style up from Twitter.  But that only works within Buzz — the interesting thing here is that Twitter is trying to reach outside its own domain.)

I don’t know if they’ll succeed in this, but it’s a smart game to play, and I’d bet that we’ll see more services try to dive for this.  I’ll be very curious to see if they get any traction with it…

Wave getting better at talking to the rest of the world

March 2, 2010

Yes, yes — one of these days I’ll get back to Catching the Wave.  But in the meantime, keeping up with the news: the Google Wave Developers blog announced today that they’ve come out with a major revision of the Robots API.

To explain what’s going on here, I need to briefly get into the kinds of automata that Wave allows.  There are two types:

  • The obvious ones are gadgets.  A gadget is something that you see on the screen, generally, and tends to be interactive.  So the Google Map embedded in a wave would be a gadget, or the various implementations of thumbs-up / thumbs-down voting.
  • Subtler, but more important for conversations, are robots.  A robot is an external process that can listen to and modify a conversation.  The most obvious and trivial kind of robot that people started playing with initially was the censorbot: one that would keep an eye on the conversation and bleep out bad words.  But there are lots of others doing all sorts of things — and in particular, mediating between Wave conversation and other media like IM.

The new API has all sorts of new capabilities, but two aspects seem most immediately interesting.  First, a robot can pro-actively push data into a conversation.  This implies to me that you can start building really powerful, really interactive bridges between Wave and other services.  For example, an IM bridge becomes considerably more useful when you can send IMs and have them immediately reflected in a persistent Wave.

Second, again most obviously useful for bridging, is the new Proxying-For capability.  Basically, the robot can say that a change is being made on behalf of a specific person.  This opens up *breathtaking* opportunities for abuse, but you really have to trust the robot before you allow it into your wave in the first place anyway.

Put together, it sounds to me like Google is putting a major emphasis behind allowing Wave to interact with outside systems.  That’s smart: they’re trying to make this a key new component of the Internet ecosystem, and the more other parts they can hook into, the more it will be.

What sort of things would you be interested in hooking Wave to?  We’ve seen a lot of examples: pushing bug reports into waves; stockmarket information; IM and email bridges; and so on.  What else?  The sweet spots here appear to be recording transient events, and making it easy to hold conversations around those events as they happen.  I can see lots of obvious applications based simply on email and IM bridging, but I’d bet there are far more off-the-wall possibilities here, like live game scoreboards…

Which comments are relevant?

February 26, 2010

Okay, not to pick on Buzz (which is fine for my purposes and which I’m using a little), but here’s a very basic user interaction bug that Iam seeing.  It shows up on conversation systems from to time, and I bring it up to encourage others to think this through better.

Like most online conversation systems, Buzz notifies you where there is new content in a conversation you’ve already read — that’s generally good.  (Although they really ought to make it a little more obvious how to mute a conversation you’re not interested in.)  Like many, it elides many of the old comments that you’ve already read, so you can skip quickly to the new stuff — also good.

The bug?  It elides all the old comments to the post except the first one.  That’s broken in two respects.  First of all, in an unthreaded conversational system, you virtually never give a damn about the first reply.  (You occasionally do in a threaded system, and I kind of wonder if they are mixing up the models.)  In an unthreaded system, the first reply is old news — neither the root of the conversation nor a recent reply, and more often than not irrelevant.

The second issue is that it doesn’t show you the most recent reply.  In an unthreaded system, that’s usually the one you really do care about, because it provides the context for the new replies.  Unthreaded conversations are by their nature often pretty linear, with replies to replies in order on the stack.  So quite often (I’d guess more often than not), the new reply that just came in makes little or no sense if you don’t have the one or two directly above it in the conversation.

Again, it’s the sort of thing I wouldn’t mind if Buzz was labeled as the beta that it is: this is the sort of thing you’re supposed to fix in beta.  But it’s the sort of basic user-interaction glitch that looks kind of embarrassing in a supposedly released product.

(Am I off-base here?  My perception is that this is just a design bug, but I’d be curious to see if anyone cares to argue that it’s actually appropriate…)

Google is paying attention to the complaints

February 14, 2010

A quick update to my post the other day: Google posted yesterday that they have made a lot of changes in the past few days. At a quick glance, they appear to have addressed most of the complaints I’ve been hearing: no more auto-following, no more auto-linking to Picasa, an easy one-click “Get rid of Buzz” option.

I’m actually pretty impressed at the quick turnaround: most companies would be caught flat-footed for weeks by this mess, so dealing with it in just a few days while the crisis is still erupting is well-done. (It’s the sort of thing I expect from small startups, but not from large firms.)

We’ll see how much damage is already done, but they at least seem to be making a sincere attempt to grapple with the problems…

ETA: I may have spoken a bit too quickly.  Reading the Google post more carefully, it appears that they are working on the quick option to get rid of Buzz, but haven’t rolled it out yet.  (Thanks to Anna, who pointed out that it hasn’t yet shown up in Settings.)

Buzz, Beta, and Can it Recover?

February 12, 2010

As most of the Internet is aware by now, Google released Buzz earlier this week.  If you have a Gmail account, you’ve probably encountered it already.  If not, the easiest summary is that it is much like your Facebook news feed, but it tries to infer your social network based on who you exchange email with.

The core of the idea is fairly clever, and not unreasonable.  Honestly, I rather like the service.  But a number of my friends have had reactions that range from “meh” to burning, fierce hatred, and I can’t say they’re wrong.

The thing is, for the first time in living memory, Google didn’t label this a “beta”.  Presumably that’s because it was well-tested and solid — and really, it is.  On the purely technical level, I haven’t encountered any bugs yet.  (Although I do think there are some design flaws — for example, catching up with new comments isn’t nearly as clear as it is in Wave.)

Where they ran into trouble, though, is in the usage model.  Buzz is doing a lot of stuff that is actually kind of dangerous, because they are building a social network through the back door.

Traditionally, a social network has started out with the network itself — a system that lets me say who my friends/contacts/whatever are — and has gradually layered functionality on top of that.  Today they add a news feed; tomorrow photo-sharing; the next week, multi-player games.  But it’s all in the context of the communities that you’ve established explicitly, so you feel in control of those communities.

Google’s kind of doing it the other way around.  They have all these properties, like Gmail and Picasa, that started life as separate projects.  Now, they’re trying to tie them together into a unified whole, with as little friction for the user as possible.  I’m sure that the mindset inside Google was, “Let’s make it as easy as possible for existing users to do more with their friends”.  Put that way, the idea sounds almost admirable.

Problem is, the users weren’t really consulted on this.  The usage of those separate systems can be pretty different, and people have long-standing expectations about them.  Worst of all, trying to infer a public social network based on private email — well, it can lead to leakage of links that people thought were private.  And that’s exactly what has happened, causing anything from embarrassment to anger to actual danger in a few cases.

Some folks are crying conspiracy, that Google hates privacy, and stuff like that; frankly, I think that violates the “never infer malice where incompetence will suffice” rule, and is certainly wrong.  Rather, they took a product that was really, truly a beta — good, but needing wider testing — and released it as if it was completely done.  It absolutely needed to be labeled a beta, and it absolutely needed to be strictly opt-in (and much more cautious about data exposure) for at least the first few months.  That would have slowed down its spread — and I suspect that somebody inside Google argued that they had to go fast, to compete with Facebook — but the result of not doing so was a huge misstep, and unusually bad PR.

But what’s done is done.  A lot of folks are pissed off, and a lot have turned the system off.  So I’m curious: what’s your reaction to the whole flap?  Do you like the system?  Are you angry about the privacy screwup?  And perhaps most interesting: can they redeem themselves in your eyes?  What mea culpas and changes would they have to make in order to make you give them a chance?