In the Silicon Valley, companies don’t like to talk about their competitors. So if you ask Google how its Android mobile application development platform compares with Apple’s comparable iPhone 2.0, you are likely to get a polite response that there is plenty of room for both. But the contrast is striking. The iPhone device itself was released as a closed environment that was opened only reluctantly. Whereas Google based its SDK on Linux, formed a consortium of companies to promote adoption, sponsored a $10 million developer’s challenge, and is now waiting to see what will bubble up.

Whether Android will result in the kind of cult following that has made the iPhone such a phenomenon remains to be seen. But the two philosophies could not be more different: Apple’s approach is pure “⁠cathedral⁠”⁠ (to cite Eric Raymond’s term for closed source development)―it is controlled, organized, visually stunning and, perhaps as a result, highly appealing, whereas Google has opted for the more chaotic “⁠bazaar,⁠”⁠ whose success has yet to be proven. At this writing, the iPhone Developer Program is open to a limited number of U.S. developers, who pay a fee: $99 for developers building commercial apps, $299 for in-house, developers building proprietary apps. The SDK itself is free. Distribution is strictly through Apple’s App Store, which takes a 30 percent commission.

“With iPhone SDK applications, you have to go through Apple―they are the gatekeeper,⁠”⁠ said Scott Webster, who, along with Jamie Hunter, created the Web site AndroidGuys.com. “⁠Whereas Google is much more open, not just in software development, but in the delivering of services, regardless of the platform.⁠”⁠ Webster said that Android is better equipped to take advantage of a wider palette of mobile Internet devices, including those based on Intel’s Atom processor, a low-watt challenger to the ARM. “⁠We’ve seen phones get smaller these last few years,⁠”⁠ said Webster. “⁠But as phones also get smarter and people realize what they can do with these devices, that trend may reverse.”

Intel is a founding member of the Open Handset Alliance, a consortium of hardware and software companies formed around Android. While that connection doesn’t cement the link between Atom and Android, it does suggest a symbiosis: at the time of the announcement, Intel said that Android could “⁠enhance⁠”⁠ Atom-powered mobile Internet devices. Other members of the Alliance include handset makers Samsung, LG, HTC and Motorola; carriers NTT DoCoMo, China Mobile Communications, Telefonica, Sprint Nextel, and T-Mobile; and chipmakers Texas Instruments, Qualcomm, and SiRF. At this writing, AT&T―which has the exclusive rights on the iPhone in the U.S.―is rumored to be joining.

As with Intel, these companies have been vague about their exact plans, if any, for Android. But taken as a whole, the Alliance is a factor separating Android from iPhone, from LiMo, a competing Linux-based mobile platform, and from Windows Mobile. For application developers, platform adoption is the bottom line, and the Alliance makes it tempting, as does Google’s $10 million Developer Challenge.

Meeting the Challenge

Phase one of the Android Challenge was still underway when I spoke with Dan Morrill, one of Google’s Android developer advocates. “⁠We see the Android Challenge as just that―a challenge, rather than a competition,⁠”⁠ he said. “⁠We want it to be a chance for developers who may not have been able to build these kinds of applications before to do that for an emerging mobile platform. It’s a challenge in the sense that it is a new way to approach this industry, and some developers will rise to the task.⁠”⁠ Morrill has particular affinity for developers returning home from their day jobs and squeezing in a few programming hours at night. That would describe Michael Sheeley and Michael Cook. By day, they are software engineers at BAE Systems in Fairfield, Ohio; on weekends and nights, they are building an Android application called GeoSyncUp.

"Before I started working at BAE Systems, I had a mobile software company focusing on the field service industry," said Sheeley. "My mind has always been a mobile mind. I try to relate everything I learn and do back to that." GeoSyncUp is based on a field service application Sheeley developed called Echo, which borrows concepts from the military and field service industry to allow users to coordinate their daily tasks with friends and acquaintances. "We both have day jobs. It’s taken up nights and weekends for both of us. We’re software engineers at heart and that’s usually what we do with our nights and weekends anyway."

"Our wives don’t like it," said Cook

Because Sheeley and Cook are aiming squarely at a piece of the Android Challenge money, they have had to work with the Android SDK in its earlier state. Early users complained about the lack of documentation, inconsistencies in API naming conventions, and a lack of code examples. But the two developers seem unfazed. "Our background is working with platforms that are in the development phase, so this was second nature to us," Sheeley said. "It was a challenge at first, but no more so than were expecting, given the fact that there wasn’t a live phone to test the code on." Sheeley said that because Apple had released its SDK on a live phone that raised the expectations for Android, perhaps unrealistically so. "But you have to take it all in stride. It’s the first release and this is a new industry so they are taking as many guesses as we are." Sheeley said that the initial tasks have been figuring out what functionality they needed compared to the functionality Android supports―"then guess a bit about what they would be rolling out in the future."

The lack of an Android-enabled phone is a particular disadvantage in testing out the SDK's location-based services. "But the SDK does provide a mechanism that returns a set of locations based on what you hard code into the emulator. You get an XML file with a list of 100 coordinates, and every time you request a new coordinate, it will give you the next one in the list. It’s a simulation, but a nice way to test your applications without having a live device."

The two programmers have been working on the application since November, and when we spoke, were close to releasing a version that works on the emulator for their round one submission to the Challenge, due in mid April. "We will definitely have a version out there by the end of the year, which should line up by the time that, at least according to rumors, Android will actually be available on phones."

Another Android developer is Paul Marrington, a 28-year software engineer who has been developing Golf Adept, first for J2M3, now for Android. The application will amass a player’s game statistics as well as showing player real-time player location on a Google map. The project is a family affair, with research contributions by his wife, librarian Mary-Ann, as well as by his two sons. Marrington worked on the design for about six months and began coding in J2ME, figuring he’d wait for Android until Android-based phones hit the market, but changed his mind after the Android Challenge. He ported his J2ME prototype to Android in seven weeks. Having climbed the learning curve, he now figures he could do the port seven times faster.

“Android is in the alpha stage: the documentation is light, the environment is brand new, and the source isn’t available,⁠”⁠ Marrington said. “⁠That means you must spend a lot of time experimenting to see what works and what doesn’t. The process reminds me of developing back in the 1980s before the Internet and open source. When there are real Android-platform phones out there, developers will be able to work a lot more quickly.⁠”⁠

Marrington tries to write portable code and said the difference between the Android and J2ME base code for his application is only about 15 percent. After all, they are both written in Java. The big differences with Android are application portability and location services. “⁠In the past, mobile phone programming was a black art,⁠”⁠ Marrington said. “⁠Even with J2ME, you still have to create and test a version for each phone brand and, often, each model. Android will provide a consistent system allowing one binary to work across all Android phones.”

But for Golf Adept, Android’s location-based services are key. “⁠I can do the basics on a J2ME phone, but I can do a lot more with Android. For example, the phone is designed for an always-on Internet connection, which means we can send information back to the Internet interactively. In an amateur competition, you could sit in the bar and see where everyone is and what score they’ve got. Ultimately, I can imagine looking at a Google map on a screen in the bar and watching the competition as it unrolls, just like with a professional PGA tournament.”

Meanwhile, the AndroidGuys think that Android will also bring changes to the American mobile industry, which continues to lag behind its Asian and European counterparts. “⁠We’re way behind,⁠”⁠ said Jamie Hunter, who sees the market at ground-level from his work at a T-Mobile retail shop. “⁠Only in the last six months the N95 [Nokia 95] is finally coming to my store, and this device has been out in Europe for close to two years. We’re also behind in the 3GM networks, so we’re not going to see the newest handsets available for those networks either.”

Scott Webster thinks that carriers have put a stranglehold on the industry. “⁠Customers don’t know what’s available. They’ve only been told there are the six or seven phones to choose from, and the mentality of the sales reps is to sell the service, not the phone. If people knew what they could do with these devices, they would be asking for more.⁠”⁠ Android, he said, could help loosen the carrier’s grip by forcing them to market on service and price, while the phone becomes more of a PC-like experience. The move by four U.S. carriers, Verizon, Sprint, T-Mobile and AT&T, to offer one-price unlimited services, is a step in that direction. “⁠They don’t tell you anything in their commercials about their phones. They are saying for $99 you get talk, internet, sports scores, updates, GPS. That’s what it is going to come down to. The minutes aren’t a problem anymore. Nobody talks about using peak minutes. It’s what can I do with my phone now.”

A conversation with Google’s Dan Morrill

Google’s Dan Morrill is a self-described evangineer―part engineer, part evangelist―and an advocate for developers interested in Android. Before joining the Google Developer Program in 2006, he was a computer scientist at GE Research, where he “⁠gave himself headaches⁠”⁠ switching between JavaScript Web development and integrated circuit design.

Where is Android in the roll-out process?

The members of the Open Handset Alliance are collectively working towards the 1.0 version of the system, and we expect that to be ready coincident with device availability in the second half of this year. We're still in the pre-alpha state.

What about adoption?

The question is: adoption by whom? There's adoption by industry carriers, by device manufacturers, and by developers. Each requires a specific set of skills and attention, and if you only focus on one, you end up with only one leg of the triangle. So we are working on all three at the same time. Ultimately, you have to have industry adoption, developer adoption, and consumer adoption.

Is there an interplay between chip-level adoption and handset adoption?

This is a subtle point. People see the Open Handset Alliance as an industry consortium, and of course it is―an alliance of companies. However, the way that the members of the alliance operate is less like a standards body or a consortium of marketing organizations, and is more like an open source core team. To make an analogy, Linus Torvalds, Alan Cox and Andrew Morton are key developers on the Linux kernel core team, which guides the operating system, shepherding and maintaining it. That's the role that the Alliance adopts with Android. Right now, the members are heads down, trying to get a product out the door―just as you would expect from an open source core team. So I'd say this: every member of the alliance contributes something to Android.

How will Android-compatible applications be vetted? Who decides?

Think about the Web, where the experience is in the hands of the user. If I want to change my home page from Google to Yahoo!, then I don't need anybody's permission. That philosophy has worked very well for Google, and we believe it will also work very well in the mobile space. So everything we're doing with Android is intended to leave ultimate control of the user experience in the hands of the user. Of course, that presupposes that developers have first created something cool. So we are trying to strike a balance between end user control and the developer's ability to do cool things with the platform.

Anything that gets in the way of developers delivering cool applications, or gets in the way of users selecting which of those applications they want to use is more of an obstruction than a help. That's not to say that we think it was wrong for Apple to have taken its [more restrictive] strategy. They are trying to strike that balance in a way that works for their own platform. But Android is a different platform, with different guiding principles.

Does Android represent a cultural shift for the mobile space, in which control has been in the hands of the carriers, or, in the case of iPhone, with manufacturers?

Yes, it does represent a sea change. We're interested in making it as easy as possible for users to get as many cool applications as they can. To the extent that that involves lowering or eliminating barriers that currently exist in the mobile industry, then yes, I think that would be a fair statement.

Will that control be given up easily, or will the carriers go kicking and screaming?

The Alliance includes several carriers, so there are carriers out there who have already expressed support of this idea.

Should people look at Android as an open source answer to iPhone?

People should definitely be looking at Android as an open source project. I don't think that anything we're doing is in response to Apple. Android has been under development for years, and there are hundreds, if not millions of man hours of engineering in this. It's not accurate to say either the iPhone or Android or any other effort, such as LiMo, is a response to the others―because they all had a gestation period around the same time. But I would agree that people should view Android as an open source project, with the caveat that the source isn't yet available.

There have been grumblings that the SDK may have come out too early and is too undocumented.

One Android developer, David Welton, pointed out in his blog that there are two schools of thought in the developer community. There's the industrial, enterprise style developer who is used to high-level, turnkey solutions. This group will have high expectations for the quality of the SDK and documentation. Then there's the open source, "bazaar" style of community, which is more free-wheeling, a little more risk tolerant, more interested in the technology and trends. So it's the conservative adopters versus the early adopters. Because we are Google, we attract a lot of attention from both of those camps. But we're trying to follow the open source style of development, which is why we released the SDK early. That release has gotten a lot of reactions because some developers assume that vendors will release SDKs only when they are completely ready to use. But our mindset is somewhat different. We are saying we're going to build this. We don't have the cycles to release the source code now, but it will come later. And in the mean time, we thought developers would appreciate getting a preview, giving us some early feedback, getting their foot in the door and start building applications―if they are interested in being there with us at launch.

Ultimately, Google's product release strategy is based on being as open and honest with our users as we can be. That's why we're calling it an early look at the SDK. When devices become available, that will become the 1.0 version of Android. Everything that comes up to that point is, by definition, an early look or an alpha.

Is there an advantage for Android applications in having 3G country-wide, as Japan has, versus our relatively slower bandwidth?

In many places in the world, the mobile phone is the primary way of getting on the internet. Particularly in those places, it makes a lot of sense to have your data network be as fast and affordable as it possible. We believe that that faster data speeds will spread to other parts of the world, such as the United States. Faster speeds are vitally important to the future of mobile.

Will users in Asia will be more receptive to a wider variety of applications because they are used to the small interface?

The usage of our products and services varies a lot according to geographic regions. That's why we are making sure that developers are such an important part of the Android platform. The people who are best going to be able to build applications for say, China, are Chinese developers. They are going to understand that culture and the users in that country, and will be able to build the best applications. That doesn't mean that we won't be right there with them building our applications in that market, but we recognize that one size does not fit all.

Beside location-based services, what other Android services should developers should be paying attention to?

Location based services are essentially one kind of sensor input. But Android will include APIs to access other kinds of sensors, as well. For example, the iPhone has an accelerometer that was initially used to re-orient the display based on which direction you hold the device. But that connection with the environment―knowing which way a phone is being held―opens the door to other kinds of applications: for example, the kinds of experiences found on the Nintendo Wii.

What is the revenue model - for Google, for developers?

It's not so much that Google is trying to make money off of Android by selling it. Rather, that Android is the kind of open platform we need in order to make money ourselves. It's the kind of platform we ourselves would want to have on mobile devices.

Android is the way Google gets beyond the PC.

Exactly.

What kind of developers are working on Android applications?

We don’t have any hard statistics, but from the posts I’ve seen on our developer forums, we’ve got a pretty cool mix. At one point, we asked developers if we should extend the deadline on the Challenge by a couple of weeks. One post that stuck with me said he’d welcome the extra time because, after he comes home from work, between dinner and spending time with his kids, he’s only got a couple of hours a night to work on this. I like the idea of developers who work at their day job, get home and manage find the time to build an application. We want to encourage that entrepreneurial spirit. Some professional mobile companies are interested in Android, and some software companies that aren’t necessarily mobile are also doing things. But the exciting ones are the individuals.