MWC Watch: Developers, Developers, Developers
Telco 2.0 is, of course, at Mobile World Congress this week. Something that's very obvious this year is the come-back of the North American industry, and specifically anything that involves Android or developers. All the device vendors who ship substantial volumes of Android devices are heavily present. Samsung is practically rolling in Androids. Despite the announcement of the new version of Microsoft Windows Mobile, HTC is big on Android as well. Android software developers are everywhere.
However, an interesting phenomenon is making itself felt. Rather than - or as well as - being a top-end product for the latest smartphones and early adopters, Android has been heavily adopted by vendors looking for an economical platform to get into the smartphone market. This places some strains on the technology itself and may have significant long-term consequences for the Android ecosystem.
It's something of a tradition for Google to throw hardware at its problems; we live in an era where hardware is cheap in terms of engineering man-hours, and Google has relied for years on huge numbers of PC servers crafted to its specifications. It came as a shock to the industry when we learned that there were 100,000 Google servers back in 2004 - how many must there be now? The limiting factor for this approach turned out to be power and its twin, cooling. Google has since invested heavily in improving the power performance of its hardware and its buildings.
As a result, it is perhaps not very surprising that Android has a reputation for being a resource hog. Specifically, the heart of Android, Google's home-grown Java virtual machine Dalvik, is significantly more processor intensive for comparable performance than the Sun-made original, or code running in native C. If the device in question uses Qualcomm's Snapdragon 1GHz chip, this won't be a problem. If it's a much cheaper ARM9, it can be a significant constraint on the user experience and what exactly will work. Now, if Android was only being used for the top-of-the-range, this wouldn't be a problem. But vendors are keen to broaden the smartphone sector and make use of what is the cheapest mobile operating system going.
Dalvik is one of the keys to the whole Android project; as well as wanting to avoid relying on Sun Microsystems or paying them royalties, Google created it in order to give the Android phones a primary development environment based on Java and arguably also in order to have a control point in the intellectual property rights. Whereas much of Android is pure GPL code - like the Linux kernel, the core libraries, the WebKit browser, the user interface, the Python virtual machine - Dalvik pointedly isn't.
This is why the appearance of alternative Dalviks is interesting. Myriad, for example, offers its own version of Dalvik, which it has subjected to extensive code refactoring. They claim that it performs dramatically better on the Android common benchmarks and on some standard IT measures (Grinder, quicksort); Telco 2.0 saw a jBenchmark test carried out. The performance boost seems to be concentrated in graphics rendering and in loop constructs - as the latter are very common in procedural code and most code is procedural, this is significant. They claim it is interface-identical with the original and that it passes the Android unit tests.
So it's possible to squeeze Android further down the range of devices - and to remove an intellectual property dependency on Google. This, of course, puts greater importance on the Google account, its related G-services, and Google Ads to deliver value for Google from Android.
Google has Android. RIM actually had an android on one of their two stands - skittering about among the legs, under the control of a developer skulking in the crowd with a BlackBerry. It would be churlish to complain that controlling a basic robot with Bluetooth is one of the examples in Scheibe and Tuulos' s Mobile Python; everyone we mentioned it too instantly went all shiny. "Robot!" Like some people do around cats. Developers are like that.
Take RIM. RIM has practically nothing else in the show but dozens and dozens of start-ups with their applications, spread across two enormous stands and a developer day. The immediate reaction from a Telco 2.0 perspective is that so many are rather sensible and enterprise-related - field-service ticketing systems and BlackBerry clients for industrial SCADA. Not the sort of thing that gets you on the front page of Reddit and Slashdot, or on the keynote at MacWorld, but certainly the sort of thing that makes real money.
Speaking of making money with RIM and developers, we also took in one of RIM's developer sessions about their new advertising and payments services, now in closed beta. These make it possible to embed rich, targeted adverts in an application's user interface context, to manage them through a central Web interface, and to link the adverts with a programmatic callback. Rather than just going to another advert on a Web site, the advert's call-to-action can be a literal callback that initiates a voice call, places a contact in the user's address book, places an event in their calendar, or sends the user to BlackBerry App World to make the sale. RIM is acting as an aggregator, acquiring ad inventory from multiple ad networks and placing it with developers; out of the advertising revenue, RIM intends to take a small revenue share - covering costs only - and to pass some of the rest to the ad networks, with the balance going to the application owner.
Yes; it's a two-sided advertising market, intended to sell devices through helping application developers monetise, and it's all the work of a device vendor. Not good for carriers, although they will be pleased that the related payments SDK will provide carrier billing as an option next to PayPal and credit cards.
[Ed. - we'll be exploring these issues in more depth at the 9th Telco 2.0 Exec Braintorm on 28-29 April, London].