When the Tail Wags the Dog

Java Duke image imposed on Firefox logo, pointing at the fox

The Register is reporting that the Firefox team is considering blocking Java in response to the BEAST attack, which allows the attacker to intercept data from an otherwise secured connection. The move would be contentious given the impact it could have on anyone using Java in their Firefox browser, including users of Facebook's video chat as well as Java applets deployed internally at companies who depend on the Java functionality for their business. Without getting into the details of the problem, it seems that the Java plugin, developed now by Oracle, is causing a big headache for Firefox and their options are both limited and unappealing given possible user backlash. It's just another example of why company's are increasingly tempted to not work with other software projects to obtain new functionality, instead opting to fork existing projects, create their own solutions or just go without the new tech altogether.

A recent example involves Amazon's fork of Gingerbread (aka Android 2.3) to power their new Kindle Fire. Many decried the decision, particularly since Honeycom (Android 3.0) was available and targeted specifically at tablets and the newer Ice Cream Sandwich (Android 4.0) was going to be available just around the corner to unify the handset and tablet focused Android versions. More than just forking the code though, Amazon opted to create their own Android App Store meaning users may find themselves needing to repurchase Android apps already purchased elsewhere to get them onto their Kindle Fire or at least having to jump through additional hoops to use all available Android apps. Regardless, the fork means that Amazon is not beholden to anyone else for updates or features and given the open source nature of Android, will be able to pull any choice bits in from newer Android releases without having to work on anyone else's schedule.

We also saw this with Apple's decision to create Safari. Prior to OS X, Internet Explorer dominated the Apple browser market. Given that as connectivity became more widespread, browsing the web became a more prominent activity, Apple was moved to provide a more Apple-esque experience for browsing. The WebKit project provided the core of the browser which resulted in Apple boasting a well known browser of their own on several platforms and no longer relying on another company to provide that key experience.

Apple also showed their desire not to be reliant upon other company's technology in how they have handled Adobe's Flash. Flash has never seen the light of day on an iOS device and is no longer shipping pre-installed on Macs. There were clear performance issues (the 2009 Apple keynote mentions plugins at 10:23 but in retrospect it seems clear the reference was mostly to Flash) but more important were the control concerns. Apple has retained tight control over the user experience of their platforms, control which would only have decreased had Flash become more pervasive on Apple devices. Apple has put considerable effort into providing technologies which developers would have a hard time making use of on a meta platform like Flash, so the less dependence upon Flash by Apple, the more control they retain over their own platform.

Historically we have also seen what happens when companies attempt to coexist with competitor technologies. Witness OS/2's slow death (or lack of uptake) because developers could just develop for Windows and let the OS/2 Windows layer handle running the non-native application. Users never got a taste of what a real OS/2 app could accomplish. And while RIM's PlayBook was practically stillborn, the last gasp effort to renew life by declaring that Android apps would be allowed to run on the device was generally considered a bad idea by pundits since that, as with other similar decisions, would result in less push for developers to target the platform natively.

The lesson here is simple. Only trust third party components to the extent that you can do without them entirely. The more your own platform or project becomes dependent upon the functionality of other plugins or platforms, the more beholden you are to their schedules and priorities. It can be difficult to predict when a shift like that is going to happen (or already has), but it can be crucial.


Kindle Fire vs RIM PlayBook

John Gruber, at, in a post about a comparison between the Kindle Fire and RIM's PlayBook, quoted Ryan Block regarding the Kindle Fire's resemblance to the PlayBook:

From there, Amazon’s team determined they could build a tablet without the help and experience of Lab 126, so they turned to Quanta, which helped them “shortcut” the development process by using the PlayBook as their hardware template. Of course, it’s never quite that simple, and as I’m told Amazon ran into trouble, and eventually sacrifices were made (like using a slower processor).

Although Amazon did refresh the ID of their PlayBook derivative, I’m told that this first tablet of theirs is “supposed to be pretty poor” and is a “stopgap” in order to get a tablet out the door for the 2011 holiday season — which doesn’t exactly leave the best taste in my mouth.

John then follows up by asking:

My question, though: if it’s based on or even just very much similar to the BlackBerry PlayBook, why is the Kindle Fire only $199 and the PlayBook started at $499?

My response: Amazon is hoping for a halo effect, subsidizing a reduced cost tablet, perhaps sold at or even below cost, with the expectation of additional revenue from services provided by the tight integration of the Kindle Fire with Amazon products and services. This halo effect, which is something Apple has counted on with their hardware products, selling Macs and Macbooks because users purchase iPods and iPhones, is also something RIM never counted on. RIM never had services they could push toward PlayBook users which would grow revenue beyond the simple sale of the hardware.

I actually mentioned the idea of Amazon subsidizing Kindle Fire through service revenue a few weeks ago. What makes sense for Amazon didn't for RIM, and I think for anyone trying to break into the tablet market against the iPad, they're going to have to provide a clear improvement on price because the quality and content aren't likely to be matched or beaten well enough to make a difference. And for that to hold true, someone's going to have to take a loss on the hardware and make it up elsewhere. Amazon is one of the few who can do so at this point.


iPad Competition That May Stand a Chance

Techcrunch got their hands on a test version of the new Kindle and based on their report, it seems to give a glimpse of how a worthy competitor to the iPad might be fashioned.

Taken as a whole, it's like most any other Android tablet. The form factor is an improvement and we'll have to wait to see what the battery life is like. Let's just say that much of the raw capability of the device will remain the same as any other Android tablet on offer. So what makes up the difference? Spit and polish plus price point.

First, consider Mac hardware in general, laptops and desktops. Even displays. They are made primarily of common components that any manufacturer can get ahold of. There's no secrets here. That's not to say there aren't some serious hardware design chops being put to work to make that hardware hum, but in terms of the overall capabilities of the units in question, you can find similar quality from many other vendors if you're willing to look for it. It's when you boot it up that you see a huge difference. OS X has Apple stamped all over it. It's a very consistent experience and one that Apple takes great pains to maintain.

Likewise Amazon is putting their stamp on the Android tablet experience with this newest Kindle. You'll apparently be getting their look and feel, their color scheme (by default anyway) as well as their app store (again, by default). They've even taken their version of Android and run with rather than trying to stay up with the latest updates from Google. Essentially it appears they have forked their own copy of Android, tweaking it to maximize its effectiveness on their own hardware. That's well and good, but lots of vendors do this. Or at least put their own mark on it. The difference here is going to be in execution and while it remains to be seen how effective Amazon can really be at customizing the Android UI, they have the advantage that their device is being sold to customers with the express purpose of linking them to the Kindle reader and Kindle store. In essence, you're buying the device specifically because you anticipate using it with Amazon's services. So they will be more free to integrate their services into the end product without customers complaining that they can't remove the apps. And that's going to be one big difference. Other Android vendors have tended to go the same route as PC vendors have, shoveling unwanted and unneeded applications onto the device in order to push customers toward additional purchases or as part of relationships with other vendors. Here, Amazon is the only vendor in question and the customers are buying the device because they want Amazon's services.

The other thing that will help this be more competitive with the iPad is the price point. It's low. It's not HP TouchPad low, but at $299 it's below even entry level iPad prices. Plus, unlike previous Kindle devices, it's intended to be a fully functional tablet, not merely an e-Reader. Even if Amazon is selling at or just below cost, they are no doubt expecting to make it up with additional revenue down the road from new Kindle book sales. And this is the secret sauce for the price point. HP had no plan beyond selling the hardware. Sure, they would have loved to have leveraged those TouchPad sales into additional software sales down the road, but the fact is HP is not an Android developer. They don't have anything that the typical customer links to tablet software. So the ridiculously low price HP is offering their units for is unsustainable in the long run. Amazon does have that software in addition to their own Android app store. It remains to be seen how popular their app store will be with developers and purchasing customers, but it's definitely a plus. Gravy, really, since Amazon is going to be primarily counting on Kindle sales, not app store revenue, to sustain Kindle purchases.