One of the outstanding questions around Windows 8 is how Microsoft will keep it fresh after RTM.  Most recently Long Zheng raised this question in the context of the relative immaturity of the new Windows Runtime.  If the Windows team retains its current release philosophy we’d have to live for 2 1/2 to 3 years for the next release.  In a world of annual, or more frequent, updates by competitors such a philosophy would be fatal for Microsoft.  I devoted a paragraph to this topic when discussing falling footware, but it deserves additional analysis.  And as is often the case I find that examining history gives lots of clues to how the future might evolve.

From its beginnings Windows has primarily been on a 2-3 year release cycle.  This held true from 1.0 to 2.0 to 3.0 to 3.1.  This wasn’t especially surprising as other vendors had similar release cycles, Apple being an example in the PC space.  But with Microsoft’s decision to pull out of the OS/2 partnership with IBM to focus on Windows, it now entered a period of more rapid releases turning “3.1” into a series.  Windows for Workgroups was released 6 months after 3.1, and version 3.11 about a year later.  Not only that, Windows started the practice of independently shipping add-ons such as the Windows for Pen Computing extensions to enable tablet devices.  It even updated the Windows 3.1 API set to include Win32s after Windows NT shipped so developers could write Win32 apps for both platforms.

In 1995 (three years after the initial Windows 3.1 release) Microsoft shipped Windows 95, then in 1998 (there is that three-year thing again) shipped Windows 98 (and two years later ME).  But focusing on these dates can be very misleading, because after Windows 95 shipped Microsoft actually went into a period of very rapid evolution of Windows.  Windows 95 was followed by four updates called OEM Service Releases (OSR) that added new functionality such as Internet Explorer, the new FAT32 file system, and USB support.  Microsoft also adopted a philosophy of making new Windows functionality available as downloads so that Windows was constantly evolving.  In fact the delivery of a Windows version as a series of updates over time became so ingrained that Microsoft changed its accounting practices to spread the recognition of revenue from a Windows’ sale over a multi-year period!

I mostly want to leave Windows NT and Windows 2000 out of this discussion because they were both a parallel activity and a precursor to Windows XP, but do keep in mind that from a customer standpoint in the late 1990s through 2001 Microsoft was pushing out new releases at a rapid clip.  So in one three-year period you had four releases (98, ME, 2000, XP).  XP is where things once again get interesting.

After shipping Windows XP in 2001 Microsoft followed up with the Media Center Edition and Tablet PC Editions in 2002.  It later added X64 support, and a Starter Edition for emerging markets.    Microsoft continued to ship new Windows functionality very frequently in separately available downloads as well as in Service Packs.  Microsoft also introduced Windows Update, which made it even easier for Microsoft to deliver these updates to Windows XP systems.  If you compare Windows XP as shipped in 2001 to Windows XP as it looks with Service Pack 3 installed in 2008 you see two massively different operating systems.  From networking to security to user interface details (though not basic philosophy) to hardware support to API set (.NET in particular) Windows XP was in constant motion.

Which brings us to Windows Vista.  There was a five and a half-year gap between the original shipment of Windows XP and the release of Windows Vista.  This was unplanned and obviously totally unacceptable.  Not only that but it was, by most standards, not a good release.  Both the actual delay, and the low adoption rate, put into customer’s minds that Microsoft takes way too long between releases of Windows.  In other words it is the Vista experience that people focus on, not the near constant stream of updates to Windows XP.

After the Vista fiasco Microsoft had to completely re-examine its development philosophy for Windows, and the starting point became the philosophy used by the Office team.  This planning/design-heavy philosophy results in very predictable release cycles with generally excellent quality.  The tradeoff is a lack of responsiveness to changing market conditions.  Whereas in the Win95/WinXP worlds an emerging challenge would be met by rapidly spinning up an effort and shipping out-of-band updates or even a specialized edition this does not fit well in the post-Vista Windows development philosophy.   I think there was another recognition as well, Microsoft was backporting so much of the functionality it worked on for a new version as updates to the old that the new versions offered little to customers.  Take Vista as an example.  If you strip out the quality issues it had there is very little functionality that isn’t available as updates to Windows XP!  If customers had been comparing Windows XP RTM to Windows Vista RTM, rather than Windows XP SP2 + other updates to Vista RTM, then they would have found Vista a far more compelling release.  And so Microsoft not only adopted a development philosophy that would produce more predictable higher quality releases, it became far more thoughtful about what kinds of functionality should be provided as updates to earlier releases.  Internet Explorer, because it had gotten behind the curve, maintains an independent update capability.  And the consumer-oriented applications such as those for mail or photo editing, that needed frequent updates to be competitive, were actually removed from Windows and put on an independent delivery system.  But otherwise there is far less in the way of updates to Windows 7 then there was to Windows XP.  Let me give a simple example.  Windows XP added system supported WiFi configuration in Service Pack 1, so while Vista had even further refined support the difference between XP and Vista was not enough for it to be a real differentiator.  Windows 8 adds system support for 3G/4G connections, something that you need third-party software to do in earlier Windows versions.  Back in the Pre-Windows 7 days it is likely that Microsoft would have made (at least a subset of) this new functionality available as an update to earlier releases.  Not these days.  Integrated 3G/4G support will be one of many compelling small improvements that really differentiates Windows 8 from its predecessors.

When I summarize that rather long history lesson it comes down to a few points.  First, Microsoft has used a number of different strategies to keep Windows fresh over time.  Sometimes it goes into accelerated release cycles, but far more often it has used various forms of updates to existing releases to keep them fresh.  It has also shown it is not afraid to make API additions in these updates, with Win32s introduced as an update for Windows 3.1 and the .NET Framework introduced as part of Windows XP SP1. On the other hand, Microsoft has recently moved away from broadly updating Windows between releases making it less clear how it might handle keeping Windows 8 fresh.

Three more points about updates.  First, there has long been tension over what types of changes should be in a Service Pack.  Because you want a Service Pack to increase system stability, and to be widely adopted, there has been pressure to keep new functionality out of SPs and have them completely focus on bug fixes.  However the reality, if you look across product families, is that some SPs are indeed just collections of bug fixes while others introduce small numbers of functional improvements.  Occasionally a Service Pack is used to make major improvements to an existing area of functionality, as was the case with Forefront Unified Access Gateway SP1.  UAG SP1 (like Windows XP SP2, BTW,) could easily have been introduced as a new release, but we chose to make it a Service Pack for a number of reasons I won’t go into.  Second, Microsoft has occasionally used the notion of a Feature Pack as a way to introduce new functionality.  I consider this nothing more than a feature-oriented Service Pack and thus won’t explore it further.  Third, there are two areas where changes are avoided between releases.  The most obvious one are architectural changes.  These almost by definition requires a new release.  The second is User Interface.  While tweaks are possible, you don’t want users (or IT departments) to avoid installing an update because it causes usage disruption.

Lastly, Microsoft has always been caught between consumers who want the latest and greatest, its own need to address new markets and new initiatives as quickly as possible, OEMs who want support for freshening their hardware offerings fairly frequently, and Enterprise IT who want stability.  So you have some audiences that want rapid change (1-2 releases a year would be fine) and others who want little change (a release every 3 years is just dandy).

Thank you for putting up with that long setup!  Now on to Windows 8.

That IOS and Android have rapid, at least annual, release cycles puts a lot of pressure on Microsoft to keep their tablet OS on a similar release cycle.  Not only that, OS X has also gone to an annual cycle.  And to top it off Windows Phone is on an annual cycle (with some interim updates) as well.  I can’t believe anyone at Microsoft is under the impression that they can get away with a two to three-year cycle for Windows!  So the question isn’t will they do more frequent updates, it is how often and how extensive they will be.  And it is how they will ship the updates and how will they handle the engineering.

How the engineering is handled is the first big question.  The engineering philosophy that Windows adopted seems to be working very well and so I don’t think they want to throw it away.  At the same time a long planning cycle is not conducive to quick release cycles.  And so my first conclusion is that they won’t change the basic engineering philosophy, they will adapt it.  There are two ways you could adapt it, what I’ll call Forward Looking and Series Planning.  With Forward Looking you would plan the next major (2-3 year cycle) release and choose which things you wanted to make available as updates to the previous release.  You’d then schedule engineering to complete those items early and release them as updates.  With Series Planning you wouldn’t think of a release as a single event but rather as a series of released deliverables that included a base release plus updates.  In either case you’d have more concurrent development than Windows has today because you would need to be writing and shipping updates during the planning portion for the next release.  I think Series Planning meshes better with the Windows philosophy, but there is one little hitch.  I assume they weren’t doing this when Windows 8 was initially planned, so it’s a bit unnatural of a transition.  However, you can take items that were dropped later in the release cycle plus input from the Previews and create a series plan now.  Then for Windows 9 adopt Series Planning right from the start.  The main point here is that Windows will likely want to remain very thoughtful about what goes into a release and very planful about how to get there.  Updates to the mainline release will stay within the boundaries of the original planning scenarios/themes.  Architectural changes, significant UI changes, changes that could disrupt stability, and completely new scenarios/themes will wait for the next major release.

Given the above assumptions the question then becomes how will these changes manifest themselves?  Will we see a continuing stream of updates delivered through Windows Update?  Will we see annual or semi-annual Service Packs that contains these changes?  Will we see these given a new release name, so we get an 8.5 for example?  I’m going to go out on a limb and make a prediction.

When I balance all the competing forces here I come up with a scenario that I think works for Microsoft.  I want something that updates frequently enough to keep the experience fresh for users, fills out Metro/Windows Runtime for developers, and keeps OEMs happy in terms of hardware support.  I also want a consistent “current” platform for everyone to target.  And I want updates infrequently enough that you can keep control over quality and let Enterprises develop good and rapid adoption policies.  To me that means you go with the Service Pack-oriented philosophy.  Frequent small updates are too disruptive.  New releases have lots of baggage, including resistance to adoption as well as all kinds of marketing implications.  Doing an annual or semi-annual Service Pack addresses the real problems without introducing new ones.  It becomes the “Spring Update” or “Fall Update”, or maybe has some amusing internal name like “Knish” that everyone knows even though it is never called that.  You market Windows 8, period.  What Windows 8 is just gets better and better over time, until you finally have such major changes to introduce that you launch Windows 9.

Now to Long Zheng’s point.  Microsoft has already shown it will introduce new API capabilities between major releases.  Further, continuing to fill out Windows Runtime between major releases fits with both my Series Planning idea and within the notion of a Service Pack.  And so I strongly expect Microsoft will continue to improve Windows Runtime in 6-12 month increments even if it retains a 2-3 year overall Windows release cycle.