Mike Rowehl: This is Mobility

There seems to be a lot of “take it for granted” style discussion around the possibility of Android fragmentation. Without strong top down control of the platform, folks seem to think that we’re going to end up with hundreds of versions of Android, all slightly different. This was the nightmare that mobile Java became. There were large engineering teams dedicated to and specialized in taking your write-once-run-anywhere app and actually getting it to work on the volume of handsets you wanted to hit.

It’s true that technically anyone who wants to build a slightly different version of Android can, so in that sense there CAN be fragmentation. However, the ecosystem has also fundamentally changed. Before we had the carriers tightly controlling the channel, dictating what was in and out in terms of hardware, enforcing strict standards on the software they pushed to users, and doing everything they could to keep anyone else from pushing software to users. In that world the burden of dealing with fragmentation was with the developers, and the benefit went to the carriers. The carriers controlled the channel, so fragmentation continued.

The one lesson that everyone in mobile seems to have learned over the last year was that the carriers were really bad at determining the right hardware and managing that application and content catalog. It’s why everyone is jumping on the App Store Bandwagon. One of the side-effects of that is that it breaks the strongly controlled content and application channel. If ATT decides that their Android version is going to do Bluetooth slightly different, sure, go ahead. But how can they strongarm Android developers who produce Bluetooth apps into making an ATT specific version? The control isn’t really there any more. Developers might do it, but only if ATT is offering up enough incremental sales revenue to make the port worthwhile. Right now developers frequently do it cause they’re contractually obligated to if they want ATT to promote their app.

Anyone who’s worked in open source knows that forks are technically possible, but practically uncommon. When the “market” is completely open folks tend to follow a path that serves them best. And it’s a reinforcing path. Even when someone with vested interest tries to keep a fork distinct, normally the burden ends up being more on the controller than anyone else. Forks tend to get folded back or die off pretty quickly. I think the same thing should happen with Android. Sure, people might try at the start to get a leg up by including proprietary features and customizations. But in the long run if Android as a whole works, the only person they’re hurting with a fork is themselves (to the tune of a decreased application catalog). And although it’s possible for them to create a custom application catalog with some differentiation in the short term and attempt to keep that differentiation going, there’s no difference between that and the strongly controlled channel that we currently see failing today. The cost of trying to do so will outweigh the benefit of joining the mainline.

Looks like the official cupcake release is delayed a bit I was able to do a manual install of cupcake on my dev phone (Thanks Debajit for the pointers!). Top feature I was looking forward to is the onscreen keyboard. Especially somewhere like the browser, it was always a pain before to have to flip open to type something, flip closed to view, flip, flip, flip. The onscreen keyboard has been working great. Few mistyped letters here and there, but I still do that on my iPod touch as well, so I’m not faulting it that.

Probably the most interesting point from converting over (I’m going to try carrying my Android phone instead of the E71 for the next two weeks and see how that goes) was actually more service than phone. The contacts app has an option to copy contacts off the SIM, but I always have too many phonebook entries for that to work. I run out of storage space on the SIM trying to copy my contacts over.

So what I had done last time was use Funambol to upload my contacts from my S60 phone, and then downloaded the connector app to my G1 to pull down contacts. It worked okay, but some of the data was somewhat munged (most contacts ended up in “last name, first name” format when they came over to the G1, and it just looked ugly). I was going to do that again to sync over the new contacts I have on my Nokia. But then I remembered that Nokia Sync supports S60 now, and decided to give that a try instead. It ended up working out quite well! Once I had my contacts all cleaned up (and now they live in gmail, where I get a lot more use out of them) syncing back to the Nokia seems to work almost as well as syncing from the G1. Have to see how it works over time, but it looks good. Getting S60 supported in Google Sync is a pretty slick move in terms of being able to entice over new users to Android.

One thing that still doesn’t work out quite perfectly for me is the account support. I have a main Gmail address I use for all sorts of personal stuff, and collects a half-dozen of my other email forward currently. It’s where I’m connected to folks on Latitude. Then I have a Google for domains setup for work, and that’s where I store my work emails and my actual calendar. Problem is I can’t get this mix of accounts to work quite the way I want them to. I would like to use email with both inboxes (and default to personal email when other apps are sending by default), I would like calendar to use my apps for domains account, and I would like maps to use my gmail account (I put a little Latitude badge in the sidebar of this blog with a happy little motorcycle zooming around wherever I happen to have last been, I love it!).

So what I’ve ended up with is my main gmail account embedded as the base setting in the phone, and using the browser to access my work email and calendar. Not horribly slick cause I don’t get notifications. However, the browser uses local storage for both calendar and email, so they’re available offline. Unexpected and very welcome! Still, I would love to see multiple account support in the native apps. But I’m going to have to fool around with the browser capabilities in this release. The mobile mail app in the browser is making me drool. Great stuff.

I also downloaded the 1.5 update of the SDK to poke around still. Seems like from the application developer side Android is getting little love. The number of devices in market along with the demographic skew of the audience just don’t make for a compelling target. I’m pretty anxious to see how the upcoming devices shift that however. I’m hearing lots of the old hands from mobile saying that the lack of a formal program to facilitate OEM integrations is a limiting factor in how fast Android can spread. Lots of manufacturers might be interested in it, but they tend to flail around when trying to get projects done with it and have no one to turn to. I’m definitely still rooted in the “cautiously optimistic” camp. The way that should work out with Android is that someone will put together a professional services firm disassociated from Google to help those folks plan and implement their efforts. And I think there’s still plenty of room and time for that to happen.

I posted yesterday about wanting to use my phone to publish my location in realtime, and I got a bunch of fantastic responses both in the comments and as emails (thanks folks!) I fooled around with some of them with varying degrees of success. Nokia Sport Tracker seems like it would be great! However, I can’t figure out how to make the phone app do it’s job. Maybe my fault, I have an E71 and it’s not listed as a supported model. I’ll have to dig out my N95 and try that one. However, on the Android side, I put FirePin on my phone and was able to upload and share out info about my route (course, it only has to points, cause I have the phone on wifi only right now). FirePin supposedly also works with FireEagle based on the comments I got. But I can’t figure out how that’s supposed to work.

Generally I’ve been hearing frequently about how location based services are really starting to happen this time around. Yea, yea, I know. That’s what we’ve said every year for the last decade. Don’t even bother, I’ve heard it all before. However, this time we have some open platforms with GPS built into the handset, which means there’s a way to work around most of the problems inherent in the carrier based system we had before. Any by “problems” I mean “crippling cost structure”. I can kinda understand how that seems like a more mature market for location based services. Because end users can grant permission to an application for it to directly grab location info, there are all kinds of services out there.

However, I would hardly count that as platform maturity. That’s a degree of market maturity, but not platform maturity. Sure, it’s easier to build a location based app. Just plop your application into any one of the silos that folks have built to control the deployment of your application and management of your data, and blammo! New app. Yea, not the way I normally think about these things. Which is not to belittle the efforts like FireEagle, I just think there are a few missing bits.

Here’s the kinds of stuff I was expecting to see:

That basic set of functionality is a write-once bit of infrastructure. It gets us out of the “Oh yea, FirePin is great!! Wait, no, you can’t use it on your Nokia”. Not that the tools won’t evolve. But there should be an open set of base clients for all the different mobile platforms, and then anyone who wants to build a web app that pulls in location info can just say “Okay, add local.rowehl.com:9900 to your location client to start updating the Mike-o-matic pile of gold finder app with your current location” Instead we have all these different point solution client applications, frequently hardcoded to send location to a given server. Dumb.

There’s a package now for installing X11 on the G1, which builds on the Debian for G1 package. I haven’t fooled around with the stuff yet, but what am I interested in running with access to the full set of Debian software? Well that should be obvious. Metaspoit of course. Cellular interface + Wifi interface + handheld device + automated security scanning = fun!

A friend over at Google provided me with an unlocked Android phone, which I’ve been poking around with here and there doing some development. I hadn’t really poked around with the phone itself all that much, meaning looking at hacks and usage tricks and whatnot. Yesterday I decided I wanted to update to the latest firmware (RC33) however, so the journey began. I have my G1 running on the AT&T network, which is where some of the complexity comes from.

I started out with the normal instructions for manually installing the RC33 update, which are pretty actually slick and simple. However, I was getting a failed check when trying to install the firmware. I assume there’s some internal ID that identifies the phone as a TMobile phone or not, and my dev phone doesn’t have that, so the installer was throwing some assertion failure check. So I figured I would try out one of the jailbroken images if I’m going to have to muck around for a while anyway.

There is an alternative version of the RC33 update available, called the JF33 sometimes, and other times the JF RC33. The JF stands for Jesusfreak, the forum user who repacks the roms and has apparently provided test keys that can be used to downgrade a unit. Once you know what you’re looking for, there are tons of posts in forums and blogs all over the place. The problem is just figuring out what you need to search for.

The process goes something like this:

It was a bit of an involved process to get through. And at first when I installed the RC29 firmware and had to re-activate, I was afraid I wasn’t going to be able to do so without a TMobile SIM. Just a bit of APN hackery took care of that however. Phew! Now I have Latitude working in maps, and root access in the terminal. W00t! Back to developing now.

I’ve been sick for the last few days. Perfect time to put a bit of a dent in that ever-growing pile of unread books next to my bed! Which I began doing without hesitation, until I kept running into cross-references to other books in Dreaming In Code. Some of the books I know I’ve read, others I know I should definitely pick up, others I’m not sure about. Have I read them? Do I own them? As I scan my bookshelves looking for my copy of The Soul of a New Machine I re-realize that I’ve already cleared the unread book stack a few times. Now there’s a bunch of still-very-interesting unread stuff mixed in with the filed-away-for-reference stuff. Maybe it was because I was reading Dreaming In Code that I began suffering from delusions of adequacy, but I thought “I must organize this!”. Maybe it was just the Nyquil talking.

First thought was along the lines of “there must be some software out there that will do this for me already.” Lots of stuff for OS X, but I’m on a Linux system most of the time. And the the most promising of the Linux based cataloging software crashes immediately on window move or resize on my 64-bit desktop system. Maybe that’s not the way to go. I want something quick, easy, and hopefully composable into other usages.

How about something for Android? I’ve been fooling around with developing some Android stuff. And they have Zebra Crossing, a prepackaged lib for barcode scanning. I should be able to find something floating around out there that should make it easy to just scan a whole bunch of barcodes. I can use that to make a big list of ISBNs, and then feed the stuff into a combination of ISBNdb.com and Amazon lookups to make myself a database of my books.

In poking around looking for a simple barcode scanning notepad kind of app I saw the Oilcan app sitting on my Android desktop. Oilcan is a browser wrapper that lets you plugin Greasemonkey style extension scripts into the native Android browser. One of the examples that comes with Oilcan is an extension that allows you to scan barcodes directly into the input box on m.half.com.

It took about 5 minutes to turn that into something that would use a page on my own server to make me a database of scanned ISBN numbers. No native coding required, which I thought was pretty interesting. One thing to pay attention to is the supper aggro caching that the Android browser does, make sure you insert cache control headers and meta tags. Instead of ending up with a one time throw-away tool to create a list of ISBNs, I’ve ended up with an online service that I can use to toss other barcode based info up to my server.

And most importantly, I’ve found a way to use creative coding to procrastinate my way around actually getting done what I set out to accomplish. Happy 2009 everyone!

One of the points I was harping on at and around the Symbian Partner conf were my perceived issued with the Symbian Signed effort. As a developer I get no benefit out of the initiative, but I’ve commonly felt some pained incurred by it. David Wood also just posted about the basic principles of software signing, so apparently it’s on his mind too.

I’ve already put down a bunch of my gripes about the current system. But if we want to break it down to basics, there are a few questions that I think we need to answer about a signing process. I was going to try to lay then down in some form of coherent order, but I have a rapidly evolving situation that needs some tending to. So here they are in jumbled rough form:

Damnit, gotta run. Give David some feedback if you can, I think he’s headed in a good direction with this conversation.

I went to the Symbian Partner Event yesterday, and then grabbed some dinner with a bunch of folks from Symbian and Nokia afterward. Most of what I was interested in hearing about was how they plan to convert to open source. There’s some info up already at the Symbian Foundation website, but that’s all very much marketing oriented material without too much detail about the major important factor - the code. Charles Davies gave a presentation toward the end of the day that laid out some additional details though.

The folks at Symbian and Nokia are just putting together the disparate code bases they work with and trying to unify the layout. They’ve been breaking up the code into sets of modules, it’s looking like there will be about 100 modules all told. The code roughly breaks down into operating system elements, middleware and API elements, application elements, and then some desktop packages. Not everything is going to be open sourced right off the bat, they’ve mentioned that before, due to encumbrances of existing licensed code in the base as it stands. Whole modules will be open sourced however, so that when you get some code it should represent the full set necessary to understand and debug a particular function. I was concerned initially that the open sourcing might follow some kind of horizontal stratification, which would be a lot less useful to anyone looking to dive in and understand how something works.

Which leads to the next question, if you’re a developer at least, can I compile the open source bits and run them somehow? I asked David Wood that later on in the evening, are the parts that aren’t open yet going to come in a binary form that I can use with my own compiled modules to link up a running system? Actually, that is the plan, but the details are still getting worked out it seems. Which would be awesome, I would love to be running a hacked version of my E71 firmware that adds a few functions to the standby screen. However, the partially open model is going to mean that porting to a new platform isn’t something that the standard basement hacker could undertake for a while.

The other interesting bit in his presentation was their approach to branding and ensuring a consistent platform across Symbian based devices. They’re actually putting together a software test suite to exercise the APIs and behavior of a base system and using that as the yardstick for compliance. And the test suite itself is part of what goes out as open source. If your product passes the test suite, you should be good to go. Very nice.

Overall though I think the foundation has some learning to do still about interacting with developers and really enabling a larger ecosystem. Lee Williams, the current Executive Director for the foundation, spent an awful lot of time bashing the Apple and Google store models because they’re old style thinking “control points.” And people need to get away from thinking in terms of control points and start thinking about enabling. So I asked a question about application binary signing, which is an excellent example of control point thinking and a common stumbling block for folks looking to do Symbian development. And his answer was pretty much “Well, that we need because this is telecommunications, and that’s the way telecom works, it’s actually a benefit not a hindrance” and went back to bashing Apple and Google. Booo. Bad form.

Fortunately David Wood and a few folks from Symbian where around later on to pick up the conversation that Lee tried to shut down. Although signing will probably exist going forward in Symbian, they are looking at reworking the mechanism and making things easier for developers. In particular I tend to use the example of getting GPS support into Python for S60. One of the benefits of Python on S60 is supposed to be that you can develop for it without having to get into the details of dealing with the standard SDK (great for me, I don’t use a Windows machine). You cut off that benefit if the developer needs to sign Python modules in order to get access to the interesting functions. In my mind Python is great to enable prototyping and experimentation. Exactly the areas where you would like to expose new and enhanced functionality. I think some of the folks heard the message, but it certainly wasn’t universally received.

Hopefully this is a learning process, and we’ll see the Symbian Foundation folks moving more and more toward genuine open thinking. Right now there seems to be a mix of marketing oriented open thinking together with some deeper understanding of the technical benefits of being open. That’s one of the nice things about being open however, it’s a model that tends to overtake other models.

One of the most common reactions that “mobile experts” have when new converts start waxing poetic about the iPhone is that the iPhone is just a niche device. “It’s only really popular in the US, you need to start thinking about the billions of devices out there in the market” is something I hear pretty frequently. Especially from people at Nokia. They love to talk raw numbers of handsets, cause that’s the leverage they have. And when someone starts saying things like “think about the bigger market” and “address the global audience” it just seems politically incorrect to disagree with them. I mean, it’s gotta be a small-minded move to think about just the US right?

I’ve made that argument over and over again actually, so I’m intimately familiar with it. It sounds so good, and it gives you a warm fuzzy feeling for thinking expansively. And of course some of the top level numbers seem to support that being a good idea. Hell yea, there are billions of cell phones out there in the world. Why bother going after a market of 7 million when there are billions out there!! Crazy right? So allow me to explain why it makes sense. Cause the entrenched mobile market is in some real danger here, getting actively blindsided by new devices and market models. Fingers in their ears. Vehemently denying that anything has really changed.

The first and foremost is this misconception about addressable audience. People throw around the 3 billion number quite a bit, cause that’s the number of cell phones out there. But that’s not your market size. Spend some time with venture capital guys and you’ll eventually catch them joking with each other about the prototypical entrepreneur who walks into their office and claims their market is “everyone with a television” or “everyone who wears shoes” - breathlessly exclaiming that if they just “capture 1% of the market in the first year they can make 10 billion dollars!!!” It’s pretty ridiculous to think that just because there are X of something out in the market, that your potential market size is X.

First of all not everyone with one product automatically wants a complementary product. Even if it’s a great complementary product. Second of all your market size isn’t just an installed base, it’s installed base and ability to reach the customers who make up that installed base. If you have a small number of customers who are easy to reach sometimes that’s better than a large number of customers who it’s difficult to get to. Don’t take my word for it, read some Steve Blank and let him explain it. A few years ago the only option was to reach a localized audience for high cost, or a global audience for high cost. The decision was pretty easy, go for the larger audience. But now you can reach localized audiences for a much lower initial outlay, so there’s a real decision to be made. I don’t think it’s a done deal to be always going after the global market.

There’s also the need to make money. This was a common topic of conversation at Mobile 2.0 this year again. Sure, emerging markets hold a ton of potential. But how do you make money off addressing them? They’re relatively hard to directly monetize. You can make your application so that it’s relevant and usable by people in Africa and China, but if you’re looking to sell it for a few dollars you cut a bunch of volume out of those markets. So you take the millions of people in those markets and reduce it down to the number of people able and willing to pay a few dollars for an application. I have no idea what the percentages would be, but there isn’t too much disposable income floating around there. There’s an associated cost to the application developer in setting up and maintaining payment systems in different areas. And don’t tell me that going through a third party payment provider allows you to address a global audience cause that’s a lie. I’ve worked on it, and there’s customization to be done for different markets no matter who you use. So don’t even try that one any more, I’m officially calling bullshit on it.

The common answer to that is to monetize through advertising. Awesome. That’s a very engineer friendly answer to the problem. It’s true, most problems can be solved by adding an additional layer of abstraction. Unfortunately someone eventually has to make money, and in this case the additional layer of abstraction just hides the problem instead of reducing it. The reason that advertisers advertise is so that they can make money off the audience. If you weren’t able to make money selling to users why should other advertisers be able to? Sure, there are plenty of cases where the diversity of offerings from an advertising network allows for monetization of an audience where a single seller couldn’t. But if the underlying problem is that the audience doesn’t have money to begin with that changes nothing. The value of an advertising audience is the size of the audience multiplied by the average amount of capital you can extract from a member of that audience. It doesn’t matter how large the audience is, anything times zero is always zero.

And there’s the problem of, you know, actually making your application work globally. Another common theme from the conference again this year was context and making applications use the unique features of being mobile. Mobile isn’t just about taking the desktop web or application and jamming it onto a small screen. You need to build on the unique capabilities of handsets and mobile networks. Unfortunately there’s very little global thinking about how to make that happen. We had a panel of folks at Mobile 2.0 talking about their developer programs, handset manufacturers and carriers/operators. They were talking about how they’re helping developers build for their devices and networks. Seems nice on the surface, but that’s not how things should work. Take development for PCs as a model. If I was looking to develop for PCs and had to join Dell’s developer program to get into about developing for Dells, and then Gateway’s developer program to make my app work on Gateway, and then Toshiba to make my app work on Toshibas - and then have to worry about differences between Comcast and Savis and Internap at the network level. Nothing would ever get done. But when I asked folks working on these program about what they’re doing to provide base consistency so that mobile development could work like PC development I mostly got confused reactions.

So why develop specifically for the iPhone? Omar actually summed it up extremely well at the Mobile Web Wars event a while ago. The iPhone has a full ecosystem. It might be small right now, and it might seem like we’re just exchanging multiple overbearing overlords or a single overbearing overlord. But the iPhone is that juicy segment where development is consistent (cause it’s one OS and one device), there’s a way to reach audience directly (via the AppStore if you can get on there), and the user primarily are in affluent areas where advertisers are looking to spend dollars (and part of a great distinct demographic for the most part on top of that). So fricking start paying attention people. You can’t dismiss the iPhone cause the overall numbers are small (unless you’re a VC, then you can continue to poo-poo the small overall market size all you want, that I’m not going to argue against). The specific numbers are compelling. People are still making noise about the iPhone cause it works.

Of course, this doesn’t change the fact that I’m a bleeding heart mobile booster. And that I would love few things more than to have a real global market for mobile solutions that application developers could actually address. It’s going to take some different thinking however. If you can’t make money from directly selling to customers in emerging markets, and collectively they don’t yet make a compelling audience for media plays, what do you do? Well you could let those users create value and skim some off the collective. Take the Amazon Mechanical Turk as an example. Think of it as a way to do micro-outsourcing. Mob4Hire in particular is applying this to mobile already, with a crowdsourced system for doing mobile application testing in areas where it’s normally difficult to get access to different handsets on particular networks. Fantastic.

I’m also a believer that the best people to build solutions for emerging markets is the people in those markets. That’s the idea behind efforts like FabLab and (though not everyone believes it) One Laptop Per Child. Folks living in developed areas normally aren’t familiar with the particular constraints and challenges that go along with living in these other areas. The best way to service them isn’t to do product development in the traditional sense, but to provide hackable systems that allow users in these areas to tailor what they get to the situations they have to deal with. That’s one of the reasons I hold out a lot of hope still for the Linux based mobility efforts, particularly Android, to help these markets move themselves through the progression so that people stop thinking of them as low yield media targets.

Overall though I think it’s kind of ridiculous for folks inside of mobile to be crapping all over “the iPhone hype” while doing little to nothing to help move mobility as a whole into a state where us application developers really can start to address a global audience.

Gregory and Matt invited me to participate in a developer focused pre-event session on Thursday right before MobileBeat 2008 kicks off. The session is going to focus on the evolution of mobile operating systems and services platforms.

It should be interesting, cause in general I think the services platforms are a load of junk, and mobile operating systems are generally moving in the right direction. The services platforms are fundamentally mismanaged and misaligned efforts to try to replicate the success of user generated content from the web and apply it to application development for mobile platforms. Generally they seem to be shiny trinkets to dangle in front of business folks to make them salivate over addressable audiences, but I know of very few successes running on top of any of these platforms.

Compared to say something like GetJar, on which I’ve heard good feedback from both existing businesses and entrepreneurs looking to bootstrap distribution. The iTunes App Store could be the counter example, but I think it’s too early to know for sure. Too bad the iPhone as an overall platform isn’t one that I would pick out as a real boon for developers, generally closed off as it is. Still, everyone seems to fail their saving throw vs. shiny when an iPhone shows up, so they could have at least a sustainable success going there.

Should be a great discussion. If you want to attend make sure to contact Jacob as described in the post. Even if you have a ticket for MobileBeat, this is a different deal. The folks at MobileBeat need to know how many folks are going to drag themselves out of bed for a 9:30am session. This is a developer focused session after all, that’s like 6:30 in the morning in real-people time. Hope to see you there!