About a month ago, I upgraded from Google Chrome version 8 to version 9. Funny thing is, I didn't really notice much of a change. The browser told me there was an update, I installed it, and things just kept working. That's the way most Chrome versions seem to arrive. Google just makes the browser better with these updates, but doesn't change things to the extent that it's jarring or disruptive. It's time for Microsoft to follow this model.
The fact that Google Chrome is up to version 9 also says something about its pace of development. Certainly version numbers can be fudged, but they do provide some idea of update frequency. Internet Explorer first saw the light of day in 1995, and is about to make its way to version 9. The first beta of Chrome was released in September 2008 and it's now at version 9.
What about Mozilla Firefox, then? It's the second-most-popular browser, yet the number 2 browser hasn't yet even made its way to version 4 yet. Firefox has sometimes added significant feature changes in point-upgrades that browsers like IE save for a major version change, but even so the pace of Firefox changes hasn't been nearly as fast as Chrome. Signs point to an quickened pace for Firefox once version 4 makes its way out the door.
Jay Sullivan, vice president of product development at Mozilla, indicates Mozilla has decided the Chrome model is a good one to follow. "What we want to do is get the power into users' hands more quickly. For example, the video tag was shippable in June -- we should have shipped it," he said. "Meanwhile, we're waiting for this whole package. Why wouldn't we ship the video tag when it's ready?"
That, in a nutshell, is the problem with waiting for big releases. Functionality that goes into those releases is warehoused for months or years, unavailable to anyone but beta testers, until the big release happens. Firefox has experienced it, and so has Microsoft. Former Microsoftie Mark Lucovsky wrote a blog entry back in 2005 that contemplates the problems of a schedule oriented towards a big-bang theory of software releases:
"When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you. . . . The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM."
Microsoft's general policy is that nothing is updated in a slipstream fix unless it's a security or stability issue. In short, "Read My Lips: No New Features." That can be a pretty restrictive rule, however. It often means that serious deficiencies go unfixed for years until the next release. In fact, Internet Explorer 9 is the first version of IE that has not been released in unison with a new version of Windows. That alone is a good sign for IE's viability, but it's not enough.