In blocking Windows Phone access to YouTube, Google delivers rough justice

Ted Samson’s Tech Watch article yesterday about the latest public Microsoft/Google spat left me seeing red. In a nutshell, Microsoft’s VP and deputy general counsel Dave Heiner, quoting an earlier European Commission complaint, says Google should open up its YouTube API so Microsoft can use it in a Windows Phone YouTube app:

In 2010 and again more recently, Google blocked Microsoft’s new Windows Phones from operating properly with YouTube. Google has enabled its own Android phones to access YouTube so that users can search for video categories, find favorites, see ratings, and so forth in the rich user interfaces offered by those phones. It’s done the same thing for the iPhones offered by Apple, which doesn’t offer a competing search service.

Unfortunately, Google has refused to allow Microsoft’s new Windows Phones to access this YouTube metadata in the same way that Android phones and iPhones do. As a result, Microsoft’s YouTube ‘app’ on Windows Phones is basically just a browser displaying YouTube’s mobile Web site, without the rich functionality offered on competing phones. Microsoft is ready to release a high-quality YouTube app for Windows Phone. We just need permission to access YouTube in the way that other phones already do, permission Google has refused to provide.

Despite government scrutiny, Google continues to block Microsoft from offering its customers proper access to YouTube.

Google responded by saying that Microsoft could build an HTML5-based Windows Phone app that has access to all of the mentioned features, through the YouTube HTML5 API. As far as I’m concerned, that dodges the heart of the matter.

The simple fact is that Microsoft invented — or at least perfected — the “API as competitive bludgeon” approach. What we’re seeing now is Microsoft’s comeuppance for decades of fighting this same dirty little war. And it’s not just historical. Microsoft continues to use API blocking as a blunt weapon to this day. The company deserves to be hoisted with its own petard.

While making allowance for creative license inherent in any attorney defending his client, I’m still struck by Heiner’s apparent obliviousness to Microsoft’s long, sordid history with API blocking and its ugly stepsister, obfuscation.

I won’t bring up the old (and largely discredited) DOS 2.0-era cry, “DOS ain’t done ’til Lotus won’t run.” Nor will I dwell on the “Chinese wall” — a phrase that’s still hotly contested — that refers to Microsoft’s claimed separation of the Windows and Office development efforts, specifically to avoid anticompetitive flimflammery with Windows APIs. The situation’s far more nuanced these days.

Allow me to don Mr. Peabody’s natty red bow-tie and have you set the WABAC machine to 1991. Jim Allchin sent off a series of memos to Brad Silverberg, Bill Gates, and others that not only admonished the Windows team to keep the Windows APIs proprietary, but actively encouraged use of the APIs to break competitive products, including, notably, DR-DOS.

Now set the machine for 1992. Andrew Schulman, David Maxey, and Matt Pietrek released their voluminous “Undocumented Windows” tome, which covered hidden and obfuscated (and, well, undocumented) Windows 3.0 and 3.1 APIs. It ran 656 pages. Following in the esteemed footsteps of Charles Petzold and his seminal “Programming Windows,” a small band of very tenacious programmers managed to shed light on Microsoft’s top-secret APIs.

On to 1995. Microsoft changed its API in Windows 95, breaking WordPerfect in the process. WordPerfect (owned by Novell) brought a lawsuit against Microsoft claiming that Microsoft not only broke the old API calls, it hoarded undocumented calls and interfaces, allowing them to be used by Office but not by WordPerfect. Robert Frankenberg, former CEO of Novell, put it this way:

Our key competitor, Microsoft, could control our ability to put product out the door and did so. And that meant that it was impossible for us to fulfill our promises to customers, it was impossible for us to derive significant value, and it made much more sense for us to sell product and pursue other opportunities.

Novell filed the lawsuit in 2004. It lost: The suit was dismissed in July 2012.

Jump to 1999. James Gleick, best-selling author and Windows iconoclast, published a lengthy analysis of Microsoft’s dirty tricks with APIs, “Making Microsoft Safe for Capitalism.” Weighing in on the antitrust debate at the time, Gleick says:

The Department of Justice does not need to break Microsoft apart. It need only — a far-reaching step in itself — require Microsoft to make its operating system, and the web of standards surrounding it, truly and permanently open. Other companies should be allowed to clone it if they could; Microsoft should be restricted from taking internal advantage of new changes until they were published to the rest of the market. For that matter, Microsoft should open its standards voluntarily. It will not, but it should: end the painful cognitive dissonance that comes from proselytizing for open standards and then threatening to close them at will.

In the same article, Gleick quotes Eric Schmidt — then at Sun, now executive chairman of Google — as saying,

If [Microsoft] really did open interfaces, it would change the dynamics of the industry in a positive way … They could get back to work and try to build great products and compete.

That was almost 15 years ago, and the shoe then was on the other foot. Now Microsoft’s trying to get Google to open its proprietary APIs. Schmidt must feel a bit of vindication, eh?

It isn’t just Windows. Microsoft perfected the art of API warfare with all sorts of products. MSN Messenger, for example, saw plenty of use as a blunt instrument: For many years, every time Microsoft updated Messenger, one or more of the other instant messaging clients would be unable to communicate with Messenger for a day or a week, while programmers worked furiously to fix the problem. It was never clear to me if Microsoft’s Messenger mess-ups were intentional or the result of indifference, but the API changes broke things badly. Repeatedly.

Back in the WABAC machine, let’s return to the present day.

Google’s trying valiantly to get Chrome to work on both the Metro and old-fashioned desktop sides of Windows 8. Firefox is trying, too. They’re both having lots of stability problems at this moment. Could that be due to Microsoft API obfuscation? Hard to say.

But this one’s quite clear: Microsoft won’t let Chrome or Firefox on Windows RT. Although the Windows Phone-on-YouTube and Chrome-on-Windows RT arguments are similar in some respects, they’re quite different in others. For one, Microsoft has been dinged by the European Commission repeatedly for its failure to provide equal access to competitive browsers. At this moment Microsoft faces stiff fines for failing to include the browser ballot in Windows 7 Service Pack 1. Microsoft’s frequently played dirty with competing browsers.

Is Microsoft required to allow Chrome and Firefox on Windows RT? That’s one for the lawmakers to decide, but my opinion is that Microsoft can keep the APIs to itself — at least, until Windows RT reaches monopoly status, which should happen shortly after the Mayan calendar cycles again. Apple doesn’t lay bare the iOS API for browsers to muck about, although there are suboptimal workarounds. Similarly, I’d argue that Microsoft has a right to keep Chrome out of Windows RT’s innards. 

So please tell me, why does Google have to give Microsoft full access to the YouTube API?

Microsoft’s made its bed. Indeed, it’s honed and perfected the art of API warfare. Let it lie in it.

I won’t shed even half a crocodile tear for Heiner’s arguments.

This story, “In blocking Windows Phone access to YouTube, Google delivers rough justice,” was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.