Android and the Perils of Open Source

Over at Tim Bray’s Android Developers Blog, there is a fascinating post by Dan Morrill, the Open Source & Compatibility Program Manager for Android. (“Program Manager” is tech-speak; it generally means someone who tries to make sure that the trains run on time and that a given program / project stays on track to meeting its larger goals.) One of the perils of an open source project is compatibility (the flip side of forking): how do you make sure apps written for Version A of the open source software operate on / play nicely with Version B? This was, and is, a huge problem with the various flavors of Unix. (Back in the day at Lotus, the Domino team even had to worry about getting the server to run on Sun Solaris/x86 and Solaris/SPARC.)

Android does three things. First, it mandates putting a “chunk” of code onto each device. Thus, developers can count on having certain core functionality available to their programs. Second, it sets out a Compatibility Definition Document (CDD), which tells you what you can and cannot do with Android (for example, no tinkering with official APIs). Lastly, it puts out a bugchecker, the Compatibility Test Suite (CTS), to catch known issues. The reward for following these three rules? You get to call your device Android-compatible, and you get to put it in the Android Marketplace.

There’s a fourth interesting thing that Android does, though it’s bumped to the bottom of the post: when I load the Android Marketplace from my Droid, I see only apps that are compatible with my phone. The Marketplace filters what’s presented to me so, for example, if I have a device with no camera, I don’t get apps that require one. That’s smart – it lowers information and error costs for users, and prevents people from being dissatisfied because they (unknowingly) downloaded an app that doesn’t play well with their hardware.

While I don’t love my Droid (the keyboard is straight from a Casio organizer circa 1998), I think Android will become the dominant smartphone platform. (Sorry, iPhone cultists.) That’s in large part because I think these 4 things (chunks, CDD, CTS, filters) go a long way to meeting the fear that Apple identifies for iPhone users: the worry that an app will behave maliciously or perform poorly. Apple does this through arbitrary and draconian decisions about what can make it onto their phones (and iPads). Google, by contrast, sets up modest channeling devices to reduce bad code, but otherwise, the pool is open. My belief is simple: a more open development environment means more apps (perhaps even better apps), meeting more users’ needs, drawing more people onto the platform. Once network effects get going, Android’s dominance will increase. (And that’s without considering the iPhone’s lock-in with AT&T.) Maybe we’ll have to put up with porn on our Android phones, but hey, that’s a small price to pay for openness…

Comments are closed.