You've all heard by now that Blackberry (formerly "RIMM") has announced two new phones (the Z10 and Q10), with the first shipping in Canada and Britain first, then here in the United States with the Q10 (with keyboard) to follow.

You've also, if you read my material, know that I've been very bullish on the prospects for QNX, the operating system that Blackberry acquired a few years ago, to drive adoption predicated on its "microkernel" architecture.

But what you've probably not considered is exactly why that architecture could be levered to produce a device and environment that nobody else can copy or compete with in the present time.

And see, that's the deal, really.

Let's think about the "iTunes" and "Android" ecosystems.  They're basically the same thing -- copies of one another.  That is, the model is that you have a bunch of devices that use the Internet as a data pipe, and you load applications ("apps") from the "store" which drives revenue to the various parties.

Ok, that's nice.  But it's not innovative, and the reason it's not is that the architecture of the devices isn't innovative, much as Windows Mobile isn't innovative.

All three are basically an attempt to take a desktop (or server) architecture and cram it into a phone.  You have services like "Dropbox" that make file access (mostly) transparent, but that's about the extent of it.  This, to a large degree, is due to the architecture of the operating system -- a monolithic thing that uses device drivers to talk to physical hardware -- how we've always thought of computers and their peripherals since the dawn of the mainframe.

QNX is different.

It's different because there is no such thing, per-se, as a "device driver."  Rather, it has a microkernel that handles just the essential elements of task scheduling, memory allocation and similar.

Everything else is a user-land process.

That probably went over your head.

But it shouldn't have.

I said everything else is a user-land process.

Consider the camera in your cellphone.  On Android (and iOS) there's a device driver that talks to it.  I know how it works because I've ported Android on the Motorola Triumph, and had to fight with that piece of crap.  The driver runs in the kernel space; it's part of the hardware.

Now consider a userland camera that is distinct from the kernel.

Why does it have to be in your phone? 

Suddenly -- it doesn't!

So now let's say you and a friend are both in a bar. You want to take a picture with his camera!

With Android or iOS, this is very difficult to do.  You'd have to have an app that is specifically designed to do that sort of thing, and it would have to know all about the various cameras in various devices.

Not with QNX.  With QNX there is no difference between your camera and his camera, except for where it physically is located. 

Now sure, there's a security requirement here -- after all, that's his camera, not yours.  So he'd be asked if it's ok for you to use it.  But assuming he grants you permission, his camera becomes part of your device for the period of time both you and he want it to.

This isn't limited to cameras.

It applies to your screen -- and his.  It applies to storage, to executing programs, to literally anything.

More importantly, it applies to anywhere, not just anything.

This is something that Blackberry can do -- but nobody else can, as nobody else has QNX.

The implications here go far beyond "cloud drive" and similar storage schemes as we've seen in the past.  The potential is literally limitless.

Consider this:

Your car may run QNX internally.  If it has a cellular, bluetooth or wifi module in it, you can talk to it as if it was a part of the phone.

So you can sit in your house and say "car on", and -- the car starts.  You can also do something like say "car only runs if it can find me", and your car now won't start or run if someone moves it beyond its communication range of your handset.

If the car has a GPS in it (and they all pretty much do) you can ask where it is.

And all of this is easily-secured, since a communications pipe is just another resource, and that resource can be anywhere and of any sort.  So if you'd like to use AES-encrypted (or SSL-encrypted) transport, knock yourself out.

Remember that all these devices already have four means of communications in them -- cellular, a Wifi device, a bluetooth device and a nearfield device.  Again, all are transparent at the application level, unlike what we have now where I have to have a specific driver and data path set up for them.

Therefore I can communicate over Wifi, over the cellular network, over bluetooth or over nearfield.  Which I choose has much to do with (1) how much power budget I desire to use and (2) how close I am to the desired resource.  Seamless handoff becomes easy, since there's nothing special about one over the other.

Anything that can be used on one device in one place can be used on any other, as if were local, constrained only by the size of the pipe between the two physical points.

Suddenly, the model of "apps" is turned on its ear.  Any resource on any QNX-operated device can theoretically become available to any other QNX-operated device -- seamlessly.

Now its entirely possible that Blackberry doesn't understand all of this in their offices, and just sees QNX as another kernel with a power-management budget advantage.

But I rather doubt it, as this is something I understood about QNX when I looked at it in the early 1990s and advocated for it to be adopted for a project where exactly this sort of virtualization would have made certain things we were doing that were hard very easy.

I lost that fight, incidentally; the company didn't like the per-unit license cost and decided to roll their own instead.

But I bet Blackberry won't make the mistake of ignoring this capability, and if they don't they have a clean shot at changing forever how we think of and use that little brick in our pocket.

Disclosure: I am active in this name, cashed front-month CALLs yesterday, and both have and may initiate or dispose of other positions without notice.