This post is purely speculative. I have no particular insight into Microsoft strategy. Now that I’ve disqualified myself as any sort of authority on this matter, let me explain why the $249.99 price tag for the new Kinect for Windows sensor makes sense.
The new Kinect for Windows sensor went on the market earlier this month for $249.99. This has caused some consternation and confusion since the Kinect for Xbox sensor only costs $150 and sometimes less when bundled with other Xbox products.
Officially the Kinect for Windows sensor is the sensor you should use with the Kinect for Windows SDK – the libraries that Microsoft provides for writing programs that take advantage of the Kinect. Prior to the release of the v1 of the SDK, there was the Kinect SDK beta and then the beta 2. These could be used in non-commercial products and research projects with the original Xbox sensor.
By license, if you want to use the Kinect for Windows SDK publicly, however, you must use the Kinect for Windows hardware. If you previously had a non-commercial product running with the Kinect for Xbox sensor and the beta SDK and want to upgrade to the v1 SDK, you will also need to upgrade your hardware to the more expensive model. In other words, you will need to pay an additional $249.99 to get the correct hardware. The one exception is for development. You can still use the less expensive version of the sensor for development. Your users must use the more expensive version of the sensor once the application is deployed.
I can make this even more complicated. If you want to use one of the non-Microsoft frameworks + drivers for writing Kinect enabled applications such as OpenNI, you are not required to use the new Kinect for Windows hardware. Shortly after the release of the original Kinect for Xbox sensor in 2010, Microsoft acknowledged that efforts to create drivers and APIs for the sensor were okay and they have not gone back on that. You are only required to purchase the more expensive hardware if you are using the official Microsoft drivers and SDK.
So what is physically different between the new sensor and the old one? Not much, actually. The newer hardware has different firmware, for one thing. The newer firmware allows depth detection as near as 40 cm. The older firmware only allowed depth detection from 80 cm. However, the closer depth detection can only be used when the near mode flag is turned on. Near mode is from 40 cm to 300 cm while the default mode is from 80 cm to 400 cm. In v1 of the SDK, near mode = true has the unfortunate side-effect of disabling skeleton tracking for the entire 40 cm to 300 cm range.
Additionally, the newer firmware identifies the hardware as Kinect for Windows hardware. The Kinect for Windows SDK checks for this. For now, the only real effect this has is that if the full SDK is not installed on a machine (i.e. a non-development machine) a Kinect for Windows application will not work with the old Xbox hardware. If you do have the full SDK installed, then you can continue to develop using the Xbox sensor. For completeness, if a Kinect for Windows application is running on a machine with the Kinect for Windows hardware and the full SDK is not installed on that machine, the application will still work.
The other difference between the Kinect for Windows sensor and the Kinect for Xbox sensor is that the usb/power cord is slightly different. It is shorter and, more importantly, is designed for the peculiarities of a PC. The Kinect for Xbox sensor usb/power cord was designed for the peculiarities of the Xbox usb ports. Potentially, then, the Kinect for Windows sensor will just operate better with a PC than the Kinect for Xbox sensor will.
Oh. And by the way, you can’t create Xbox games using the Kinect for Windows SDK and XNA. That’s not what it is for. It is for building PC applications running on Windows 7 and, eventually, Windows 8.
So, knowing all of this, why is Microsoft forcing people to dish out extra money for a new sensor when the old one seems to work fine?
Microsoft is pouring resources into developing the Kinect SDK. The hacker community has asked them to do this for a while, actually, because they 1) understand the technologies behind the Kinect and 2) have experience building APIs. This is completely in their wheelhouse.
The new team they have built up to develop the Kinect SDK is substantial and – according to rumor – is now even larger than the WPF and Silverlight teams put together. They have now put out an SDK that provides pretty much all the features provided by projects like OpenNI but have also surpassed them with superior skeleton recognition and speech recognition. Their plans for future deliverables, from what I’ve seen, will take all of this much further. Over the next year, OpenNI will be left in the dust.
How should Microsoft pay for all of this? A case can be made that they ought to do this for free. The Kinect came along at a time when people no longer considered Microsoft to be a technology innovator anymore. Their profits come from Windows and then Office while their internal politics revolve around protecting these two cash cows. The Kinect proved to the public at large (and investors) not only that all that R&D money over the years had been well spent but also that Microsoft could still surprise us. It could still do cool stuff and hadn’t completely abdicated technology and experience leadership to the likes of Apple and Google. Why not pour money into the Kinect simply for the sake of goodwill? How do you put a price on a Microsoft product that actually makes people smile?
Yeah, well. Being a technology innovator doesn’t mean much to investors if those innovations don’t also make money. The prestige of a product internally at Microsoft also depends on how much money your team wields. To the extent that money is power, the success of the Kinect for non-gaming purposes depends on the ability of the new SDK to generate revenue. Do you remember the inversion from the musical Camelot when King Arthur says that Might makes Right should be turned around in Camelot into Right makes Might? The same sort of inversion occurs hear. We’ve grown used to the notion that Money can make anything Cool. The Kinect will test out the notion, within Microsoft, that Cool can also make Money.
So how should Microsoft make that money? They could have opted to charge developers for a license to build on their SDK. I’m grateful they didn’t, though. This would have ended up being a tax on community innovation. Instead, developers are allowed to develop on the Kinects they already have if they want to (the $150 Kinect).
Microsoft opted to invest in innovation. They are giving the SDK away for free. And now we all wait for someone to build a killer Kinect for Windows app. Whoever does that will make a killing. This isn’t anything like building phone apps or even Metro apps for the Windows 8 tablet. We’re talking serious money. And Microsoft is betting on someone coming along and building that killer app in order to recoup its investment since Microsoft won’t start making money until there is an overriding reason for people to start buying the Kinect for Windows hardware (e.g. that killer app).
This may not happen, of course. There may never be a killer app to use with the Kinect for Windows sensor. But in this case Microsoft can’t be blamed for hampering developers in any way. They aren’t even charging us a developer fee the way the Windows Phone marketplace or IOS developer program does. Instead, with the Kinect for Windows pricing, they’ve put their full faith in the developer community. And by doing this, Microsoft shows me that they can, in fact, occasionally be pretty cool.