Why we don’t get builds faster, and why that is a good thing.

One common complaint about the Insider program seems to be that Microsoft doesn’t release builds fast enough. This selective and delayed rollout of builds is seen as annoying and unnecessary by many.

It is often misunderstood why that is.

First things first: There are a lotof development branches. If Microsoft has learned one thing from the Longhorn debacle, then that a lot of different people working on one codebase is a recipe for disaster. So they split development into different virtual build labs.

Take a look:

Source: ms-vnext.net

There are currently 154 (known) build labs in the Redstone 2 development cycle.

In each of these build labs, a team is working on a specific feature or part of Windows.

What this means is that these feature packed builds many are looking for simply don’t exist – They are only created after the individual features are mostly done and stable enough to be merged together in another branch.

This is in fact the reason why we don’t see builds leak as much as we did in the past: The most exciting and feature packed builds are the ones that you can already access via the Insider Program.

Now, why is Microsoft so tight-lipped about new features and what is going on internally? You have the former President of the Windows Division, Steven Sinofsky, to thank for that.

His philosophy was to avoid making bold promises and then under-delivering, something that had been one of the many factors contributing to the Longhorn/Vista debacle.

While Microsoft has since moved on and changed, a lot of this mentality remains, some of it for good reasons. And the outcry following Microsoft abandonment of a lot of older Windows Phones contradicting their previous promise to update them all to Windows 10 certainly hasn’t helped change this attitude.

So you see, if they wanted, they could of course give us access to some of the internal branches and early glimpses at new features, but should would they? They’d put themselves under the scrutiny of the entire worldand risk a shitstorm if they decided to drop a feature or change their plans.

They’d have nothing to gain, but a lot to loose. It doesn’t make any sense for them.

Now then, why doesn’t Microsoft at least roll out the Insider builds faster?

While builds of the rs_prerelease branch are compiled on a daily basis, as is the case with most branches, many of these builds don’t meet the internal criteria to be released.
If you follow any of the people who do sometimes get access to these builds, you will quickly see that these are not something you want. They are buggy and a nuisance to work with.

Imagine Insiders updating to one of these and having their PC stop booting. Microsoft would be bombarded with complaints, even if they added disclaimers.

If you have any doubts about that, take a look at all the comments in the Insider Hub accusing Microsoft of poor quality control even now.

This might reflect poorly on the public perception of the quality and stability of Windows.

So, why do we even want faster builds?

It is in Microsoft’s s own best interest to release builds as fast as possible to be able to better pinpoint where instabilities or bugs were introduced, and to see how we react to new features.

If they decide to postpone a build release, they usually have a good reason for that.

It wouldn’t hurt to tell everyone the reason though. Knowing that we don’t miss out on anything might make waiting a bit more easy for all the Insiders.
This would also be a huge step in the right direction in terms of open communication with the Insiders.

While I and many others would appreciate Microsoft to be a bit more open when talking about new features and such, it is obviously a walk on the line for them. They’ve been hurt by this in the past, and are understandably reluctant to promise too much.

I’m going to leave the final words to Raymond Chen, who said the following about leaked builds in the Windows 8 era. You will find a lot of his statement still applies even today.

These were builds not intended for public consumption, and their existence was pretty much all downside. The first impression the outside world got of a new feature was the buggy version, which was also probably quite ugly on top of being buggy.

That is rarely a good first impression. The feature arrived without context; people often jumped to conclusions about what the intended purpose was.

The team didn’t get a chance to talk to partners in order to give them a chance to raise their concerns about the new feature.

The premature disclosure meant that the team’s big announcement event no longer had the impact the team wanted.

And there are some legal issues that are tied to the date a feature first becomes available to the public. Seeing a feature go public prematurely throws a bunch of scheduling into disarray because you now have to finish those legal documents in less time than you planned.