RSands Consulting

At Mobile Monday Boston last Wednesday (yes MoMo can be on Wednesday if Yom Kippur is on Monday…) Bill Scott, VP of Sales and Business Development at GetJar, a large multi-platform app store, delivered the soundbite of the night in explaining why he thinks the smart money will bet on Android long-term, vs. iPhone. He said “iPhone is the new BREW, Android is the new Java.” There are certainly some parallels:

Bill walked the audience through an economic argument as to why the most successful app developers will target multiple platforms, not just the iPhone. He’s right – if you’ve got the money, the scale, the know-how and sophistication to manage a big porting and test matrix, a lot of partner programs and distribution negotiations. His point is that the more handsets and end users you can target, the more money you can make. But there comes a point of diminishing returns, even with automated porting and testing tools. The question is not how much revenue you can pull in, it is how much profitable revenue.

Jason Jacobs, founder of RunKeeper and a successful iPhone app developer was also on the panel. When asked about his plans to port RunKeeper to other smartphones, he said he’s thought about it but right now is quite happy with his success on the iPhone. Jacobs says that the fastest route to greater profit for RunKeeper has been to expand his existing market through community building features, global reach, and product extensions to new sports and training methods. For RunKeeper, the point of diminishing returns has already been reached with just one target platform. Jacobs did not rule out porting to other platforms in the future, but he’s focused on profitability, not just maximizing revenue.

The iPhone is different from BREW in some very important ways. BREW has always been perceived as tied to Qualcomm’s CDMA-centric focus and to Verizon Wireless in particular. The iPhone is on the most broadly deployed network technology – GSM. The BREW certification process is perceived as complex and costly, designed to facilitate operators’ “walled garden” models. Verizon Wireless’s announcement today of a Google/Android partnership points to the end of that sorry era. While the App Store approval process gets dinged for being arbitrary and opaque, for most iPhone apps it is fairly smooth sailing by comparison. And lets face it – BREW never has had sex appeal – targeted at more low-brow feature phones. The iPhone fairly reeks of it. In an earlier post, I’ve talked about some of the ways the iPhone is disrupting the mobile ecosystem. You can see that disruption in action, watching Apple and AT&T’s competitors scramble.

The iPhone adopted the best elements of BREW: nearly zero fragmentation and integrated distribution, and ditched the bad bits – narrow network, small subscriber footprint, weak marketing and branding. Android has adopted both the best and worst elements of Java ME – broad footprint, open platform, fragmentation and a “wild west” competitive landscape.

Bill Scott said that fragmentation is an inevitable cost of the mobile marketplace, and that successful developers must just learn to live with it. With over 2 billion apps downloaded, Apple is disproving this bit of conventional wisdom. Google needs to manage their platform’s “diversity” if they hope to catch Apple in this very new world.

Continue Reading

Motorola is jumping into the smartphone market to try and win back some of their former Moto mojo with their Android-based new Cliq smartphones. More competition is good, right? Yes, but the MOTOBLUR (whose sharp branding mind invented that one?) user interface is going to drive Android application developers nuts. Why? Here’s how Sanjay Jha, Motorola’s co-CEO describes MOTOBLUR at GigaOM’s Mobilize ‘09 conference:

“With MOTOBLUR we are differentiating the Android experience for consumers by delivering a unique mobile device experience designed around the way people interact today,”

Hooray! Motorola is differentiating the Android experience! Can you hear the screams of Android application ISVs? Oh yes – MOTOBLUR is a “skin” and doesn’t reimplement the virtual machine at the core of Android. Applications written to Google’s SDK will likely run. But if you want to really integrate your app with the Cliq and other MOTOBLUR phones, you’ll need to code up something special. And Motorola is gearing up to give you that rope, as Mr. Jha proudly announces in an interview with PC World:

“Over a period of time–we’re not there yet–we’ll allow the APIs to be available so people can develop many more applications than we can think of ourselves, but it’ll take us a little bit of time to mature ourselves to a place that we could open up APIs.”

And that’s just Motorola. HTC has an Android phone or two or three or four. LG and Samsung are getting in the race too. The Open Handset Alliance (what an ironic name!) has 47 members. Pretty soon Android is going to fragment into a thousand implementations. Goodie for Google, right? Android will beat that pesky iPhone through sheer diversity and market momentum!

Ah yes, the iPhone. Two versions! Black, and white. But only one API. Apple exerts absolute, iron-fisted control over their platform as the sole handset OEM, turning back all entreaties (except perhaps from China) to build variants specific to to carriers and geographies. By nearly eliminating the cost to port applications and handling deployment through a single mechanism – the iTunes App Store, Apple has dramatically improved the economics for application developers. With over 75,000 apps available, its been a huge success.

Android is already fragmenting, and fast. Google knows this, and knows it is a big obstacle to developers. It just makes it more expensive to create Android applications, and makes it likely that Android developers will target only a subset of the market. Chris DiBona, Google’s open source program manager said as much at this year’s OSCON Conference:

“We think it’s really important that we spend a lot of our time trying to reduce fragmentation from an the application stand point – so when you code the G1 it’ll also run on later platforms from Sony Ericsson and Motorola and all the rest – and that’s a huge challenge.”

Huge challenge indeed. Can Android succeed if it ends up with hundreds or thousands of different implementations each subtly different from the others, as Java ME sadly ended up? How much fun will it be for consumers to hear about the latest cool application for Android phones, visit the Android store, select their phone (which model is it again? the XV7845a or XV7845c?) and find out that the app doesn’t run or has unpalatable limitations on their handset?

The moral of the story: if you give your partners the ability to “differentiate” your platform, you had better understand the implications for developers and the end consumers of your software. Google has a lot of smart people and they’ve made the calculation that it is better to get Android on a zillion handsets across all the carriers, and that the inevitable price to pay is fragmentation, the OHA’s “non-fragmentation agreement” notwithstanding. It is a huge gamble, and history is not on their side. Is fragmentation inevitable? Is openness worth the price? How valuable is differentiation when it dramatically raises the cost of application development? Who does it benefit, anyway? Consumers? Will MOTOBLUR really help Motorola regain their mojo? What do you think?

Continue Reading

So, Sun embraces Oracle, not IBM, in the end. Most of what I said here about IBM applies to Oracle as well. They’ve based their middleware on Java just as IBM has. And they’re perhaps even less of a charity than IBM. But Oracle also has much less experience in open source communities than IBM. Indeed, as far as I know, Oracle has very little community presence at all, and haven’t open sourced any of their marquee products.

This is causing some consternation among open source and free software advocates, who are concerned mostly about MySQL falling into Oracle’s clutches and being summarily dispatched. I’m not savvy on open source DBs so I’ll leave commentary on that one to those who know something. What might happen to Java though?

Ars Technica’s Ryan Paul thinks Oracle will be good for open source Java:

Sun’s dictatorial control over the evolution of Java has been widely criticized by other stakeholders and is generally viewed as detrimental to the language’s growth and adoption potential. The Java Community Process (JCP) has been a particularly thorny source of controversy and friction.

Oracle could finally democratize the JCP by making it more transparent and inclusive. Sun’s overt hostility towards the Apache Software Foundation’s Harmony project, which seeks to build an Apache-licensed Java SE implementation, could also finally be brought to an end.

Bad, bad Sun! Now the community can rejoice! But wait… Here’s Glyn Moody of ComputerWorld who thinks overall it will be good but perhaps not so great for open source:

The downside is that Oracle’s feelings about open source – and hence its advocacy – are probably more ambiguous than Sun’s. In particular, it seems to have very little truck with the more idealistic leanings of the free software side of things. Pragmatists might rejoice at that, but it does mean that Oracle will be aiming to use open source as a tool rather than see itself as an evangelist with a mission to convert.

Canonical’s Mark Shuttleworth, in a report on a press conference after the Ubuntu 9.04 launch, is sanguine:

“I’m sure Oracle has carefully thought through everything it committed [itself] to [and] there will be no reversal of the idea that Java should be widely available and available as open source,” Shuttleworth said during a press conference today to launch ubuntu 9.04 upgrade.

“It’s a one-way trip,” Canonical chief said about the process of making software open source. “What is interesting [about the Oracle-Sun deal] is that it really cements the idea that free and open source software is the profound driving force in software today. ”

Shuttleworth is correct. Once a code base has been open sourced, the community has the power to take the code and run, if they don’t like the direction a project is headed. Having had first-hand experience with the power of community thought leaders to influence even Java, the largest and most corporate of code bases, this is a lesson Oracle will learn. Either they’ll learn it the hard way, or they’ll learn it from people at Sun who understand this stuff deeply, and whose expertise could save Oracle a lot of trouble.

Redmonk’s Stephen O’Grady sums up the most likely scenario of all:

However the politics resolve themselves or not, though, the Java landscape is characterized as much by its inertia as anything else. Ergo any potential shifts in the landscape here are likely to be glacial in pace. I’d expect something very akin to the status quo for the foreseeable future.

Time – lots of it – will tell.

Continue Reading

(Just a reminder – I’m no longer at Sun.)

There is a heckuva big investment in Java software across the IT industry, and so it is interesting to think about where this platform might go if Sun, the inventor and “steward” of Java, gets swallowed by IBM, the company that has made the most money on Java over the years.

IBM has bet a big piece of its software strategy on Java. A long-term licensee, IBM has been a leader in the JCP, built and then contributed to open source the most popular Java IDE (Eclipse), has long marketed one of the leading Java-based middleware product lines (WebSphere), and builds lots of well-regarded Java plumbing, including virtual machines, Java EE implementations, tools and embedded versions – the works. Even as IBM and Sun have cooperated in promoting and advancing the Java platform, they’ve competed on implementations and have at times not seen eye to eye on where the Java standard should go, and how the platform should be governed.

Sun’s software strategy over the past few years has been to intensively open source its marquee software platforms, including Solaris, and Java, in order to drive platform adoption by developers. Sun’s FOSS platforms are free as in – zero cost to acquire, and Free – as in, built by a community of developers and licensed to eliminate proprietary lock-in. The hope is that developers, and the enterprises they work for, will adopt Sun technology as the plumbing on which they build their critical business applications and processes if acquisition cost is zero, and their investment in time and effort are protected. Once ready to deploy, some fraction of these customers may choose to buy support. Oh… and gear to run it on – software DOES still require a computer to run it, even in the cloud.

All of this is spelled out in Jonathan Schwartz’s blog, and is party line and marketing message. But there’s a bit of subtlety that isn’t apparent until you actually try to use the FOSS Java code, especially in embedded applications. Sun has done well over the years licensing its Java ME software to those building devices. The company has a legitimate business interest in maintaining these significant licensing revenues (pdf – see pg. 6). The GPLv2 license without the Classpath exception, chosen for Java ME can be impractical for an embedded device maker to use, as it includes a “copyleft” provision requiring that modifications to the code, or other code linked to the GPL code must also be published as source code, under the GPL license. So, the recipe to any “secret sauce” must be freely available under the GPL. Hardly something that excites a handset maker, for example. Why not use Java SE then – since smartphones and other advanced devices have the power to handle it? Not so fast! There are some even more mind-bendingly complicated licensing issues for Java SE that riled up the Apache Software Foundation, related to this embedded device revenue. Ever wonder why Google’s open source Android platform – which looks startlingly similar to Java SE in many respects, is nonetheless not based on Sun’s open source code, but rather on Apache’s Harmony project? One can speculate…

IBM approaches open source platforms differently. Rather than monetizing open source only by selling support for deployers, or by choosing licenses that drive commercial licensees to keep paying, IBM distributes FOSS code that comes from elsewhere – often non-profit foundations such as the Apache Software Foundation – but licensed in such a way that IBM can bundle proprietary extensions with the FOSS code. This lets IBM add value, create something unique, and yet leverage the open source development model and the momentum of FOSS adoption for the bulk of the code they ship. Good idea! Get the benefits, and still sell stuff and make money. This approach doesn’t annoy licensees, and keeps communities happy and burnishes IBM’s FOSS credibility by contributing to independent FOSS projects. Seems to work for them too.

What would Java look like, if it was ideally suited for IBM to profit from it, using the same approach? Maybe IBM would donate Java to ASF, making it an Apache project. Or donate it to Eclipse? Perhaps they might spin it off as part of a “Java Foundation” or something equivalent, licensed under the ASL, or perhaps the EPL – the Eclipse Public License. It is interesting to think about the role of the JCP if Java were to become a code base built within a non-profit foundation, rather than controlled by a corporation as it has been with Sun. Would the JCP even be needed anymore, and if so, who would pay for platform JSRs? How much code, and staff, would IBM contribute to help the platform evolve? What commercial extensions could IBM sell? What would embedded Java look like as an IBM product? Would Google still need Android as a separate code base? Or could they adopt “real” Java under such conditions? Could IBM unify the fractured Java ME ecosystem?

IBM is much less of a charity than Sun. Perhaps that is why they’re making money and Sun is shopping for a suitor. But under IBM, it seems to me that Java is likely to remain FOSS, under a very liberal license – arguably even more liberal than GPLv2. Of course the existing code will always be available under GPLv2 as well.

Would IBM be a good steward of Java? What do you think?

Continue Reading