There's not much question mobile devices exploded last year. In 2005, more than 750,000,000 new mobile phones were shipped worldwide, and over 75% of them were more than just a voice handset: they include a Web browser, a contact manager, a calendar, a mail client, or Java. These are small handheld computers disguised as phones.

This year, millions of new phones will have enough horsepower to run Linux: 140MHz CPUs with megabytes of memory. This will mean big opportunities for Linux games, utilities, and client software that run on the handset.

But handheld device software isn't the killer app. The real opportunity is to make these phones into clients for distributed applications. That can mean transactional clearing, or location-based services, or custom applications. Thanks to tools like Eclipse and client-side frameworks like J2ME, creating these new applications can happen easier and faster than ever before.

But even those applications aren't the killer app for mobile handsets. What everyone is looking forward to is an equivalent of a RIM Blackberry, but without the hardware lock-in, high monthly costs, and patent issues. The killer app will be "push" e-mail, with over-the-air synchronization of messages, appointments, contacts, and calendars. Fifty million people have been willing to spend $500 on devices and hundreds of dollars a year for proprietary services. Imagine how many would demand this service on low-cost phones, along with the cost structure of Open Source.

Mobile E-mail Standards and Open Source
E-mail systems have proliferated through standards. Early systems, such as PROFS, created perhaps a million mailboxes each. POP/IMAP/SMTP and other standards have fostered the growth of e-mail worldwide - to more than 1.4 billion e-mail accounts - and Open Source implementations of these protocols are widely available.

These e-mail standards were developed for networked servers and clients with continuous connectivity. But the mobile world is different:

• Mobile devices have weird connectivity characteristics (particularly as users roam other networks);
• Mobile networks haven't been reliable enough for data, or have throughput that varies during a connection;
• Mobile devices have been underpowered and haven't had enough memory; and
• Mobile developers seem to need arcane knowledge of device peculiarities (screen characteristics, keyboard mapping, timing issues, etc.).

By the end of this year, more than a billion devices will support SyncML, the data synchronization standard backed by the 300 vendors in the Open Mobile Alliance (OMA). The SyncML protocol supports both Personal Information Management (PIM) data synchronization and push e-mail.

The OMA standard has been implemented in Open Source, on both the client and the server side. The Funambol project (formerly known as Sync4j) has been downloaded more than 200,000 times in the last year alone, making it the world's most popular mobile Open Source project. Funambol v3, released last month, adds full push e-mail support. There's no doubt that Open Source software and standards will do for mobile e-mail what they did for the explosion of the Internet.

Where Open Source Software Meets Mobile Development
The mobile market is unique in its rate of innovation and device proliferation - 800+ million new mobile phones will sell in 2006, with dozens of new models introduced every quarter. The rate of innovation in mobile handsets creates price competition and fads that drive high demand - so diverse devices are the rule in this marketplace. But all the myriad devices must be compatible with networks worldwide and the value-added software from third parties. For the Network Effect to work - where the value of a network service grows with the number of devices connected to it - high volume and diversity must be accompanied by compatibility.

This is a testing and certification problem never faced by the IT industry before. In many cases, carriers have had to turn off innovative features in devices because they weren't reliably compatible. Vendors do conventional compatibility testing and focus their limited resources on their brand of phone. They can only afford to do so much.

Fortunately, the Open Source development model provides a decided advantage here. Every community member who owns a new device has a personal incentive to get the device configured and working properly, so they quickly find which firmware revs work and figure out workarounds to make sure the one with bugs still work. The community can achieve more breadth and depth of testing than proprietary vendors could ever hope to achieve.

Open Source solves an even deeper area of compatibility: rapid compliance. Open Source projects thrive when implementing standards, moving them forward more quickly than any proprietary vendor would ever want to. For example, OMA has been moving the mail synchronization standard forward at a speed that vendors want. Meanwhile, the Open Source community has created production-grade software that implements the entire standard - and this product will be commercially available within days of the final specification.

How Open Source E-mail Gets Deployed
Carriers and enterprises have already deployed proprietary push e-mail systems, so they have expectations and migration issues to deal with. Typically, they're looking to replace a working proprietary system with minimal disruption. The first phase usually takes place in a lab testing environment. Even though these are not production systems, it's best to use Open Source only for the subsystems where it's essential. The Open Source systems are often used as test-beds for testing device compatibility, both for PIM data synchronization and push e-mail updates. In this role, the Open Source software gains credibility quickly.

For example, a large European mobile carrier uses mobile Open Source software as the basis of its device compatibility test-bed. New devices must go through this internal certification test lab, and the software is now used as the reference standard for device compatibility.

The next phase is typically a pilot project involving a new group of users and new low-cost devices. Since commodity handsets have a phone keypad instead of a QWERTY thumb-pad, it takes a while for users to get comfortable dealing with e-mail. A good first step is to deploy PIM synchronization, since this provides user value without a lot of keypad input. The goal here is to minimize negative user experiences and get as much credibility for the system as possible.

The large deployment phase that follows must involve a wide range of devices. For high-end mobile devices like Microsoft SmartPhones some plug-in software will be required to support the standard protocols. For other phones, it's a simple matter of configuration options for the OMA/SyncML features. Since large companies may have hundreds of different phone models, it's essential to put up a user portal before the service's broad rollout. It's a good idea to encourage community self-help dynamics (e.g., submit a workaround, win a prize) via the portal to keep costs down.

Delivering a Complete Product
For SIs delivering a solution, ASPs creating a service, or ISVs selling a subsystem, using Open Source in the mobile world presents unique challenges. The carriers and service providers in the mobile market have very high standards and often haven't deployed any Open Source technology of any significance.

So, it's far more important to fit in with their internal infrastructure than it is to deliver a pure Open Source system. Each customer will have its approved brands of infrastructure, and it will be a deal breaker to insist on moving in a new database or application server. This means designing your product to be as agnostic as possible in the areas where you have software dependencies (translation: don't use proprietary extensions). Test your product on top of the market leaders no matter how proprietary. Certify your product on back revs of the infrastructure: many carrier environments allow upgrades only once a year and their approved standard is the version that came out two years ago.

Be ready to certify and support your product with stringent Service Level Agreements (SLAs), including penalty clauses for non-performance. These customers know they'll have to pay for "no downtime" and fast response, but they need you to deliver. Just because your technology base is Open Source doesn't mean they are expecting "free."

When Will Mobile Vendors Jump on Board
Mobile device makers like Nokia, large software vendors like Computer Associates, and network operators throughout the world have licensed mobile Open Source software. They recognize Open Source as an unstoppable force and beneficial to the market overall. Indeed, even proprietary mobile software suppliers such as Intellisync now predict that Open Source will be good for all parts of the mobile marketplace.

The question is, when and how?