July 12, 2011 ☼ Technology
Lately I’ve grown tired of reading about how a platform is closed or open based on a single facet of its operation. I expect lazy coverage from pundits but much less so from technology journalists.
In the age of competing mobile computing platforms we’ve seen a lot of discussion of “openness.” Often these debates focus on the open source angle from the last great technology platform war: Microsoft vs. Linux. Nothing illustrates this more than a single tweet from Google’s Senior Vice President of Mobile, Andy Rubin:
the definition of open: “mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make”
Andy’s tweet implies that mere access to the source code for your platform along with the ability to build the code in some form is the endgame of openness. Andy’s openness script glosses over the complications an independent developer might have in building the various Android flavors created by HTC, Samsung, or Motorola. If a developer cannot build the various platforms they wish to deploy their application on, is the platform still open?
If source code isn’t a sufficient measure for openness, what other checkpoints might there be for a mobile computing platform?
There’s only one mobile computing platform I can think of that would receive a passing grade on most of these marks (with several marks of unsatisfactory at that): The Web.
Platforms come in all shapes and sizes with various levels of “openness”. Source-code alone won’t prevent a developer’s business model from being invalidated overnight. Source-code alone won’t allow consumers to switch platforms if their device, platform, handset maker, or carrier denies them the privilege. Source-code alone won’t prevent locking a developer into a licensing strategy (such as the GPL) which will hamper future efforts to transfer, license or expand the intellectual property they’ve developed. Source code that is missing a critical component (application or other forms intellectual property) doesn’t help a developer hunting down a potential compatibility bug or an end-user trying to enhance an application’s workflow to their own liking.
Device fragmentation doesn’t rule out a platform as being open. There’s a lot of device and implementation fragmentation on the Web. We each have our own prism of the Web defined by our browser, network provider, operating system, and user preferences. Any of these players might make a particular shard of the web more or less open.
If the platform and an “application store” help normalize the differences across devices (for both consumers and developers) does that make platform more or less open? Was Mac OS X more or less open before the Mac App Store? Before you answer, factor in the cost to market, sell, and support an application before the App Store. Consider the same experiment for a developer targeting Slackware Linux. If you only provide a limited set of device choices but in doing so you’ve enabled a consistent, fluid, and engaging user interface have you made your platform more or less open?
There aren’t black and white answers to most of these questions. It is a battle of tradeoffs that enable and hamper platform providers, developers, and consumer in contradictory ways. The Web is seemingly an open platform but has a high barrier to entry for certain types of implementors and business while being extremely open to other uses. iOS is not a “closed platform” because Apple & the carriers dictate the rules of how you may use the hardware & network they’ve essentially leased to you. Android is not an “open platform” because they provide a significant portion of the operating system code.
Platforms are too complex for narrow definitions and it would serve everyone’s best interest if technology journalism would help us unravel the tradeoffs. Users (be they developers, end-users, or business-folk) are ready for sophisticated discourse of mobile technology because we’ve invested our future in making the smartphone a core part of our daily experience.