[Schmidt] talked about Netbooks… saying the the unit numbers were becoming material and that use cases were “consistent with the cloud computing model” that Google is focusing on with Google Docs, Gmail and other services.

And this isn’t some smokescreen or distractionary tactic; Schmidt’s words are true to Google’s actions. Why do you suppose Chrome is designed to spawn each of its tabs as a separate process on its host OS? [jump to 1:40]

Google sees “cloud computing” (read: Chrome) as the platform for the netbook, not Android.

With the offline storage capabilities coming in HTML5, it seems thatweb browser operating systems are less laughable by the day.

He writes:

The formula behind the iPod Mini was simple: Apple made a smaller, cheaper device with more or less the same technical specs as the original iPod from October 2001.

[...]

So here’s how I see Apple applying its iPod strategy to the iPhone. At some point the iPhone will expand to two form factors:

1. A high-end iPhone with the same basic size and price as previous iPhones, but with significant new features…

2. A new, lower-priced, smaller, and more adorable iPhone, with more or less the same technical specs as the original iPhone. Given that those specs include the 320 × 480 display, I wouldn’t expect something tiny…. Shrink the iPhone’s forehead and chin and make it thinner … is what I’m thinking. Existing iPhone apps would run just fine on the new device, as it’d have similar, if not identical, CPU performance and RAM to previous full-sized iPhones. [emphasis added]

Reading the piece got me thinking back on the concerns I had about Palm’s fragmentation of both their prospective developer communities, as well as consumers, should the rumors of their introducing “Pre Lite” to the market.

Note the points where emphasis has been added. There are two reasons for Apple to aim for roughly the same specs as the first generation iPhone when it introduces additional models:

1. a device with such specs will be significantly cheaper to produce more than two years later, and
2. it helps ensure maximal compatibility of existing apps with the prospective newer members of the product family.

Apple has been very clear that minimal hardware variance is an explicit concern in their iPhone product design strategy (and, even their platform strategy for all devices running iPhone OS, or what I've been calling Touch OS X). Naturally, since the devices in the product family must continue to evolve, it’s impossible to entirely avoid hardware variance, but the more that the devices in the iPhone product family can have in common, the easier a job developers will have creating and testing the apps they make and sell.

By contrast, the Android platform is beginning to get its first dose of non-trivial woes around hardware variation issues, but more on this later.

There are plainly over a billion reasons that Apple would want to maximize the extent to which apps remain compatible across their entire product family of iPhones, and screen size and shape is one of the critical details to keep consistent in the mobile world, where developers (at least the competent ones) take great pains to make every last pixel count.

And for platforms like iPhone OS (and even Pre’s webOS) that are designed so meticulously around the user’s direct physical interaction with the screen, screen size is not a detail to be varied willy nilly.

Android(s)

Android is the finest example of a maturing platform that can lend some insight to the situation. The platform is thoroughly modern, and is in a phase of its life comparable to the iPhone’s. On the one hand, the Android SDK is older than the iPhone’s, but the platform didn’t offer any consumer grade phones until last fall, when T-Mobile’s G1 started shipping.

The platform has seen its release of version 1.5, and a number of new devices running Android are poised to enter the market in the coming months.

Andy McFadden published a post on the Android Developers blog, entitled Backward compatibility for Android applications. As one can infer from the title, the article offers advice to Android developers about how to handle backward compatibility for their apps, and suggests they consider whether or not they will actually even attempt it.

He concludes:

You must test your application on every version of the Android framework that is expected to support it. By definition, the behavior of your application will be different on each. Remember the mantra: if you haven’t tried it, it doesn’t work.

Now, allow me to assure you — with over a decade’s worth of experience in web development — that testing my work across just three browsers has been a colossal pain in the ass.

Understand that I had just linked to the first five arbitrary upcoming Android phones that I discovered as I searched around the Web, and that’s frankly just the tip of the ice berg. The market is expecting dozens of different Android phones (and even netbooks!) to show up in the market in the coming years.

And so I am loathe to imagine the experiences Android developers will endure in their attempts to publish their apps for use on multiple different models.

Repeating: if you haven’t tried it, it doesn’t work.

I am not trying to knock Android, by the way. There are many things that excite me about the goals of the platform, but I think it’s fair to say that — despite Google’s launching the Android Market — these platform’s goals will be a greater boon to device manufacturers than to application publishers.

The manufacturers will realize significant benefits from having a modern operating system and API:

• they are afforded the freedom to further innovate upon and customize themselves, or just use the “vanilla” version on a lower-end device;
• the software platform will continually mature and advance, without them spending a dime on R&D
• the talent pool of skilled developers from which manufacturers can build their product teams will continue to grow

Android developers seeking to earn a living publishing third-party applications for the platform, on the other hand, will be grappling with some very complex decisions regarding which devices they intend to target, since they’ll generally want to ensure their app has the broadest potential customer base (or, at the least, a non-trivial one). This will consequently require them to constantly keep tabs on at least two critical bits of information:

1. how well each phone is selling, and
2. whether owners of the phone model(s) in question are likely to buy apps for their phone, at all.

Apart from the burden of keeping abreast with this information, developers will be stuck making their decisions retrospectively. That is, if app publishers intend to leverage such information to make informed decisions about whether or not to invest in development efforts to target any particular model, they can only do so after there is information to collect.

Forecasting becomes tricky.

Consider the attempt to capitalize on the opportunity to make your app one of the first available on a given new device: do you invest development effort and QA resources on the unproven, or do you wait and see how the phone sells, and who’s buying it?

It isn’t to say, however, that these considerations that are impossible to deal with. Certainly the publishers of third-party applications will develop, over time, a good feel for how to handle such considerations. I can also foresee the rise of products and services that promise to deliver reporting of all relevant stats. Regardless, the mere matter of even having to contend with such complexities certainly does raise a non-trivial barrier of entry for the entrepreneurial indie outfit.

This is especially true for the one-man operations that we have seen thriving in the iPhone application scene.

Intuition tells me that the OSS application scene will fare better on Android than the entrepreneurial independent publishing scene will. This is especially so with respect to achieving broader device compatibility, since OSS efforts will be able to crowdsource their development and testing efforts.

There are — at the time of this writing — 35 for-pay apps available in the Android Market, since Google enabled payment functionality for developers in February.

But, to be fair, Google’s primary motives for putting the Android platform out into the world was to loosen the iron grip the mobile telcos have been maneuvering to exercise over internet access available through their data networks; fostering a healthy entrepreneurial landscape for indie developers was a peripheral concern (if ideal outcome). To be certain, the only way for Google’s goals to be realized is to get as many different manufacturers (and, by extension, devices) on the Android bandwagon as possible, so hardware plurality was always necessarily a leading concern.

Yes, the matter of hardware variety stands to be a dreadful pain for the indie developers, but it’s a key element of the Android strategy.

Palm and WebOS

The idea behind launching a “lite” version of the Pre is to introduce a lower-grade — and, importantly, cheaper — device running on the same WebOS platform as the Pre. This lower grade device will necessarily a have a differing hardware configuration, including a different screen size, according to reports.

If this is true, and Palm carries on with this strategy, they will be lining up a family of products, straight off the starting line.

But you can’t leap into the race in fifth gear.

After reading Gruber’s reflections on how Apple grew the iPod from a single product into a family of products, I’d started thinking about how the efforts of putting together such a family calls for both time and, most of all, planning.

From a business perspective, releasing such a low-tier WebOS phone would be both naïvely ambitious for Palm to take on this family development endeavor so early in the platform’s lifetime, and that such a move will prove a marketing disaster, likely taking the wind out of the Pre’s sails before she even managed to leave port.

From an engineering perspective, Palm seems to be choosing to take on the worst of Android’s worst problems, without any of the contextual details that make hardware diversity a good idea for Android.

But the Pre is a particular product.

Although WebOS can one day emerge as a compelling platform, this can only ever happen if the Pre first succeeds on its own merits as a product. And so Palm will need to play matters closer to the iPhone’s playbook, than to Android’s.

Google has the money and time to invest in developing a grand multi-device platform. They also have partners.

Palm, however, is in a far more precarious situation.

A decision to go to market with a “Pre Lite” within months of the Pre’s introduction would essentially be Palm hedging their bets, on account of the iPhone clearly kicking ass and taking names in the high end.

I’m sympathetic to the fact that it may seem like a good enough idea on the surface, but by chasing both ends of the market from the start, however, Palm would risk overextending themselves and winding up with a watered-down, lowest-common-denominator technology, in a worse place than Mobile Java.

And that would be an awful place to be.

The “Pre Light” is—at the least—something Palm are thinking seriously about; its introduction would naturally move would be an attempt to capture both ends of the market.

But if the Pre is to stand a chance at saving Palm from extinction, they need to put all their product design effort and muscle behind crafting and refining exactly the thing that the Pre is, rather than trying to make the crazy new whizzbang that aims to be all things to all people.

Palm needs to focus their efforts like a laser on the Pre.

They essentially need to enter the arena boldly, charge straight up to Apple, and deliver a swift, mighty blow where it counts—then they can suss out how they’ll manage to land a few more.

The piece kicks off with this gem:

…BusinessWeek asked me about Apple potentially open sourcing the iPhone over a year ago. Since then: nothing out of Apple, despite mounting pressure from projects like Android that are vying for Apple’s throne.

I guess I missed the part where Apple has any incentive or desire to concern itself with a question Business Week asked this guy. Then, I missed the part where Android is applying “mounting pressure” on Apple’s iPhone.

Continuing:

I’m not asking them to completely open source the iPhone. I’m just asking them to crack the door and let the breeze in.

I thought I was about to embark on reading about 5 reasons Apple should Open Source the iPhone.

At this point, and in the absence of any true guidance from the author as to a thesis he might be driving towards, I began to wonder if he knew that the code base for Mobile Safari (WebKit) is Open Source Software. What about DTrace? I mean… these are all Open Source Software components that are in the iPhone.

Open source is becoming the default way to develop software in many industries.

What does that even mean? I’m at a loss for what even constitutes a “default way to develop software.” It’s hard enough to get everyone to agree on whether or not unit testing is a critical part of the software development process, let alone being anywhere near some sort of industries-wide consensus on whether to Open Source all software, or not.

Hurley goes on to say:

More importantly, many folks that aren’t traditional developers are starting to develop apps for platforms like the iPhone. He who satiates that audience wins the war.

Check out the post; it doesn’t carry any additional meaning when it’s experienced in its full context, either.

Choice

William contends that “Customers love choice.” On the surface, that does seem like a sensible assertion; when I’m in the market to purchase a product or service, I always appreciate having at least a handful of options from which to make my ultimate choice.

On the other hand, too much choice can be a hindrance, as it can get difficult to fully grasp all the merits and trade-offs associated with each choice.

So, there’s a balance.

Naturally, the verdict on where anyone’s threshold of “too much choice” gets drawn will depend on the number of options they are being asked to consider.

Hurley continues:

Open sourcing the iPhone gives customers a much broader selection of applications.

Of course we’re back to what exactly Hurley does or doesn’t mean by “open sourcing the iPhone.” Apart from that, he fails to demonstrate that the selection of applications will be any broader; the App Store has a pretty fucking broad selection.

It seems like the next sensible matter to consider is how a more open ecosystem, like Android, compares against the iPhone’s App Store with respect to volume of available apps.

The numbers seem to defy Hurleys predictions.

Though, to be fair — as the update appended to that link mentions — we may see more apps appear in the Android Marketplace once Google makes it possible for software developers to charge money for their apps.

And what about “all those” Openmoko platform apps out there…?

Customers faced with a plethora of attractive applications when they visit the app store will spend money.

Many developers are now worried that the sheer volume of apps available in the App Store has gotten so large that it’s becoming increasingly difficult for developers to get their apps to stand out.

Many are even calling on Apple to devise ways to let the better ones bubble to the top.

And so this may interestingly be where Apple is on the ironic “downside,” beginning to fall victim to its own success, but where — in deliciously layered irony — Hurley remains chasing a hollow argument.

An open source iPhone dulls some of Android’s luster.

And here I was thinking that Android’s luster was being dulled by the inability for developers to be able to rely on:

1. screen size
2. input capabilities
3. availability of various components

Ol’ Steve can level the playing field—he holds sway over a loyal following of diehard developers.

Last time I looked at the playing field, “ol’ Steve” doesn’t have a whole hell of a lot to gain by leveling it.

Linux on the iPhone

Hurley then goes on to argue that if Apple doesn’t open up the iPhone, then someone else will find a way to do it regardless. Why this insight seems particularly riveting to him, I can’t really know.

One might pause to wonder if he’s heard of jailbreaking and rockbox; this happens.

Then, he drops this bomb:

Earth to Apple: if the iPhone had been open sourced, [Linux on the iPhone] probably wouldn’t have happened.

Let’s take a step back. I think we can all agree, at this juncture in history, that if a device has a microprocessor in it, somebody is going to try to get Linux running on it!

So, my alternate-reality wager is that Linux would have been ported to iPhone regardless of whether Apple were more “open” with it or not.

Besides, here we have iPhone Linux and Apple didn’t have to spend a dime on its development. And they won’t be spending any money on supporting it, either.

This is perfect for Apple: nothing to engineer, nothing to QA, and no responsibility to field support calls for it.

If anything, it seems like the teams at Apple have been struggling to keep up with QA issues on their closed and tightly-controlled platform; does anyone really think it makes any sense for Apple to take on the additional resource burden acting on this idea would incur?

The OSS route, however, is finally here.

Now, anyone can install Linux as an alternative OS for their iPhones, and even switch back and forth between iPhone OS; let’s see how many people actually have enough interest to install this.

Perspective & Respect

So, what I want to know is: how many folks with Macs out there are running the Nautilus file manager via X11, instead of dealing with Finder?

Now, I use open source every day.

I’ve been an occasional contributor to a handful of projects (most recently, I’ve submitted a number of patches to plugins for a PHP MVC framework called symfony).

I even published two projects of my own to Sourceforge.

I love, respect, and regularly participate in the phenomenon that is OSS in various capacities, including software development and community support.

That said, I personally can’t bring myself to find any fault with Apple for not having any interest in “open sourcing” the iPhone. At least, not without a compelling economic incentive.

And, let’s face it, all the data points to Apple’s economic model playing out reasonably well, for the time being.

15 Dec: Apple has tweaked the iTunes App Store, in response to some developers’ mounting distress that their for-pay apps were getting buried by the popularity of the free apps, by better showcasing the most popular for-pay apps.