There’s a titanic clash for the control of the Internet—this is between the world wide web on the one hand and Apple’s app model on the other," he explained.
So if you think of Google as the leader of the world-wide web group, their problem is that the underlying software for the web — HTML — hasn’t changed for a decade.
The ongoing debate about apps vs. web apps has hit the news again just recently, with the coverage given to Mr McNamee's comments about the relative performance of Apple and Google, respectively (about which he's of course right), and what he infers from this regarding the future of the Web. I believe he's wrong about the latter, essentially because he misunderstands the fundamental dichotomy between server and client that has underpinned the Web ever since it was first conceived and which, so far, remains as vibrant as ever despite the attempts by some commercial interests, and some governments, to undermine it.
The server-client paradigm: tech's most misunderstood fundamental?
What is the server-client model? Put in non-technical language, it's an environment in which data resides in a repository called a server, that can be accessed, via a client, in order to perform whatever task the user requires. This is the basic paradigm that underlies everything we do that involves an Internet connection—meaning practically anything we do when we use a computing device, whether desktop or mobile, or what will eventually become the Internet of Things.
I never cease to be surprised at how many otherwise bright and articulate people fail to grasp the significance of this and, in this instance, this is what the otherwise rather clever Mr McNamee, and those who are giving voice to his view, are guilty of doing.
Google's excessive focus on the browser is failing, because it isn't more 'open' than a self-standing app, and because it's less user-friendly
Of course, they're right on one point: Google's strategy of relying on web apps to do everything, in which they have been engaged for over ten years now, is failing.
Google bases its entire corporate strategy on the premise that it's more convenient to use a single interface, the web browser, to access all your data whenever you need to do something with it. As a result, many users come to assume the browser is the web—and, misleadingly, that a browser-based development strategy is somehow more 'open' than one that relies on a specifically developed client application.
Neither of these assumptions, however, is true.
Firstly, the browser is a client like any other, and uses a protocol (http, https, ftp) to access whichever server it needs to use. The prime example of this approach, of course, is Gmail: Google has never developed a single mail client for its award-winning mail server, instead putting all its effort into making the online experience as pleasant as possible for anyone reading their email on their browser.
Secondly, that a browser-based strategy isn't more—or less—'open' than a self-standing application-based one should have become even more self-evident now that Google's strategy has become irrevocably embedded in its corporate culture: it launched its own browser, Chrome, which has grown explosively—deservedly so, since it is arguably the web's most innovative and user-friendly way of exploring the web. Inevitably, a growing number of the new features Google is incorporating into Gmail and into its other server solutions are being offered—either directly or through browser extensions—only on Chrome. Hardly the mark of an 'open' user experience.
This arguably needn't necessarily imply that Google browser-or-nothing approach is flawed per se… except that, in addition to not being 'open', manipulating data exclusively via browser clients demonstrably isn't the most efficient or user friendly method. Nine times out of ten, on a Mac (or a PC, for those who still use them), a standalone client application provides a quicker, less resource-intensive and more pleasant experience than launching one's browser and navigating to the server's web address. For Gmail, the superb Sparrow is a far superior way of receiving and sending email than doing so on Chrome.
Mobile environments are blurred, showing the app/browser distinction is becoming less, not more crucial—most users just want to be able to access their data easily from all their devices, whether desk-bound or mobile
The issue is, admittedly, slightly blurred in a mobile environment. Using a browser to access server data, even on the iPhone which is the most effective device by far, is still suboptimal and often totally impractical unless mobile versions are offered in parallel to the desktop ones. Because developing these mobile declinations is childishly simple, they are increasingly being provided and as a result, defenders of an all-web approach, à la Google, have argued the phenomenon lends support to their position, while those contending that Apple's iPhone apps are easy to develop have convincingly come to the opposite conclusion.
In reality it proves nothing either way. Ironically, the reason both approaches are logically correct is because, in both cases, as we've seen, we're dealing with clients: a web client necessarily accesses a server using protocols (or an API if some of the language required to use a server environment is specific to it); a self-standing application uses the same protocols and API. Crucially, developing a mobile adaptation of a web interface will not differ as radically, code-wise, from a an independent application in a mobile environment as it would for a desktop.
A common trait of nearly all the successful server-based applications I use is that they can be accessed from all three environments: desktop, mobile and tablet. The difference lies solely in the fact that some choose to provide the requisite clients themselves (Evernote, Instapaper, Cloud App, with Twitter a recent convert to this approach after sitting on the fence for quite a while) while Google continues to bask in the illusion that the browser is the web. It has, so far, been able to get away with it because the exceptional quality of its applications at the server end makes it worthwhile for third parties to develop clients for it (and to Google's credit, unlike Twitter, it has never stood in their way and provides well-designed APIs for the purpose).
Neither Google, which is unwilling or incapable of designing attractive, user-friendly applications, nor Apple, which seems strangely defensive in its refusal to move into the cloud, has as yet won the war of Titans
Ultimately, therefore, Mr McNamee is labouring under a somewhat curious misapprehension: he seems to believe the browser, on which Google has based its entire strategy, is the web, whereas the browser is merely one client among others and it's not a realistic proposition to turn a browser, even Chrome, into a closed environment—that approach died fifteen years ago when Microsoft fatally miscalculated by attempting to take over the web with its Microsoft Network portal.
In addition, Mr McNamee, and a good many observers with him, fail to identify the second defining factor in the Google-Apple rivalry: Google, despite the handicap induced, for the user, by its irritating browser-is-all approach, reigns utterly supreme in servers—a skill Apple has singularly failed to master, even giving the impression that it despises it: its boy-scout apologist John Gruber just recently wrote a rather well-argued piece defending Apple's reluctance to 'cut the chord' that it insists on using for users to make any information pass between its mobile and desk-bound devices. Mr Gruber argues, somewhat plausibly, that
It just isn’t technically feasible to have people backing up and restoring 32 or 64 GB of data to the cloud.
Yet he also rather disingenuously fails to point out that Apple has doggedly refused to allow such flows of over-the-air information for even such technically trivial and routine operations as saving an easily accessible version of a document created using the mobile version of its iWorks office suite—as a result of which iWorks has utterly failed to gain any traction among Apple's mobile users. We have, also, yet to see any actual implementation of Apple's long-awaited music locker in the cloud. Apple's only cloud-based solution, MobileMe, is universally regarded as a joke as a result of its uniquely mediocre combination of an outrageous price and spectacularly poor performance. As a result, I suspect I'm not alone in using a Google server (Google Apps Premier) to store my email, but an Apple client app (Mail for iPhone) to read my mail on my iPhone: a good demonstration of the fact that, in an open, properly-connected environment where the same protocols are used to connect clients and servers, the respective failures of the titans are not a problem for the user.
The war of titans described by Mr McNamee is thus far from won by either side and I suspect it never will be: I doubt Google will ever become capable of designing elegant and user-friendly client applications, even if it suddenly saw the light on the subject; Apple seems equally blinkered in its refusal to make any serious investment in the cloud—though it may turn the corner if, for instance, the opening of its much-vaunted massive East-Coast iMaiden data centre turns out, as some are predicting, to be a strategic turning point.
Ultimately, the real battle is elsewhere: so far, despite rather baseless accusations of lack of 'openness' thrown from all sides, Apple and Google have both chosen to operate in an open (i.e., technologically neutral) environment which they both know is essential to their long-term interests: crucially, the protocols have remained stable and what Mr McNamee is complaining about—that the http protocol has remained unchanged for a decade—is precisely what enables clients and servers to connect without issues while competing in a level playground to provide the best user experience. You only need to look at the situation prevailing in those segments (of which video is perhaps the most notorious instance) where this stability of standards has not yet come about, to see that it is a virtue, not a problem. As a result, third-party developers, a handful of which will inevitably end up becoming the next generation of tech-sector titans, have been free to provide the solutions, on both the server and the client end, that consumers require and that Google and Apple, for whatever reason, have been unable or unwilling to provide.
I strongly suspect this status quo will continue to prevail for the foreseeable future. The threat, if any, will come not from the sector titans, who have no vested interest in bringing down a system that has served both them and consumers well, but from governments such as China and France that seem increasingly intent on curtailing net neutrality by undermining the universal system of all-embracing undifferentiated protocols that underpin it—and, unfortunately, they of course have the regulatory clout to do so.