Google Gives J2ME the Finger, but Still Needs a Carrier Partner

It turns out that as The New York Times says, Google is not building a phone. They’ve built (bought, really) a phone platform called Android. It’s Java on Linux, and it’s open source, but notably it is not J2ME based. Reportedly it will run J2ME apps, but the SDK makes the Android API look more like the BlackBerry’s Java API than J2ME. It’s a full featured API that isn’t a least common denominator of all possible mobile devices.

By building on top of and bundling Linux, instead of an assortment of phone OS’s with varying feature sets, developers can be assured that the low-level feature set across handsets will be constant, by which I mean that threads will work and multitasking will always be available. Given that some J2ME implementations and some non-J2ME mobile Java runtimes lack threads, and many phones lack multitasking, this will make writing sophisticated apps for Android far easier.

Android is a huge win for developers. The SDK is already available for Windows, Mac-on-Intel, and Linux-on-i386, and it uses technologies that are already mainstream. Based on my previous post I am curious about whether Rhino, Jython, and JRuby will work on the Dalvik VM, but I have no specific reason to believe they won’t. This is exactly the sort of thing I was talking about when I said that layering on top of the JVM or .NET DLR would ease portability; the Dalvik JVM means that you can likely write a Hello World in any language that can compile down to Java bytecode and run it immediately.

OK, so it’s great for developers. So what? Developers don’t control the mobile market; carriers do. Handset makers would probably love to use Linux instead of paying a per-handset license for a closed phone OS; PalmSource/ACCESS and Palm, Inc. have already said they will move in that direction (though Palm, Inc is creating some confusion about whose Linux-based Garnet-compatible runtime will end up on future devices bearing the Palm OS name). But why would carriers want this?

It’s possible that carriers would like to see their value-added apps run on many different handsets without the cost of developing them separately for each handset they sell. Handset makers and mobile OS vendors clearly are making some money from consulting to carriers on these projects (somebody has to tell Sprint how to write the PictureMail app), so actually in this area handset makers would stand to lose money.

What carriers probably would like less about Android is that it would allow Google to bypass the carriers’ value added services and build their own ecosystem of mobile apps for Android-based handsets, which is exactly the point of Android. Who gets the value added dollars from customers? That’s what this is all about. Google is battling ISPs regarding Net Neutrality, and it comes back to the same thing. If a customer is going to pay for a service delivered from a server across a network onto an endpoint, there are at least four parties that want to get paid, and who view the division of revenue as a zero-sum game.

The server folks (Google, Yahoo, Microsoft, Apple, etc.) want to charge you for the subscription to their applications or for individual chunks of content. That charge may take the form of just showing you ads. Then they want to pay a flat rate for the bandwidth across the network to get to you, and will minimize that cost using the massive content delivery networks which they already have in place.

The network folks want to put a toll booth on that network that charges either the end-user or server folks (or both) for transferring paid content, or one that penalizes the end-user (bandwidth shaping) for buying a cheap connectivity plan and then trying to use it for transferring large media files from the server guys. The network folks also still think they can force the Internet to look like Cable TV, by putting up barriers to keep their users from using anybody’s services but their own, so their ISP customers also become their content customers.

The handset OS folks want to be paid to write those apps for the server folks and the network folks who want to also be server folks. They want to encourage developers (ISVs, or server or network big guys) to focus on their platform, thereby making it more attractive to users, thereby making it more valuable so they can charge a larger amount from each phone sold. These folks are directly in competition with Android, whether Google intends to attack them or not.

The handset manufacturers want to minimize the price of their phone (a free OS that supports tons of hardware components that they might use is a good start) and maximize the number of apps that will run on their phone. They should love this, although the most successful high-end handset makers who also use closed OS’s (basically every major handset maker) will not like it as much as the underdogs who sell tons of cheap phones. LG and Samsung say “hooray” while Motorola, RIM, Palm, Sony, and Nokia say “boo-hoo.” Their investment in special fancy phones and fancy apps for their chosen OS is undermined by the prospect of commodified hardware with carrier- or user-installable third party apps.

Users should be happy as well. Developers, as I mentioned, should love this platform, so users should benefit both from more apps and cheaper handsets, and probably also from more service offerings that will work with their handset.

The problem with all this is that as I mentioned in Technical Architecture is a Form of Investing, just because developers like something doesn’t mean it will win. If Google’s aim is to open up and commodify the handset market, they will have to fight the folks that are trying to keep the handset market closed and fragmented. That group includes all of the major U.S. mobile vendors, and the companies who make handset OS’s. The latter group is weak and easily conquered, with the exception of Microsoft; in this space, though, Microsoft is not strong enough to fight Linux and Java. The former group is extremely powerful and will not simply sell handsets that eliminate their chief source of revenue (proprietary value-added services that show up on your mobile phone bill). Nevertheless, these value-added offerings are generally awful and absurdly overpriced, so there is quite a lot of opportunity if someone can break through the carriers’ stranglehold.

The strategy that Google must follow is to convince an underdog mobile carrier to market an Android-based handset to consumers. Google has little strategic advantage to gain from replacing handset OS makers; they are a service and as such need to prevent the network guys from erecting that toll booth in front of Google’s services. To do that they will need to bypass the network guys, and a phone OS isn’t going to do that. Even a handset offering won’t be sufficient; look at Apple’s iPhone bricking debacle for evidence of that. The mobile carriers control the handset makers in the U.S., and Apple has had to learn that the hard way, screwing over their customers who dared to choose another carrier than Apple’s partner. You can bet that Apple wasn’t the driving force behind that decision.

So Google will have to go all the way to partnering with or acquiring a carrier who is currently an underdog and who needs this offering in order to win customers away from the big guys. Alternatively (and less likely, due to the red tape involved) Google will have to become or spin off that underdog carrier themselves as a new carrier.

So, look for the second shoe to drop: not who is going to build a “GooPhone”, but who is going to offer you a mobile plan that lets you use one without placing severe restrictions on what you can run on it.