Windows 8.1 has been released to manufacturing.
OK, technically that’s incorrect. It’s actually been released to manufacturers, as in original equipment manufacturers, or OEMs. But it hasn’t been released to developers and IT pros, as was the case with prior Windows versions.
The initial reaction to the official news, even from normally sympathetic quarters, was scathing.
Why is Microsoft holding the final Windows 8.1 bits close and refusing to share them with its traditional partners?
I don’t know, and Microsoft isn’t saying. When I asked a Microsoft spokesperson for comment, all I got back was this bland non-answer:
Only sharing RTM code with OEMs is really about optimizing the overall experience for our customers—putting our hardware partners in a position to prepare the variety of new and innovative devices consumers and businesses can expect later this Fall just in time for holiday. While our partners prepare their exciting new devices, we’ll stay close to them and continue to refine Windows 8.1 to ensure a quality experience at general availability for customers on October 18th. This includes commercial customers with or without volume licensing agreements, our broad partner ecosystem, subscribers to MSDN and TechNet as well as consumers.
So what’s the reason? We’ll just have to guess. Here’s my list of possible reasons.
Getting the upgrade experience right is crucial.
Don’t underestimate the impact of this one.
The Windows 8.1 update represents uncharted territory for Microsoft. It’s a full upgrade to the operating system, with major new features that touch some of the most important low-level subsystems in the OS. But the plan is to make the update available as a free download to anyone running Windows 8. That raises the stakes substantially, especially for hardware partners who sold Windows 8 machines that are still under warranty.
If you’ve followed discussions in the Windows 8.1 support forums, you already know there are plenty of compatibility issues with the Windows 8.1 Preview. For example, according to one lengthy forum post, “Microsoft is actively working with Bluetooth manufacturers to improve a number of known issues with Bluetooth devices in Windows 8.1 Preview.”
Now multiply those issues by more than 10,000, which is roughly how many unique Windows 8 device strings there are out in the real world, according to one recent survey from AdDuplex. If those issues remain unresolved before general availability, the user experience will be awful, the support burden will be crippling, and the reviews will be scathing.
Windows 8.1 is more than just the client code.
Windows 8 was the first version ever to include tightly integrated services as part of the product. That means there’s code on Microsoft servers that makes it possible to sign in with a Microsoft account and sync settings. There’s more code that connects to SkyDrive for syncing files, and there’s yet more code that powers the Windows Store. And of course, there are a couple dozen “first party” (Microsoft-authored) apps.
All of those back-end services have legitimate dependencies on the client code. It’s perfectly reasonable to expect that development on those server-side pieces and apps will continue between now and the October general availability date.
Of course there will be bug fixes and updates for the client code. Windows development doesn’t stop with these milestones anymore, and Windows Update is routinely used to push out compatibility fixes and reliability updates. That’s perfectly normal.
Releasing to MSDN and TechNet is the same as releasing to the public.
I have little sympathy for Windows enthusiasts who feel entitled to early access to a new version. But developers have a legitimate need for early access to code so they can verify that their apps work as expected. The trouble is, anyone can sign up for an MSDN account and get enough key codes to activate a few dozen devices.
Microsoft and its hardware partners desperately want to control the publicity cycle. There are undoubtedly some surprises that will appear for the first time in the final code. Releasing that code to MSDN and TechNet would kick off a wave of reviews, which will of course be based on incomplete code (see the previous point).
Corporate customers and developers will be watching closely.
One of the biggest changes in Windows 8.1 is the move to a new rapid update cadence, with annual updates that introduce new features. That prospect is probably giving enterprise administrators nightmares. It’s causing developers to reach for the Rolaids as well.
The worst-case scenario is that those frequent updates will cause apps to break. If those are critical line-of-business apps, then corporate customers will reject the updates and Microsoft’s support burden will get worse, not better.
Microsoft says developers who build apps for Windows 8.1 can test them against the Windows 8.1 Preview, and they promise that the final code won’t break those apps. Developers have every right to be skeptical of those promises. This is uncharted territory for them, too.
What’s most disappointing about this whole scenario is both the lack of substantive comment from Microsoft’s management and the perception that they didn’t see this negative reaction coming. If you’re going to change the rules so radically, you really owe it to your stakeholders to communicate with them.
This is one place, ironically, where Steven Sinofsky’s influence is truly missed. He probably would have approved the decision to withhold the final code until the public on-sale date, but the reasons for the decision would have been outlined in excruciating detail in a 2500-word post on the Building Windows 8 blog.
Meanwhile, some of Microsoft’s core customers will be carefully watching what happens immediately after the mid-October release of Windows 8.1. If the transition goes smoothly, this minor uproar in the dog days of summer will quickly be forgotten. But if the update doesn’t go well, you can bet there will be plenty of people willing to say “I told you so.”