Apple

For all the discussion of the importance of transparency and openness on the Web today, it's very telling that the world's fastest-growing mobile platform may also be the most proprietary.

Apple wins rave reviews (including from me) on its technology but certainly not for its commitment to sharing its innovations with the world...unless, of course, you fork over $299 and sign a two-year mobile service commitment.

Indeed, Apple has earned the dubious honor of being more closed than Microsoft.

And yet, as Marc Hedlund reveals over on the O'Reilly Radar, application growth for the iPhone dwarfs that of the former leader in the smartphone category, PalmOS:

iPhone OS app growth vs. PalmOS app growth

(Credit: Marc Hedlund)

If openness matters so much, why is Apple doing so well with its uber-proprietary iPhone, just as Microsoft dominates the desktop with proprietary Windows?

There are at least two answers. One is that while Apple's iPhone (like Microsoft's Windows) isn't open in the open-source sense, it is open in the sense that it's easy to create applications that run on it. The second reason is that there's a huge financial incentive to do so, given the momentum behind the platform.

For some, these reasons aren't good enough, such as Mozilla Chair Mitchell Baker:

Many of us participate in closed systems where the rules are set for us and we don't see them, certainly can't change them, and aren't permitted to "participate" in building the rules. This is true of very popular web services. For example, I "participate" in Flickr and Facebook, but within the system and rules that those organizations set up to meet their own goals. That's fine; there's no reason for those sites to change.

Mozilla is trying to build a layer of the Internet that's different, where "participation" extends to the very core of what we build.

With 40 percent of Mozilla's Firefox written by outside contributors, it's clear that an open platform works for Mozilla to build a better browser, which is why Mozilla continues to improve the ways in which developers can contribute to it. But it's equally clear that there are other ways to be "open to participation," ways that pay the rent for Apple, Microsoft, and huge ecosystems of commercial partners.

Is one platform approach better than another?

While it's clear that the world has room for both proprietary-but-open-enough and pureplay-open approaches to platform building, I favor the more open approach. The reason is that eventually, it appears proprietary approaches can collapse under their own weight.

Take Windows, for example. To maintain its growth, Microsoft has had to include more and more functionality in the operating system, stepping on the toes (or outright devouring the toes) of its erstwhile partners. (Interestingly, while discussing whether openness matters for Apple over Google Android, Slate describes Microsoft's Windows approach as open.)

Eventually, Windows grew to such heft that the market, including Microsoft partners, started looking for open alternatives, causing then Microsoft chairman Bill Gates to dub Linux Microsoft's "most potent operating system competitor." The "good enough" operating system that performed certain tasks much more efficiently and powerfully than Windows has now grown to seriously threaten Microsoft in a range of applications and markets.

Eventually, even Microsoft's desktop dominance may be threatened by Linux as new classes of easy-to-use, cost-effective devices like Netbooks arise.

Back to Apple. Today, Apple's iPhone seems set to rule the world because it enables a huge community of application developers to reach a paying audience. Tomorrow, however, Google (Android/Linux), Nokia (Symbian, Linux), Palm (WebOS/Linux), and even Microsoft (Windows Mobile) threaten its cozy corralling of the mobile market.

Microsoft has made it clear that it's possible to build a massive business with an "open enough" approach to platform development. The question is, can Microsoft (and Apple) maintain that without truly opening up?

Follow me on Twitter @mjasay.

Updated 8:53 p.m. with download links and further details and 9:47 p.m. with hands-on testing results.

Google released Chrome for Mac OS X and Linux Thursday--but only in rough developer preview versions that the company warns are works in progress.

"In order to get more feedback from developers, we have early developer channel versions of Google Chrome for Mac OS X and Linux, but whatever you do, please DON'T DOWNLOAD THEM," Google product managers Mike Smith and Karen Grunberg said in a blog post, evidently trying to employ a little reverse psychology. "Unless of course you are a developer or take great pleasure in incomplete, unpredictable, and potentially crashing software."

Until now, Google's open-source browser has been a Windows-only product, and some Mac and Linux users have been clamoring for their own version. Google coders have been working to rebuild some Chrome components, such as its graphical interface and its sandbox that isolates different processes from each other, to move beyond just Windows.

Google offers three versions of Chrome: stable, beta, and developer preview. The Mac OS X and Linux versions fall into this last, category, the most buggy and least tested and complete.

Chrome for Mac OS X sports the same new-tab interface as the Windows version. (Click to enlarge.)

(Credit: Screenshot by Stephen Shankland/CNET)

The Flash plug-in won't work, for example, so forget watching YouTube videos. Printing or bookmark management aren't implemented yet. And privacy controls aren't fully baked. Google said there are more than 400 bugs that need to be stomped.

Even though only released for the experimental crowd, the new versions are a big step forward for the browser. First, the versions will plug into Google's auto-update service that automatically downloads new versions. Second, the products bear the Google Chrome brand, not just the Chromium label of the only incarnations available until now. And third, a much larger audience will be helping Google debug the code through automated crash reports of the new versions.

Not everyone can try the Mac and Linux versions, though. Google spokesman Eitan Bencuya said the Linux version is supported only the Debian and Ubuntu incarnations of Linux, and the Mac OS X version only works on Intel-based Macs.

I gave the Mac OS X version a 40-minute whirl and was delighted to find one of my favorite Windows features--fast launch. Pages loaded reasonably quickly, too, though a few times the browser seemed to hang while loading one.

Chrome has edged up to 1.8 percent of the browser market--small but good enough for fourth place.

(Credit: Net Applications)

The only pages that didn't work for me were Yahoo Mail, which told me I had an unsupported browser, and those that required Flash. But a number of complicated JavaScript-based sites, including Gmail, Flickr Organizr, and Google Docs, had no troubles.

The animation around the tabs is pleasing, but also helps your mind grasp what's going on. A new tab rises up from the window frame. When you close a tab, the adjacent ones slide over to fill the gap. The active tab is lighter, though the other tabs are not as relatively dark as in an earlier build that I tried.

I experienced what I thought was one crash I feared brought down my machine, but after about 15 seconds the browser and machine became responsive again as if nothing had happened.

I was pleased to see the three-finger left or right swipe work to page backward and forward. However, some keyboard shortcuts were flaky--or perhaps I just have to learn new ones.

Google isn't saying when the new versions will make it to beta status, much less stable. "It's unclear. This is a first step," Bencuya said.

After years of near-dormancy when Microsoft's Internet Explorer ruled the roost, the browser world again is on fire, fueled by competition and a new generation of more interactive Web applications. Mozilla is on the cusp of releasing Firefox 3.5, as is Apple with Safari 4 for both Windows and Mac OS X. Opera 10 is in beta, and even battleship Microsoft is slowly starting to speed up with the weeks-old Internet Explorer 8.

The Mac OS X version, 3.0.182.5, is close to the latest Windows developer preview, 3.0.183.1.

(Credit: Screenshot by Stephen Shankland/CNET)

According to Net Applications statistics, Internet Explorer remains the king of the heap, with 65.5 percent market share in May 2009. Firefox has 22.5 percent, Safari 8.4, and Chrome has edged up to 1.8 percent since its launch in September.

All this variety means Web developers have to test their sites to make sure they work with more versions. Because Chrome uses the WebKit engine for interpreting and displaying Web page coding, the same engine Safari uses, Google argues that Chrome should be similar. But Chrome uses a different engine for JavaScript called V8, and Web-based JavaScript instructions are at the heart of much of the present proliferation of elaborate Web pages and applications.

The browser challengers argue that having multiple browsers on the market means that Web programmers will aim more for supporting standards such as HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), and JavaScript. And indeed, Microsoft made a standards mode the default for IE 8. However, varying interpretations of standard and varying degrees of support complicate the matter, and a large number of people haven't upgraded from IE 6, much less IE 7.

Google is coming a bit closer to releasing a working version of its Chrome browser for Mac.

Programmers for the company had been building an engine that could render Web pages, but it only ran within a simple framework called the test shell. Now they've begun hooking up the renderer to a full-fledged browser, which among other things can handle multiple tasks at the same time. That's key for a real application, especially one such as Chrome that isolates each browser tab into its own computing process.

The result of the work: a screenshot of Chrome running on Mac OS X posted to the Chromium developer mailing list. "Now we can call it Chrome!" crowed programmer Avi Drissman wrote.

Granted, it's a view of Chrome failing to properly show a Web page, but it's a step in the functional direction. Google has set a deadline of shipping Chrome for the Mac and Linux by end of June.

It may not look good, but this screenshot actually marks progress in getting Chrome to run on the Mac. (Click to enlarge.)

(Credit: Avi Drissman/Google)

Moving Chrome from its initial incarnation as a Windows application to Mac OS X and Linux hasn't been easy. Ben Goodger, a Firefox programmer who now leads Chrome's interface work, griped about the difficult balance between preserving Chrome software across multiple operating systems while coping with the different abilities of each.

Google chose to split some of the Chrome interface into a Mac OS X-specific incarnation, despite the maintenance difficulties that imposes, but the choice isn't as easy when wrestling with Linux's interface, he said in a January message.

Goodger said that after some teeth-gnashing, Google eventually decided to create the Linux version of Chrome using the GTK package of graphical interface components used with the GNOME user interface.

"My initial thought was that a Windows-clone would be acceptable on Linux provided the performance of the app itself was outstanding, given the general reluctance of some of the team working on Linux towards UI (user interface). But they stood up and made their case for a GTK UI," Goodger said in a February 4 message, "and...that's what we've decided to do."

Google has released an open-source software project called Update Engine that programmers can use to keep their Mac OS X software up to date.

"Update Engine can update all the usual suspects, like Cocoa apps, preference panes, and screensavers. But it can also update oddballs like arbitrary files, and even things that require root--like kernel extensions. On top of that, it can update multiple products as easily as it can update one," Greg Miller, a programmer on the update engine team, said in a blog posting Monday.

The Update Engine project is hosted at Google's open-source site.

As a wise man once noted, the waiting is the hardest part.

It's been nearly six months since Google sent ripples through the mobile phone industry with the announcement of its plans to develop Android, a Linux-based operating system. But after an initial splash, Google has been pretty quiet. So much so, in fact, that several representatives of companies within Google's Open Handset Alliance professed frustration at the ambiguity of some important details at the CTIA 2008 conference this week in Las Vegas.

Much is still up in the air, just a few months before the first phones are expected to arrive. Google has yet to make crucial decisions about the code base that will accompany Android; such as, which applications are required to make it an Android phone? How will that base be maintained into the future? And how much freedom will Android developers and partners really have to tweak the software?

Google is aiming high with Android. "Android has two goals: First, to be an excellent mobile platform on its merits, and second, to be open and open source," wrote Dan Morill, a Google engineer, on the Android Internals discussion board last week. But in this new world of advanced mobile computing, those goals can conflict.

The details of how Google chooses to release Android will make a huge impact on how it is received by the world. And Rich Miner knows it. Miner is in charge of Google's wireless business and along with Andy Rubin co-founded the original Android. He is presiding over a huge development project within Google, as the company works to develop a brand-new mobile operating system using the Linux kernel, code contributed by OHA members and internally developed code.

Much of the reason for Google's low profile since the November Android announcement is that the company wants to make sure it has everything nailed down before moving forward, Miner said in an interview this week. To date, it has released a software development kit, and is encouraging Android development with cash prizes.

Which applications will be included with Android, Google's first mobile operating system?

(Credit: Open Handset Alliance)

As of now, Google and its OHA partners have agreed on a basic set of parameters for Android, such as the screen resolution to be used and how the software will support various keypad styles like the classic 12-button phone or the BlackBerry-like QWERTY keyboard.

Beyond that, things are still very much in flux, although Miner points out that protracted debate is necessary to make sure all members of the OHA are happy with the final implementation.

"We've all lived through Java and similar initiatives where we've witnessed fragmentation, and it's a major goal to make sure we don't repeat mistakes we all have scars from in the past," Miner said.

Indeed, the need to avoid "fragmentation" came up multiple times in a 30-minute discussion with Miner. Carriers, handset makers, and chip developers clearly want a Linux-based mobile operating system that's pleasing to the eye and allows developers to build applications that can run across different phones. However, Android isn't the first attempt at this idea; it's more like the fifth.

The reason that many others have fallen aside is because a common platform was taken in dozens of different, incompatible directions. Miner was reminded of Sun, who used to hope that Java would be a "write once, run anywhere" tool that lets any application written for Java run on any device. Instead, different companies chose to implement Java in different ways, defeating some of the purpose.

Google, smartly, wants to avoid that. But avoiding fragmentation requires rules and regulations that might not seem so open.

"Open" is relative
For example, what basic applications will handset makers be required to include to call it an Android phone? "(We'll do) what worked well in the early days of PC cloning, we'll all pick a subset of applications that are good challenging applications" as requirements for shipping an Android phone, Miner said. But, the final decisions have not been made on which applications will make the cut.

Different handset makers, carriers, and chipmakers have different ideas about how Android phones should look, feel, and work. Everyone wants something that's easy to implement, but that lets them develop their own identity. Few companies in this industry really wants to be another HP/Dell/Acer clone maker, beholden to Google for incremental advances in features, capabilities, and presentation.

That's part of the reason why Android's open-source plans have attracted attention. AT&T, previously an Android holdout, is now showing signs that it might be interested in Android because the carrier can tweak Android to favor its services, according to AT&T Wireless President Ralph de la Vega.

It's not clear exactly how AT&T might do that, but his comments raise some questions. If, say, a music player running on an Android AT&T phone can only access AT&T's cellular network, or an AT&T-only music service, that application might not work with a Sprint phone.

So, might Google then decide to include a standard media player with Android that prohibits that kind of exclusion? In a way, that's open, since it's preventing AT&T from using its position as the largest carrier in the U.S. from locking developers into its network. But in another way, it's not open, since Google would be placing limits on what its partners could do with Android.

There are other questions about the level of Google's participation in the open-source community. The company will release Android under the Apache 2.0 software license after the first phone is released to the public, Miner said.

Google will open-source just about all of Android's components under the Apache 2.0 license.

(Credit: Open Handset Alliance)

That means that Google-developed pieces, like its Dalvik virtual machine, will be free for use by any developer. But Google has also made changes to dozens of existing open-source projects.

And all of those changes might not be appropriate for those projects, creating "forks" that Google will have to maintain. In the same discussion thread, Jean-Baptiste Queru, another Google engineer, acknowledges that a lot of the pieces of Android might not be useful for the rest of the community.

"I fully expect some of our changes to be fundamentally specific to Android, and fully expect that we will decide that we prefer Android to have those changes while the code maintainers upstream would rather not have those changes in their code," Queru wrote. This isn't unusual, but it will be harder for Google to create a vibrant open-source community around Android if developers aren't interested in Google's code.

Google also seems to be leaving the exact details of its open-source strategy until later, which is a bit unusual. "Our plan is that once we reach version 1.0, we will turn our attention to the squishier issues of releasing source," Morill wrote.

It's getting close to crunch time for Google's Android. To borrow a sports analogy, they're in the third quarter; plenty of time left, but it's time to develop a sense of urgency and figure out a plan for the current situation.

Google wants Android to be an open-source project so that it can marshall the open-source community's ideas and let its partners put their own stamp on the software. But it must also prevent Android from turning into a "25 operating systems for 25 carriers" mess of incompatible fiefdoms that defeats the very purpose behind Android's creation.

Its trump card might be that Android, and the Open Handset Alliance, are not the U.N.

This is not a democratic process; Google is the final authority on anything discussed within the OHA, Miner said. "That's the difference between a standards body and an engineering team."

After all, it's Google first mobile operating system. You always remember your first one.