Google’s “Interesting” Week
Let’s start gingerly, with Nokia. You’ll recall the indignation when Nokia threw Symbian under the Windows Phone 7 bus and osborned its existing product line. Nokia dead-ended Symbian handsets, causing sales to plunge while everyone waited for the new MicroNokia smartphones.
The company didn’t stop there.
It then presented Meego, the offspring of Intel’s Moblin (as in Mobile Linux) and Nokia’s own Maemo (also Linux-based), as their weapon of the future. This was their killer smartphone OS.
But Nokia gave up on Meego. The result was a risky but greatly simplified product strategy: One OS, WP7, instead of three or four versions of Symbian, S40, S60, Symbian^3, and Meego.
Such simplicity couldn’t last.
We now hear that Nokia is developing an operating system called Meltemi, the name of a Greek wind (I’m not making this up). The new OS targets the low end and intends to replace the S40 engine for Nokia’s dumbphones, a.k.a. feature phones.
A few thoughts.
First, both Meego and WP7 were, and are, too heavy for entry-level phones.
Second, Nokia sees a future in low-cost, low-margin products. Today’s smartphone BOM is excessive, north of $100, and that’s before the handset maker, Nokia in our case, gets a slice of the pie.
Looking at Nokia’s Q2 numbers, we see an ASP (Average Selling Price) of 142€ ($200) per smartphone, and a low 36€ ($50) per “feature phone”. In the same quarter, Nokia sold 16.7M smartphones and an impressive 71.8M dumbphones, yielding revenues of $2.4B and $2.6B respectively. In other words, for all the excitement about its smartphone OS moves, Nokia is still a huge “feature phone” maker. To keep this business alive, it must make its dumbphone smarter without introducing expensive hardware. From the WSJ Meltemi story:
“… even consumers in emerging markets now expect low-end feature phones to act like smartphones’’
The S40 engine is old and patchy. Hack off the unnecessary limbs from a Linux ‘‘distro”, graft some hooks into a Ovi + Navteq + Microsoft Bing service, and we have our own entry-level phone OS.
We’ll see how these efforts pan out as low-cost Chinese handset makers attack Nokia’s business with customized — and unofficial — Android mutants such as Ophone and Tapas.
We now turn to Samsung and Intel. Evidently inspired by the success of the Meego collaboration with Nokia, the odd bedfellows produced Tizen, a new Mobile Linux joint venture, hosted by the Linux Foundation. Unlike Meego, Tizen is based on HTML5 and other Web standards. Quoting Imad Sousou, director of Intel’s Open Source Technology Center in a recent blog post:
“… why not just evolve MeeGo? We believe the future belongs to HTML5-based applications, outside of a relatively small percentage of apps, and we are firmly convinced that our investment needs to shift toward HTML5. Shifting to HTML5 doesn’t just mean slapping a web runtime on an existing Linux, even one aimed at mobile, as MeeGo has been.”
Just as Meego was a serious effort from two marquee companies — or an admission that neither could muster the brains and cojones to do the job alone — the Tizen joint venture is a curious contraption. Is this Intel’s admission that they haven’t enough money and engineering talent to develop a mobile OS? Or is the silicon giant dancing on coals, having been burned by two aborted launches in a row: Moblin and Meego?
As for Samsung’s taste in mobile operating systems, we can safely call it eclectic. With Android, Bada, Windows Phone 7 and, now, Tizen, Samsung now has a full quiver of operating systems. Samsung is the new Nokia in more ways than one: Smartphone unit volume and, now, four operating systems.
We’re not quite done with Samsung.
We now learn that it has reached a “definitive agreement” with Microsoft: For each Android smartphone it makes, the Korean bruiser cries uncle and pays royalties to an even tougher frenemy. HTC and other makers had knuckled under before Samsung did, leading one to speculate that Microsoft is conducting a methodical, one-redoubt-at-a-time assault against Android. As Brad Smith, Microsoft’s General Counsel explains it: “We Haven’t Seen an Android Product That Doesn’t Infringe on Our Patents.” The Valley scuttlebutt had been that Microsoft was making more money from Android-related royalties than from its anemic Windows Phone 7 licenses. Now Goldman Sachs comes up with an estimate for Microsoft’s Android royalties revenue: $444M. A nice piece of change considering the “cost of goods sold”, mostly the company’s own legal eagles.
Naturally, Google cries foul — while buying patents left and right, Motorola’s included:
“This is the same tactic we’ve seen time and again from Microsoft,” the company said in a statement. “Failing to succeed in the smartphone market, they are resorting to legal measures to extort profit from others’ achievements and hinder the pace of innovation. We remain focused on building new technology and supporting Android partners.”
Not everyone buys the ‘‘supporting Android partners” pablum. See Florian Mueller’s Foss Patents blog:
“If Samsung truly believed that Google’s acquisition of Motorola Mobility was going to be helpful to the Android ecosystem at large, it would have waited until that deal is closed before concluding the license agreement with Microsoft. But Samsung probably knows it can’t rely on Google. It decided to address Android’s intellectual property issues on its own.”
(The full post is well worth your time. Florian easily rises above the crowd of pageview netwalkers; if patents wars are your thing, you might also want to subscribe to his Google Reader RSS feed, or to follow @FOSSpatents on Twitter. And thanks to John Gruber for steering me away from a Korea Times article and back to the Foss Patents original.)
Here in the Valley, most of us think Google will have to face the music. Especially Oracle’s. Added to Microsoft’s game of IP Go, Oracle’s multibillion dollars lawsuit against Google’s alleged (and dangerously close to established) abuse of Java intellectual property could force the Mountain View Don’t Be Evil leaders to make painful concessions.
We’re not done with Android and Google.
We now move to this week’s pièce de résistance: Amazon’s new 7” tablet: the Kindle Fire. (The beautiful launch page is here. And the full 51 minute video of Jeff Bezos keynote is here.) I immediately ordered one, of course, with a November 17th delivery date. I’ll let a couple of weeks of use go by and report my second impressions, the ones that feed the all important Word of Mouth.
The hardware looks like a RIM PlayBook relative, perhaps because they use the same ODM, Quanta, and the light-emitting display technology is the same that Amazon mocked in ads touting its very nice reflective e-ink. As for the rumor that Amazon’s 7” tablet is merely a stopgap for the Holiday Season, meaning there’s a possibly larger/better Kindle Fire in the works, I don’t think it holds water. We know Amazon isn’t a short-term thinker — as we’ll see in a moment.
Let’s go back to the Kindle Fire’s launch page and perform a little experiment. Click on the link and, depending on your persuasion, press CTRL-F of Command-F and enter Android as a search term. In my case, I got two occurrences… Just two. One: “Additional email apps are available in our Amazon Appstore for Android.” And, wait, the second disappeared on me, I saw it minutes ago in a customer review, I swear…
We know the Fire is built on top of Android software, but Amazon makes no mention of it. As Michael Mace notes in his MobileOpportunity blogpost, neither does Google:
“Google’s reaction to Kindle Fire speaks volumes about its goals for Android. Kindle Fire is based on Android, and will run Android applications. Android has been struggling in the tablet space, so you’d expect that Google would be delighted to have Amazon on the Android bandwagon. But you’d be wrong. Let’s look at the press release Google issued today to welcome Amazon to the Android family. Wait a minute, there is no press release. Okay, so let’s look on the Google blog. Nothing at all. Maybe a tweet from Andy Rubin? Dead silence. […] You’re not the licensee Droid is looking for.”
Quoting from the Wikipedia Android article:
“Even though the software is open source, device manufacturers cannot use Google’s Android trademark unless Google certifies that the device complies with their Compatibility Definition Document (CDD). Devices must also meet this definition to be eligible to license Google’s closed-source applications, including the Android Market.”
This explains why Amazon started its own Android Appstore a few months back. Still quoting Michael Mace:
“The problem is that Amazon is using Android as just an OS, not using the Google-branded services and application store that Google layers on top of the OS (link). Although Google touted the openness of Android when it was first launched, the reality is that Google is using it as a Trojan horse to force its services onto hardware. What Amazon did with Android is very threatening to Google, and so you’re not likely to hear a lot of supportive words from them.”
Amazon uses the Android source code, but, unlike handset makers, it doesn’t get used by Google. (You might also want to read the aptly titled How Amazon picked Android’s lock.)
And we have Amazon’s Silk browser. An interesting and controversial development. In a nutshell, when you send a browsing request from your Fire, it’s processed by Amazon’s Web Services cloud.
Why?
The official explanation is that Silk delivers a faster, nicer browsing experience. AWS will cache frequently requested pages for a faster response. Also, AWS can process the page and re-format it for your Fire, removing unnecessary content, making sure aspect ratios are correct, and so on. All very nice, if not entirely new: The pre-processing Opera Mini performs the same gratuities for mobile devices. (More in Matthew Baxter-Reynold’s analysis published by The Guardian.)
Amazon’s browser apparently does more than caching, speeding, and munging Web pages. For example, what happens to Google ads and services? Today, on my PC, Google knows it’s me using its services. Tomorrow, from a Fire, I assume they’ll get an AWS request without further user info. That’s the ‘‘threatening to Google” part mentioned above, Google could find itself providing free services without getting much of anything in return.
Conversely, Silk could give Amazon an immense amount of personal data to be mined for its own business purposes, that is selling physical and logical objects, “stuff” and content.
This is controversial and very much in the air. On his blog, Chris Espinosa (the #8 Apple employee and still working there) raises the prospect of Amazon out-Googling Google and out-Facebooking Facebook:
“Amazon now has what every storefront lusts for: the knowledge of what other stores your customers are shopping in and what prices they’re being offered there. What’s more, Amazon is getting this not by expensive, proactive scraping the Web, like Google has to do; they’re getting it passively by offering a simple caching service, and letting Fire users do the hard work of crawling the Web. In essence the Fire user base is Amazon’s Mechanical Turk, scraping the Web for free and providing Amazon with the most valuable cache of user behavior in existence.”
Impressive. But is it true? Entirely true, partly true, or totally incorrect? As reported on GigaOM, Amazon went on the record denying such use of our personal data:
“Is Amazon able to peer into its customer usage behavior and use that to offer services based on that data. For instance if you see thousands of your customers going to buy SeeVees shoes from say a store like James Perse at a certain price, can you guys use that data to specifically tailor the Amazon store and offer up deals on those very same pair of shoes?” — the answer is no, as you can see in our terms and conditions, URLs are used to troubleshoot and diagnose Amazon Silk technical issues. Moreover, you can also choose to operate Amazon Silk in basic or “off-cloud” mode. Off-cloud mode allows web pages generally to go directly to your computer rather than pass through our servers. As a reminder, usage data is collected anonymously and stored in aggregate, and no personal identifiable information is stored. It’s also possible to completely turn off the split-browsing mode and use Amazon Silk like a conventional Web browser.”
Great. I went to Amazon’s site and dug up Silk’s Terms & Conditions, as well as the Amazon Privacy Notice that if refers to — but fails to link to. The result isn’t as transparent as Amazon would like us to think. True, you can go “off-cloud” — you can browse without AWS caching and rendering help and, in theory, increase your privacy. But if you read the legalese about cookies, or ponder the meaning of the “generally” adverb above, you’re left wondering. When Amazon states “URLs are used to troubleshoot and diagnose Amazon Silk technical issues”, they could be disingenuous; they didn’t write “solely” or “strictly for the purpose…” The Silk T&C’s and Privacy Notice don’t say anything like that, they mention sharing information with third parties, storing information for 30 days and the like. And let’s not forget these terms can change without notice, as they do everywhere.
All this leads observers to wonder: What is Amazon up to exactly?
In the meantime, seeing the Google thread this week’s events, I wonder: Is Google’s Strategy Of Everything backfiring now? Do Larry, Sergey and Andy know how counter these 360 degrees assaults?
