Google Android needs both control and community
To beat Apple in mobile, Google is going to need more open-source developers. But it's also going to need more Google.
Take me to your leader(s), earthling
Such developers, however, also want more choice than Apple offers them. Somewhere in the resolution to that tension is a big market opportunity for Google, one that carriers and consumers are going to give it time to figure out.
Google's Android efforts have looked Apple-esque at times, as Linux Journal notes. This is a problem. Google may not have discovered "the evil room" on its Silicon Valley campus, but even a hint of "evil" from Google could send developers packing.
But Google is no Apple: its DNA meshes well with that of open-source developers', as Tom Foremski notes. The company really doesn't want to do evil.
Its dilemma, however, is that it may not be able to avoid some of the "evil" that upsets open-source developers. Like control. Control is critical to good software, something that the best proprietary and open-source software has long demonstrated. Linux, for example, depends upon Linus Torvalds serving his role as "benevolent dictator."
The difference is that it's easier for Linus Torvalds to be autocratic than Google. He's an individual. Google is a company.
Even so, Google isn't going to beat Apple at its own game (i.e., deathlike grip over all aspects of a product). To win, Google must marshal an external development community, one that doesn't like to be managed and, as Dan Lyons (aka "Fake Steve Jobs) points out, one for whom rebellion in the form of 'forking' is par for the course.
Google is therefore left with a strategy that depends upon diversity not wanting to be overly diverse.
This is a challenge, but also an opportunity.
If the company can learn to exercise Linus Torvalds-like control without appearing to dominate Android, the project will win. It certainly has a lot of people cheering for it. It also has growing experience that suggests it's learning to walk the fine line between community and control.
As CNET writes, "device makers see Android as their biggest hope to compete against Apple's iPhone and Research In Motion's BlackBerry devices in the smartphone market." Bingo. Carriers can't afford to cede all control to Apple and RIM, and consumers remain individualistic enough to demand devices that fit their needs, whether they're based in India or Canada or Armenia.
The world isn't going to abandon that diversity to uniformly converge on the iPhone. It's just not. There is no one handset to rule them all, Sauron-style.
And so long as it's not, developers will give Google leeway and time to figure out the optimal development model for Android.
While TechCrunch highlights technical problems with Android's handset support, this strikes me as a short-term, highly solvable problem. It's a relatively safe bet that Google will figure out ever easier ways to manage development across diverse devices, as others have done.
Volantis, for example, offers an open-source approach to manage Web development across an ever broadening array of mobile devices: 6,000 and counting. (Disclosure: I am an adviser to Volantis.)
Google could do the same. It has time. As ZDNet's Dana Blankenhorn writes:
Google's cost structure gives it the power to be patient, something no other market player has. The Android bandwagon is built on this patience.
With over $4 billion in mobile advertising revenue that Coda Research Consultancy is projecting for 2015, it's worth it to Google to figure this out. I suspect that, like Red Hat's certified Linux, over time we'll see Google certify Android applications. There are more mobile devices than different servers and server architectures, but it's essentially the same problem.
Developers may find Google's control of Android irksome, but it's less burdensome than Apple's winner-take-all-and-we're-the-only-winner approach, and it's worth it to see device compatibility issues dissipate.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
do you read what you write? America has wrapped its lips around that iphone so hard for no other reason to keep up with the Jones'.
And secondly, the whole point of the OPEN HANDSET ALLIANCE to to allow OPEN SOURCE SOFTWARE ON TO DEVICES...software developed by the consumers for use by the consumers.
what you are proposing makes sense...ten years ago...BEFORE there was a demand for more flexibility on cell phones then there is today. of course the technology wasnt there either.
Honestly, you sound like some old coot, yearning for the day when Ma Bell was the only one that could service, install or otherwise carrier service for your phone.
Developers just need to keep writing software for the main branch which forces device makers to be compatible.
I think even now no device maker will risk losing compatibiity to the 10000 apps on the android market.
"It's tough to balance corporate interests with developer interests, and particularly in open-source development. TechCrunch's Michael Arrington suggests that Android developers are frustrated over having to support multiple code bases to cover the diverse handsets on which Android runs, which is indeed a problem. Basically, these developers are asking Google to exercise more control over Android to ensure it works seamlessly on a range of different devices."
Developers are asking google to do this but they are not right now and it is up to the developer to make sure it works on all handsets.
- by richard993 October 17, 2009 3:04 PM PDT
- Apple developers have it easy... just one screen resolution to target with a common set of API's consistently implemented across them. For example, developers can rely on the fact that the API will support 3D on all iPhones. There will be only minor differences such as additional pieces of hardware, such as the compass in 3GS.
- Like this Reply to this comment
-
(11 Comments)The fact that there is consistency, it substantially improves the usability of these applications. I've developed on the Blackberry, PALM, J2ME, and the Android platforms and I can say that supporting multiple devices from different manufacturer is a HUGE problem. It takes weeks of additional testing to ensure that widgets are aligned and that they appear and function correctly on devices in the same platform.
You can't just use an API call without checking if the platform 1) supports it, 2) implements it correctly, 3) that the appropriate hardware is installed on the device, and 4) checking the screen resolution and reflowing/adjusting positions of controls and window sizes.
Purists will say, hey all you have to do is query a couple properties and use dpi's for everything. But real developers know that using dpi measurements causes some controls and fonts to appear large on mobiles with larger screen resolutions. It is also not an effective use of real-estate on the screen. Another problem is that certain types of elements such as bitmaps, cannot be rescaled without loss of quality. Using vector based images on low resolution screens causes the image to look morphed even with anti-aliasing.
I can see a lot of challenges further down the road for mobile manufacturers, especially if they don't update their fork of the Android platform when new versions are released. The issue is that some mobiles do not have any way of being upgraded so users are stuck with earlier versions of Android. Even if you do find an update for the same processor, it doesn't work because of the other chipsets on the device. Sure they can get the source and compile it themselves providing they have the appropriate software to update the ROM... but seriously?
I don't expect Google to solve all these problems. But what I can propose is some sort of certification program that provide different levels of compliance. Each level of compliance should have tied with it the number of years that the end users can expect to get software updates. As Android is a relatively new platform, there could be several new versions and bug fixes during the 24 month contract you may have taken with your telco provider.