The mobile advertising world has matured pretty quickly. It was really simple to start out with, but it’s since evolved in the same direction as online advertising. So if you’re looking to understand what’s going on with mobile ads currently it wouldn’t hurt to familiarize yourself with how ad serving works online. Picking up on how realtime bidding works is a good idea too, cause RTB is one of the hot button items in mobile. Everyone is spinning up an exchange.

Mediation is a supply side technology. Generally speaking the folks who use mediation in the online world are at the upper end of media sophistication. They have particular constraints, such as having an in-house sales team that sometimes commits to high value campaigns. For them the mediation layer takes care of swapping inventory between what they sold themselves and what they want to put out on the general market.

Users of mediation in mobile range all over the place though, not just the upper end. The particular technical requirements in mobile, and mobile applications in particular, have a lot to do with that. One of the initial reasons for developers putting mediation in their apps was so that they could experiment with different ad networks without having to wait for an app approval cycle. In the online world if I want to try out a different ad network it’s a relatively easy thing for me to put the new ad network code up on my web servers and the swap is almost immediate. However in mobile if I want to try out a new ad network in my iOS app I might have to wait a week or longer for the app to go through Apple approval. And even then, if users don’t update they still see the old advertising setup. Some users update their apps very infrequently, some users not at all. In the mobile world the mediation layer is playing a bunch of additional roles it doesn’t necessarily have to fill in the online world.

Even though a lot of the discussion around mediation is around maximizing fill rate and increasing your effective payout, keep in mind the base tech requirements if you’re looking at doing a mobile service and considering how to setup advertising. This is the point that the Google mediation services for AdMob seem to really drive at. That you can start out with AdMob, and then turn on mediation down the line. Which doesn’t really seem like a huge deal, but keep in mind that approvals time and upgrade cycle for consumer apps and it sounds more appealing. You can do the same effectively with some of the other services. Just pay attention to the need to install the SDKs for other networks along with the mediation tool – if you have to that’s a signal that you might not be getting as much flexibility as you would like.

The really important point to underscore is that if you abstract the decision of how to serve ads and offload it to a server right off the bat instead of baking it into your binary you’re potentially saving yourself a headache.

A lot of times it’s tricky to get real information about a platform. The folks who really understand the internals have a vested interest in seeing the platform succeed in market, and they’re concerned with their relationship with the platform provider. Lots of developer programs are actually run by marketing departments, so they can do a really good job of tempting folks to a platform. And unfortunately there isn’t always someone there to call bullshit and save independent developers from dumping their time into a lost cause. That doesn’t really seem fair at all. Thought it might not seem like it I am actually sorry to harsh on B&N. I’m sure there are some good folks over there who genuinely want to make the world better. But as it turns out I feel way more obligation to the developer community than I do to a retail outlet.

The way this actually started out was my curiosity about what application distribution numbers on the Nook devices would look like. I have visibility into stats from lots of different apps across different platforms, devices, and markets. But I had absolutely no info about the Nook. I do however have a few super simple testing apps sitting around, and some of them are already Android versions. So I thought: “How about I just package up one of the Android ones and release it for the Nook just to get myself some numbers?” Seemed like a simple enough proposition. So I grabbed myself a Nook Color and checked to make sure the stuff I was thinking about releasing wasn’t an exact clone of something already in the market. Nope, it wasn’t.

My first tip off that things weren’t going to he happy shiny in Nookville was the signup process. Just in order to signup as a Nook developer there was a really detailed set of questions to fill out. It was free though, so I just wrote the process off as them being hungry for information about their developers. And I was approved within the timeframe they predicted (I forget how long, important thing is that it wasn’t a surprise). It’s all Android stuff, which I’m pretty comfortable with. So despite some hiccups with their developer mode activation and this completely oddball multibutton process they have for launching sideloaded apps, it only took me an afternoon to get an app together, tested on the actual hardware, packaged up, and ready to go. That’s where it went all sideways.

When I first went in to check on the binary uploader it said I couldn’t upload anything cause my account was pending. I assumed that was just a quirk of creating a new developer account. But as it turns out it was cause I had to enter detailed user account and banking info, even after the details from the initial signup, and even though I only at this point wanted to distribute a free app. So I filled out the details and submitted them. And waited. And waited. And waited. Eventually I started up a support ticket to try to figure out what went wrong (screenshot of an excerpt below). As of right now it’s been a month since I started trying to get my app out, and the support ticket has been open for 24 days. Apparently there’s actually nothing wrong with my info. They just can’t get their systems working.

I’m just assuming at this point that my account is never going to get approved, and that B&N is just going to shut down their Nook experiment well before they get around to clearing up the developer account queue. So just keep this in mind when you’re thinking it sucks having to deal with Apple or Google: at least those systems work.

Since I wasn’t able to actually get an app released I don’t have any hard numbers to share. But there were a bunch of really obvious shortcomings in poking through what was there if you’re planning to build a business. It’s possible that these shortcomings are undone by the power B&N has in marketing your app. They really tout their physical world presence, and their ability to feature apps in-store in addition to on the device. They could be right about that making a difference. They also have an audience that skews female, which could be really interesting if you were able to get an app released. But I suspect the winners on the Nook platform are going to be the ones that have a strong brand already, with “must have” apps getting put in front of a new audience for the first time.

In terms of obvious problems, in giving up the Marketplace you also give up in-app purchase. So the model that almost everyone has adopted to make a profit on the dominant platforms isn’t going to apply if you want to develop for the Nook. It’s paid distribution and thats it. Another glaringly obvious missing feature is remote push notification. You can always hack this in with a background thread polling for updates the way we did pre-Froyo. I haven’t tried that, but I assume it works. It might not really be an issue however. The business reason for drawing users back to an app in terms of revenue model is to expose them to advertising (hopefully not your MAIN reason for drawing them back, but that’s a whole other discussion). However, cause Nook is a closed system that doesn’t allow for promotions for services outside of the Nook marketplace, I assume you’re not going to be able to run any of the existing in-app advertising solutions. Maybe you could run mobile web ads only?

So as far as I can tell this isn’t going to be a winning platform for the average mobile dev. It’s probably a profitable distribution strategy for folks who have a lot of recognition and are looking to get maximum coverage – like Rovio. But most of us are not Rovio.

What about the obvious final question: what about your Nook Color Miker, do you actually like it? Well, now that it’s running Cyanogenmod 7.1 instead of the stock firmware, why yes, I do like it! I’ve been running CM from the SD card, which makes it easy to swap back to booting stock. I’m pretty sure I’m going to be flashing the rom to internal memory though, since I see no reason to boot back to stock any more.

UPDATE: Looks like there are a bunch of issues, and they might even spin off the Nook business unit.

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.

Sure, there was plenty of talk about the big issues at the conference. But if I look back at the conversations I had with other startup folks the topics were way more practical. The questions are always the same, tectonic shifts or not: “How do we get more users?”, “Is there a better way to make more money off what we’re doing?”, “Who would make a good partner for what we’re doing?” And in most cases those big shifts in the industry don’t impact how you answer those questions. Frequently folks talk about how startups can be more nimble than larger organizations, and this is one of the places where we should best be able to take advantage of it.

Lets take the Google/Motorola deal as an example to work from. Lots of folks are speculating that with Google now potentially directly competing with hardware manufacturers that we’re going to start to see more non-Android handsets coming to market. For the sake of conversation assume that to be true. As a startup company when should I care about that shift? I would say you should start caring about it at the point where this “third platform” gets to a large enough deployment it’s worth developing for. I’m sure someone out there would debate that. But I’m fairly definite right now is not the time for your average 5 to 10 person startup to try to get ahead of a trend.

It does make sense for large companies to care about these things. If instead of a 5 person startup you had a staff of a few hundred Android developers and a product pipeline that was 12 months long you had to care about, then it does have a strategic impact on how you should do your planning. And if that was the case you would have to figure out a strategy that covered the likely outcomes of allowing Microsoft/Nokia to get back into the game, someone snapping up webOS and making a real run out of it, Amazon pulling a Google on Android and using their technology without using their platform, or just driving interest back into iOS when devs get tired of porting.

As a startup you don’t have to go chasing shadows though. Because you can shift your strategy much faster, you can wait until you know you’re not walking into a minefield before picking a direction. That’s where I see the real value in how nimble a startup can be, and where most of my discussions tend to concentrate. Not in gambling on trends and trying to jump ahead of them, but in being able to wait till a direction is clear and then executing quickly to take advantage of it. That’s just good startuping.

There’s a whole lot of current thinking and discussion that points in the direction of engineering driven businesses being at least an acceptable idea. Be it the details of the distinction between causal and effectual reasoning laid out in What Makes Entrepreneurs Entrepreneurial?, or the Lean Startup principles that Eric Ries has been putting together, or the insights from Little Bets pulling together both current practice and examples of some great successes from the past. There are lots of folks driving the idea that the greatest risk to any startup isn’t the way you’re doing things, but that you’re doing the wrong things. So by extension, the best thing you can do to increase the chance of your business succeeding in the early stages is to structure for learning instead of optimizing for what you’re currently doing. Shouldn’t be a huge revelation to engineers, we all know that premature optimization is the root of all evil, right? :-)

You don’t need to be an engineer to be able to practice the principles these folks are talking about, but in lots of cases there are advantages to being the person doing the implementation as well as the person learning from the experiments. It also helps out when initial efforts uncover unexpected discoveries. Being the person in the code, poking around in the logs, putting together the metrics – I feel like those discoveries come about more naturally.

These practices aren’t really new. They’re just starting to get documented, given terms, and ultimately legitimized. Now we think of someone “pivoting” as a good thing. They learned that some assumption was wrong and have found a new direction that builds on their previous learning. Before there wasn’t a word for it, and we had to describe a change of direction in a way that everyone viewed as negative. So people would actually prevent doing what was good for their business because they were afraid to have to admit to peers and investors that they had made a mistake. Witness the Sapir–Whorf hypothesis at work, now that we have better words we have a better world. How awesome is that?

It also means that we’re seeing some new forms come around. The Gentleman Hacker lays out the model at the larger end of the spectrum. “Getting together smart folks to just hack on stuff” is nothing new. The subtle but extremely important difference is that we’re not just hacking to solve technical problems. We’re hacking to try to explore and validate hypothesis. We are hacking with a direction. We just expect that if we’re hacking correctly that direction is going to change.

But the process scales down as well. Entrepreneurs I talk too are increasingly spending time actually getting working versions out into market, iterating a few times and learning, and then looking for funding for what they’re doing. I think this model of figuring out a new business is infinitely more effective than drawing up a business plan and doing some market research. I think the popularity of the process is the main driver for the rising average valuation of companies getting funding, and an indication that the market agrees that this new model is the way to go. And of course if you’re an engineer who can get something out to market as well as one of the founders you’ve solved that major issue of how to get from idea to first prototype.

All this stuff is fantastic news for us. It doesn’t mean that you can completely ignore everything like learning about market sizing, or term sheets, or how to put together a corporation. But it shifts the emphasis back to a set of things that we’re more well prepared to deal with coming out of the gate.

• Convenience
• Social
• Already #1 overall (PC)
• Tablets
• Mobile, TV next
• Wifi proliferation
• FB, Google, Amazon, Netflix, et al.
• Open, free, democratic
• Targeted traffic
• Cross-promotion is easy
• Direct cloud updates

The app stores have gained us a lot with respect to previous models in mobile. But they’re also a step backwards in many regards related to what we’ve become accustomed to when delivering to a browser.

Lots of people say things like “Why would you want to deliver something like Angry Birds through a browser anyway? That would always be a native app.” But I’m not convinced there. What if they didn’t have to stage updates in big releases and just put out a level at a time? What if you could challenge a friend to get 3 stars in a level, and they could play that level right in the browser without installing an app? Stuff on the web is a lot more malleable. Even if the technology side didn’t make sense, many of the secondary benefits stack up into a pretty strong driver.

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.

Now, onto the slightly more serious points of conversation. There’s a lot of analysis floating around out there about this deal. Tons and tons of it by folks who are mobile veterans, and include theories about optimizing hardware production processes and giving Microsoft a tightly tethered OEM so that they can control the whole stack the way that Apple does. All that stuff is really missing the forest for the trees.

I think the very top level reasons are pretty obvious if you detach from the details and think about it. What is the number one criticism leveled at Microsoft over and over again about its efforts in mobile? Lack of consumer adoption and scale. And that’s exactly what Nokia has. And what is the number one problem for Nokia despite having scale and consumer adoption? They can’t create and support a third party developer system. And wow, look at that, it’s one of the things everyone accepts that Microsoft does well. Everything else really hangs off those principles. It actually gets skipped over a lot in the trade coverage cause it’s so fundamental people just take it for granted.

However, it’s important to keep in mind if you’re doing something like figure out if this was a good deal or not. This isn’t a two party deal however. In every possible future I’ve seen discussed so far, third party developers need to figure pretty heavily into this. So I’m really curious to see how the combined forces of Nokia and Microsoft attempt to address bootstrapping this new effort.

One thing to remember, for those who weren’t as into it back in the day, is that the iPhone didn’t have native apps to start out with. For the first year it managed to draw in huge numbers of users and attract a ton of mindshare based on the apps it shipped with and a spectacular web browser. Once Apple saw they had a hit platform on their hands it made sense to open it up to third party developers. Because there was pent up demand in the market from a large existing install base of users, those early developers had great stories to tell about the platform and resulted in additional developers. The additional apps from the additional developers led to more draw from users. Feedback loop completed. Nice job Apple, well played.

The funny thing about that playbook is that it only works once. Apple was able to do what it did cause all the mobile platforms that came before it sucked at supporting third party developers. Thus Apple was able to launch a mobile device all by themselves and get some real traction. An attempt to execute the same strategy in today’s environment would never work. Now the immediate response is “What? No huge catalog of apps? Your platform sucks.” There was a window of time when that wasn’t a complete given, and the Google folks managed to release Android to market under the bar. But now that window is firmly shut. Microsoft attempted to address the issue by paying to have the popular titles on other platforms ported over to Windows Phone 7. I think all would agree that the attempt was underwhelming and something not likely to be repeated.

I think the only way to address the widening gap between Apple/Google and the rest of the world is to look to the next model down the line. Competing head to head based on a native development platform with a fat and fluid monetization channel would really be the wrong way to go. What we need here is some innovation and model transformation, and generally speaking that’s not how Microsoft and Nokia operate.

So to all the other developers out there who are going to be hearing a ton of marketing down the line about the Microsoft/Nokia partnership and trying to make some sense of it, remember that this isn’t a two party deal. This is really about Microsoft, Nokia, and us. And in business deals like in poker: if you look around the table and can’t figure out who the sucker is, it’s you.