After Internet Explorer 9 was officially announced this week and a few tidbits on the release were shared by Microsoft, we had the opportunity to talk to Dean Hachamovitch, General Manager for Internet Explorer, to prod him for a little more information.

The overriding theme for IE9, he told us, is delivering a great browser for everyone, especially for developers. The big areas Microsoft is targeting with this release are performance, interoperable standards, and text and graphics. While Hachamovitch made sure not to talk more about IE9 beyond what was already revealed at PDC09, he was quite happy to answer a few of our more general questions regarding Internet Explorer's future.

We pointed out how all other major browsers (Safari, Chrome, Firefox, and Opera) are much more open about their development process than Internet Explorer. Firefox and Chrome are open source, and both Apple and Opera make updates to their engines regularly available. As a result, developers can thus follow browser progress more easily. Furthermore, IE's competitors have more frequent major and minor version updates, not to mention nightly builds in some cases. In contrast, IE typically has two betas, a release candidate or two, and then a final release of another major version—and then nothing for months or years. So we asked Hachamovitch what he thought about IE having more frequent releases and the first thing that came out of his mouth was, "God, where to begin."

"At the core, every browser has some type of release cycle for every build," Hachamovitch said. "Some of the projects do nightly releases, others don't. The goal of any prerelease offering is to have a meaningful feedback loop. The value to website developers of having all these drops to keep testing creates some fatigue for them because they keep testing this stream of drops. We're trying to balance the number of drops to just meaningful drops."

We pressed on, though. Although many developers may not really care much for nightlies or even point releases, it keeps them in the loop, and keeps them interested. Frequent releases give them an easy way to track progress, even if they also bring many problems and compatibility issues. Hachamovitch doesn't feel the tradeoff is worth it. "If we're working on a project together and I'm working on a draft, would you rather see four drafts with 10 or so fixes in each, or just a single one with all the fixes that you can then look over?" he asked us. Frequent releases generate a lot of noise but they do so at the cost of compatibility and stability, he concluded.

This analogy is an interesting one, though we're not sure it works in the context of a Web developer community. Not every developer will use every nightly, every beta, or even every minor point version. Those that do, however, will blog and write about what they find, disseminate information to the broader community, and give their thoughts about what a given browser company is doing and what it should be doing. It makes for a continuous feedback process, and is an important aspect of the development of other browsers that we feel Microsoft should adopt.

This "low-key hype" isn't there for Internet Explorer. Even if you were to say that a major release of IE is more significant compared to any of the major releases of the competition, the reality is that every other browser has a more regular release cycle than IE does, and that keeps them relevant. The result is a strong perception that IE is lagging behind, no matter how great the major release versions are.

A broken update system

A closely related problem for IE is its update system. While the browser's release cycle isn't strictly tied to the Windows release cycle, it is still dependent on it, and the browser's updates are pushed through Windows Update. The actual browser doesn't have its own updating system, and this is a large part of the reason that over 40 percent of users are still using IE6 and IE7.

While much of this user base consists of corporate users constrained to specific update cycles, the remaining users need to be pushed to update. These are the users who don't update because they don't really feel the need, don't know that there's such a thing as a new version of their browser, or don't even know what a browser is. Microsoft has said before that it won't force its users to upgrade and that the final decision is theirs to make. IE6 will continue to be supported for as long as Windows XP, the ancient OS that it shipped with, is (Extended Support for the operating system ends April 8, 2014). Hachamovitch made sure to point out that Microsoft does not drop support for its older versions as quickly as its competitors do, which again has its ups and downs.

Web developers would love to see these users update away from IE though, and they truly appreciate how the updating system works in other browsers. It allows them to see improvements on a regular basis, and the users of these browsers are also more likely to upgrade if the actual browser prompts them to (especially if it's more frequently than Microsoft releases updates for IE). It's even more likely if the browser is by default set to automatically update itself in the background.

Hachamovitch didn't state so directly, but he didn't seem interested in the idea of releasing nightly builds or minor version updates on a frequent basis. "I agree with you that people should be running the latest version; there are a lot of reasons to get developers on IE8," he told Ars. "We're doing everything we can."

What Microsoft could do better

We respectfully disagree. There are obvious things that Redmond could be doing but currently is not. Support for old browser versions could be dropped more aggressively. Rather than tying the IE6, IE7, and IE8 lifecycles to Windows XP, Vista, and 7, respectively, which results in the remarkable situation that IE6 will be supported for more than a decade, Microsoft could cut back and give each browser, say, a lifespan of five years after the next major release. This would still be generous (it would mean that IE6 would continue to be supported in some capacity until 2011), but far less extreme than the current policy.

Further, and perhaps most importantly, the existing Windows Update/Microsoft Update infrastructure could be used to push out new versions of IE as a compulsory update, just as is already done with essential security fixes.

Microsoft's attitude towards IE updates serves to undermine the good work that the IE team is doing. Though IE8 is far from perfect, it is nonetheless a vast improvement over its predecessors—but that matters little if most IE users are still using IE6 and IE7. If developers have to continue to target IE6, their dislike for IE will continue, and Web development will continue to be held back. Building a better browser is only part of the story: people have to use it, too.

Hachamovitch did indicate there was more to come in regard to pushing users towards the latest version of IE, but he wouldn't get into specifics. We asked him whether IE9 would be available for Windows XP, given the graphics improvements that rely on technologies only in Windows Vista and Windows 7, but he only said, "we're not talking about operating system support yet."

As for what the IE team's goals were for the Acid3 test, Hachamovitch only disclosed that the marks IE9 will score there is just "a side effect as we deliver progress for developers." The IE team has always stated that it finds it much more important to implement what developers really want in their browser then making sure the browser can pass a test that doesn't really cover all the bases anyway.

This stance is not unreasonable; the Acid3 test takes a scattergun approach to the standards it tests, and as such, a high score in Acid3 is not in and of itself indicative of much. For example, though Acid3 tests SVG vector graphics, passing Acid3 does not imply that a browser has complete support of the standard, nor even a useful subset of the standard.

So far, IE8 has been a huge improvement over IE7, and IE7 was a big improvement over IE6, but the fact remains that the opinion of Internet Explorer's progress in the developer world, deserved or not, is still very low. Is the ability for developers to track progress more valuable than the disruption caused by minor releases, or can Microsoft win back developers by continuing to improve their browser in giant leaps? We think it's the former.