How to stop Apple and Google's great web lockdown
Open...and Shut Both Google and Apple are vying to win the "Most Open Platform" prize in the mobile computing beauty pageant, but neither deserves the blue ribbon.
Ironically, it will be Google's desire for openness on the desktop that trumps its (and Apple's) desire for control on smart phones.
Apple's closed nature, or what Apple chief executive Steve Jobs prefers to call "integrated," is not a secret. One of Apple's defining principles is that tight control of its platform, and what runs on it, is the best way to deliver a compelling consumer experience. In Jobs' mind, Google's Android code may be open source, but the fragmentation that ensues makes it a closed platform that is bad for customers and app developers alike.
Not everyone agrees. TweetDeck's CEO argues that Android's fragmentation is easy for an app developer to manage.
At any rate, the fragmentation hasn't seemed to slow Android's success. Responding to Jobs, Google's Andy Rubin says that source code access is all that's required to be truly open, and that the company's openness is a key element to its success.
But this isn't completely true, as noted Facebook developer Joe Hewitt points out. Hewitt argues that Android is only open after the fact. That is, the company only releases code after it is complete:
Until Android is read/write open, it's no different than iOS to me. Open source means sharing control with the community, not show and tell.
Not only this, but there are clear signs that Google has intentionally avoided standards-based Java for its own Dalvik interpretation in order to ensure that Android apps remain firmly entrenched on Android. Google has played the openness card, but perhaps isn't the Saint Stallman it sometimes portrays itself to be.
Google is, however, the industry's foremost proponent of the rising HTML5 standard, which ultimately will do more for its business than controlling Android development ever could. Android, for all its success, has never been Google's primary mechanism for driving an open web, one that feeds its online advertising business. Chrome OS is.
Chrome OS takes consumers and enterprises away from dependence on the desktop and welds their allegiance firmly to the web, the platform that Google increasingly dominates. While Google is quick to dispute the idea that it has any control of the web or even of its search users, it is clear from the earliest interviews on Chrome OS and HTML5 that Google believes it will win the majority of battles that assume the web is the primary computing platform.
Apple, for its part, is willing to follow along because it wants HTML5 to displace Flash. The company appears to not be overly worried that HTML5-based web apps will dislodge developers from writing apps for its iOS devices in Objective-C. Apple might want to consider the impact of Strobe, which ex-Apple engineer Charles Jolley formed to marry the power of HTML5 and native apps. Strobe's SproutCore could make it much easier for developers and, hence, consumers, to move their apps between platforms.
But perhaps Apple is right not to worry. As Laura Merling, vice president of Open API platform and services at Alcatel-Lucent, believes, while HTML5 adoption will be fast, it's unlikely to gain more than 20 per cent of the market due to continuing browser fragmentation.
Again, Apple wants HTML5 to displace Flash. Google's advertising business depends upon rampant, widespread adoption of the web, which HTML5 supports. Even Microsoft, with so much tied up in its legacy desktop business, is playing catch-up to both Google and Apple, and standards generally favor the challenger in a market.
Yes, each of these companies, among others, will compete vigorously to skew the standards to their isolated benefit. But I still have confidence that truly standard HTML5 will win out because it works to Google's advantage, not only because Google is increasingly the team to beat, but also because Mozilla's Firefox is an ever-present reminder that the world can get along fine without the major software vendors' browsers.
Next page: Enter the Fox
I am so sick of this "open" crap.
<Warning class="rant"> Long rant is long </Warning>
Why can’t, the major OS vendors and projects could band together in one glorious example of standardisation and cooperation to create /the/ alternate app store. RPM? DEB? HTML? Who cares! Have the thing autodetect your environment and provide you awesome on demand. From in-browser applications to open-source-for-windows…let’s get something going. The open source community would of course have to start this…but if it catches on, the majors would have no choice but to join.
I want to see a truly standards-based movement to provide yum/apt-get/istore/android/market/steam/firefox-browser-store/kitchen-sink style “store” all in one neat little box that works on any OS, any device, any interface. I realise that my in-browser-app-under-Linux may not work under Windows. Fair enough! Let the OpenAppStore detect that, and simply not present it as an option. (Android can hide apps that won’t install on my device well enough…)
Let’s get paid-for apps in there. Let’s not lock it down to “only open source. ROAR!” “Open” as in “not tied to any one philosophy, operating system, approach to life or belief in $deity. One app store. Regardless of device, platform or environment. Bolt some cloud storage onto the thing so that my user data and settings are available to me regardless of device, platform or environment I am using to get access to them. Hey, if you were cooking with gas, you could do media distribution this way too. By the code! The ability for me to buy a song/bog/movie/whatever *just once*, have it tied to my profile and have it work everywhere. Why that’s actually useful! Madness, ain’t it?
The hell of it is; this is all actually possible with the technology that exists today. The only things holding it back are politics, greed and a complete lack of vision. Massive fragmentation has always been the bane of the open source community’s attempts to win over the endpoint device market. So…obfuscate it. Let the nerds gnash teeth over the method of delivering apps, or the underlying operating system whosawhatsits. Why should the user have to care about RPM, DEB, HTML5, MSI or anything else. Why should they even have to care if they are using Windows, Linux, OSX or Android? (Yes, I know Android started out as Linux. It’s distinct enough now to have earned its place as a separate OS.)
I commonly say to ISPs: shut up and be dumb pipes already. We don’t care a whit for your “added services” or your “extra features.” We want reliable, stable and fast access to the internet. We don’t care about the transport layer – we care about the content that we are using the transport layer to get at!
I now say the same thing to operating systems vendors. Shut the hell up and run my apps already. We don’t care what OS you are, what company you are or what you think makes you “better” “different” or what-have-you. We want the functionality inherent in the applications we run on that operating system and nothing more. Go away and hide underneath an easy-to-use applications-distribution and data-management layer that we don’t have to see or think about. Quite trying to “Set yourselves apart” and compete on speed, stability, reliability and how well you conform to standards.
Or is it simply too much to ask that all the various OS vendors actually live up to the “open” and “user-focused” sewage their marketing departments spew?
<TL;DR> Auuuugh Q_Q greedy corporations! </TL;DR>
Pint, because it's my birthday and I"ll get sauced and rant on the internet if'n I want to...
re: you have to play it a bit fast and and loose in the web game.
>> you have to play it a bit fast and and loose in the web game.
that explains all the xss and other rudimentary security type issues that appear in websites!
>> The cycle from deploy to test to fix to deploy can often be less than a minute as there's none of that compiling bollocks.
and by the sounds of - zero testing to confirm you have fixed the issue and not introduced a new issues
>> You cannot charge £100,000(*) for a web app
until such time as it all goes wrong - at which time the company realises that doing it properly is actually cheaper in the long run.