There have been a few attempts over the years to take a more revolutionary approach to pushing the web forward. Google's Dart, Microsoft's TypeScript are some examples of these. While these have been interesting to skim, I have never followed them too closely because they lacked the kind of support they would need to succeed. JavaScript alternatives can compile to JavaScript, but without being built into the browser, they were never going to replace JavaScript.

Yesterday, news of the Web Assembly initiative broke:

• TechCrunch: Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web
• Ars Technica: The Web is getting its bytecode: WebAssembly

It's far too early to decide whether or not this will work out, there's very little detail to go on at this point. However, I was pleased to see that the group of companies putting some support behind it seems to be the right group. If Apple, Mozilla, Microsoft and Google all put their weight behind an initiative to improve the web, there's a much better chance of it succeeding than if one, or none of them does.

Now, "weight" is a subjective term, and it wouldn't be hard to imagine one or all of these companies not putting enough force behind this to make it a success. But if they really do all commit significant resources to this kind of effort, there's a real chance that this could be a moment in the history of the web that we look back on as a turning point.

It's still too early to have much of an opinion, but I'm interested to see where this goes.

Apple has just released a new piece of software for creating ebooks for the iBookstore called iBooks Author, and the end-user license agreement attached to it has come with a fair amount of controversy.

TL; DR
Apple wants to encourage people to build ebooks for the iBookstore, and has built a tool that supports that. This tool isn't for everyone. If you want to build free books for the iPad or sell commercial books on the iBookstore and you're not planning on targeting other markets, this is probably one of the simplest ways to get up and running. If you want to support multiple devices and multiple markets and you don't want to do a lot of iPad specific layout work, this tool probably isn't for you.

What It Says
The End-User License Agreement says:

IMPORTANT NOTE:
If you charge a fee for any book or other work you generate using this software (a “Work”), you may only sell or distribute such Work through Apple (e.g., through the iBookstore) and such distribution will be subject to a separate agreement with Apple.

And:

B. Distribution of your Work. As a condition of this License and provided you are in compliance with its terms, your Work may be distributed as follows:
(i) if your Work is provided for free (at no charge), you may distribute the Work by any available means;
(ii) if your Work is provided for a fee (including as part of any subscription-based product or service), you may only distribute the Work through Apple and such distribution is subject to the following limitations and conditions: (a) you will be required to enter into a separate written agreement with Apple (or an Apple affiliate or subsidiary) before any commercial distribution of your Work may take place; and (b) Apple may determine for any reason and in its sole discretion not to select your Work for distribution.

What That Means
If you build an ebook using iBooks Author, you can only sell it through the iBookstore and you'll have to give Apple a cut. If you are giving it away, these restrictions don't seem to be important.  (I'm not a lawyer; don't consider this informed legal advice.)

What It Doesn't Mean
Apple doesn't own your content. You can make an ebook using iBooks Author and through other means, sell the iBooks Author version on the iBookstore and sell the other versions through other stores. Your content is your own, and Apple doesn't own it.

Why Did Apple Do It This Way?
Apple wants people to build ebooks for the iBookstore. They want to remove the barriers to making that happen by providing a free (reduce the cost barrier) tool that is pretty easy to use (reduce the learning curve barrier) to encourage authors and publishers to get onboard.

They don't want you taking their free tool and making money for Amazon, Kobo, Barnes & Noble and Sony by selling your books in their bookstore. If there are barriers to entry in those book stores, Apple doesn't care to solve those. Paul Carr suggests that the restriction may eventually be dropped after Apple has achieved critical mass with iBooks.

Apple may also want to control both authoring tools and the reader application so that they have the opportunity to innovate further on the nature of ebooks, either within a standards-based file format or with proprietary formats yet to come. By building tools for both writing and reading, Apple can lead the way to new features and interactivity for ebooks in a way that would be much harder to do if they were relying on third-parties to build authoring tools for their readers.

There are other business models Apple could have chosen, and authors and publishers also have the choice to use other software for creating e-books. These are all valid choices, and if you don't like the offering that Apple's making then by all means, I encourage you to consider the alternatives.

Why Do People Care?
I think there's a few reasons why people care about this, and why the end-user license agreement has created some controversy.

Some just don't like having their freedom restricted. Once they have software, free or otherwise, they don't want to be told what they can do with it. If they make an ebook with iBooks Author, they want the freedom to be able to sell it on other stores. Dan Wineman makes a case for this argument, calling it Unprecedented Audacity, suggesting that it would be like Microsoft restricting how you can use the documents you create with Word. For these people, it doesn't really matter whether or not using iBooks Author to make a Kindle book really makes any sense -- they just don't like Apple telling them what they can do. I understand this argument, but I believe that Apple providing a no-cost tool with limitations on freedom may be a reasonable tradeoff for some.

Ed Bott's biggest concern seems to be that authors might put a lot of work into an ebook for the iBooks store and that Apple might then reject it, and all that work will be for naught. That's a valid concern, although I'd stop short of calling it "mind-bogglingly greedy and evil". This is the same concern that a software developer faces when developing an app for iOS. In order to allay those concerns, Apple should do their best to establish clear guidelines about possible rejections and to do their best not to make capricious rejections -- the same advice I'd give to Apple about app store reviews.

Some are concerned that these limitations are hidden in the EULA that not everyone is going to read thoroughly. This is the argument I have the most sympathy for, although there is also a warning in the export dialog as well. I can imagine someone putting effort into iBooks Author without realizing the limitations, and that's disappointing. That said, with the current controversy, I would hope that someone interested in iBooks Author would be likely to hear about the limitations of the EULA through whatever news source(s) they consume.

Some just like the look of iBooks Author and wish they could use it in some other way, like to create books for multiple stores. They wish Apple had a different goal with this tool. I understand that sounds appealing, but I also understand that's not really what Apple wants to do here. This is a market that someone like Adobe should be addressing directly. Apple sells a tablet used for reading ebooks and operates a market to sell ebooks, so they'd be in a deep conflict of interest if they had the leading ebook authoring tool for other markets and devices.

Others are (probably) misreading the end-user licence agreement. They believe that Apple is trying to take ownership of the content. I don't believe this is true, even though I'm not a lawyer. Most other people seem to be reading this the same way as I am.

There's no shortage of discussion, if you're interested in reading more (Hacker News, Google Search).

Alternatives Business Models for Apple
There are other approaches Apple could have taken, of course. They could have built a general-purpose eBook authoring tool that would allow people to build ePub documents they could use anywhere. They could have made it the best tool for the iBookstore but not added any other restrictions. If they'd gone that route, they would presumably charge money for the authoring tool. This isn't a terrible path, but it doesn't play to Apple's strengths. It doesn't necessarily encourage more content for the iBookstore, and it potentially puts Apple into the position of their customers wanting them to add features to support things that are only useful in other stores.

They could also have worked with someone like Adobe to build a general purpose tool that works well with the iBookstore. Apple has had issues with this path in the past, and very likely does not want to rely on a third-party to produce a tool that they feel is critical to their platform's adoption.

Alternative Software for Authors
There are lots of ways to create ebooks, and lots of tools that can help you do so.

Apple's iBooks Author is compelling in that it's an easy-to use tool that helps you get from nowhere to a published ebook with rich interactions all in one graphical tool that even authors with limited technical expertise can probably master. But iBooks Author also has limitations on pricing, on where you can sell the book, on what devices you can target. Those limitations mean that iBooks Author is not going to be the right tool for everyone.

Matt Gemmell suggests that after looking at the alternatives, he feels like pandoc is probably the right choice for him. If you're considering authoring an ebook, I encourage you to decide what's the right tool for you. If the right tool is Apple's new iBooks Author, so be it. If you'd rather use bookbin, InDesign, Pages, pandoc, scrivener, sigil or countless other tools to make your ebooks, those are also entirely reasonable choices.

What About the iPhone?
Incidentally, I'm more surprised that iBooks Author only targets the iPad than that it restricts sales to the iBookstore. Apple has built a tool for ebooks and left the iPhone out in the cold. The iPad is definitely a better reading experience, but the iPhone is omnipresent, and I often find myself reading more on the phone than I expected.

Making rich content with complex layout accessible to devices with different screen sizes is obviously tricky, and I imagine this is why Apple has chosen to start with something simpler, but I wonder if we'll ever see a version of iBooks author that addresses this and gives you tools to build ebooks that you can use as readily on the iPhone and the Mac as the iPad.

Dave Winer suggests that using iOS has a flip side -- Apple controlling mobile through the App Store:

Right now it's the only open source mobile OS that has a chance against IOS. If there is no alternative to IOS then Apple will have exclusive control over what makes it to market. That is a future none of us should want to live in.  

...

I don't like Google any more than I like Apple. But at least they don't control the channel of apps to users of Android. That's a huge deal. It makes up for a lot of Android's inadequacies. And if Google fucks us, let's find another home.

John Gruber points out that you could argue the Flip Side to Android is your loss of privacy to Google:

But, to quote Neil McCauley, there is a flip side to that coin. Winer’s perspective is that Apple is the bigger threat. A different perspective would be that Google is the bigger threat, and that using Apple products is a way to better protect our privacy and personal information. 

Fear of Apple is about losing control over the software on our computers. Fear of Google is about losing control over our privacy.

These are both good arguments.  Apple's control over the App Store has some positive effects, but it's clear that it puts a lot of power in Apple's hands and they can and will make capricious decisions that we may disagree with.

Google absolutely wants to know as much about you as it can and sell you in aggregate form to advertisers. That's their business, and if you don't like that, then storing most of your personal information on Google's services is probably scary.

I think it's a mistake to link Android only to Google. As has become entirely clear, the open-ness of Android is to be open to the manufacturers and carriers who often close it with respect to its customers. Putting your faith in Android is not merely to trust Google, but to trust Motorola, HTC, Samsung, etc. and Verizon, AT&T, Telus, Rogers, Sprint, T-Mobile, Orange, etc.

Pre-iPhone mobile phones were entirely controlled by the manufacturers and carriers. The iPhone was in many respect a great liberation the mobile phone market. Although Apple retains the same powers that the manufacturers and carriers once did, they attempt and mostly succeed to use those powers to improve your experience as a mobile customer (and secondarily to profit from it), and they keep everyone else's hands outside of the cookie jar.

Putting your faith in Android is putting your faith in the mobile phone ecosystem that kept a stranglehold on your phone for years and years before Apple came along. If you think those people are more trustworthy than Apple, you're probably drinking the Open kool-aid.

If Google used its Android powers to force the carriers to make the software open to their customers, to allow people to install whatever they want without worrying about carrier agreements, to prevent spyware installed by carriers, to encourage phone manufacturers to update to the latest version of Android -- if Google was open to customers then maybe I'd agree.

For me, Dave Winer's argument doesn't hold water. I don't see the value in wresting control away from Apple just to hand the power to a larger and shadier group of companies.

Apple’s iCloud promises to keep your devices in sync so that you can use your Mac, iPhone, iPad, PC and iPod Touch without worrying about synchronization issues. No matter how that’s implemented, it’s going to be a big step up from synchronizing everything through iTunes over USB. But I’d like to know more.

What’s Been Said and Written

During the WWDC Keynote, Jobs said “the truth is in the cloud.” This could mean a lot of things, but people have been attempting to interpret it.

John Gruber paraphrases:

The gist is that Apple considers syncing to mean peer-to-peer — something where every device is on equal footing. With iCloud, there is one official data store: iCloud’s. As Jobs put it on stage, iCloud’s data is “the truth”. This means no conflicts or merging.

I don’t yet know how iCloud will work, and I can’t read John Gruber’s mind, so I don’t really know what he meant by what he said. The only way I can see iCloud avoiding conflicts and merges is if you can only modify shared data when you’re directly connected to iCloud. As soon as you allow for the possibility that you can make a change on a device that isn’t performed in lockstep with iCloud, you step back into the world of conflicts and merging.

There may be iCloud API documentation that covers this in detail, or WWDC sessions that expounded on the subject. I don’t know. I wasn’t at WWDC and I’m not a paid member of either of Apple’s developer programs[1].

iCloud-Only Changes

One possibility is that Apple will not allow you to change data that is stored in iCloud unless you’re directly connected to iCloud. For instance, if I wanted to change a Calendar event on my iPad, and I were connected to iCloud, I could make the changes. The changes would be stored in iCloud, and be broadcast to all iCloud-connected devices.

For instance, if I had an iPhone, iPad and Mac, all connected to the cloud, they might all start with the same piece of data (e.g. a calendar event), which I’ve marked with a '1’. The phone could request a change (’2’), which would be stored in iCloud and broadcast to the devices:



If I were to try and make a simultaneous change on another device, the broadcast from iCloud could simply overwrite it, or it could ask the user to make a decision.

This approach is technically possible, but not terribly likely. This would imply that if you have a laptop or an iPad without 3G service and you’re not currently on a network, you cannot make changes to your calendar or anything else stored in iCloud. That’s too limiting to make sense.

Offline Changes

If Apple is going to allow users to make offline changes — changes that can’t be immediately verified and stored in iCloud — then it seems like they also need to deal with conflicts and merges.

If you can make offline changes, and “iCloud’s data is 'the truth’”, then as soon as you reconnect to iCloud, your device will see that iCloud’s data is different than the data stored in your device and immediately overwrite it with the older version from iCloud. That’s actively worse than iCloud-only changes, because you can make all the changes you want when you’re not connected to iCloud, but they’ll all be lost:



If you make a change on a single device while offline, when you come back online, the changes could be pushed to iCloud and broadcast to all other devices connected to iCloud without having any conflicts or merges.

Similarly, if a change is saved to iCloud from one device while another device is offline, when that second device reconnects, the changes from iCloud can be broadcast to it without any conflicts or merges.

However, if two devices make a change to the same piece of data while one or both of them is offline with respect to iCloud, then things get more complicated. Either you have two unrelated changes to a single piece of data (for instance, you change the location of an event on one device and the date of the event on another device), which we’ll call a 'merge’ or you have you have two changes that disagree with each other, a 'conflict’.



Merging without conflicts is usually not too troublesome, but as soon as you have two conflicting changes, you must either make some hard decisions about which version of these changes from two devices is the 'best’ (for instance, the most recently-recorded change) or you must break the seamless user experience and ask the user which change is the best. The former will likely lead to you making the wrong decision now and again, whereas the latter is very hard to do in a way that’s not confusing to all but the most technical of users.

Saying that 'the Cloud is the truth’ doesn’t measurably change any of that complexity.

It Just Works

What you could argue is that while merges and conflict are unavoidable[2] and have the potential to be both complicated and confusing[3], Apple could conceal most if not all of that from the end user and even the developer who’s using the iCloud APIs.

Apple likes to build complex systems that offer a simple and clean user experience, so this makes some sense to me. Not only does this sound like an approach Apple might take, it sounds a lot like the approach they already take with Sync Services, as Weldon Dodd wrote for GigaOM.

Sticking with our Calendar Event example, if you make changes to your calendar event in one or more devices, some of which may have been offline at the time, either simultaneously or at different times in the day, iCloud will decide for itself which version represents the truth and present that information to any iCloud connected device. It’s possible that neither the user nor the developer will have any say in the matter. If what you end up seeing matches what you think is the right final value — and most of the time you probably will — then you’ll believe that it “just works.” As MG Siegler put it for TechCruch:

With iCloud, Apple is transforming the cloud from an almost tangible place that you visit to find your stuff, to a place that only exists in the background. It’s never seen. You never interact with it, your apps do — and you never realize it. It’s magic.

If this is the case, then the means by which conflicts are reconciled and merges are performed may remain a black box, even to well-informed iOS and OS X developers. And if Apple’s done a sufficiently good job, no-one will ever mind.

It looks like Apple has relaxed some of the more controversial purchasing rules for iOS applications, in particular:

Apple rumors are getting out of hand. It's bad enough that everyone has an opinion about products that Apple hasn't yet announced, but when these rumors start to get two generations out, it's ludicrous.

@gruber highlights @counternotions on "Why Weren't Samsung and Apple Able to Settle?":

The other possibility, of course, is that Apple never even contacted Samsung before filing the suit.

That would have been my assumption. Apple doesn't want a conversation, doesn't want a settlement, here. They probably want something more like this:

• Samsung to stop making phones that are so derivative of iPhone.
• All handset makers, Android or otherwise, to be afraid of mimicking the best parts of the iPhone design.
• To damage the momentum of Android by encouraging handset manufacturers to see it as a potential liability.

I don't have any contacts at Apple or Best Buy. I don't know anything about their politics or what, if anything, is happening between them today and yesterday. But it does seem a little odd to me that TUAW can post the following two news articles, almost in sequence, and not think about drawing a connection:

Is Android “Open”? What does that mean? Is that changing? Does it really matter if Android is Open?

It's hard to open a web browser or twitter client these days without running into one or more of these questions, so I'm going to take a deeper dive into Android and Open and see if we can give some meaningful answers to any of these questions.

Is Android Open?

Google Says Android is Open

Android is an open-source project, and right from the beginning, Google positioned it as “the first truly open and comprehensive platform for mobile devices”, “without the proprietary obstacles that have hindered mobile innovation.” Google continues to position itself as open, such as the keynote address of their most recent developer conference, Google I/O 2010: “So if you believe in openness, if you believe in choice, if you believe in innovation from everyone, then welcome to Android.”

What does Open mean for Android?

“Open” is a difficult-to-define concept. It means a lot of different things to a lot of different people, and in any conversation about Open, you can probably guarantee you'll find two people using a different definition and arguing about it. So whenever you're having a conversation about 'Open', it's vital to make sure that there's a definition involved.

Unfortunately, for Android, there's really no such definition. There's no clear, concise and consistent definition of what Google means when it says Android is open. This is bound to cause some confusion, and it has, repeatedly. If you look over all the ways Google has used the word and how they've behaved, it mostly seems to come down to a few things.

Android is an open-source project. You can go to the android web page, download the source, build it, and you've got your very own copy of Android. The license allows you to make changes to that code, allowing you to customize Android for your own needs.

If you're a manufacturer or a carrier, this means you can start with stock android, then customize it for your needs and the needs of your customers, the carriers. You can add a look-and-feel that makes your phone look a little less like the phone made by another manufacturer. You can provide software add-ons specific to a particular carrier or partners of that carrier.

Of course, if you're not a manufacturer and a carrier it gets a little more complicated. You can of course still get the Android source code, but what are you going to do with it? Just having access to the source doesn't mean that Joe User has any hope of tweaking their handset through access to the code.

Finally, Android is typically pretty open to controlled user customization. Google doesn't assume that they know how your phone should work, they allow you widgets and themes, alternate keyboards, and all sorts of customizations that Apple's iPhone does not. This is still pretty limited in its effect, but if Apple's defaults don't work for you, this might be something of real significance to you.

What doesn't Open mean for Android?

Because open means so many different things to so many different people, it's nearly impossible to enumerate all the ways in which someone might not consider Android open, but there are definitely a few limitations that Google has made clear or that have become evident over the course of Android's history.

Carriers and Manufacturers can customize the experience in ways the customer can't change. If a carrier wants a particular application added to your phone in such a way that it cannot be removed, that's something that Android allows them to do. Android is open to the customization of the carriers and manufacturers even if that runs counter to the desires of a given customer, or even customers in aggregate. Wired Magazine says, “In other words, while you might be able to copy and paste the code from Rubins' tweet and take a look at Android yourself, what arrives with actual phone is every bit as tightly controlled as iOS.” TechCrunch's “Android is as Open as the Clenched Fist I'd Like to Punch the Carriers With” argues this point vehemently.

Google writes the vast majority of Android code internally, controls all commits to the public source tree, allowing very few contributed patches, and maintains private repositories that are significantly ahead of what is publicly available and beyond the published roadmap; Stephen Norcott adds, “therefore essential for an OEM to stay competitive.”

Compatibility is required in the form of a compatibility test suite, as well as controlling the use of Google's closed-source Android apps (Gmail, GTalk, Android Market). The restrictions allowing the use of the Android market remain unpublished (“Unfortunately, for a variety of legal and business reasons, we aren't able to automatically license Android Market to all compatible devices.”)

Google controls the Android trademark and branding. They require you to use their location services, not someone else's. There's an anti-fragmentation agreement, the details of which are largely unknown, but which may be moving towards a more central role. Quoting Stephen Northcott again, “In short, it's either the Google way or the highway. If you want to branch off Android you're completely on your own and you need resources of the size of China Mobile.”

Joe Hewitt's tweet on the subject strikes to the heart of it, “Rubin bickering with Jobs is a farce, because both refuse to share the one thing that matters: control.”

Why doesn't Google define Open for Android?

Why is Android's definition of Open not more clear? It's hard to say. I could argue cynically that Google prefers to wrap themselves in the mantle of 'open', and get all the positive attributions of the word, ignoring the fact that not all of them are a good fit. I suspect it's more likely that defining 'open' for any context is difficult and prone to causing arguments, so they've simply avoided doing so.

Does it Matter?

Who Cares if Android is Open?

It seems clear that some portion of consumers with Android phones have them precisely because they feel Android is a more 'open' platform. It's also clear that Android's version of Open Source doesn't always live up to the expectations of open-source advocates (see Joe Hewitt's commentary, for instance). If Google seems to be stepping further away from 'Open' with Android, those people might not see the value in Android handsets, or, worse, feel betrayed.

Similarly, if handset manufacturers got into the business of making Android devices because they felt like they were partners in the platform, not constrained by the whims of a software manufacturer they didn't control, they might feel as if that's no longer true. The manufacturers risk being commodities, easily replaceable, companies that make devices more strongly associated with Google. They might start looking for alternatives, either by building their own operating systems or by leading a revolt against Google on Android (start by replacing the Google Android Market with the Amazon Appstore, which now comes preloaded on the HTC Merge; continue by replacing the Google Search Engine with Bing and keep on going).

Does Open make or break Android?

Does Android succeed fully or in part because it is Open, or is that simply an unrelated fact? To what extent does Google's openness with Android affect its continued success? It's easy to argue, as Stephen O'Grady does, that Apple's iPhone proves that it's entirely possible to get traction in the mobile marketplace while using a closed ecosystem. Of course, Android is positioned differently than iOS, and unless Google's willing to drop the Open Handset alliance and start treating the manufacturers as Apple does Foxconn, then Google needs some cooperation from other companies.

Ultimately, it's the relationship with the manufacturers and carriers that Google needs to cultivate. If possible, it would be great if Google could avoid excessively irritating open-source advocates, some of whom buy Android phones, but I think Android would continue to be viable, even successful, if every open-source advocate refused to buy their devices. Android can succeed with or without 'open.' Using O'Grady's words, “it is difficult to build the case that Android's governance will read on its outlook.”

While 'open' is one way to pitch your operating system to the manufacturers, I think “free” (as in beer) and “good” goes a long way, particularly if you continue to allow the manufacturers to differentiate themselves, albeit perhaps in a more controlled manner than they have been.

Is Android getting Less Open?

Is Android changing to become less open? You could argue that point, and many currently are. The source code for Honeycomb, Android 3.0, has not yet been released, Google is moving to exert more control and reduce fragmentation. Some even argue that this amounts to a bait-and-switch where Google gains traction for Android by offering openness, only to snatch more control as soon as it's too entrenched to be easily discarded.

Honeycomb isn't Open

Android 3.0, Honeycomb, is appearing on Android tablets, yet Google has not yet open-sourced the code behind it, explaining:

To make our schedule to ship the tablet, we made some design tradeoffs,” says Andy Rubin, vice-president for engineering at Google and head of its Android group. “We didn't want to think about what it would take for the same software to run on phones. It would have required a lot of additional resources and extended our schedule beyond what we thought was reasonable. So we took a shortcut.

One could argue that if Google were to open the source code, they could issue the same warnings, and let potential adopters make their own decision, but that Google isn't willing to trust them to make that decision correctly:

While we're excited to offer these new features to Android tablets, we have more work to do before we can deliver them to other device types including phones. Until then, we've decided not to release Honeycomb to open source

Since Andy Rubin provided a definition of 'open' for Android — that you can download and build Android from source code — you can argue (as does the Register) that by that very definition, Android 3.0, Honeycomb, isn't open.

Despite the stir that holding Honeycomb back has caused, this is not a particularly new development for Android, similar complaints go back to at least 2008; Google often develops Android behind closed doors, and gives access to those private repositories sparingly, only releasing the code to the open-source Android project later. This might be the most visible occurrence, but it's certainly not the first.

Anti-Fragmentation isn't Open

Although Google has had anti-fragmentation measures in place before, recent news strongly suggests that they're going to be much more strict in their enforcement, requiring manufacturers to seek Google's approval. The implication seems to be that Google will be encouraging the manufacturers to deliver devices that are much closer to the stock Android experience than has previously been the case:

Playtime is over in Android Land. Over the last couple of months Google (GOOG) has reached out to the major carriers and device makers backing its mobile operating system with a message: There will be no more willy-nilly tweaks to the software. No more partnerships formed outside of Google's purview. From now on, companies hoping to receive early access to Google's most up-to-date software will need approval of their plans. And they will seek that approval from Andy Rubin, the head of Google's Android group.

The Bait and Switch

If Android threw on the mantle of Open to get traction, and has now thrown it off to wield the cudgel of anti-fragmentation, is this really just a bait-and-switch manoeuvre? John Gruber thinks so:

So here's the Android bait-and-switch laid bare. Android was “open” only until it became popular and handset makers dependent upon it. Now that Google has the handset makers by the balls, Android is no longer open and Google starts asserting control.

Not everyone agrees. Seth Weinstraub (Fortune) and Chris Lindsey (Chris Conundrum) argue that you can't complain about fragmentation on the one hand and then complain that anti-fragmentation measures make Android not open on the other:

See the problem? They complain about an issue (fragmentation or a good tablet and phone operating system), but when a solution is put in place, they complain about the solution and tell you why their iPhones/iPads are so much better.

It's not hard to see that there's a conflict inherent in Google's position. It can't do all the things it wants to do well, because being truly open almost always results in fragmentation, and trying to control fragmentation is likely to put your openness at risk. Google can't help but contradict itself. The android open source project page still claims:

We wanted to make sure that there was no central point of failure, so that no industry player can restrict or control the innovations of any other.

And in 2010, Rubin, speaking to PC Magazine, said:

If I were to release an operating system that I claimed was open and that forced everybody to make [phones] all look the same and all support very narrow features and functionality, the platform wouldn't win. It wouldn't win because the OEMs have a lot of value to bring and the carriers have a lot of value to bring, and they need a vehicle by which to put their interesting differentiating features on these things.

And yet, Google seems to be trying to control the innovations of the manufacturers, trying to make the phones look closer to one another.
Essentially, Google's trying to find a middle-ground between fragmentation on one side and openness on the other. Google has let the manufacturers have their way so far, and has decided they need to exert a little control to fight off fragmentation while still retaining as much openness as they can. It's a hard path to follow, and I don't expect Google to get it right every time, but I do think there's a number of ways that Google could make life easier on themselves.

What Should Google Do?

Google is seemingly caught between a rock and a hard place. Seth Weinstraub says that Google can't catch a break. If they let manufacturers deliver the custom experience they want to deliver, then Android is “fragmenting” and everyone complains that the handset manufacturers don't update their handsets. If they try and rein in the fragmentation, then Android “isn't open.” They have a few choices, some of which aren't compatible with the others.

Work with Manufacturers

The manufacturers remain important to the success of the Android ecosystem. Google needs to keep these relationships strong and healthy. Don't worry too much about the media, particularly the tech media, and even the public as long as HTC, Motorola, Samsung etc are all on board. If those companies keep turning out strong Android devices, the carriers and the public will continue to buy them.

While Google probably can't convince the manufacturers to stop thinking about controlling their own destiny by building their own operating system, a great experience with Android will probably keep the in-house operating system on the back burner, as a plan B. The manufacturers really just want to sell phones, and if building an operating system is too painful and too costly when compared to what Android offers, they just won't bother.

Simpler Messages

“Open” is complicated. It means a lot of things to a lot of different people and discussing it leads to arguments. It's also true that the vast majority of the phone-buying public doesn't care about open. It's a good idea for Google to fall on the side of open, to have Android be the phone of choice for advocates of open (of various stripes), but it shouldn't be the defining message of Android.

It's time for Google to figure out what Android stands for and how to communicate that simply and clearly, both to the technical and 'open' audiences and to the public as a whole. I don't think that “Open” is, or should be, a big part of that.

Embrace Open

If Android being Open is a really big deal for Google, then embrace it, go all the way.

Make sure that every developer can see the changes you're making that are six months out, let alone major releases that are already in the hands of consumers. Share your source code with everyone, don't keep private repositories. Encourage developers to contribute code, loosen up commit rights. Put your roadmap in the open. Let handset manufacturers do what they want with the interface, no matter how terrible it really is. Let Android be a beacon for 'open' and try and solve the rest of your problems in some other way that doesn't restrict the openness of Android.

This will let you continue to frame Android as the open alternative to iOS, and take the high ground. It'll appeal to a certain segment of your technical customers, and presumably to the carriers and manufacturers. It might cut into your profits if the manufacturers cut deals to put Bing on your phones, but that's the price of open.

Partner with an Open Manufacturer

If Google were to replace open, they should find a manufacturer who's really willing to partner with them, over the long term, on being open. The manufacturer could deliver stock Android phones, work on the public codebase with Google, making visible improvements to Android as a whole, deliver OTA updates to their handsets as soon as is feasibly possible and generally promote the experience of Android. If you can prove to the public that stock Android is better than the manufacturer-differentiated version, then other carriers will follow suit, and even if you can't, you'll encourage customers who do care about open-ness and fragmentation to put their money where their mouth is.

Shut Up about Open

Google could simply shut up about 'Open'. It could use tightly-controlled language, continuing to refer to the Android project as open-source, but not trumpeting its benefits, nor framing Android vs. IOS in the terms of 'open' and 'closed'. At this stage, it's questionable whether or not continuing to frame Android as 'open' is beneficial or harmful. Stephen O'Grady writes:

Google's outspoken defense of the project's governance has predictably set high expectations for source code availability and the ability to participate. The benefits of this approach are debateable: leverage of the term open appears to offer marginal soft benefits in mobile against a hard cost of negative public relations and developer sentiment.

If Google were to back away from the positioning of Android as 'Open', taming down the way they talk about Android without changing their behaviour significantly, it would slowly lead to people complaining less about Android's lack of openness — they would be harder-pressed to pit Google's behaviour against its words. There would always be some who'd complain about Android's openness, just as there are people who complain that Apple's iPhone is proprietary, but if Google were to shut up about 'Open', this would quieten to a vocal minority.

When even the BBC suggests that being open is the first step on that path to malware, you have to question whether or not it's worth Google's trouble to champion openness. Quoting Jonny Evans (Computerworld):

It really is time to cease the "Android is open" mantra.

In Summary

To be honest, I don't think Google will do any of these things. I think they're going to keep trying to walk the fine line, talking the open talk, but having trouble walking the open walk as much as they'd like to. I think they're likely to make some ground on the fragmentation side while continuing to develop behind closed doors, refusing to loosen their grip on commit access, and generally making a bit of a mess of things.

I think this will result in a regular ebb and flow in news about Android and how they are or aren't open, little controversies like the Honeycomb source not being released and new efforts to control fragmentation.

I also think Android will continue to do well in spite of all this, because despite all of the above, I don't think that being strictly open is fundamental to Android's success.

But if somewhere in these three thousand words, I was able to clarify for or persuade some of you, then I'm glad I wrote it.

Apple is both a platform (hardware and software) for selling applications, content and services, and a vendor of content (music, movies, books) for the platform. This puts them in competition, as a vendor, with some of their customers (as a platform), and sometimes that leads to conflict.

This is a topic that John Siracusa's been talking about with Apple's Strategy Tax, both on Ars Technica and on Hypercritical (with Dan Benjamin).

There's some interesting parallels with the inflection point reached by Netflix (as covered by Wired Magazine):

It had taken the better part of a decade, but Reed Hastings was finally ready to unveil the device he thought would upend the entertainment industry. The gadget looked as unassuming as the original iPod—a sleek black box, about the size of a paperback novel, with a few jacks in back—and Hastings, CEO of Netflix, believed its impact would be just as massive. Called the Netflix Player, it would allow most of his company's regular DVD-by-mail subscribers to stream unlimited movies and TV shows from Netflix's library directly to their television—at no extra charge.

The potential was enormous: Although Netflix initially could offer only about 10,000 titles, Hastings planned to one day deliver the entire recorded output of Hollywood, instantly and in high definition, to any screen, anywhere. Like many tech romantics, he had harbored visions of using the Internet to rout around cable companies and network programmers for years. Even back when he formed Netflix in 1997, Hastings predicted a day when he would deliver video over the Net rather than through the mail. (There was a reason he called the company Netflix and not, say, DVDs by Mail.) Now, in mid-December 2007, the launch of the player was just weeks away. Promotional ads were being shot, and internal beta testers were thrilled.

But Hastings wasn't celebrating. Instead, he felt queasy. For weeks, he had tried to ignore the nagging doubts he had about the Netflix Player. Consumers' living rooms were already full of gadgets—from DVD players to set-top boxes. Was a dedicated Netflix device really the best way to bring about his video-on-demand revolution? So on a Friday morning, he asked the six members of his senior management team to meet him in the amphitheater in Netflix's Los Gatos offices, near San Jose. He leaned up against the stage and asked the unthinkable: Should he kill the player?

By choosing to focus on selling movies, not making hardware, Netflix has integrated successfully with platforms far and wide, rather than encouraging themselves to focus on a single platform. As a result, you can watch netflix on iPhone, iPad, Apple TV, Roku, computers, internet TVs, and other platforms of which I'm not even aware. This seems to have worked well for them.

This is a tricky situation for Apple to be in, and a line they have to walk very carefully if they want to remain effective in both businesses. It's not hard to imagine that being in both businesses makes it harder to be in each business. Netflix and Amazon/Kindle would probably be happier partners if Apple weren't also selling eBooks through iBooks and movies through iTunes. At the same time, Apple's ability to provide a very streamlined end-to-end simple solution for reading books, listening to music and watching movies has been key to their success in the past and probably the present, so leaving one business or divorcing the two businesses through some kind of a corporate split might well damage both irreparably. Having come this far, I think they have to stay the course.