Category Archives: Google

“Google and the AP Should Reveal Their Licensing Terms”. Should They Really?

The always canny Danny Sullivan has a piece that calls for the Associated Press and Google to reveal the terms of any business agreements they may come to. He notes that the AP and Google first made a content licensing agreement back in 2006, and lately the AP has been making noises about extracting more dough from Google, making all kind of disingenuous accusations that Google “steals” AP content when in fact Google is helping AP subscribers by sending them traffic. (Danny and I are both former reporters turned web guys; we have both written extensively about this situation in the past.)

Information about Google/AP hookups would obviously be nice to have, but there are a lot of potentially more interesting private business agreements that it would be nice to have access to, as well. For example, I want to know what Bill Cosby got paid for doing those Jell-o Pudding Pops commercials we all remember from our childhoods. But just because I’m curious about this, it doesn’t mean I’m entitled to the information I’m after.

What makes Google/AP agreements of special interest? Google is a big technology company that is distinguished principally by its near monopoly control over search monetization. The Associated Press is a newsgathering collective that is distinguished principally over its near monopoly control over certain types of national and international news. What these companies do is of interest principally for those reasons. But I’m concerned about our impulse to treat the business of journalism differently than other kinds of businesses. I don’t think it helps consumers of news, and I don’t think it helps journalism, either.

Certainly, as Danny points out, journalism is necessary to support a vibrant democracy. From that springs forth the notion that journalism is a special activity that ought to be protected — call this Journalistic Exceptionalism. For example, we have laws (known generally as “sunshine laws”) that cover the disclosure of information to the public. Journalists are given special access to politicians and corporate bosses, and so forth.

It’s easy to conflate the democracy-enhancing nature of journalism with the dysfunctional news business. But assigning a special status to the business of news (as distinct from the process of newsgathering, which may or may not be coupled to an actual for-profit business) seems wrong to me. Let’s not treat Google or the AP specially because of journalistic exceptionalism. If you agree that Google and the AP should be more up-front with the terms of their licensing agreements, then that should take place because of those organizations’ unprecedented power over the marketplace, not because they happen to be involved in the business of news.

Google vs. the “Tyranny of Data”

Link: Should Design Be Held Back by a Tyranny of Data?

The Times’ “Bits” blog today chased the two-month-old story of Doug Bowman, who left Google for Twitter in March. Bowman’s story wasn’t particularly remarkable aside from the fact that he has a great reputation and was expected to have quite an impact when he joined the big G in 2006, and the fact that he was fairly vocal after he left Google that, to his surprise, he wasn’t able to have as much of an impact as he would have liked.

I don’t have any direct knowledge of Bowman’s situation, but it shouldn’t be difficult for anyone who’s worked for a technology company like Google (and I’ve worked for two, and turned down offers from two more) to see the big-tech company dynamics at work here. It’s quite possible that the problem started the day the Google recruiter called him, promising him he’d be able to bring a new discipline to Google, spin up his own team, and “have a huge impact” on millions of users. I hate to be cynical about this, but it’s vanishingly unlikely that anyone brought in to work at a company with thousands of employees and years of established history is going to have any kind of material impact on that company unless they are brought in as a C-level executive (and even then, just maybe). And it may not be the case that “having an impact” is the thing that someone should be shooting for in the first place. To me, it seems to reduce one’s career to a series of video game achievements and sets aside the notion of teamwork and team success. I generally question the credibility of any recruiter who uses it to pitch their company to me as a prospective place to work. If you’re a technologist, you should, too.

I didn’t want to let this go without a few comments on the way the writer, Miguel Helf, approached this story. When you’re writing about something that’s two months old, the expectation in the newsroom is that you’ll add something new to the story. If there isn’t any actual new information, an inferential leap of some kind will usually do. So in this case, Helf makes “data” the villain, pitted against the hardworking, sensitive artist who really just wants to make the world a better place. This is, of course, a narrative framework used by all kinds of writers to make their stories more interesting, but for this story it really clouds the truth and does a disservice to both Google and Bowman (both of whom, I’m sure, felt like they were doing the right thing). Is there a place for a talented visual designer within a large company? Certainly. Is Google the kind of place for a talented visual designer to do his best work? Maybe, maybe not, although I’m guessing a lot hinges on your professional and artistic aspirations (particularly if those aspirations are in line with Google’s minimalist aesthetic). Should the managers of a multi-billion dollar business rely upon data analysis to determine whether the changes their designers propose are sensible? Well, duh. Bowman himself, in his farewell-to-Google blog post, even says “I can’t fault Google for this reliance on data”. So there’s an unfortunate, imagined tension between two schools of thought going on here that is mostly made up by the Times writer, Helf.

Helf’s inferential leap that he uses to keep the story viable is the notion “crowdsourcing,” a buzzword which I’m sure he has devoted a brain cell to, but isn’t really applicable here. Google doesn’t crowdsource much, if anything (since it doesn’t have to — it can generally buy or crunch whatever data it might need). The story as Helf tells it doesn’t actually have anything to do with crowdsourcing. What Bowman objects to is relentless bucket-testing (the process through which a big web property introduces a change on a trial basis, measures the impact, and then implements the change more broadly or rolls back the change based on the responses of consumers). But I think that even focusing on bucket-testing misses the point. In a big technology organization there will always be someone down the hall who objects to what you’re doing, and you’ll always spend a significant amount of time driving consensus. In some cases this is a good thing, because so much of what we do hasn’t been done before by anyone, and we want to make sure we aren’t making expensive mistakes. But there’s obviously a point where it can paralyze an organization, and it’s certainly not the case that that environment brings out the genius in everyone. Those people generally go to work for startups, as Bowman did.

Product Managers, Lawyers, and Google Chrome

Product managers have an interesting relationship with corporate attorneys. In my various product management jobs I had to deal with attorneys quite a bit, but this kind of interaction clearly doesn’t happen often enough, for reasons I can sort of understand (lawyers can be intimidating, they frequently say “no” in a overly authoritative way that evokes images of the apocalypse, and in a big company they sort of operate in their own little world).

In the consultancy I have to talk startups’ attorneys off the ledge quite a bit. I have two talks that I find myself giving over and over with lawyers: the Open Sourcing This Tool Does Not Invalidate Our Entire Business talk, and the You Don’t Get To Invent Your Own Open Source License talk.

So there can be a pretty big divide between what lawyers want and what product managers want. Their interests are slightly out of alignment (product managers want to deliver feature functionality to customers; lawyers want to insulate the business from legal risk), but that’s okay. But it does mean that these two roles need to figure out ways to communicate and negotiate to move the business forward.

Not too many people get excited at the prospect of a meeting with a lawyer, and lawyer-wrangling is not the kind of activity that product managers get much credit for. There were several developer products my team released at Yahoo! that would not have seen the light of day if my team hadn’t devoted a bunch of time to convincing the attorneys that it was in the company’s advantage to releasing them. We certainly didn’t devote the majority of the time that went into creating these products, but it’s a fact that if it weren’t for the time we put in with the lawyers, the products wouldn’t exist today as products (they’d be a set of firewalled APIs or internal tools).

So I was thinking about this dynamic this week following the release of the Google Chrome browser. The product used the standard Google licensing agreement, which gives Google a non-exclusive license to anything you submit to a Google service. Because they used the same license on the browser, people who didn’t read or understand the legalese came away with the impression that Google owns everything you do using the browser. And “non-exclusive” is key here (it means they can use your data — in a search index, for example — but they don’t “own” it). Still, it freaked some people out and for good reason — the one-size-fits-all nature of a license agreement that’s appropriate for a web site isn’t necessarily going to fit well for a browser product.

Google has since said that they’re going to look into the licensing and retroactively remove the clause from the license agreement, but in a lot of ways the damage is already done — the license kerfluffle culled some momentum from their launch and made them appear less than thoughtful. Getting this stuff right is the kind of thing that a good product manager does.

Google App Engine: Fish or Foul?

We’ve been paying attention to the launch of Google App Engine over the past day and a half and we will continue to keep an eye on it on behalf of our consulting clients. As is often the case with paradigm-challenging products, people often try to characterize the new thing in terms of what they already know. But we don’t believe that Google App Engine is directly competitive with Amazon EC2 today, although it could be in the future. We also don’t believe, as a few people have asserted, that it’s competitive with social networks like Facebook either. Here’s why.

Amazon EC2 is one of the most open platform products in existence today. When you spin up an instance of an EC2 server, you get to make all the choices regarding operating system and software. You log in as root. You can write applications on an EC2 instance using any language and tools you want. You pay only for what you use.

Google App Engine, on the other hand, is a walled garden. In the words of Tim Bray, if you go the App Engine route, particularly if you choose to use Google authentication, you are essentially a sharecropper, working on Google’s farm. You write the application, but Google owns the infrastructure and, more importantly, they own your users.

Ah, you say, but it’s certainly true that closed platforms can be spectacularly successful, at least some of the time. Look at Facebook, for example, one of the most popular walled gardens in existence today. Facebook exerts a great deal of control over what applications running on its platform can do through frequently-changing terms of service and rules enforced in its technology stack. But the difference here is that Facebook asks you to trade off openness and control of your application in exchange for something valuable — its users’ attention. The deal you make with them goes something like this: give me access to your millions of users, and in exchange I’ll adhere to your terms of service and accept your proprietary application framework — I’ll even go so far as to learn the only programming language that you really support well (which in Facebook’s case is PHP).

Google App Engine is neither fish nor fowl. It requires developers to write to their framework without the commensurate benefit of access to a huge built-in audience of users.

Google is providing access to App Engine for free for now, although traffic and storage is limited and we haven’t seen information about commercial licensing, which is troublesome and probably a deal-killer for all but the most trivial applications. It’s true that in many cases “free” can trump “open” or “complete”, but in the case of Google App Engine we believe that “free” won’t make a huge difference. It may attract experimenters and people writing demonstration applications, but virtual hosting (through EC2 or fixed-price virtual hosting providers such as Slicehost) is so close to free today that the “free” part of Google App Engine should not make a difference to anyone who is looking to write a non-trivial application.

The design choices that Google made with this product are pornographically good news for Python developers, who now have their own dedicated application server and a way to build web applications using their language of choice. This may well put Python on the map (as the second language of choice alongside Java, PHP and C#) as one of the Languages That Matter. But it’s also important to remember that consumers don’t use Python (or any other programming language), they use applications. In this respect, Google App Engine is one of many Google products that seems to have been created with technologists, as opposed to consumers, in mind.

On the consulting side we’ve been getting a ton of inquiries from customers regarding strategies and tactics for virtualization on platforms like Amazon EC2, and we’re in the process of adding a formal software development practice dedicated to supporting Amazon’s EC2 and S3 products. That doesn’t mean that we wouldn’t support something like Google App Engine if a client asked us to and there was a good reason to, but for the reasons we’ve described here, we’d prefer to take a wait-and-see attitude towards this and carefully weigh the drawbacks and limitations before devoting serious time or development effort to the platform.

All that having been said, we still believe that Amazon has missed an opportunity by positioning EC2 as a developer product as opposed to a hosting product. If the Google App Engine product were to make a dent in EC2’s momentum, we’d recommend that Amazon provide better support for multi-server scalability scenarios. Amazon recently started moving in this direction with the release of new features intended to give administrators the ability to assign IP addresses and machine instances to specific data centers, but providing explicit support for an adaptive clustering package like Scalr would give EC2 a vital edge, particularly for professional applications.

Dear OpenSocialTards,

Link: Announcing the OpenSocial Foundation

Banding together to make a half-dozen social networks interoperable is not the same as having critical mass. It is the equivalent of having fifteen women band together to give birth to a child.

Also, creating a nonprofit foundation to manage your endeavor does not automatically make you equivalent to Firefox.

Cheers. I’m always here if you need anything.

Jeffrey

Why Your Business Blog Shouldn’t Be On BlogSpot.com

Link: Why Your Business Blog Shouldn’t Be On BlogSpot.com.

"No problem, we thought, Google is nice enough to provide a programming interface to support this. In fact, they have multiple such APIs (application programming interfaces). As it turns out, neither of the versions of these interfaces that Google provides works completely. One version doesn’t let you migrate comments (an important part of many blogs). The other doesn’t let you move more than a few dozen articles – period. Basically, Google has seemingly made it intentionally difficult to migrate off of their platform. This is just annoying. We ended up writing a fair amount of custom code and jumping through a few hoops to get all of the data migrated over (which we finally did). But, this was much harder than it should have been, and we’re trained professionals (so please, don’t try this at home). If you’re not a programmer, chances are you won’t be able to do this yourself. It shouldn’t be that hard."

I know that WordPress does a good job of letting you liberate your data and move it around; I’m thinking about moving the four or five blogs that I maintain onto a single server — the fact that all of them are either in WordPress already or are importable by WordPress is going to be helpful.

Google and Friends to Gang Up on Facebook

Link: Google and Friends to Gang Up on Facebook

“On Thursday, an alliance of companies led by Google plans to begin introducing a common set of standards to allow software developers to write programs for Google’s social network, Orkut, as well as others, including LinkedIn, hi5, Friendster and Ning, according to people briefed on the plans. Those people asked not to be named because they agreed to keep the alliance’s plans confidential.”

We’ll see what this looks like when it emerges, but whaddya wanna bet that the “standard” they come up with walks and talks like Facebook’s API yet is every so slightly different (and incompatible) with Facebook’s API?

And how is LinkedIn supposed to factor in here, I wonder, with their famous opposition to the notion of an open platform?

I’m still willing to accept that this initiative is getting lost in the NY Times’ muddled inability to do a decent and technically accurate story on Silicon Valley technology, but it really sounds Google is trying hard to turn “openness” and “interoperability” into the new “embrace, extend, extinguish” here. Which, if successful, would be quite a feat.

Update: A second-day story on this quoted Joe Krause on behalf of Google. From this one could deduce that Google’s entry into the “open but not Facebook” cabal will be the relaunched JotSpot, whenever they get around to re-launching it.

Update: Marc Andressen has more about this on his blog. I wish he’d posted this yesterday instead of letting everybody get half of the story via TechCrunch. Marc’s post clears things up a bit but I’m still interested in seeing what the bits look like. It seems like this is more an attack on Facebook’s proprietary markup language than anything else. Memo to interoperable social network cabal: there is no such thing as a platform that does not use some kind of proprietary semantics to map out its feature set. You’ll find yourself doing this as well if you haven’t done it already.

Side note to web marketers, PR mavens and evangelists: if you want to ensure that there is an elevated level of confusion associated with your launch, one sure way to accomplish that is to provide an exclusive leak to TechCrunch prior to your public launch. I know it’s virtually impossible to get on TechCrunch unless you give them a scoop, but there’s a cost associated with making those guys your media leak of choice. To put it another way, no product launch has ever failed because the product didn’t brief TechCrunch about it a few days ahead of time.

Update: Michael Arrington’s headline on this today says “checkmate!” which is of course nonsense since the game isn’t even half over, OpenSocial hasn’t even produced anything yet and Facebook could of course join at any time if they wanted. His commenters mostly seem to agree.

Saul Hansell of the NY Times has some less hysterical thoughts on this; he points out that “LinkedIn has also said it may ask for a revenue share from those who
create applications for its network. And haggling over money, no doubt,
will slow down the deployment of many social applications.” No kidding. This is my main concern about the path that LinkedIn is going down. Having to ask permission to build an app and then provide a revenue share isn’t a platform; it’s the definition of a walled garden. AOL was successful at this for a while in the 1990s because they were able to bring a mass audience when nobody else could, but these days, that dog won’t hunt, monsieur.

Google’s Muni Wifi Contingency Plan

It looks like Google had a contingency plan for municipal wi-fi in San Francisco in the event that Earthlink cratered. Last night I got an email from my ISP, Sonic.net, that said they’re going to try build an open wireless grid in partnership with Google using existing customers’ internet connections.

I sent this over to Om Malik who wrote it up on his blog last night.

It’ll be interesting to see if this plan to build the muni wi-fi network in San Francisco on an ad-hoc basis gets anywhere. There’s not much in it for the typical ISP customer, who would  supply the electricity and a small chunk of bandwidth in exchange for a vague promise to share an unspecified bit of any Google advertising revenue that may be generated at some point in the future.

The real trick here for me would be figuring out who’s ultimately responsible for the network. I ran an open wireless network for my neighbors to use for a year, but I had to button it up after one of my bonehead neighbors started using it to download copyrighted movies, triggering several nastygrams which I did not appreciate.

Google: Meg Whitman is Not To Be Screwed With

Link: eBay pulls U.S. ads from Google AdWords network

"eBay has pulled its advertising from Google’s AdWords network in the United States, an eBay spokesman said on Wednesday. Technology trade publication Computerworld, which originally reported the move, cited a source as saying it was in response to Google’s decision to hold a party starting at the same time as an eBay conference for merchants who sell on its site."

I’m surprised this didn’t get more attention today, since eBay’s annual Google spend is what the money men like to refer to as "materially significant". I wonder why Google is willing to sacrifice one of its biggest customers to promote an also-ran payment system that is squarely outside of its core competency?

Update: I saw more belated stories and posts on this in the past 24 hours, including a good one from former eBayer Shri Mahesh defending eBay and suggesting that eBay "won", which I’m not sure about. This particular battle isn’t over and the overall war is just starting.

There’s some more good comments from Paul Kedrosky suggesting that eBay is hurting themselves by boycotting AdWords. eBay may indeed be hurting itself in a business sense, but there are also reputational effects to consider when this kind of thing happens, and I don’t think that Google or eBay come off well in all this. Anyway, I don’t expect that eBay will stop using Google forever (the fact that they have very little leverage over Google undoubtedly drives them crazy). At the same time, there is a certain unfortunate petulance at the soul of eBay and if anything about this episode is harmful to that company, it’s the fact that its petulant nature is being exposed. Arbitrarily zapping partners like this, even big scary ones, is not a terrific way to run a platform.

A couple other points in the eBay/Google battle that nobody seems to have brought up: 1) eBay banned Google Checkout a while back on the flimsiest of pretenses, so creating the opportunity to take its case directly to eBay’s sellers would seem like a reasonable thing for Google to do; 2) there is ample precedent for this — those of us whose attention spans are longer than two weeks recall that elbowing in to the eBay Live conference was one of the tactics that PayPal used five years ago when it was penetrating the eBay marketplace. The outcome of that tactic was well-known (eBay was compelled to write PayPal a nine-figure check after its home-grown payment processing business failed to catch on). I doubt this is the outcome that Google is going for here, so it begs the question — why is Google even in the payment-processing business and how could their strategy be so tone-deaf to the reactions of the incumbent in this space?

How To Be Recruited By Google

My pal Jeff Barr of Amazon posted on his personal blog about how he was interviewed by Google and continues to get pinged by their recruiters after he already gave them a polite "no thanks". He asks whether their recruiters shouldn’t maybe have way of looking up candidates in some sort of database — you know, maybe like a search engine?

I don’t think I’ve blogged about this yet, but I interviewed at Google from late 2005 through early 2006. The experience was pretty strange. Google kept me on the hook for five full months, having me in repeatedly for meetings with people who had no idea why they were talking to me or what to ask me, putting me in front of middle managers who would theoretically be my superiors but who had far less experience than me, handing me off from one recruiter to another, and never getting back to me when they promised to.

In one of the interviews, a very young Google product manager spent a good hour and a half pumping me for information on developer relations and platform evangelism. The questions he asked suggested to me that he wasn’t interested in hiring me at all; it seemed like he was getting me to verbally convey to him the essence of what developer relations people do so they could go off and re-invent the discipline themselves. Maybe the plan was to reduce it to a few hundred lines of Python, I’m not sure.

So anyway, after months of interviews, epic games of phone tag and myriad unexplained delays, the recruiter du jour promised me that a job offer was imminent. I called her to say "don’t bother". I wound up going to work for Yahoo! because I was inspired by what they wanted to do and they gave me everything I wanted without making me feel like a recent parolee. The amount of time that elapsed between my interview and my first day of work at Yahoo! was approximately a week and a half.

There are a lot of things that Yahoo! that still needs to get ironed out. Retaining talented hires is a big one, as it is for any company (coincidentally, my wife’s last day at Yahoo! is next week). But swooping in and snagging me as quickly as they did was one of the things that Yahoo! definitely did right.