Android’s Definition Of “Open” Creates Problems
[Developer Joe] Hewitt kicked off [a series of tweets about Android’s definition of “open”] with a question: “How does Android get away with the “open” claim when the source isn’t public until major releases, and no one outside Google can check in?
For those who aren’t familiar with Android’s release cycle, Hewitt is referring to the fact that developers can’t take a look at the current version of the OS as it’s being developed. Instead, they have to wait for the Android team to finish the latest release internally, at which point Google releases the code to developers and carriers begin to deploy it to handsets a few weeks later. This process stands in contrast with many other popular projects that are considered to be ‘Open’, which allow developers to access the code as it’s being written, and in some cases, to check new code in themselves.
This lack of openness (at least compared to, say, Firefox or Linux) exacerbates a problem common on Android handsets. The handset makers and operators can’t even begin to put their crapware customizations in until Google releases the source to the current version of Android–which doesn’t happen until it’s released and not a moment before. This means that handsets sold around the same time have different versions of Android on them. It takes different handset makers and/or operators different amounts of time to get their handsets up-to-date.
In short, Google’s “openness” is making fragmentation much worse than it would be otherwise. Meanwhile, I, along with every other recent iPhone owner can upgrade to the latest iOS release because there is only one OS image to worry about.