I also tried a bunch of intermediate stages of downgrading and testing, including 10.5.0, 10.5.1, 10.5.2 without the Leopard Graphics Update, then with it, 10.4.6 (from the DVD), 10.4.11 with all the current stuff, with and without external display, with and without a shim propping up the bottom of the case with a desk fan blowing directly at the underside of the case. No matter what, I can make it crash, but it takes a good half hour or more before it happens.

Plugging in the external display seems to help (it crashes much more quickly with the external display connected). My guess is that the GPU or VRAM is overheating or is just plain faulty, and that increasing the number of pixels they have to drive is what makes them fail faster.

I had suspected that it might be a GPU temperature problem, or even the dreaded Thermal Paste misapplication problem, but using iStat and Bresink’s Hardware Monitor, I wasn’t able to find a correlation between GPU temperature and a GUI crash. But, now that I can prove that it isn’t due to any non-Apple hardware, and that the OS version is irrelevant, this MBP is going back to Apple for repair. Again.

Again? Yes. I had a somewhat similar problem before, but the video artifacts were much more hardware-y in nature. Apple blamed it on 3rd party RAM and told me if I continued to use non-Apple RAM they would charge me for the next logic board, regardless of AppleCare coverage. So I’ve been using Apple RAM, which costs about twice as much as the Patriot RAM I had bought originally.

However, that problem was visible to the Apple Hardware Diagnostic software. This one is not – the diagnostics find nothing wrong (even on the extended diagnostics mode), but in real world usage I get about 2-4 hours of uptime before having to restart. Even, as I said before, under a fresh Tiger reinstall with Apple RAM, and nothing but the power cord plugged in.

Hopefully Apple service folks will be able to reproduce this problem, or diagnose it with some kind of fancier tool that runs for long enough to provoke a failure. I apologize to anyone who has followed in my diagnostic footsteps, which now appear to have been off track.

Update: It was actually an intermittent hardware problem and Apple has replaced the logic board of this computer.

A closer examination, though, reveals that Kindle doesn’t solve the problems that caused prior e-book efforts to fail. It’s not better than a book in any way, and yet it costs more than a laptop PC and is nearly as complicated.

Let’s look at the key features.

600 x 800 pixel, 6″ diagonal grayscale display: This is probably the best part of the device. Those dimensions yield a 160 DPI resolution, which is quite sharp (compare to CRTs and LCD displays which typically have a resolution in the 72-96dpi range). I suspect that the display probably has outstanding contrast and sharpness, and that anyone attempting to objectively evaluate the device will be too busy drooling over the display to think about anything else.

“Simple to use: no computer, no cables, no syncing.” Well, why does it come with two cables, then? Oh, by no cables, you mean that there are two cables. Power cable, sure, because it’s more convenient than a book that way.

But what’s the USB cable for? Amazon CEO Jeff Bezos has a letter on the Amazon home page today that says “there is no software to install and no syncing required.” That’s true, as long as you don’t use the Audiobooks feature. If you do, well, then you need the second cable. (In that case it’s less convenient than an iPod because an iPod is smaller and cheaper, and has a color display. But an iPod won’t let you read books as clearly on a 6″ screen. So the Kindle is better than an iPod at that, I guess.)

“A copy of every book you purchase is backed up online in Your Media Library in case you ever need to download it again.” So, there’s no syncing, except for syncing with the server where the books are. And also there’s an SD card slot so you can keep track of what downloads are on which card already, and maybe accidentally keep multiple copies on multiple cards. So it’s not really syncing, it’s downloading. That’s completely different from what a Zune or an iPod does. (Except in the case of Audiobooks, when it’s exactly what an iPod or Zune does.)

You can email non-Kindle documents to your Kindle. That costs $0.10 each, and let’s hope you only need one version of that document, or else you’ll have to pay an additional $0.10 each time. Any Word documents will need to be converted automatically for you, which means that some percentage of formatting will be mangled in the process. So, there’s no syncing, which means that you have to be on top of making sure that the documents you wanted to have on your Kindle are manually re-emailed (at $0.10 per email) to your device each time they change. That’s much easier than syncing, yes?

Let’s make that absolutely clear: there are no cables whatsoever, other than two cables. There is no syncing, except for three different kinds of syncing.

“Navigation on both sides means both “lefties” and “righties” can easily use Kindle with one hand.” There are large next/previous page buttons on the left side, but only a next page button on the right, together with a back button. Shall we presume that the Back button and the Prev Page button do the same thing? Or do they mean that lefties and righties can go to the next page, but only lefties can go to the previous page?

It seems that as far as the controls, they have looked at what Apple has done with the iPod’s ultra minimalist design, and done the opposite. There’s a QWERTY keyboard, but it has “chiclet” keys, the space bar is in the wrong place, there’s a gap in the middle, a bunch of unused space around each key for no apparent reason, and an almost comical angling of the keys. There’s a weird LCD scroll bar on the right side of the main display, which is as tall as the main display, but is apparently physically separate. And there’s a big vertical scroll wheel.

Of course, the screen is a touchscreen and you can use your fingers or a stylus to select text. Wait. No? Oh, you can’t select text that way. It’s not a touchscreen at all. You just use the arrow keys… um. there are no arrow keys; there’s just backspace. Based on the photos on Amazon’s site, it looks like you hit Alt and then a number key in order to edit text, which you shouldn’t really be doing, because this is a book. Except, you also can use it to search, or annotate, or shop. So it’s sort of like a pen, or a black and white catalog, or a library. You might say it’s kind of like a laptop, but not really, because it’s supposed to be a super evolved book. But it has audio features, so it’s sort of an iPod, but not really, because it’s much too large to fit in your pocket.

Okay, so let’s assume that people in vast numbers will overlook ergonomic problems and aesthetic issues and the usual headaches of syncing, in order to get something substantially less functional than a laptop PC, which can be had for about the same price. (Let’s also assume that they don’t know that Sony makes a “Digital Book” reader that costs $100 less than Kindle.) There’s no reason to assume any of this, but let’s just pretend.

There’s still the property problem caused by DRM. Amazon’s Kindle page says that Fair Game by Valerie Plame Wilson has a list price of $26, but I actually clicked a couple of times to check this out. I can order it online, from Amazon.com, for $12.25 plus shipping. Then I can lend it to my wife, my friends, and then sell it to a bookstore or at a yard sale, or donate it to the library. I can get far more use out of a book at $12.25 plus shipping than I can for a $9.99 Kindle limited use license to read that same text on a $400 device.

(If I can be a little bit patient and wait for the paperback version, or for a lot more copies to be bought and then offered for sale used, I can get well under $9.99. I just bought a hardcover statistics textbook for $7.79 including shipping, just to avoid the wrath of Zed Shaw). List price? $123.53.)

Of course, the reason Fair Game is available for $12.25 in the first place is because it’s possible for someone to sell me a used book. I bet I could go to one of a half dozen local used bookstores and find the same book for a similar price. Or, I could just go to my local public library, and get one of the ten copies they currently have, for free. Again I could photocopy it, or let my wife read it before I return it. They own the physical books, so they get to do this.

(By the way, the library will also let me download time-limited PDFs for free onto my computer or brand new sub-$400 laptop. Yeah, they’re DRM encumbered, but they’re also free, and don’t require that I buy a special e-book reader.)

Clearly, buying physical books has some advantages. So what are the advantages are of electronic books? It’s definitely not financial. Here’s where the fun math applies: real physical books cost money to print, ship, store, and destroy. Electronic books don’t. Some large percentage of the cost of each physical book or magazine you buy goes to print, ship, store, and destroy the copies of that same book which no one ever buys. The printing and distribution costs of books are nothing to sneeze at; ask anyone who works at a bookstore. Electronic books, then, cost far less to distribute to customers. Why should we pay the same price for a license that costs less to make and sell, and gives us less in return, than a real book? That’s not even counting the very expensive reader device, which obviously will not last as long as a book will, and thus will need to be replaced in a few years just so you can keep reading the same book.

And that’s the biggest problem with e-books: Amazon is promising that when you “buy” a Kindle book, you will always be able to read it. This is not implied, it’s explicit: “Amazon is storing your personal library, which can always be re-downloaded wirelessly.” “…in case you ever need to download it again.” (emphasis mine) That means that they are promising you that someone will always sell you a reader device compatible with their format, and that you will always be able to put your “bought” books on that device. So, the file format and DRM and back-end service always will need to be there, and will always need to be available to you for free, or else the deal isn’t what they are telling you it is.

Would they pull the rug out like that? According to one early adopter’s comment on Amazon’s own side, they already did that with e-books once before. Google did the same thing with their video store. When a service can only survive if a massive end to end infrastructure is maintained, which pretty much defines all internet-based DRM efforts, the risk to the buyer of license revocation with no refund is very high.

Now, take a look at the film, television, music, and book publishing industry’s combined downward spiral and listen to their cries of despair. These are the people who are launching DRM-heavy services tied to closed devices. Are you going to entrust your entire personal library to what might well be a service that is cancelled in a year? What will you do with your $400 single-purpose closed hardware device then?

In short, Kindle is junk. It’s worse than a book in every way, and has no advantages whatsoever. I predict that no one you know will buy one, and that it’ll be discontinued in less than a year.

Android is a full software stack made up of many projects that exist separately from Android. The components of this stack are available under a variety of different terms: Linux is GPL’d; WebKit is LGPL’d; SQLite is in the public domain; FreeType is available via GPL or its own license. There are probably a dozen more little libraries and components that Android builds upon, all of which have licenses that need to be considered. It’s not possible for Google to just put a bow on the whole stack and say it all uses license X.

Google has released the Android SDK, which is the top layer, under the Apache license. According to the OSI list of approved open source licenses, this is an open source license. And yet, the reaction to Android from open source advocates is negative. Why? Well, the concern is that some implementation of Android will add proprietary code and/or remove standard code, fragmenting the platform. Since Google can’t rewrite the licenses of the underlying components of the stack, we’re really talking about fragmentation at the top layer of the stack.

The Apache license allows for parties who download the source code to alter it and then keep the altered source code secret, while distributing a derivative work. Contrast this with the “viral” GNU Public License, which obligates all parties who modify the source to either keep the modified software completely to themselves, or to distribute the source if they distribute a derivative work. Ignoring the case where a licensee simply keeps the derivative work to themselves, the GPL forces a web of innovation and collective advancement, whereas the Apache license encourages a central publishing model, where innovations are kept private and used for competitive gain.

Thus, Android applications designed to be compatible with Google’s platform could be made incompatible with a particular device, by a handset vendor who removes core Android APIs and replaces them with their own closed source alternative. This might seem like a paranoid fantasy of a small clan of open source zealots, but it’s not. This is the same tactic that Apple has successfully used to keep Mac OS X closed. Mac OS X rests upon a large amount of open-source code (some of which is also part of what Android is built upon), while requiring developers to code to Apple’s proprietary Cocoa APIs in order to make Mac apps. You can install Linux on a Mac, but then you lose the ability to run Mac OS X apps. You can build generic Unix applications on a Mac, but they look quite different from a standard Mac app, and lose a lot of Mac-specific functionality. Apple chose to make this possible, but compare this with the iPhone, which uses much of the same software underneath, but (as of this writing) cannot run a generic Unix app because Apple doesn’t want you to do this.

This same sort of situation is possible with Android under this license. Company X grabs the Android sources, dumps a few key APIs (maybe the GUI, network, and process management ones) and suddenly they have their own incompatible platform that can run on the same hardware but can’t share apps with the mainstream. Dump phones on the market (subsidized by monthly fees, as usual) and fund a few key apps (MP3 player, movie player, email/SMS, web browser) and users are stuck with that vendor’s offering, just like they are now. And this is just how telcos and media companies, both of whom are desperately trying to keep hardware and software platforms closed, think. The more closed a platform is, the more secure they feel about their profits, and the more willing they are to invest in it.

The only charitable explanation I can think of for why Google chose this license is the Apple explanation.

If Google were really pandering to the existing mobile carrier crowd, they could simply have released nothing, because another closed platform to build phones with and to write apps for is pointless. There are plenty of existing trunks to be locked in already. We don’t need somebody else to slap together a Linux distro for phones with a closed GUI on it. You can to go LinuxWorld Expo and probably find two dozen companies doing exactly that, and none of them is particularly successful. Google is too smart to add itself to this list of flops. It makes no strategic sense.

More likely, I think, is that Google intends to be Company X in my above scenario, putting themselves in the role of Apple by making an “Android Plus” premium platform that they put on the handsets they’re pushing. In this scenario, you can write your own apps to the reference platform and they’ll run on Google’s favored phone, but Google can still reserve the right to put all sorts of funky stuff on their phones without documenting it or giving developers or users any rights to it, and more importantly, without having to open source their special components so that non-Google devices could use them.

Sure, this is a charitable interpretation. They might just have screwed up royally, buying a company (Android) that wasn’t anything special and releasing something that no one other than journalists will pay attention to. But given that Google is betting $4.6 billion on the 700MHz spectrum auction in the U.S., I’m reluctant to simply write Android off as a “hail mary” acquisition.

There must be a larger strategy here, and I suspect it’s Google putting itself in the shoes of mobile carrier, handset OS maker, and service provider. Somebody else manufactures the handsets, of course, but Google owns and operates the whole experience from end to end other than that. You buy a Google device, pay a monthly Google subscription fee, your bits travel over a Google global network of wireless towers and a wired backbone, and you run apps on your Google phone that interact with Google back-end services. It’s a carbon copy of Apple’s iPhone/iTunes strategy, without AT&T in the picture, and with third party apps allowed on the phone, as long as they work on the already-published Android SDK. All Google has to do is to make a decent looking device and be less customer-hostile than existing U.S. mobile providers, and they’ll do well.

In this light, the partnering talks with existing mobile carriers is puzzling. It’s possible that they’re pitching a strategy that removes the burden of application development from mobile carriers, allowing them to be the billing companies that they really are, and putting Google in the position of being the provider of content and software. The lukewarm responses from these carriers is predictable; for the carriers to be involved as just bandwidth providers and customer billing service providers, there would have to be a careful negotiation of revenue sharing, or else the carriers will simply continue on their current, very lucrative course.

If they are planning to become a carrier themselves, then nothing can actually begin to happen until January, when the 700MHz spectrum auction actually takes place. There’s a closer December 3rd deadline for Google to reveal their plans. At that point we’ll know what they’re up to, assuming they’re actually able to buy the spectrum that would make it possible. Alternatively, this spectrum purchase could be a bargaining chip on Google’s part, which they do not intend to directly utilize themselves. Google would provide the spectrum, the handsets, the OS, the apps, and the services, and the carrier partners would provide the towers, the maintenance staff, sales, and billing.

Given all this, it makes little sense for Google to GPL the Android platform. They need to own it so that they can assure a prospective carrier partner that they will be the ones whose phones are being used by customers, in order to share revenues. If they were to open up the handset market entirely, the carriers would block any new entrants and Android based phones would be doomed.

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.

Eclipse is an IDE so it’s hard to imagine it not being baroque and difficult to use, requiring weeks of effort to become productive. JBidWatcher has saved me a lot of money on eBay so I could probably put a dollar value on how much it’s worth to endure its bizarre UI. Azureus is fairly fugly also but it does a very good job and has a deep, sophisticated UI that’s fairly easy to understand, so despite the eyesore, it’s at least fairly clear. The common thread among all of these is that they are all written in Java, and that they are so valuable that it’s worthwhile to overlook the ugly UIs.

Now imagine those sorts of trade-offs, but on already difficult to use mobile devices, and aimed at consumers. Are you making a strategically wise choice by sacrificing usability and control over the user interface, and probably access to platform-specific features such as dialing the phone, in order to save money on development? Adam Breindel talks about this in When Building a Smartphone App, Resist the Siren Song of J2ME.

Adam and I worked on a J2ME application and I totally agree with him about the disillusionment of trying to write a single app that would work across phones. Issues include:

• Complex and difficult application installation procedures for end-users: How do you install the JVM on the phone? How do you get the plain J2ME app packaged up so that the phone will accept it? Does the app require manual user configuration before use? Is there a different launching process from other apps?
• Lack of control of the user interface: hardware details such as how many buttons you have, whether there’s a stylus, etc. differ from phone to phone, and the API to let you code once and let J2ME handle the layout for each device leaves your code very disconnected from what’s actually happening on the screen.
• Not being able to use recent J2ME APIs because even the latest phones only support older, more minimal J2ME APIs
• Not being able to do things on a phone that would seem obvious, like dialing the phone, opening a hyperlink in the phone’s browser, sending an SMS, or making a network connection. Either these are entirely impossible or require phone-specific or JVM-specific tools and procedures to sign your application, or having the runtime nag the user to request permission to do something that they just asked the app to do for them.

For all the noise Sun is making about broad J2ME penetration, the developer experience is quite disappointing, and as a result, the user experience is also quite disappointing. You can look up J2ME features and APIs and get excited, but when you actually deploy your app to a handset, it won’t load, or runs terribly slowly, or looks awful, or simply doesn’t do the things that the API says will happen when you call it a certain way. Suddenly the strict J2SE and J2EE logo certification programs make sense, because the J2ME approach of making so much functionality specified but optional leaves developers high and dry. The phone supports J2ME version xyz, but write an app coded to that API that works on the emulator and deploy it to a handset and lo and behold, all those optional APIs turn out to be missing even though the handset is capable of that functionality, and some mandatory API functions are not working. Here be dragons.

Case in point: can’t dial the phone on a Treo 650 (at least, not as of a year ago). The J2ME API tells you how to do it. The PalmOS JVM (made by IBM) lets you make the API call, and returns a successful response. Nothing happens. IBM says they’re aware of this issue. The end. The docs say you can, the code you write says you did, the phone just doesn’t do it.

Case in point: Every time you start an application and it accesses the network for the first time on a Treo 650, the user is nagged for permission to access the network. Quit the app and start again, nagged again. IBM has a tool that you can use to sign the app, but you have to use their VisualAge Micro Edition IDE which costs hundreds of dollars to do that. Try and find and download the trial version. A year ago, it was not possible. So, making that persistent nag go away probably costs several hundred dollars. (I never verified that it actually works, just that IBM says the way to sign the app so that it’s trusted is to do that, and that there was no available free way to get that tool.)

These are minor issues, but they certainly interfere with the quick usage pattern of a mobile app, and make it annoying to use your app. Imagine what that would be like if you had a competitor with a native application for that phone, whose application probably cost them more, but their app is better and the user likes it a lot more.

The important distinction here is not cost, it’s ROI. It costs a lot to develop a similar application for each smartphone platform, using that platform’s native tools. It would seem to cost a lot less to develop a J2ME app. But that’s only if you assume that it’s OK to abandon features and settle for a horrid user experience in the course of development.

It’s likely that your goal as a development team is to develop an app that has a predefined feature set that you know the device can support, and a predefined UI design that your mobile-savvy UI people are sure will go over well with users accustomed to that particular kind of smartphone. In that case you will almost certainly fail to accomplish that goal using J2ME. You have to scale back your goal so that you’re satisfied that you got something kinda like what you wanted working on a bunch of phones, and determined users will probably be able to figure out how to install it and make it work.

I call that phenomenon “write once, be disappointed everywhere.”

Let’s continue talking about cost, though. The native apps may require (or suggest) different programming language skills for different devices. It might seem wise to just write everything in C, but I think that’s a false economy as well. The phone APIs will differ so much that you will really need a native developer for each platform, not a team of generic C developers who will figure out the individual phone stuff and be freely floating resources that you can assign to whatever app version needs their attention. Smartphones may run Linux, may run Windows Mobile, may run PalmOS, may run Symbian… these are different operating systems with very different ideas of how applications run and coexist. The platform specific knowledge (APIs, appropriate UI feel, device capabilities) is probably an order of magnitude harder to learn and maintain than the ability to get an application working in a given programming language.

How much of a great C programmer’s skill is really the C language, and how much of it is proficiency with the available libraries on the platform he or she is accustomed to? I think close to 90% of their professional skill set is platform and library familiarity, and 10% syntax and low-level understanding of how the language actually works.

In light of this (just using C doesn’t mean developers or code are portable across smartphones), consider that there are high level languages available for some smartphones. What if that 90% platform familiarity means they can use a language and/or development environment that makes them 5 or 10 times as productive, after spending just a few days or a couple of weeks learning the language syntax?

After our very disappointing J2ME-on-PalmOS port experience, Adam found Handheld Basic which initially appalled me (oh no, BASIC!) but turned out to be a great choice. It’s a flavor of BASIC, so learning the language didn’t take long, and the support happens to be quite good (lots of code samples) so picking up the library portion of that 90% didn’t take long at all. I imagine that C# on Windows Mobile is similar. As more and more phone start to use Linux as their OS (which will be a particularly huge improvement for PalmOS based phones), you’ll be able to use Python, Ruby, Mono, J2SE (a whole different animal from J2ME), TCL, or pretty much any other high level language available for Linux. At LinuxWorld 2006 I saw a development device running unmodified GNOME desktop apps running on a PalmOS device alongside PalmOS apps. There are more options appearing all the time, and with the exception of Handheld Basic, most of them are ports of familiar, mature, well understood desktop languages, with class libraries relevant to mobile devices.

So, I recommend that you work in whatever high level language lets you do all the platform specific stuff you want, and if that means a different language per phone, that’s actually going to be the least expensive way to get to the apps you actually wanted to build. A big chunk of the scary cost of developing native apps goes away, because native doesn’t necessarily mean abandoning Java for C. (In fact I found Handheld Basic to be a more productive environment for me after a couple of weeks than J2ME was, despite my ~8 years of full time Java experience before starting that project.)

That pretty much means no reuse for you. Sorry, but that’s the deal right now.

If that unique-app-per-platform cost is too scary, consider a few ways to save money:

• For networked apps (aren’t they all?) ask yourself if there’s some logic that could just as easily be done on the server as on the client. Is there some complicated parsing code on the client that could be simplified by changing the response format from the server to something that’s easier to parse?
• Can you remove or alter certain features from a subset of platforms you intend to support, so that your premium supported platforms get your ideal app, whereas a few less popular phones still get a nice app, but perhaps one that doesn’t have every feature available on your premium app. You might be reading this and thinking “but that’s what you said J2ME would force me to do! Why is this any better?” The distinction is that you are in control of the decision of what to leave out to save money, whereas with J2ME it’s the platform vendor who makes that decision for everyone using their platform. If you’re writing an address book, not being able to dial the phone is lethal; not writing the code to let the user attach a photo to the entries is not.
• Can you move some user-facing functionality to the server to make the client simpler? Maybe there are some rarely-used features that could be done via a desktop or mobile web browser, so you can focus on putting the ten-times-a-day features on the handset, and making those features fast and convenient. You probably already made that trade-off in general, but perhaps for some kinds of handset, you’ll move the dividing line a little further, so that for users of particularly rare phones, some moderately frequent features can’t be done on the phone. This could also be a good approach for new handset types: design a “lite” app and a “full” app version, build the “lite” app first on each platform, and let user demand tell you whether the full app is worth it. Your developers can tell you much more accurately how much the incremental functionality would cost, since they already have done the lite version. Maybe you’d provide a VoiceXML interface, or mobile web browser interface, for that feature so that the user can still do whatever the feature requires while they’re far from a desktop PC.

A final consideration: labor. Maybe you have some Java developers, or C developers, and don’t have developers good at Handheld Basic or C#, so you’re not inclined to fire them all and hire new developers to do native apps, you’re thinking maybe C on every handset, or J2ME, is still the right choice. I still say that you should probably use native apps in native high level languages on every smartphone platform. If you’re committed to a strategy of good apps on a bunch of different phones, I think I’ve made clear that native apps are the only way to currently get there; J2ME simply doesn’t let you make good apps. So what’s left is C code written by C developers vs. high level code written by C developers who have to retrain.

As I said above, I don’t see much chance that your developers or your code will be portable across different smartphones if you use C. Maybe you’ll get 5-10% savings that way (some code ported across phones, or some developer hours shuffled between platform teams). But you’d get a 5-10x cost saving from using something very modern and high-level instead of C, and the overhead of training for the language would be very very small as compared to the large and unavoidable overhead of having to learn what the handsets can do and how the APIs for the handset’s OS work.

I suppose that means that if you have a bunch of C developers who lack smartphone skills, you’re in a pickle, but that situation seems kind of unlikely to me (a mobile app company hires a bunch of Unix and Win32 C developers with no mobile phone skills?). More likely is that you’d find a mobile developer who is proficient with one or more handset OSs and the best tools for each one, and they may be of the opinion that C is the best choice since they can reuse skills and some code across platforms. I would say that in that case you need to convince them to (or more likely encourage them to do what they were already considering, which is to) go ahead and find a highly productive high level programming language/environment for each smartphone platform.

A final possibility if you have a ton of platforms to target and a pile of killer C programmers is to try and port something like Python across most of your target platforms, or to make a very high-level API or domain-specific language that runs inside your own custom C portability layer. You might be able to find an open source option that you can invest some developer hours in, so that the actual application-specific code that you write on each platform is minimized and portable. But I suspect that this would still be expensive and would result in some J2ME-like UI abstractions that ended up being very unsatisfying in the end.

Best of luck!