Mobile Linux is hot. New products, platforms, initiatives, projects and consortia pepper the media. Each touts a vision of Linux on phones and other devices, using stacks combining open source software (OSS) and proprietary wares.
|
Bill Weinberg
|
Diversity is good, but mobile Linux diverges at every level, in parameters small and large: Linux kernel and library versions, user interface (UI) and application frameworks, IPCs, telephony and multimedia APIs, etc. Mobile Linux efforts, commercial and community-based, strive to fight fragmentation. Unfortunately, their existence and diversity are
creating fragmentation unseen since the UNIX wars.
Can mobile Linux graduate from marketing mantra to ubiquitous platform? How can developers and ISVs sustain businesses targeting a diffuse moving target? Consider the merits of three paths toward unification:
Natural Selection
Duplication among OSS projects usually resolves itself in a Darwinian fashion. Examples include the winnowing of six IPv6 implementations to two, and evolution of the Linux threads programming model. Counter examples present consequences for adoption: regional, vertical, seasonal and ideological Linux distributions and ongoing desktop and framework wars account in part for low desktop market share.
Initiatives, projects and new Linux-based devices each tout impending formation of developer communities. Have mobile Linux projects over-worked this metaphor — like proverbial primates banging out Shakespeare, can reduplicating platforms produce a viable mobile Linux?
Reference Implementation
De facto standards build on consortium-based and vendor-sourced implementation. Consortia posit "get the right players in the room, give them code and everything will be fine." Vendor vision entails building devices so ubiquitous that developers beat a path to suppliers' doors and mailing lists.
Both approaches face challenges. Consortia suffer from member intertia, unwillingness to share IP and competing interests. Code quality is also an issue - will members share their best code or leftovers? Vendor-sourced implementations risk lock-in and catalysis: Can vendors aggregate and support communities around stacks and handsets?
Optimally, consortium and vendor implementations bridge to open source by sharing code, using suitable licenses, accepting patches and cooperating with related projects. Worrisome are "IP Clubs" that restrict access to useful code. "Openness" shouldn't mean selectively exposed APIs, meted out or presented to community as marching orders. Similarly, OSV stacks and OEM reference handsets are hampered by closed code, licensing restrictions, cost and availability.
Formal Standardization
Standardization and open source speak different languages. Deliberation around traditional standards focuses on requirements, specification and compliance. By contrast, OSS conversation centers on implementation, that is, on code.
OSS has a long history of standards-based implementation, e.g., swathes of POSIX and TCP/IP RFCs in Linux, and HTTP, HTML and other Web standards in Apache and Mozilla. Unlike building proprietary software, OSS development doesn't routinely involve (proprietary and expensive) compliance suites. Preferred is community-based use testing. Compliance is a recent and challenging requirement.
Standardization of OSS has a mixed history. Efforts such as the Linux Standards Base (LSB) began as "trailing" standards, describing commonality among distributions; today LSB provides a beacon for defining the OS. Developers initially rejected specifications like Carrier Grade Linux as unfunded mandates; instead CGL requirements snuck piecemeal into mainstream code.
Philosophically, standardization has little in common with open source. Vendors build standards from commercial interest, guided by large participants' agendas.
Standards body members implement and license specifications, derived IP and conformance regimes to third parties, in contrast to OSS sharing of implementations and APIs.
Mobile/wireless follows this model. GSM, CDMA and other networking standards foster closed implementation, backed by government regulation. They are successful, widely adopted, but not open.
A Fourth Path
The three approaches above are flawed, but not fatally. Mobile Linux needs a synthesis of the three, with caveats:
- OEMs and developers must concentrate on enabling applications, not building devices or one-off programs.
- Consortia should use resources to create viable reference platforms, but not create new walled gardens.
- Standards bodies cannot create new specifications in a vacuum, or for proprietary use. Accompany standards with OSS implementations.
- Start building compliance regimes on day one, not as an afterthought. Compliance is best managed by consortia and implemented as a business. Standards grow old and irrelevant waiting for community-based conformance testing.
- Occam's razor*: Resist the urge to multiply entities. Avoid creating new licenses, frameworks and code bases. Instead work to improve existing projects.
The result is a virtuous cycle, not squeaky spinning of wheels. Standards must inform implementations and emerge from them. Developers need to write code to real APIs on actual devices, but also need to know their code will migrate with minimal tweaking.
To succeed, mobile Linux must be more than a trend – it must sustain real business across an ecosystem. It must provide opportunities for silicon suppliers, developers, OSVs, OEMs, ISVs and operators. Early on, Symbian understood and acted upon this business-centric interdependence. Microsoft is learning fast. It's a lesson that the mobile Linux community cannot afford to miss.
* Occam's razor is a principle attributed to the 14th-century English Logician and Franciscan friar William of Ockham. The principle states that the explanation of any phenomenon should make as few assumptions as possible, eliminating those that make no difference in the observable predictions of the explanatory hypothesis or theory. It is often paraphrased as "All things being equal, the simplest solution tends to be the right one."
Weinberg is principal analyst at LinuxPundit.com and LiPS Forum general manager.