¶ The Fast Pace of Getting Left Behind
/In hardware and software, fragmentation is inevitable. Eventually newer software will demand too much of older hardware, and the older hardware will need to enter the realm of being unsupported. Sure, this can be caused artificially by the software or hardware maker not wanting to put forth the effort to support the past. The decision can also be made for the sake of not impacting the experience of a device. No one wants to run software that performs poorly because the hardware can't keep up.
Normally this retirement process takes years. But as technology moves forward at an ever increasing pace, the span between hardware debut and retirement is closing faster than ever. Sometimes it is done out of necessity, and other times artificially.
Let's take the Mac. Apple tends to support hardware with software on the Mac for about five years. This day and age, that is plenty reasonable in my book. Apple's approach is to support the hardware until it becomes a technological burden to the advancement of the software. The chief exhibit is the current version of Mac OS X — Snow Leopard. Snow Leopard cut off support for the old PowerPC architecture. Folks with PowerPC Macs are cut off using Leopard until they buy a modern Mac.
Why did Apple need to do this? Because supporting older hardware was eating up too many development resources for newer software. Eventually you have to stop supporting things you no longer make. When Apple cut off PowerPC support, Mac OS X went from an installed hard drive footprint of around 13 GBs to 6 or 7 GBs. The result was a faster, leaner operating system.
In the upcoming Mac OS X revision — Lion — Apple will be dropping support for 32-bit Intel processors, which were the first Intel Macs. Again, these Macs are 5 years old. And the reason this time is to cut out supporting 32-bit and 64-bit processors, especially at the kernel level. The goal is to be faster and leaner.
Now, let's look at iOS. This is a whole different ballgame, as mobile development is moving so much faster than desktop and notebook development. There have been 4 iPhone and iPod touch generations. The current generation of these devices are leaps and bounds faster and more efficient than the first generation models. Yet Apple supported first-generation devices through the third OS revision. With iOS 4, Apple finally pulled the plug on those first-generation devices, because the software had truly outstripped the hardware.
Here is where Apple made a bit of a mis-step though. They were still selling the second-generation devices as discount, entry-level prices just before iOS 4 shipped. So they felt obligated to support them. And that didn't work out so well because the second-generation of handheld iOS devices shared much of the same hardware as the first-generation. This caused these devices to perform poorly, and Apple scurried to optimize iOS 4 for performance on these older devices in 4.1 and 4.2. But it really wasn't enough. So with iOS 4.3, Apple pulled the plug on support for second-generation hardware, which I am sure they didn't want to do until iOS 5.
What I've described above for iOS is only one side of the coin. Those were necessary hardware retirements. That isn't to say that Apple hasn't artificially retired features improvements along the way. For instance, iOS 4 brought along Game Center integration. This was included in the second-generation iPod touch, but not the second-generation iPhone. I can't imagine that was truly a hardware limitation. Or how about this: iOS 4.3 brought Personal Hotspot to the iPhone 4's tethering ability, but not to the iPhone 3GS, despite the fact that jailbreakers can do Personal Hotspot on the iPhone 3GS. Are artificial limitations a jerk move? Yeah, they are. And everyone can be a jerk at times.
Finally, let's look at Android. Android has been the prime target of the fragmentation blame game. And it often seems like it has been earned. But who is really to blame? Google? Or the carriers? I say a little of both. Vlad Savov wrote on Engadget over the weekend:
Where the trouble arises is in the fact that not all Androids are born equal. The quality of user experience on Android fluctuates wildly from device to device, sometimes even within a single phone manufacturer's product portfolio, resulting in a frustratingly inconsistent landscape for the willing consumer. […]
The point is not that carrier or manufacturer customizations should be abandoned entirely (we know how much those guys hate standardization), it's that some of them are so poor that they actually detract from the Android experience. Going forward, it's entirely in Google's best interest to nix the pernicious effects of these contaminant devices and software builds. The average smartphone buyer is, ironically enough, quickly becoming a less savvy and geeky individual and he (or she) is not going to tolerate an inconsistent delivery on the promise contained in the word "Android."
And this is exactly how things are in the Android world. There isn't a uniform experience standard. Perhaps this is why, according to Bloomberg Businessweek, Google has started handpicking partners to showcase Android, and delaying the source code to everyone else:
Over the past few months, according to several people familiar with the matter, Google has been demanding that Android licensees abide by "non-fragmentation clauses" that give Google the final say on how they can tweak the Android code—to make new interfaces and add services—and in some cases whom they can partner with. […]
Google has also started delaying the release of Android code to the public, putting smaller device makers and developers at a disadvantage. On Mar. 24, Bloomberg Businessweek reported Google won't widely release Honeycomb's source code for the foreseeable future.
The company's moves are hardly unprecedented in such a fast-moving industry. Google owes it to its partners and consumers to prevent Android from running amok.
Android has been running amok. It is saddening when I hear some friends — who are normal, non-geeky people — lament about how the phone they bought three months ago isn't getting the new features of so-and-so's phone from last week.
As I stated at the beginning, every platform will experience fragmentation. Apple does a pretty good job at mitigating that effect because they control the platform from top to bottom. Google let the main Android experience get out of hand because they have been controlling very little in the grand scheme of things. Why have they been controlling so little? Marco Arment writes:
Nobody “opens” the parts of their business that make them money, maintain barriers to competitive entry, or otherwise provides significant competitive advantages. That’s why Android’s basic infrastructure is “open”, but all of Google’s important applications and services for it aren’t — Google doesn’t care about the platform and doesn’t want it to matter. Google’s effectively asserting that the basic parts of a modern OS — the parts that are open in Android — are all good enough, relatively similar, and no longer competitively meaningful. Nobody’s going to steal marketshare from Google by making a better kernel or windowing API on their competing smartphone platform, regardless of whether they borrowed any of Android’s “open” components or ideas derived from them. But Google’s applications and services are locked down, because those are vulnerable to competition, do provide competitive advantages, and are nowhere near being commoditized.
Unfortunately, Google spent the last few years letting Android's core experience go unchecked, allowing the carriers to decide whether or not to use Google's applications and services, and whether a certain phone gets an update or not. Google hasn't been giving Android a chief place in their bottom line, they've let carriers use Android to pump up their bottom line, and have been sticking it to customers.
It all comes down to this: let the end-user be your customer, and use the carrier as the channel; or let the carrier be your customer, and the end-user is the channel.