First off it’s necessary to understand how businessy folks view open source. I have no idea how many of you who read this blog were around for it, but this was a huge raging debate in the early 2000s. How could it possibly make sense for a company to just give away something that it had sunk a huge number of hours into, and potentially represented some significant chunks of intellectual property? The argument that really won the day centered on a concept called commoditizing your compliments. See this blog posting from Joel Spolsky for a bit of background on the economic principle. In terms of software it means giving away the stuff that won’t make you much money so you can make more money on the stuff with good margins. If anyone out there can make an alternative argument for why HP would open up the OS have at it. But I’m going to stick with the assumption that they’re positioning for a market shift in which the stewardship of the mobile OS itself is a commoditized low-value position.

So what’s the complement of a ‘platform designed from the ground up to be mobile, cloud-connected and scalable‘? Traditionally hardware has been the mainstay for HP. And it would make a kind of sense if they were looking to open up the OS and have folks integrate their own platform components in order to be able to make more hardware work together. They could be looking at the suite of iPad, iPhone, Apple TV, and iTunes and be thinking “Uh oh, Apple is starting to lock up the whole electronics space though integrated media components.” Which means if they want to keep playing in those markets they have to be able to catalyze a similarly optimized delivery channel if they want to keep a seat at the table. Possible. But I don’t think it’s the most likely one.

Another complement to webOS would be the stuff sitting on the other side, the cloud-connected part. That end would certainly line up with the software is eating the world idea that Marc (one of their board members) has been putting forth. Plus, it’s generally a bad idea to attack someone head-on when they’re in the kind of position of power that Apple is in. You try to look down the line to where their model extends and try to find a weakness. And while Apple has been fantastic on the merchandising side of the iTunes/App Store world, generally speaking their efforts to expand their cloud service offerings have fallen flat. If I were backed into a corner and forced to try to find a gap in the armor when competing with Apple, it’s the place I would go.

Since the full webOS stack is actually Linux under the hood, I assume it has an opportunity to capture a chunk of the Linux embedded system market the same was as Android has. As someone who spent way more time than I care to remember configuring and rebuilding Midori systems, I assume the more we can do on that part of the market the better. My fear though is that this opening of the platform is really just an attempt to try to get some free development. I’m sure that the folks involved at the top (like Marc) genuinely have a vision for everyone benefitting from opening up webOS, however it’s really easy to spoil an open source community down in the details even if your heart is in the right place.

If I put my rose colored glasses on and try to look into the future for webOS I see a future where the inherently web-connected OS manages to pull us out of this siloed mobile experience we’ve ended up in. It takes the best of what we’ve learned about putting services together as “apps” and reapplies that to the open web distribution model, and mixes in the deep platform capabilities from Android (for instance, I can write an app that accesses call log info. iOS GAH!).

However, to end up at that future we need an awesome technical platform AND distribution power. Products don’t win in market just for being the most technically awesome hacks. Otherwise we would all still be running BeOS today ;-) Unless there are a bunch of devices out in market running webOS it doesn’t make sense for third party developers to target the platform. And without a bunch of third party developers to write apps it’s hard to get a bunch of devices out into market (no one wants a phone without apps any more). So while I see a lot of awesome stuff that webOS COULD be, I still don’t see an obvious way to take it from where it is to where it needs to be. I don’t disagree with the open sourcing of the platform in general. It may be the right step along a roadmap. But because I have no idea what that roadmap is, I remain underwhelmed.

Like we were talking about last week, mobile advertising as a whole really isn’t delivering on the promise of the platform. So it’s great in concept that advertisers are willing to try out something new to find the value they’re looking for. But there are so many blunders in the campaigns from the delivery of the code itself to the post-click content… makes me feel like the last few years worth of mobile advertising hasn’t yielded any learning at all.

So here are some things to keep in mind. First off, when QR codes were first making the rounds even most of the higher end phones still had tripple tap text input when we were inputting URLs. So having a scannable code saved us some painful typing if the URL was long. And since folks were on their phone it made the most sense to link people directly to some specific resource to save them from having to navigate around. If folks were going to be scanning codes anyway, and the codes could store a decent amount of info, the advertiser could also include some additional tracking info in the URL so they could more easily segment their inbound traffic. Things are different now. That’s not to say there’s no reason to have QR codes at all, but their role has to be different.

First off, lots of us are on phones with keyboards (software or hardware) and very comfortable typing on them. Show a nice short url along with the QR code. It used to be user hostile to have to enter a URL, now it’s more user hostile to ask us to download a QR code to follow a link. Second, it doesn’t make sense to save me typing when entering a URL if you’re then going to take me to a full desktop version of a web page with a half-dozen fields on it. Third, it’s fine if you want to do some extra tracking of inbound clicks, but don’t force inconvenience on me in order for you to be able to track. I’m just not going to engage with your campaign at all.

Frankly, I think a lot of the uses I’m seeing are really misuses. Abuses even. The sarcastic side of me can’t keep from thinking there’s some advertising agency somewhere looking to crank up their bill with no regard for the benefit they’re providing the the advertiser or the experience of the user. But I’m going to be positive and not “attribute to malice that which is adequately explained by stupidity.” And hope that this is an opening where we can learn a bit and find some additional ways to get value out of everyone having a phone in their hand these days.

One of the first areas that always pops up for me when we talk macro level trends is mobile is advertising. Mostly cause I was wrapped up in AdMob early on, but I’ve also been involved in the previous iterations of online advertising (early banner ad plays back in the mid 90s, Overture back when it was called Goto, and RSS advertising). There’s currently a big disjoin in the understanding of mobile advertising because the health of the system differs depending who you ask.

If you ask someone at a mobile ad network how things are going, they are genuinely happy. They’re making more money than ever. However, if you talk to the people doing the advertising they’re generally unhappy. Cost of acquisition is really high and they have trouble getting value out of the users they’re able to drive. For the publishers they’re making less and less off their inventory cause there’s so much supply side surplus. So generally folks are left confused, cause they see numbers for the industry as a whole saying mobile ads are generating a ton of money – but the folks trying to make a living off running those ads are having a tougher and tougher time.

That’s the first shift to take notice of. At one point it was possible to put out an app for free, get a decent amount of sticky users, and make a pretty good chunk of money just running ads from a network. That doesn’t work any more. The folks who are actually pulling in significant money from advertising have setup custom arrangements because they have some unique traits to their traffic. And for the rest of the folks out there, because there are so many more apps out there also running ads, even if you generate a huge amount of views it’s increasingly difficult to break even.

Mobile advertising as a whole needs a lot of work to deliver on the promise of the medium. There are some great folks out there working on making that happen, so I’m sure it will change eventually. But in the meantime don’t get caught on the wrong side of the trend.

The second major area of discussion was around games and in-app purchases. This is one area of the mobile app store environment that consistently generates money. There are some nice repeatable models being run in mobile games. Should those of us not doing games try to borrow a page from the games folks and attempt to put together models that shadow the successes?

Definitely, there’s a lot to be learned from what’s working in gaming. However, most folks tend to hop right to “game mechanics” as the major takeaway. Trying to slap some level/badging system on top of an existing system doesn’t really drive any benefit. The pieces that we should be pulling out of the gaming world are the attention to user funnels, where to put your monetization events, and how to break down your offerings. The result of paying attention to those metrics generated the game mechanics and virtual goods based system that’s become the norm in games. Outside of games the same principles generate systems like Dropbox. The takeaway is replicate the process used to distill the model, not the model itself.

The third big area of discussion was the online/offline models. The folks like HotelTonight and GigWalk and TaskRabbit. They’re models where a lot of the value to the business is created outside of mobile, but mobile has provided them with a channel that wouldn’t have been possible (or as effective) via desktops. Most of us agreed that this is one of the most interesting areas. The folks working in these spaces are pulling in a lot of new value to the system, and they’re likely to end up with more robust businesses less at risk from platform changes.

However, the models here are just starting to shake themselves out. There’s lot of infrastructure to these services that hasn’t yet been packaged and replicated. Payments is probably the most obvious area, where payments for offline goods stands in stark contrast to the in-app purchase systems available through the stores. But as we see more instances of the model there will definitely be additional areas where common tools and services could help.

There are two real takeaways from the online/offline models. The first is that if you’re looking at a model like this you should put your major focus on solving a problem and figuring out how mobile helps you address the problem most effectively. The contrast being starting with the technology and existing systems and working backward to a solution. The second is that there are some huge opportunities in doing infrastructure for these kinds of models. They’re hard to do, and “messy” cause they tend to have to deal with nasty real world problems. A lot of the problems we’ve been tackling at Churn Labs recently fall into the online/offline category, and a few of them have really knocked us for a loop. But there’s obviously a lot of value you can capture if you can pull a system together.

Actually, there was a lot more we talked about. And some great tidbits like Rich calling out that lots of the interesting “enterprise” stuff in mobile, like Dropbox and Evernote, are things that are used in the enterprise but not sold to the enterprise. But it’s getting late and I have a whole lot of programming to do tomorrow.

NFC as it stands is setup to suffer from exactly the same set of issues that has effectively killed Bluetooth as everything except a wire replacement protocol. The problem is that when NFC pushers say that NFC is “about more than just replacing your credit card with your phone” what they really mean is that NFC could be about more than just replacing a credit card. The decision about how capable or restricted an NFC stack is lies with the equipment manufacturer. And generally speaking folks don’t just toss random features into phones because they’re available. They do so when it’s really necessary, normally because of consumer demand.

Right now the NFC field is going through something very similar to what the GPS world went through. I’m sure some of you will remember that back in the deep dark recesses of pre-history not every smartphone had a GPS chipset in it. Those of us geeky enough to care went out of our way to find the models that did have GPS support so that we could play around with our own little hacks. But back in those days the consumer public didn’t really care about GPS support in phones. Back in those days the only folks who were clamoring for GPS support in every handset were the folks who were selling navigation or mapping apps for phones, and they were charging way too much, and not sharing revenues back with the manufacturers. So the environment was pretty well jammed up.

Eventually Google Maps came around though. And a meaningful free mapping application with fantastic search changed the potential value of having a GPS chipset in a handset, made the handset more attractive to customers across the board, resulted in more sales for handsets with GPS even if the manufacturer couldn’t sell additional GPS related apps, and we ended up where we are today. Generally that pattern is true, to get a new technology out into peoples hands there has to be a killer application to drive it. And the version of the technology that gets deployed will be the minimum version required in order to make that kill application work, and that ends up being the new standard.

Contrast the GPS uptake with the way Bluetooth has worked out. The Bluetooth technology folks early on used examples ranging from the headset connection version everyone knows through syncing all your data between devices automatically. There’s a whole ton of potential functionality in the Bluetooth specs, and at this point it probably is possible to sync data wirelessly and automatically in some subset of devices. However, the killer app there was connecting a wireless headset, so that’s all that anyone really uses Bluetooth for these days. And on lots of devices that’s all you can do. I’m sure that statement is going to piss of a whole industry. But tough, it’s true, deal with it.

With NFC the killer application appears to be payments. So my pressing fear is that the version of NFC that gets deployed to the devices out there is going to support the subset of features required to be able to participate in payments, and that’s it. Now, I know, the subset of stuff required to support payments potentially covers a few other areas like being able to scan other styles of tags. While I understand some of the convenience points there from a consumer perspective, there are some massive downsides from the point of view of an independent app developer. MASSIVE! Having a fully functional system requires a new bit of hardware even if I have an NFC enabled phone. That’s a huge barrier to experimentation and uptake for anyone except the folks with deep pockets and long timelines.

I was hoping that after the discussion last night I would find out a few things I was unaware of. I would be able to grab my Nexus S and with some quick bits of hackery potentially do something interesting. While I admit that NFC could potentially deliver some wins for a subset of cases out there, it’s not something that an independent app developer needs to take into consideration when building applications. I’m hoping that things shift somewhat as this evolves, but as it stands I’m taking NFC off my list of stuff to find some time to play around with. I just don’t see any areas in which it’s close enough to being a practical component of mobile development for someone trying to build a new business in mobile. Those of us looking for additional ways to make applications more context aware are going to have to stick with other techniques for now.

The README has info about how to output bookmarks in a form that the shim will understand. This is just initial hackery, not a real project yet. I just figured I would share it cause, well, taking some JSON and syncing it to the default browser bookmarks just seemed like the kind of thing other people might want to play with. If you turn on install from unknown sources you can download my prebuilt binary if you’re not into the whole Android development thing. Who knows, once I clean it up some I might even upload it to the market. There’s more hackery to be done first. Firefox Sync, I’m looking at you.

It’s too bad bookmarklets don’t work too well in the default Android browser otherwise there would be some much more obvious fun to be had.

So what does that theory have to do with the mobile web? I think it helps summarize one of the primary failure modes for doing mobile web work. There’s a natural tendency to look at the desktop web when thinking about how to address mobile. However, many things that we’re doing on the desktop web just aren’t adjacent to the existing practice on the mobile side. We might make it there eventually, but we can’t make it there now. We assume we know where the mobile web is eventually going TO because we know all the awesome things that grew out of the desktop web, but it’s more important to think about what the mobile web is going THROUGH in order to up the chance of being successful.

For instance it’s pretty natural to assume that because more capable devices are ending up in the hands of a wider audience now would be the time to start working on mobile media properties. However I don’t think the advertising environment is really at the right stage of evolution on the mobile web to make that style of property the same slam dunk as it would be on the desktop web. I think what we really need are a few direct monetization services to kick things off. We need the Amazon and eBay of the mobile web. Those two shifted perceptions on the desktop side, one with direct sales and the other as a sales platform. The media models formed around the commerce that started flowing. I’m starting to think that until the mobile web has something to sell it’s premature to start trying to run media models.

Not that media properties won’t work, I just don’t think they’re what we need to significantly shift development toward the web. And of course, I’m planning to test some of this out cause I might be completely insane. Hat tip to Jay Jamison and Eric Ries for the recent discussions at Founders Labs and Bluerun that have kicked off some interesting ideas.

The state of the mobile web presentation that Dion Almaer and Ben Galbraith from Ajaxian did at the start was a fantastic summary for someone like me. I frequently say “I’m not a web developer” so that no one would confuse me with the folks who live and breathe JS and CSS3. However I’m also not a “native guy” either. I try to use the right tool for the job, so I’m not really in any technology camp at all.

I have a long history of working on the mobile web actually. Sitting in the sessions yesterday I was blown away by how different of an environment we have over quite a short time. In particular during the talk from Alex Russell about browser support and during the state of the mobile web talk it reminded me of a set of discussions we had in June of 2007 about applying the AJAX model to mobile. The points that Dion and Ben made summarized the set of issues way better than I ever have. There are three important components to making a development platform work:

• Platform Distribution
• Platform Capabilities
• Merchandising

The first two points echo the discussion we were having in 2007, with the difference being that now mobile browsers don’t crash if you throw standard desktop JS libs at them. Because we have a nice meaty set of high capability devices in a relatively large number of hands, its finally possible to tune the platform capability vs platform distribution tradeoffs in a way that makes business sense. I think we’re just now edging over a tipping point actually, but that discussion is for another time.

I would actually call their third point “monetization” instead of merchandising, but that’s a nit really. The way they were discussing it, advertising and promotional programs are lumped into merchandising. But this is the area that I think is most in need of help currently. Most folks working on the mobile web are rolling their own when it comes to merchandising. And I don’t really know of many services to point to who are monetizing effectively outside of the app store systems. So if anyone else out there knows of good examples please pass them along. Ben and Dion did make the point that for anyone who has tried to sell software on their own either independently or through other channels, the 30% cut that Apple takes for selling your app on the app store doesn’t seem overbearing. Good point.

Another fantastic point for the day came from Yehuda Katz. He came and presented at the last Mobile 2.0 developer day, but was just settling into the new role. This time around he said something along the lines of (and I’m paraphrasing, so forgive me if I misquote) “people used to have 0 or 1 main computing device they used, now we have 2 or 3″, and addressing that shift is that “mobile strategy” should be about. It should be about delivering the right experience at the right time across different devices. Echoes of the service avatars presentation Mike K did at Mobilize. I think Yehuda really hit the nail on the head in calling out that point as the base of the discussion.

I had already been poking around with JQuery Mobile, Sencha Touch, and SproutCore. Now I’m thinking it’s time to pull together some of the hackery into a project and see if I can make one of them work at scale. Seems like all the ducks are finally starting to line up.

Here’s an example of fetching the most recent unread messages for an account and writing out the subjects into a text buffer:

ContentResolver cr = getContentResolver();
Cursor unread = cr.query(Uri.parse("content://gmail-ls/conversations/xxxxxx@gmail.com"), null, "label:^u", null, null);
unread.moveToFirst();
int subjectIdx = unread.getColumnIndex("subject");
 
TextView tv = (TextView) findViewById(R.id.buffer);
do {
    String subject = unread.getString(subjectIdx);
    tv.append(subject + "\n");
} while (unread.moveToNext());

Of course, the way I would like this to work is some kind of digital signature. But I’ve lived through enough failed waves of attempts to bootstrap public key cryptography systems (and have the keysigning party trust signatures to prove it!) that I know better than to try something like that. And all it would really accomplish anyway is exchanging my fools errand of looking for a printer where ever I happen to be with a half hour conversation with someone explaining how yes, a digital signature is a signature and can be accepted for legal documents.

So I decided to figure out a way to be compatible with existing process instead, figure out how to take the existing inputs and emit the existing outputs. But without all that messy physical process in between. I was hoping for something that would record a signature of mine and allow me to just cut and paste it into a document. Instead I found some decent PDF editors for the iPad that allow me to open up an existing doc, sign it with my finger on the touchscreen, and just mail it back. There are actually a few out there that are supposed to be dedicated to this function, but I’ve instead settled on the free Paperpad Lite application. It’s free. So at the end of the day, I’ve found myself a replacement for print/sign/fax that thus far has cost me zero dollars. Double w00t!

The dedicated “signature apps” are supposed to do things like allow you to open up other document formats like Office docs, but in my experimentation so far they generally don’t work. Most of the time the doc comes out garbled. So in those cases I resort to bring up the doc in Pages on my Mac and saving it as a PDF myself. When I’m really in a pinch (like I don’t have my laptop with me and I need to get the doc back right away) I normally just request a PDF version instead. Just watch out for asking for a PDF version from your lawyers, probably less expensive to just wait on those ones :-)

The transformation for me has been pretty extreme. Now as long as I have my iPad with me I can return a signed document right away. That’s more like it! Not perfect mind you, I wish I could do it with just my phone and a click, the way it would be with a proper digital signature. But I’ve eliminated hardware, waste, and a number of digital to analog conversions (which always make me sad). I could probably deal with the “other docs” to PDF problem with a set of filesystems triggers on my Mac, some commandline hackery, and Dropbox. Then even with my Air sitting on my desk at home it could still be working for me.

It’s made me think a decent amount about some replacement workflows enabled by devices. It’s not like using phones/mobile tech to replace paper and scanners is something new. Scanr has been around doing the same for a long time, and with companies like Zosh getting snapped up by document management companies I assume others are looking in the same direction. So if it’s been around for a while as an idea, why start caring about it now? I think it’s a combination of image capture capabilities being at the right level, applications being gregarious enough that I don’t have to worry about by digital documents being locked in a silo once I decide to make the transition, and now the availability of touchscreens.

For me this is a usage that finally turned the corner from interesting hack to useful set of services. I regularly use my Android phone as a scanner now using an app called CamScanner, which automatically crops and contrast corrects the image, and will save it directly off to Dropbox for me. It’s made me wonder about that camera that’s supposed to be in the next version of the iPad. The iPad has made a good paper replacement device thus far, but if it can also pull docs in from paper to ease the transition from existing process we could have a genuine enterprise transformation on our hands. Cool stuff.

I just wanted to point how much catch-up needs to be done. Carriers might think they have some real unique assets. However some of the real core ones are already showing some issues. Take messaging for example. If I have an application on iPhone the notification system built into the iOS platform far and away trumps trying to fall back on something like SMS, both from the app provider and user points of view. And if I’m a website owner who wants to get notifications out to my users? Best way to make that happen is to integrate Facebook so that I can send users notifications through that platform.

So yes, there’s some unique value to be derived from the core services. But take note that the bar has already been raised. We get notifications for free with Facebook and iOS. Receipt of message controls are granular and at the control of the user on those platforms. SMS based services lack much of what we’ve come to expect out of the platforms that we are using. To put together a cross-operator notification/messaging service that’s compelling isn’t going to mean taking the single-carrier model and extending it. Some of these core services need to be rethought before they can be scaled.