Excerpt from my OSD blog post:

Every year the movers and shakers of the mobile/wireless industry converge upon the industry’s mecca, the Mobile World Congress (MWC).  This year’s ecosystem extravaganza in Barcelona drew 1,500 exhibitors and over 72,000 visitors.  Attendees spanned the gadget gamut, from mobile chipset vendors and software platform suppliers to device manufacturers and network operators, from app developers, ISVs and services providers to journalists and end-users in consumer and enterprise IT markets.

Following is a roundup of highlights from this mobile mega event, and it is no surprise that every key announcement and trend coming out of MWC 2013 involved open source software.

Read More

Since my wife decided to spend the evening cleaning out the bedroom closet, using the bed as buffer space for old clothes and other detritus, I HAD TO stay up and play with my RPi some more.   Since I have guests sleeping in my office, I set about doing some remote hacking from upstairs.

I moved a few steps closer to making the PI more useful:

• Without any additional configuration, I used SSH to login to the Pi from my upstairs desk.  Most excellent that no additional messing about was necessary
• Used apt-get to update the distro and installed PHP5, Apache, vsftpd and a few other tidbits.  Started playing with building content – totally standard Apache configuration.  Again, the CL tools are easier to use than the utilities included in Raspian.
• Discovered that I can’t address the RPi using local DNS (.local addresses), but both the Ethernet and WiFi interfaces (10.0.0.x) serve just fine.   Tried pinging a variety of clients using the .local syntax.  Some resolve, some don’t.  Need to grok this issue in fullness.

 What to do Next?

So, I have a very cute and reasonably powerful ARM-based system to play with.  I don’t want it to just sit on the shelf next to my MIPS-based ShivaPlug, so I am mulling over some real-world applications for it:

• Use it as a caching/loop storage server for IP cameras I originally installed to watch our puppies from Hawaii
• Build a home-brewed smart thermostat – think Nest with wires hanging out
• Experiment with Lua (very doable, even if the RPi community is focused on Python), among other things to diddle the bits on the GPIO port
• Use it to learn Python
• Employ the RPi to teach my younger daughter about embedded systems, web programming, etc.

Other suggestions welcome!

Incidentally, I backed Karl Lattimer’s HotPi project on Kickstarter.  I plan to have fun with the HotPi daughterboard once it arrives – it’ll help with the Nest clone project.

RaspberryPi.local – Avahi Daemon!

Without even meaning to, I tripped over a useful blog post by Matt Richardson – 10 Tips for New Raspberry Pi Owners.  To enable local DNS-style naming of my RPi (raspberrypi.local), I needed to install the Avahi Daemon.   Impressive dependency set – bless apt-get.  Worked immediately.

I received a Raspberry Pi (B) as a holiday gift, along with a case and a wireless nub.  I had commented in the media on several occasions about the RPi phenom, but had never laid hands on actual kit until this week.

Well, I downloaded the Raspian image and rolled up my sleeves.

• Burned Raspian on an SD card using my MacPook Pro – don’t bother with the graphical UI – dd works just fine.  Set bs=2m for better performance.
• Hooked the cute little card up to my giant monitor using HDMI, inserted the SD card,  plugged in an old IBM USB keyboard/hub, ran a short CAT5 cable to the nearest Ethernet switch, and connected a borrowed Nexus charger/power supply.  And . . . nothing.  No boot msgs, no diagnostics.  Bubkes.
• A little research revealed that the SD card (Sandisk Ultra 8 GB) I used was marginal, at least for the RPi (works great in cameras).    Bought a handful of alternate cards (after consulting http://elinux.org/RPi_VerifiedPeripherals).  Gotta love post-holiday sales. The next one I tried, a PNY 4 GB Class 6, worked fine – gave the rest of the cards to my kids for use in Xmas presents.
• The RPi booted right up, albeit slower than I would have liked (700 MHz ARM).  Nice clean Debian distro, familiar in some ways, alien in others.  Awkward config utility – need to go back and reconfigure a few key items
• Discarded the IBM keyboard (too much key bounce) in favor of an ancient Compaq I dug out of the garage.  Added an equally antediluvian MS mouse.
• Having run out of USB slots, I dug out a nice little powered 7 position USB hub.  Moved the KB and mouse over, jettisoned the Nexus charger, and now draw power from the hub (up to 2A).
• Stuffed a wireless nub in the now-available RPi USB slot.  Rebooted, ran the wireless config util and voila – everything just works.  Only issue – both the wireless and Ethernet interfaces present the same MAC address to my router.  Hmmm.

More later.

Guest Blog for Black Duck Software

Part II

In earlier blog posts, I examined five areas challenging Android development (Android Cat Herding – Part I).  In this blog, I discuss two solutions to address them.

SPDX

The first is SPDX – the emerging Software Package Data Exchange, part of the Linux Foundation’s Open Compliance Program.  SPDX has a charter to

create a set of data exchange standards that enable companies and organizations to share component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.

building on a specification defined as

a standard format for communicating the components, licenses and copyrights associated with a software package. An SPDX file is associated with a particular software package and contains information about that package in the SPDX format.

Read More . . .

Part I – Synchronizing / Harmonizing Android Source Code & Licenses

In earlier Black Duck blog posts, I highlighted the complexity underlying the Android mobile application platform, especially complications arising from the multi-sourced nature of the OS and its enabling middleware.

At the close of that blog, I listed five challenge areas and promised to elaborate, and to follow up with ways to address them.  In Part I, I’ll expand on the challenges, in Part II, I will examine some solutions.

1. Unique Licensing and Copyright of Patches / Contributions
While the Android project promotes a global Apache 2.0 licensing regime, there is no formal submission or copyright assignment process (cp. those for Linux and for GNU projects).  This somwhat casual patch submission and management process results in diverse and sometimes uncertain provenance of Android platform code (see my earlier blog for examples from the Black Duck Software study).

Read More . . .

Part 1 – Hidden Complexity

This week Android application developers from around the world are gathering in San Mateo at AnDevCon – the Android Developers Conference. While they are soaking up tutorials on UI haptics and building apps with Ruby and HTML5, I find myself pondering the particulars of the Android platform.

A quick glance at the conference curriculum (and Gingerbread documentation) reveals Android as ever more resource-rich, with a growing repertoire of APIs and capabilities to leverage emerging hardware (like the barometer on the Motorola XOOM) and to meet developer community requirements.  In providing the underpinnings for its burgeoning app portfolio (approaching 300,000 – AndroLib.com), Google and its Open Handset Alliance (OHA) partners have created an increasingly complex mobile applications platform.

A Daunting Integration Task

The underlying complexity of Android platform code can be daunting to developers, especially to software teams at chipset suppliers, device manufacturers (OEMs) and integrators.   Anyone needing to integrate Android platform code with hardware and system software will be concerned about

• Managing the 165 different packages that comprise the Android GIT repository
• Tracking changes in over 80,000 source code files
• Integrating Android internal system code, device drivers, Dalvik code, middleware and applications with myriad external repositories
• Maintaining, integrating and QAing company-specific additions to the platform (e.g., UI customizations and Dalvik performance enhancements)
• Reconciling the rights and obligations represented in at least 19 different licenses
• Repeating this exercise every 3-4 months (hello Gingerbread and Android 3.0!)

Read more . . .

Guest Blog for Black Duck Software

Mobile Open Source:

Out of the Attic, Into the Spotlight

Only a few years ago “open source in mobile” was like a crazy cousin or unpleasant uncle, barred from family gatherings and discussed in whispers.  While the first Linux-based handsets appeared almost a decade ago (like the Motorola A760), open source remained in the background, lurking in platform code, far from application developers and the mobile end-user experience.

Mobile is different, or is it?

Mobile, while standards-based, has for over two decades been a proprietary affair.  “Mobile is different,” I was told repeatedly by operators and platform suppliers at the Linux Phone Standards Forum. “Operators and the FCC mandate closed devices for secure networks,” they continued.  “Mobile IP needs special protection,” lectured lawyers at consortia and handset OEMs, imposing impenetrable 100+ page IPR documents whose sole purpose was to corral community code and maintain legacy status quo. . .

Read more at blog.blackducksoftware.com

The mobile device market has traditionally been highly stratified (at least as described by industry pundits).  Pricey smart phones on top, more accessible feature phones in the middle, and entry-level devices for for the masses.  Increasing functionality at incrementally lower retail prices — cameras, texting, web, email — is blurring boundaries among tiers, leaving distinctions that emphasize software and price:

Some explanation

• Pre-load Software includes OS, middleware and basic applications built into handsets at the factory; Post-load comprises software installed in-channel and by end-users
• Pricing will vary by region and by plan, especially for regions favoring MNO subsidies to operators
• Smartphone OEMs typically deploy highly integrated chipsets with dedicated silicon to run applications, multimedia and radio baseband; cheaper devices rely on a single CPU to handle all types of processing

Boundaries among the three tiers are further degraded by product life-cycles, especially from top-tier OEMs:  last season’s smartphone is often repositioned as this season’s featurephone, in terms of functionality, but especially in price:  in the U.S., after introducing the iPhone 3GS, Apple knocked down the price of the iPhone 3G to under $100; Cupertino recently announced the same shift with the iPhone 4 and the 3GS.

Born to be Cheap

The vision for a mass-market smartphone is not one of relegating older kit to the bargain basement.  Instead, these devices are spec’d and built to deliver a smartphone experience at a featurephone price.  While initially emanating from less well-known Asian OEMs, top tier handset manufacturers also investing in mass-market smartphones as well.

What is motivating this paradigm shift?  Isn’t the mobile market complicated enough, already?

The desire for a mass market smartphone actually is shared by all participants in the mobile/wireless ecosystem, with shared benefit. Basically, it all comes down to volume:

• OEMs: increase model/product line volumes and/or margins at a given price point
• MNOs: drive data traffic volume (more subscribers, not more data) and services revenues, sustaining ARPUs; reduce or remove the need for subsidies for smartphones with high wholesale prices (a $99 iPhone still lists a unsubsidized $600+ MSRP)
• ISVs and Developers: provide (even larger) markets for mobile applications through higher application-capable handset volumes

• End-users: give more consumers in more markets a taste of the smartphone experience at a lower cost of entry

The Path to Mass-Market

A friend of mine refers to the present time as “the decade of cheap”.  A mass-market smartphone would certainly fit his threadbare vision of a Walmart-style, made-in-China mobile marketplace.  However, for a mass-market smartphone to succeed, it truly must deliver a smartphone quality experience.

There are two non-exclusive parallel paths to building mass-market smartphones, focusing on hardware and on software.

Hardware: to date, most OEMs have focused cost-cutting efforts on existing hardware bills-of-material (BoMs).  Without really changing how smartphones are built, they seek to scrimp and save on individual components:  cheaper displays, less hefty batteries, end-of-life chipsets, etc.  This kind of thousand-cuts incremental approach can work for an individual device, but the exercise must be repeated with each new device as market conditions change.

Software: smartphones are defined by the software they run more than the hardware that runs them, so attacking an increasingly pricey software BoM should yield results, right? To start with, OEMs large and small are shifting to open source applications OSes, especially Android and Linux (and driving down the price of WindowsMobile and pushing Symbian to become open source).  But the same logic applies to pricier, full-bore smartphones, and with an increasingly open source software stack, there are even few opportunities to cut BoM line item costs.

The key, then, to building a mass-market smartphone, lies not in hardware nor in software, but in optimizing the two together — getting smartphone software to run on significantly more modest hardware platforms. This exercise involves

• consolidating separate application and baseband chipsets into mainstream ARM9 CPUs
• porting baseband and multimedia stacks from legacy DSPs and dedicated ARM chips onto applications processors

and yields significant BoM savings from integrating cheaper CPUs, consolidating previously dedicated DRAM and flash, broadening the choice of available displays and batteries, simplifying circuit board design and testing, and many other areas.  Such consolidation can also enhance battery life and yield surprising performance gains, especially for cross-stack operations like networking.

Deus ex Machina?

Sounds easy, no?  So why isn’t the market flooded with cheap and richly functional devices?  The main impediments come from investments required for consolidation and integration.  Porting (legacy) software takes time and introduces new headaches, and chipset vendors of course would rather fill sockets with new, higher-margin silicon than seek new designs for existing chips.

A different, perhaps radical approach that I personally favor is to use virtualization.  Targeting virtual CPUs instead of shoe-horning code into a single physical processor saves time and money otherwise spent on porting, (re)integrating, re-certifying, etc.  My friend at Steve Subar of OK Labs talks about how to leverage virtualization for this purpose in a recent blog, and I myself looked at the BoM impact in a related Linux Pundit tear down white paper.

Smokin’ Smartphones

Americans at the turn of the last century may never have gotten a really good five cent cigar, but consumers will soon enjoy mass-market smartphones.   Recent announcements of mass-market smartphone chipsets by Qualcomm (MSM7225), Marvell (Pantheon 9xx) and other suppliers, and of actual handsets by HTC, Motorola, Samsung et al. are only the beginning of a trend that will encompass handset OEMs of all stripes and energize the rest of the mobile-wireless ecosystem.

Tell me what you think.  Would you buy a mass-market smartphone for yourself, for your family, for mobile workers at your company?  Will the ecosystem embrace this new class of device, or continue with business as usual?

My first reaction to the Linaro announcement was “O Joy, another Linux knitting circle”.  But I am happy to say that Linaro appears to be what the industry really needs – the glue between silicon and software (my apologies to fans of Linaro stallions). Instead of creating standards or aggregating yet another embedded Linux distribution, Linaro has the stated goal of enabling existing (and new) software to run on actual silicon in the marketplace.

Deliverables of such an effort include

• device drivers
• board support packages (configurations)
• Linux kernel patches
• tools to support integration of these and other contributions

Let’s take a stroll down .org memory lane to compare Linaro’s goals to the aspirations and accomplishments of other initiatives, past and present:

Embedded/Mobile Linux .org Roll Call

OSDL Mobile Linux Initiative – MLI put together requirements for a mobile Linux-based platform as a de facto soft standard (as OSDL did with Carrier Grade Linux).  Unlike CGL, MLI members were disappointed by the lack of actual software deliverables (that is, participants played chicken with contributions).  MLI did serve to help popularize Linux as a foundation of mobile telephony.

CELF – the Consumer Electronics Linux Forum worked to create standards for Linux in a range of consumer electronics, including mobile telephony; these efforts were very skewed toward particular member implementations and did not survive industry scrutiny.  CELF also instigated real  implementation by funding kernel contributions by maintainers (e.g., for flash and power management) and today survives as a sponsor of Embedded Linux Conferences.

LiPS – the Linux Phone Standards Forum had the explicit goal of creating Linux-based standards for mobile terminal devices.  Led by FT/Orange, ACCESS and VirtualLogix, they published several generations of specifications and were in the process of launching an open source TAPI project when the organization was absorbed by LiMo in 2008.

LiMo – the LiMo Foundation strives create the “first truly open, hardware-independent, Linux-based operating system for mobile device”, realized as a distribution shared by its members and deployed in member-built handsets.  Despite these lofty goals, LiMo is hampered by a highly stratified and expensive membership structure, tortuous IPR with limited out-licensing,  slow-to-market specifications, and most importantly incomplete validation suites and an MIA SDK.  While LiMo claims dozens of phones as compliant, the basis is a very rudimentary specification, with little or no visibility to applications developers (cp. Android).

Linux Foundation / MeeGo – In 2007, the Linux Foundation was born out of the merger of Free Standards Group (home of the Linux Standards Base) and OSDL.  They have been very successful in continuing work on LSD (fighting fragmentation) and in sponsoring a range of kernel engineering and other development activities.  They recently announced their acceptance of hosting MeeGo, the result of merging Nokia’s Maemo tablet platform with Intel’s netbook/MID Moblin project.  MeeGo targets a range of embedded/mobile applications, including mobile handsets.

So, Linaro is NOT a standards body, not a distribution supplier and not a mere cheerleader, as far as I can tell.  They seem to have a clear vision of what they want to do – enable Linux on real silicon.

To that end, they are not getting fancy, especially in terms of licensing.  Unlike LiPS, LiMo and others, they have pledged to adhere to existing licensing regimes and not indulge in license proliferation (beyond the profligate OSI corpus).  In particular, the Linaro IP Policy refreshingly stipulates

• respect for and adherence to upstream licenses

• commitment to use only existing, OSI-approved licenses

Cautious Optimism

Like embarking on a second (or third) marriage, launching a new .org for embedded Linux represents the triumph of optimism over experience. Despite (or because of?) my personal involvement with several of the .orgs above,  I believe that Linaro has achievable goals and the members and means to achieve them.  In particular, Linaro sets its sites on providing and improving infrastructure, an area where open source and .orgs have classically excelled.

So, keep your eyes on Linaro.  Not the horse, but much needed glue.

Little Androids, On the Hillside . . .

Yesterday, my friend and fellow analyst Andreas Constantinou of VisionMobile delivered an excellent guest blog for mobile virtualization supplier OK Labs.  In his post, Andreas posits that Android is changing the macroeconomics of mobile, increasingly to resemble the PC business.  In particular, he highlights the emergence of cookie-cutter Android reference designs and ever-cheaper Android-based handsets from chipset vendors, ODMs and contract manufacturers in Taiwan and China.  He segregates the coming wave of Android handset OEMs into Leaders, Innovators and Assemblers and projects that by 2015 the top 5% of the handset market will enjoy 50% of the revenue, in concert with today’s global PC marketplace.

There are indeed striking parallels between the PC business and trends in mobile-wireless, as well as important, persistent differences.

In the mid-90s, a decade before Linux Pundit, I worked as Country Manager at Acer Brazil. We constantly referenced Acer founder Stan Shih‘s “Smile Curve”. Let’s use my old boss’s paradigm (slightly updated) to compare the two markets.

Stan Shih's Smile Curve

Pre-commoditization, PC value-added was dominated by manufacturers cum hardware integrators — originally IBM, Digital and their peers.  PC expertise sat in the hands of a few,  those companies drew on components of their choosing and went to market through direct sales channels.  Industry standardization gave rise to the “PC-AT virtual machine” (BIOS, memory maps, peripherals, etc.) and more importantly, the emphasis on PCs being defined by DOS and Windows software (and not the box they lived in).  Standardization on these h/w and s/w parameters initiated the value shift into the “smile” that Stan described:  the highest value today lies in key components — CPU, HDD, display, memory, GPU, etc. and OS — and in brand and channel, and not in with integrators and motherboard manufacturers.

Another angle to describe this value-added rictus is with barriers to entry:  almost anyone today can put together a whitebox PC from available components — take a trip to Fry’s or visit the Mom-and-Pop PC stores that still dot developing countries.  Design and manufacturing-wise, any decent team of hardware engineers can start a motherboard company is 9-12 months.  But how much time and money must you invest to ship your own processors, hard drives, DRAMs or LCD displays?  Ditto for brand and channel, which takes years and millions of Dollars and Euros and RMB to cultivate.

The global handset market, from its inception in the 1980s through most of its history, cleaved closely the legacy PC (frowning) ecosystem:  handset OEMs defined what is a mobile phone (especially a smartphone), and held value-added captive.  Nokia, Motorola, Samsung, LG, Apple and their cohorts essentially dictate(d) to chipset vendors and to OS suppliers the form and function of the shiny mobile baubles they produce(d).

The mobile business, however, departed and still departs markedly from its PC analogs in key parameters:

• handsets were (and mostly still are) content delivery vehicles (voice, data, video) and not stand-alone compute platforms (cp. pre-Internet PCs vs. modern desktops)
• core handset requirements were/are determined not by OEMs but by their channel partners, the mobile network operators (MNOs)
• wireless connectivity (GPRS, CDMA, etc.) while standardized as protocols and embedded in mobile chipsets, is not available to all comers:  narrow and deep silicon sales channels and certification/homologation requirements restrict who can field a phone in most global markets; building a quality radio set is still an art.
• while barriers to entry in building handsets notch incrementally lower, building and profitably marketing mobile handsets is still difficult and arcane

The introduction and increasing ubiquity of Android is leveling the playing field and certainly can have the impact described by Andreas:  lower-cost (cheap?) Android-based smartphones built by upstart Asian OEMs and sold through non-MNO retail and self-service channels.  But building and shipping quality Android-based handsets (let alone functional ones) has consistently proven more difficult than it should be.  Even branded T1 Android phones have received lackluster reviews. Moreover, while CES and MWC this year and last were replete with Android phone announcements, most devices have been late to market (or yet to ship), with underwhelming user experiences.

I do not argue that like the PC marketplace, the Android ecosystem is increasingly driven by applications.  Indeed, the Android Market is flush with thousands of apps and poised to give the Apple iTunes App Store stiff competition n the next 12-18 months.  But, for the moment at least, handsets, even smartphones are still phones first and application platforms second (I own Nokia Maemo devices but I use my iPhone all the time).  OEM expertise still rules in delivering mobile phones to market, more in concert with the notebook market than its whitebox PC parent.

The undeniable value-added of technology vendors (Qualcomm, TI, Samsung et al.), of handset OEMs (Motorola, HTC, Samsung) and of full-service operator-centric channel will for years keep the mobile market from grinning Stan Shih’s pearly smile, or even from flashing the notebook sneer.  Instead we’ll have the Mobile Handset Bite:

The "Handset Bite"

Unlike the PC Smile Curve, the Bite will be shaped by

• Android itself not adding value, but the hardware technology to support it doing so, as will key s/w components like CODECs, media players, home screens and of course, applications
• Upstart Tier II/III OEMs and ODMs adding little value to Android itself and the chipsets it runs on, but Tier I OEMs building Android handsets will enjoy better margins (sans royalties and subsidies), and delivering Android-based differentiated user experiences, hopefully/eventually on a par with Apple iPhone
• Cheap Android-based handsets flooding BRICK, developing and even developed markets through non-operator channels, with mixed results

So, to answer the question posed by the title of this blog — Yes and No.  Android will not commoditize the mobile market (more than it already is), but it will help to keep it polarized between Tier I devices with high value-added and the rest of the (commodity) pack.

Also interesting will be a new category,  emerging from Tier I OEMs – the Mass Market Smartphone.  More on this topic in my next blog.