10:15 AM -- I was interviewed this week by a major U.S. newspaper doing an article on Android. It was a follow-up article to one written last fall, and surprisingly to some, not much has changed on the Android front in recent month, albeit with an increase of chatter around potential first Android product introductions. But is that a bad thing?

There is an interesting dichotomy out there. The application community, and the Venture Community that finances them, are rightly tired of what can be perceived as a small global cadre of folks in the carrier community, as well as egregious application qualification processes, putting a chokehold on the deployment of innovation in the applications space. And the chokehold is stifling innovation and growth of the wireless data applications business. But as usual, the truth is not so simple.

So, as I am apt to do, I'll give a few examples. In my seven months since I’ve left Qualcomm Inc. (Nasdaq: QCOM), I’ve spent a lot of time looking at innovation and cool mobile companies, both on my own (for example as a judge in the GSM Association (GSMA) ’s Innovation Summit) and with various VCs, as well as companies where I am exploring direct involvement (investment, consulting, etc). Some of the things I’ve observed over last several months have been painful to watch. How do innovation, development, and deployment really work in a small company? A bunch of really bright folks get cool ideas, and get the venture capital community to fund them. As the ability to “monetize” (i.e. get money in one way or another) applications is still a challenge, the Business Development folks need to chase the carriers to try and cut a deal. Why? ‘Cuz there are only two ways to go about it nowadays…

First, "on deck": This is an application where the operator has the application readily accessible to their subscribers. This is complicated by the fact that certain applications will only work on certain phones or certain “application platforms” such as BREW, Java, Symbian, Microsoft, etc. If you get your application "certified" and "on deck," it helps a lot, as your app has in essence the operator’s seal of approval and sometimes marketing muscle. However, to get something on deck requires a costly (think lots of trips for business and technical staff, lots of field engineering time, lots of modifications to meet the direct requirements of operators one by one -- a hugely labor- and cost-intensive process for a small company).

The second way is to get around the operator, and have the app available "off deck." This means that folks need to search for it, which makes the marketing and user adoption much harder for a small venture-backed company to drive (and thus survive). Sometimes, but not always, there are still various certification processes for off-deck apps, but usually it is easier to get it out to wireless users than the on-deck variety.

Then if you are trying to simplify a discussion on open, even the simplification has to break down the various categories of open. There are hardware open, software open, and platforms. This is my version of simplification -- folks may have more or others, and they are welcome to join in the discussion.

Hardware open is when certain operators have announced that they are going to make it easier for various hardware devices, both specialized and broad market handsets, to get on their networks. Right now, it can often take several months (even six or up), along with associated human resources and development costs, to make it through a carrier testing pipeline. Again, I'm not being a "carrier apologist," but certain carriers more than others are VERY protective of their networks and brands, and I’ll get into some of those reasons below.

Software open is where folks develop on a platform such as Symbian, Windows Mobile, BREW, Palm, and now Android (which is also a hardware platform, further complicating matters), in a way to minimize or get around some of the on deck, off deck issues above. The problem with software open in the real world is that folks on the device side have had to modify requirements or hardware for a specific carrier or set of carriers and then discover that what they think is “Write once, and run, and more importantly, TEST successfully on many handsets on many carriers” is often somewhere between a challenge and pipe dream. Again, not out of nasty intent, or conscious desire to delay things, but something even worse... reality. Bottom line is that operators do not have cookie-cutter networks, they have a infrastructure that is an amalgam of many different vendors, platforms, technologies, etc., and this causes a natural tension/barrier/reality against any desire to have it be easy for folks developing software to various mobile platforms.

So what happens when you drill down? A vicious cycle starts to occur where small innovative companies can’t afford the time and resource constraints to get past carrier decision and timing points and get their app on deck, and getting apps off deck does not typically drive the opportunity to scale users and commensurately the ability to monetize (i.e. get cash) for the app. And if the company can’t monetize, then their employees, execs, and venture investors are not happy.

And then there are the stories. One REALLY cool company got a trial with a few operators. A small problem: Their application bricked (i.e. killed dead, dead, dead) the phones of some of the trial users. Other applications, usually written by folks that are accustomed to the massive memory and hard drives of PCs or Mac, are WAAAY too resource intensive (memory, processing power) for anything by the top tier of smart phones, and even with that tiny market, performance of the apps is often suspect. Another application (fixed now), kept a persistent data connection up between the phone and carrier network. This is a huge issue, as a lot of users still don’t have unlimited data, and if an app is sucking data without them knowing it, it could be costing them a fortune, let along putting an anchor on the data performance of the operator’s network.

A common denominator to MOST of the applications developers that I’ve met and spoken with over the last year (and the years before that at Qualcomm) is that MOST have NOT taken the time to really understand that wireless is NOT a wired connection. Sounds simplistic, but most executive and development teams in the wireless space are folks that have been developing apps for Web 1.0 and Web 2.0 that are now trying to mobilize existing applications, or taking great new ideas and creating a new mobile innovation from scratch. On top of that, there have been a few bozos out there who tell a great story, woo the VC guys, get funding, make a lot of noise with the press and at conferences, and then burn through all their cash until they start another company and begin the cycle again.

However, the vast majority of folks that I meet are incredibly bright, staggeringly driven, and wholly passionate about driving innovation. But, with very few exceptions, they tend to have spent a limited amount of cycles deeply understanding the differentiation and challenges of supporting various wireless infrastructure platforms, various wireless technologies, and the massively varying capabilities of wireless devices. Their field guys who have to work with operators and third-party vendors (i.e. billing system, roaming, data infrastructure, etc.) either understand it or learn quickly, but it’s common to see big disconnects between the real complexity of implementation, and the necessity of simplicity of the pitch on the biz dev or financing side. Wireless is NOT the Internet, and wireless mobile broadband cannot be treated as, nor does it behave like, its enterprise, cable modem, or DSL wired equivalent. Winning at this game is painful and time consuming, not glamorous.

For the operators, the simplistic reality is that the bottom line is the bottom line, and they CANNOT allow applications to either 1) raise their costs structures or 2) damage their brand/customer base, because when things go wrong with an application or phone, people blame the operator. Every piece of research I have seen (or conducted) over the past decade makes that point clear. And just why do operators need to protect their network? A few months ago, I saw a CEO of a major operator speak. In the Q&A, he mentioned as an answer to a question that it costs him a minimum of $8 per phone call to answer a support call. That’s not counting the pissed off customer factor and dilution of the brand that he’s spent billions of dollars or euros building. Additionally, let’s just look at one example of a new and amazing application getting deployed that has a persistent connection problem. Let’s say in a month, 5 percent of users are using the app and loving it. Nobody’s gotten a bill yet. As the app gets deployed, the perceived performance of some larger number of users for that operator go down (say 10 percent)... These users do not know what is happening, but their phone browsing is slower and their data cards are slower. Then the users of the app start getting their bills for hundreds or thousands of dollars because they did not know the app was sucking data continuously. Ugly, nobody is having fun. So along comes Google and Android. The idea is awesome and will be increasingly powerful over time. Create a hardware platform where lots of folks can make compatible devices, and create an applications platform where folks can write once and have applications that will run on these devices and across carriers. Here is Google’s overview: http://code.google.com/android/what-is-android.html

However, developing applications for Android will have its own learning curve and challenges. Spend five minutes and DEEPLY read this introduction from the Google site. Sage wisdom, but sometimes (all the time?) counter to the imperatives of an exciting entrepreneurial company burning through cash with products (and revenue streams) later then their VCs would like.

Android is a welcome addition to the wireless ecosystem and will be a driver of innovation, but WILL NOT be a panacea to the issues I described at the top of this missive. My belief is that a robust and “100 percent” Android platform will take longer than what is currently being pitched. This is not a value judgment, but a recognition of the complexity of what the Google folks are trying to drive and pull off. And their developers should not look at Android as a way to beta test apps on an unsuspecting public. A few public disasters on either the hardware or application side of the equation (and believe me, there are folks who will be looking for these disasters) and Android will be set back tremendously.

Android caused the operators to pay attention to open, and that is a good thing. The operators have hired folks, talked about increasing access of new apps and devices into their network, made commitments to the public and financial markets. This is all good and, at the margin, will increase the flow of more open devices and applications. But the operators are STILL NOT GOING TO LET THIS STUFF KILL OR DAMAGE THEIR BRANDS OR NETWORKS. Ain’t gonna happen. A few examples, good and bad: Bad: At a recent developers conference, an operator was telling a story of a section of a city where service parameters all went to hell, cells shrinking, customers losing service. They tracked it back to an enterprise customer that had gotten permission to test a new piece of hardware, and that hardware was causing nasty network effects. Bad. Another example, not as brutal, is when several applications that, when I asked about some trial metrics, with persistence (or even no persistence but frequent network access) were impeding customers' ability to make or receive voice calls. Very bad, again -- something operators just ain’t gonna allow because when these things start to happen, customers are going to look down at their phone, look at the logo on the phone, and get pissed at their operator. And pissed off customers churn. And churn makes operators' metrics look bad. And bad metrics make financial markets unhappy. And unhappy financial markets make operator executives lose their jobs. So it just won’t happen.

Good: The Amazon.com Inc. (Nasdaq: AMZN) Kindle. I love the Kindle, somewhat for what it is now, but more for what it represents for the future. It works, it was developed with the operator (an actual example of a good move by Sprint Corp. (NYSE: S)). The user does not know or care that the “Whispernet” that drives one’s book, magazine, blog, and newspaper downloads is Sprint’s EV-DO service. It just works, and if there are problems, Amazon gets the call, Amazon incurs the support costs, Amazon takes the brand hit. When it’s working (and I’ve yet to have any type of problem), Amazon gets new revenue streams, Sprint gets another device in their network, and Sprint sells a bunch of EV-DO data bits hopefully at a profitable price. The anecdotes one sees about vending machines, meter reading, equipment/asset tracking, heath care devices, etc., all fall into this category. They're incremental applications and incremental devices, but they're executed in a way that the provider of the device takes the support or brand hit if something goes wrong. Not thrilling for folks that want to generate a "killer app" or a startup that might be projecting 10 million devices in year three, but there is a route that the operators will accelerate by definition -- devices that add incremental volumes where the operator does not take on network load, customer service, brand, or credit risks. The iPhone was a massive exception to this rule with the 2G flavor, but Apple is Apple, and with the iPhone 3G, there may be some increasingly wary customers and operators out there (full disclosure: I own Apple Stock, and have a bunch of iMacs and iPods, and I’m wary).

It’s either the “good” route, or the painful slog that a whole bunch of successful gaming, enterprise, GPS, contact, backup, and music companies have made it through. Get it right, build it up, strike a balance between the pain of making it through the operators' application hell mill, and have something robust that consumers and businesses are willing to pay for once the apps make it through to the other side.

In my view, that will be a basic filter for how open will evolve. Google is to be complimented for making the investment, as well as driving the operator and vendor community to find ways of broadening and accelerating the whole process. However, operators, consumers, and enterprises have never tolerated, nor will tolerate, being beta testers for supposedly open apps that are not ready for prime time. Open cannot equal beta. A finished product is a finished product and stands or fails on its own merits. A painful truth, but one that offers both a challenge and a reward for those that understand what that means.

— Jeff Belk is a principal at ICT168 Capital LLC, focused on developing and guiding global growth opportunities in the Information and Communication Technology space. He can be reached at [email protected]. Special to Unstrung