MNB RG: Does BB need to die, in order for Nokia/WP to live? Is it a zero-sum game?

Advertisements

An interesting discussion at O2 Germany Said to be Leaving BlackBerry in favor of Windows Phone (http://mynokiablog.com/2013/07/27/o2-germany-said-to-be-leaving-blackberry-in-favor-of-windows-phone/) prompted me to write a comment that eventually became really too big to post as a comment, so here goes little pondering on this topic… Disclaimer: I don’t want BlackBerry to die. They have their own identity and I’d prefer for them to stick around and stick to it. However, if it comes down to Nokia vs. BB, of course you know where my loyalties are.Not ecosystems, but content

The question of must one die for the other to live, is indeed an interesting one. It is possible, at least. Clearly the biggest issue with selling a smartphone these days is the content you can get for it. This is what started the downfall of many computer platforms when the Windows PC became the de facto standard – if you can’t get the content, you move to where you can. Some of that content comes through standards, such as the ability to connect to the phone network or the Internet, and that’s almost trivial nowadays (it wasn’t always), but the big question is the rest of the content.

These days content is more than phone services and local software, of course. It is music, video, books, location, maps, access to services and connections to other systems. A well concentrated effort from the hardware manufacturer probably can organize most of these for a new platform (after all, most sellers of “dumb” content are more then happy to sell it to whomever), although with the rise of third-party video and music streaming services that road too eventually comes down to applications. There also the issue of would you get competitive deals as a small platform (famously Apple got very competitive deals for the iPod because they were considered a niche player at the time…). Nokia famously or infamously cited this whole as a reason to team up with Microsoft – they’d have synergies to fill these gaps was the argument and one of the graphics of February 11th was a graph of these different content elements.

The hardest part, clearly, for a new platform is the app-support. Much of the content many smartphone purchasers want comes in the form of apps. It’s not necessarily that they use many apps themselves, but it doesn’t really have to be more than one or two important ones that they’d miss – and people also like the idea that they have all those apps available to them, just in case. For application developers every new platform comes with a cost, it may be smaller or bigger depending on the technologies there, of course. Opposite to that cost is the earnings potential, but that requires numbers of users, which won’t easily come until there are apps. Classic chicken and egg conundrum.

The promise of universal content

Now, there are some ways to mitigate this issue: emulation or other kinds of compatibility layers is one. (BB10 does this with Android.) There are other ideas too, such as tools to create apps from web content for example. However unoptimal, emulation can indeed solve a part of the issue – what remains then, is the age-old question who wants to develop for your platform, if they can just sell an emulated version. Steve Jobs famously used this example as a reason not to originally allow third-party cross-platform APIs in the App Store, but of course Steve Jobs was not the first one to ponder this issue – it is as old as emulation itself.

Do they have to, though? Develop for your platform. Nobody makes movies for your platform either. Steven Spielberg doesn’t film for “iOS and Android”. The same movie is “emulated” on all platforms through whatever distribution technologies. What if, through some feat of magic, you could make all content available to your new platform even though nobody would develop for it directly? Would the average user care? Probably not. When you’d reach sufficient numbers, you might start to be noticed by app developers and perhaps they’d develop for you directly too. Indeed, this is the promise of the web, (nearly) same content on all platforms – more on this point later.

The problem with emulation – or emulating native apps with web content – is the current reality that emulated is almost always inferior to native. Nokia too noticed this, when they rushed HERE Maps to iOS as a wrapped HTML5 web app. BB10 got a lot of slack for inferior experience on its emulated Android apps in its reviews. When the user expects a native experience, but is instead served some kind of emulated content that isn’t as slick, they just assume the app (or perhaps even the platform) is bad – especially if their friend has a phone with a much slicker native experience. Currently, emulated content, no matter how convenient in other ways, can make your platform look bad.

Developer support parallels

So, at the moment you need native apps. How many platforms are developers prepared to support? Some have argued two or three or whatever is the maximum, but let’s look at history. In the early days of home computing, software was made for a plethora of platforms – so many, in fact, that ports usually had to be outsourced because nobody knew all the platforms that intimately. This happens still today, too, many Mac ports have been outsourced and recently Microsoft made headlines by teaming up with an iOS/Android house for mobile versions of one its PC gaming franchises. In those early days, a lot of software was definitely available for at least four platforms – and I’m not even counting the console versions yet.

Ah, yes, the consoles. That is another area where multiple platforms have vied for our attention. Consoles got mainstream a bit earlier than home computing, but unlike early home computing, quickly became a race of two dominant consoles and challengers of various qualities. Looking beyond those very early Atari years, first it was Nintendo vs. Sega, then Nintendo vs. Sony. Now, there were others too (Atari still dabbled, 3DO tried, even Commodore was in the console game for a brief while, and an overlapping period where Sega still fought for relevance with Sony), but many were false starts compared to the superstardom of the two major brands of the time.

Handhelds are an even sadder story of market dominance. Only Nintendo has really succeeded in handheld consoles, leaving only room for very, very distant seconds such as Atari Lynx and more recently, and at least with a little more success than Lynx, Sony PSP and Vita. One issue with handhelds was that much of the successful handheld software was in fact made by Nintendo – and only for Nintendo platforms. Many developers weren’t that interested in handheld gaming at all.

This brings us back to modern consoles and how many platforms developers are willing to support. It can be argued that last console generation was, again, an even fight of not two but three platforms: Nintendo, Microsoft and Sony. However, as any Wii-owner can attest, the third-party support is fairly bad. What makes up for the difference is the excellent first-party support from Nintendo. This lack of third-party interest seems to be amplified the next generation, with Wii U gathering even less interest. Technical differences explain some of this. If making the same game for Wii is harder than for Xbox and PlayStation, some will ignore the platform – or at least ignore its differentiator, the motion controls. And that’s probably not the only reason either.

So, indeed if we were to parallel gaming consoles and smartphones, it could argued there is only room for two or three. There is another gaming precedent to consider, though. How many platforms does a game support? Because if we take away artificial limitations of how we look at things, clearly many games support more than three platforms. First off there might be PC and Mac versions, iOS and Android version, a few console versions, a Facebook game, Java app for emerging markets and so forth. Consider how many platforms get your average Sims game for example. Could it be that today, many games actually support more platforms than in the age of 8-bits?

Revolutions, but also evolutions

Coming back to home computers. In the early 8 and 16 bit eras indeed developers were willing or forced to support a plethora of platforms, but that quickly dwindled down to one or two platforms (DOS/Windows and Mac) as other platforms failed to keep up technically and otherwise. I’m sure developers welcomed this change and indeed for a while it seemed like this was all there was room for. Some tried starting up competing computer platforms in the 1990s and failed miserably. Some of it was Microsoft protecting its PC turf (and deserving the eventual anti-trust beating), like BeOS, but some of it was simply the whole inertia of it all. Struggling NeXT and Apple were saved by each other. If you’d ask this question back in 1995, most people would probably say there isn’t room for two platforms, let alone four. No matter how false it was, it became the common wisdom at that time.

Two things would change the status quo, though. First was the web. Clunky at first, web would eventually become a major part of our computing content. So major, in fact, that some began to ponder if that was all they’d need. This, combined with the quiet rise of FOSS, has bought Linux on the desktop perhaps closest to reality than ever before and as that has happened, more commercial application software makers have taken an interest too (web content fixing the chicken and egg dilemma). Second was the smartphone as a computing platform. Smartphones didn’t run Windows software, so if you wanted to target them, you had to go multi-platform again. Indeed, this also simulatenous dealt a blow to the web: By 2008 people had gotten used to getting everything from the web, but now some of that was moving back into native applications and some of that all-platforms progress was undone.

There is also a third underlying current that has changed the computing world since those halcyon days of yore (somewhat tied to those FOSS developments I mentioned), is the rise of cross-platform APIs and frameworks. Whereas back in the day of the 8-bits, you basically re-coded for all platforms, and in the 1990s targeted Microsoft’s and Apple’s APIs, these days much of code is cross-platform. This is what made Apple change its mind about third-party cross-platform APIs in the App Store – and support for those is by far the most important update Microsoft brought to Windows Phone in WP8. A good example of this are gaming engines, which may be developed quite separate of an actual game and then used in many games on many platforms.

Promise of universal content revisited

Many have tried and failed when attempting to solve the problem of universal application software content. No, it wasn’t Java applets, it wasn’t Flash or whatever, although many of such technologies had some successes too. There really isn’t, even today, any one software platform you can target and run everywhere. That doesn’t mean, though, that there hasn’t been progress. Certain languages and technologies have become almost universal, almost industry-wide, that targeting most platforms is at least a lot easier than is used to be.

But could it be done, though? I mean, if we could create a solution that truly ran on all platforms, wouldn’t that solve the content problem for a new smartphone platform? If software execution was as standardized as, say, wireless networks? I’m sure it would solve the problem, at least for a while. The first problem, though, is how to do that realistically? What technology would allow native-like performance for both the user and the developer? How to spread that technology wide-enough so it wouldn’t be impeded by some major industry player, like Apple basically blocked the progress of Flash on mobile? Neither of these are easy questions and answers seem to be quite far away.

That said, HTML5 is probably the closest to a universal software content technology than anything before it – ever. It is possible that in a few years runtimes and developments have matured enough for compelling native-like content to be made for HTML5. It also seems to have wide-enough industry support, I doubt anyone will pull the plug on it. It is possible HTML5 will continue the success story of the universal web, after the small hickup of native apps on smartphones causing a detour. Maybe in a few years time the focus will, on the mobiles too, be less on apps and more on the web – like it has become on the desktop.

Maybe HTML5 of 2020 will become the Windows of 1995, where only one platform reigns supreme, because it runs virtually everywhere. Surely, in such a world there would be room for as many smartphone platforms as you could imagine – as long as they run HTML5.

Whatever the promise of HTML5, though, it is not an immediate solution. It won’t solve the app problem for the current generation of smartphone platforms. (For those of you wondering what is Nokia’s strategy beyond Windows Phone, I’ll bet you HTML5 is in it.)

Question of differentiation

Coming back to the question of succeeding with a new smartphone platform, be that WP or BB10 or whatever. If you can solve the content issue, are there other limits to how many platforms people are willing to accept? I’d say probably not. While the history of consumer electronics is full of diverse devices met with different levels of success, one thing is clear – there is plenty of room for many different brands with very different products. Walk into any store selling televisions and you won’t find just one or two brands of televisions there. Sure, if you are too different you might suffer, but close enough is usually good enough. And even very different might find a lucrative niche and go on for many decades.

Another customer group, and this affects BlackBerry especially, is the enterprise. Now, this is not as fickle a bunch as consumers. Enterprise loves fewer distinct options and is slower in making changes. This has been both a benefit to BlackBerry in years prior, but also a threat if the pendulum swings the away from them – if enterprise support is lost, its return will be equally slow. But of course, a smartphone platform doesn’t need the enterprise to succeed – all it has to do is entice enough consumers and in the present day BYOD culture even the enterprise will have to yield and support that platform eventually. If BB10 can rise with WP, say, close to iOS market share, the balance of power will shift even if there are four players in it.

What really isn’t important is how many platforms there are, but how popular they are relatively. If we have a 1. at 55%, 2. at 23%, 3. at 17% and 4. at 5%, it is easy to see how 4. might be cut. But if the reality becomes 1. 55% and 2., 3. and 4 all at 15%, the picture changes. (This, of course, is a simplification. Other things come into play, such as how much money customers of certain platforms use for apps etc.)

However, the smartphone market has one barrier of entry that pretty much no other consumer electronics market has: the operators. In too many markets to ignore, the operators hold they keys to reaching significant amount of customers. It is possible operators might be wary of too many options. History has shown operators quite willing to support at least four different smartphone platforms, but then at times they have been known to play favorites too for whatever strategic reasons they might have (Verizon and Droid come to mind in the U.S.). It has been argued that currently operator’s want a strong third option to challenge the Android/iOS duopoly (so that operator’s have more leverage) and that might mean shunning somebody to support their chosen third alternative.If there ever is a limit to competitive smartphone platforms, if there is a zero-sum game for the third place, it must be over the operators – not the developers.

How many platforms will developers support?

It was, indeed, a longer detour than I planned but finally returning to the debate: Is there a limit to how many platforms developers will support? Is there a limit of how many smartphone platforms they will support?

I think as far as historical precedent goes, it is true that at every point in history, there have been dominant platforms that have received more or better software support than the lesser platforms. The number of these dominant platforms has varied, during the early home computing era it was maybe three or four, during the PC years it was one or two, for the consoles it has been two or three. On the other hand, if we combine the number of dominant platforms over categories (lump PCs, consoles, mobile etc. into one), at all times since the 1980s there has been significant amount of software for four or more platforms.

Based on this, I would have to say there is no limit to how many platforms developers are willing to support. Wide-reaching support is easier than before, but even when it hasn’t been easy, developers have targeted whatever platforms have been popular in the day. Without apps, it might be hard to become popular (hard but not impossible if your product is otherwise compelling and you get the operators on your side), but once you become popular enough, you will get apps no matter if you are the third, fourth or sixth ecosystem.

Does BB need to die, in order for Nokia/WP to live? Is it a zero-sum game? No and no – at least as far as developers are concerned.So, next time somebody tells you there is a limit, cringe. They are probably as wrong as the guy (and there were many) who said, back in the 1990s, there is only room for Windows software in the world and even the Mac will soon die.

Post Scriptum

If we ever get to that utopia of HTML5 universal content – and we might – I’ll wager it won’t last. Somebody, somewhere will find new uses for technology that HTML5 can’t or won’t support, make it popular and start the cycle all over again. That somebody can be someone we know or it can be someone we don’t yet know.

And we’re going to be screaming to that somebody: SHUT UP AND TAKE OUR MONEY!

Advertisements