mult.ifario.us

As a heavy GMail user, I see a lot of Google ads. I used to enjoy the relatively random nature of the ads, but now I just wish I didn't see the same ads over and over again. If Google is going to track my online behavior, then maybe after the 1,000^th impression they'd get the hint that I don't want to work for them in Bangalore and stop showing me that ad... (Advertisements for jobs at Google are the primary offender, actually.)

For context, see my earlier post on Yahoo, Amazon, Google and the effectiveness of "stepping on the gas" with R&D.

Marc Gerstein over at SeekingAlpha has some comments from a similar perspective (ratios between engineering expense and revenue), although he draws a different conclusion about Amazon:

For Amazon.com (AMZN), analysts have focused investor worries on the monies being spent to draw in customers. They're right to hone in on the spending levels, but they've been overly alarmist on the worry bit. Heavy spending on marketing and technology has worked for Amazon.

I maintain that the interesting proposition for Amazon (Yahoo, EBay, Google, etc.) is not how effective engineering spend was in the past but rather how effective it will be in the future.

I spent some time in the jungle, so it was interesting to read the Yahoo! "peanut butter" memo for an inside glimpse of another one of the Internet behemoths, draw a few unfounded conclusions, and make some comparisons. (The obligatory disclaimer here is that even when I did work for Amazon, I didn't speak for them, and I certainly don't do so now.)

A quick digression on peanut butter. I ate plenty of peanut butter growing up, although it was always Adam's. Jif, Skippy, and their ilk were rightfully regarded with some disdain because of the non-food substances (e.g., "fully hydrogenated vegetable oil") that they contain, but real peanut butter is generally good stuff food-wise: healthy oils, calorie-dense, high in protein.

My first observation about the letter was that reading it was a bit like a dog eating peanut butter. An SVP at an Internet major should be able to pound a diamond into dust in a few sentences. While a problem list is good fuel for an off-site or brainstorming session, information flows up the chain and direction flows down; put another way, there were a lot of nouns but not a lot of verbs in the memo.

My second observation was that I don't really think that Yahoo's doing so badly, even if the letter's factual in every respect. (See, e.g., this commentary for a "street-oriented" perspective.) I like to look at a metric that I'll call business-effectiveness of engineering ("BEE"), and it's computed as:

       1-(revenue(t)/revenue(t-Delta))
B(t) = -------------------------------
          1-(cost(t)/cost(t-Delta))

for some time range Delta, e.g., a year or other financial reporting period. Taking the numbers from SEC filings by Google, Amazon, and Yahoo:

The 3Q2006 number is computed versus the 3Q2005 number. I've pulled numbers from the financial roll-ups in the 2005 10-K (AMZN, GOOG, YHOO) and 3Q2006 10-Q filings (AMZN, GOOG, YHOO). (I should add eBay to the list, but maybe later; for comparison, their BEE for 3Q2006 is 0.91. Salesforce.com has a 3Q2006 BEE of 0.82.)

The numbers suggest that Yahoo's and Amazon's core business models, vis à vis their ability to execute in terms technology and engineering, are essentially at end of life, since it costs $0.50 of engineering labor to buy $1.00 of revenue. (Yahoo is profitable and could afford to spend significantly on growth if the raw materials (i.e., smart people) are available in sufficient supply; Amazon has less fiscal wiggle room.) This shouldn't be surprising — it takes a lot of software to run a big Internet business, and there's a pretty good chance that not all of it was written by top-notch folks working under clean-room conditions... That said, Amazon is trying to leverage its core expertise in operating its server fleet (and they are very good at it) into new lines of business (S3, EC2, etc.), and all three have been rolling-up customers, partners, or players in their respective spaces: Amazon is consolidating online retail, Yahoo is consolidating social and personal software, and Google is consolidating the on-line advertising business.

The prescription for Yahoo seems simple enough:

• Consolidate. Keep the peanuts and salt but flush any fillers that accumulated after the last bust.
• Avoid a money fight with Google by innovating from within, strategic investing, or grabbing properties early. (Not buying YouTube was a miss; knowing that video sharing was hot and not already having or owning a hunk of a parallel property is a bigger miss.)
• Ensure that offerings are readily identifiable and usable by regular folks. Having two photo sharing services isn't a sin, but having any difficult to use, locate, or understand services is.
• Use social context (rather than keyword inference) to target advertising.

As for just how to do it, since I'm not an SVP at Yahoo, I'm not on the hook for that part...

In terms of an hourly wage paid for blogging, AdSense pays me something less than slave wages, but it's fun to shake up the Google magic 8-ball and see what it thinks is relevant to a given page. Sometimes it gets things right (ads for BizTalk and cello for the orchestration tag), and sometimes it gets things wrong (ads for VB for the Erlang tag).

So, let's see... <shake shake shake>...

As a consumer/producer of open source, it was interesting to see Google Code hosting launch today. It also explains why people from Google were trolling with questions about how Google could help open source... (I should have asked for a search appliance for the Haus now that I'm thinking about it.) It's pleasantly minimal in that it fits cleanly into the spectrum of available infrastructure below the level of a SourceForge, RubyForge, or Java.net: no mailing lists, no forums, no releases, and no project entry criteria — just fill-in a form to get 100Mb of subversion space and an ultralight bugtracker.

From a producer perspective, no strings attached, free subversion hosting is a great offering, although I'd be more likely to use something private and something cooler than subversion — like darcs or Bazaar or another system that supports both push and pull branching semantics — until and even after a project is ready for public consumption. (Subversion+svk would count.) As a consumer, my question is how I'm going to filter out the crap. Nothing is worse than seeing a promising-sounding project and then finding out that there's nothing of value there. On SourceForge, there's plenty of deadwood, but I can look for releases, at activity levels on mailing lists, or at project statistics. On Java.net, I can look at releases, mailing lists, or at rankings. A good start on a crap filter would be a simple voting model for projects, e.g., allow a user to leave a star on a project that they found actually useful. (Of course, something like the Google Finance plotting widget applied to subversion activity and branches/tags wouldn't hurt, either.)

My answer to the “How could Google help open source?” at the time was straightforward: contribute effort and even sponsorship to the projects that Google developers find useful. This is what everyone does (or at least what everyone is supposed to do). Barriers to entry have never been an issue for open source projects, but drawing together a community and channeling combined energy into defining and creating good software have always been and remains a challenge.