Should Microsoft add features in service packs?

This is an issue that gets debated around the company from time to time, and there are many people on both sides of the fence who feel passionately about it. In Exchange 2000 SP1, we did add a few features. In Exchange 2000 SP2, we added even more (I was the program manager for most of the new features in OWA in SP2). Exchange 2000 SP3 had — read my lips — “no new features” (also by that time, the entire team was heads-down working on Exchange 2003).

I have seen varying levels of feedback in Windows and Exchange communities on this issue, such as:

  1. “Yes“: It’s OK for applications or operating systems to have features in SPs
  2. “No“: There should never be a feature in any SP of any Microsoft product, it makes the SP buggier
  3. “No“: There should never be a feature in any SP of any Microsoft product, even if the SP is high quality
  4. “It depends“: It’s OK for applications to have features in their service packs, but operating systems shouldn’t have features in SPs

I’m sure there are many more reasons, but one of the most common ones I’ve seen discussed is that the quality goes down whenever features are added (#2). With Exchange 2000 SP1 & 2, however, I feel we did a good job of adding features while still achieving a high level of quality, so ever since then I’ve been wondering if that has helped change any opinions about this issue.

(Site note: Several of us who participate in Exchange communities had a good time forwarding around the mail threads in those communities that happened soon after the E2K SP2 release that went something like this:

Person A: Knowing Microsoft’s track record, what should I be aware of when going to Exchange 2000 SP2?
Person B: No problems here! Went without a hitch.
Person C: Likewise, installed it on 5 servers without a single problem. Users didn’t even notice it.
Person D: Well, my users noticed it, but only because they noticed the new features in OWA and loved them!
Person E: Ditto.

…etc. OK I’ll stop patting myself on the back here 😉

Not that I mean to imply that no one had any problems at all, but the overall perception I got from looking through the support calls we got and seeing the chatter in the communities was that those SPs were well received, features and all.

So, all that being said, I would like to use this blog to hopefully start a conversation: In your opinion, is it acceptable for Microsoft (and the Exchange group in particular) to add features to service packs? I’m most interested in hearing why you feel the way you do, as well as whether you’re talking about Exchange specifically, OS’s or all products. Thanks in advance!

Comments (17)

  1. Chris Stewart says:

    My opinion is no. I’d rather have an even more solid product than the chance of having issues.

  2. Mike Bateman says:

    First I will say that I love it when features are released "out of band". However, why does a Service Pack have to be the only means by which you deliver new features? With Windows 2003 they’ve begun to introduce new features by themselves (i.e. iSCSI initiator, Group Policy Manager). Based on comments at the JDP (ehem TAP) sessions they seem committed to continue this practice.

  3. jkipk says:

    A home user comment here: My feeling is that with the inundation of security patches, the perception of a service pack is somewhat of a "necessary evil", and certainly not very much fun. I think it would be nice to receive a "spoonful of sugar" along with the medicine we seem to have to keep taking. I don’t think it has to be new features particularly, but if the software for example boots faster, or looks a little cleaner, or gives some perception of positive value rather than just fixing a bug or security hole, that’s all for the better. Not only will the sp be perceived in a more positive light, but the chances that it will be implemented are probably greater.

  4. Steve Bell says:

    No. The blurring of the lines between stability, security, and new features has to stop. Sure it sounds like a great idea to add new features — after all we want them, they are good. But where is the line drawn? What if the new feature is Home Movie Maker 3.0 and you include it in the SP? Now we have the choice of either living with the old code or seeing more bloat and uneeded "features" on production servers. Also adding new features could also trigger a new EULA on what can be done on the server by MS? What if the new feature was simply turning on autoupdate by default and not allowing users to turn it off? No one would install the SP and therefore not get the much needed updates. Instead how about offering service packs for updates and feature packs for new options?

  5. KC Lemson says:

    Thanks everyone who has commented thus far.

    I started writing up a response about feature packs and why it’s not a simple answer, but it got so long that I’m going to save it for a new blog entry sometime soon rather than add bloat to my own comments 🙂

    Keep ’em coming.

  6. (William Bartholomew) says:

    From a security and a stability point of view I say definately not, but (and there always is one), if the feature is something that is causing a large number of customers grief and can be implemented without architectual or significant changes then the benefit of implementing it needs to be weighed up against the security and stability cost of implementing it.

  7. Adam Field says:

    I agree with William

    additional features are OK in an SP but only if its not a major architectural change and only if it’s entirely necessary.

    This is the reason that MOC courseware always runs on the vanilla product (No SP’s) as they are renowned for adding feature changes and would thus make the courseware wrong.

    Im happy to have new features, just call them a point release rather than an SP..

  8. AndrewSeven says:

    I thought this question was settled…

    A new feature has the potential to introduce new bugs.

    A service pack is supposed to fix bugs.

    New features should be found in Feature Packs.

    Feature Packs should include Service Packs.

    Service Packs should not include Feature Packs.

    There is no reason that both the FP and SP should not be distributed on the same CD…

  9. Chris Kunicki says:

    I agree with the comment that features should be added out of the normal release cycle and service packs should just fix issues.

    I really wish<a href="">Microsoft Office</a> would follow the windows 2003 pattern. The problem is they come up with all these great ideas in one release and then we have to wait 18 to 24 months to add the few little things that would be helpful that are discovered after the release.

    This is one area where Open Source potentially has Microsoft beat. The old days of monolithic release cycles (every 18 to 24 months) is just not practical for a market that can change every 3 to 6 months.

    Now there are a lot of Add-ins put out by Microsft that are tremendously useful. The problem is that there times where the baked in functionality needs to be expanded to really solve a problem.

  10. Josh says:

    It is a shame that MS developers come up with all these internal tools or features AFTER release, and then have to keep them internal, or release them as unsupported tools (Power Toys).

    But I agree Service Packs are not the answer. There should be something like Feature Packs.

    But I can see where this would create quite a support issue (probably what KC was going to write about, no?). You create a much larger cartesian product of permutations of the platform to test every time you want to release a Service Pack or Hotfix. Would Service Packs contain fixes to Feature Packs?

    Instead of having App2K3, App2K3 w/SP1, App2K3 w/SP2 to test against, you now have App2K3, App2K3 w/FP1, App2K3 w/SP1, FP1, App2K3 w/SP2,FP1, etc).

    So, I guess I appreciate why these things often come out as "unsupported" upgrades. But does installing an "unsupported" tool invalidate your support on the base product?

  11. I’m all for new features or the feature pack routine the Windows folks have been following. In fact, I like the latter better. I get a new package to play with, without any other permutations fo problems from bugfixes and what have you/

  12. just me1 says:

    Well, just call it something different then. But it is in my not so humble opinion not acceptable to wait 2-3 years for a new version of a product with some new features. And even then it is not guaranteed that those features customers have been asking for are really added.

  13. Andy Doyle says:

    Yes I like it when a product gets a new feature; it almost gives it a new lease of life. But as a rule of thumb, service packs are there to fix things. New features should come along in ‘Feature Packs’.

    MS seem to be doing this with Windows Server 2003 by releasing new features as time goes on. In a time of high-security this gives users the flexibility of only installing what features you want. I’d like to see this methodology employed across the entire product range.

  14. Thomas Anderson says:

    Well, Service Packs should be focused on one thing. Fixing problems.

    I think new features should be added by "update packs" rather than "service packs" because new features in service packs can lead to new bugs or features that perhaps are not needed.

    I’ve seen in some cases systems that are so tight in their integration between different programs that a lot of the OS or Application features are not really used.

  15. Neil B says:

    I think introducing new features in SP’s is fine as long as they don’t cause any additional problems. I’d much rather see new features 6 months down the line in a SP than the same features being rushed into the original release.

    Why should SP’s just be about fixing things? If they can do that and add new features doesn’t that make them more appealing to everyone?

  16. D Snow says:

    I’m surprised this issue still exists.

    The issue lies with large enterprises that need to control the features that are introduced. Imagine a corporation that has 200 exchange servers and needs to deploy a critical fix available in a just released SP. In addition to the fix(es), MS decides to introduce a new feature that is visible on everyone’s desktop, but for which the enterprise does not have the bandwidth, disk resources, support assitance or training in place. To them, the cost of deploying the SP often includes the cost of planning and deploying new features that they had not planned or budgetted for.

    The solution to this problem is to release SPs with only fixes and if necessary, Sim-ship a Feature Pack or equiv.

    This is a huge disatisfier for large corps.

  17. GM says:

    Mmm, service packs …

    o Emotionally, I like new features (excitement/change/growth, something for nothing).

    o To some locked-down customers, unexpected features ARE bugs.

    o Why not include new features in the SP, but make them an installation option, like the optional parts of the OS, and add them to the Add/Remove WindowsComponents or application feature selection.

    o Make more of those hot-fixes public that are currently available only on application.

    o For the sake of Microsoft, the users and/or devlopers, include feature upgrades like MSI3 & IE6SP1 & MSXML4 in the next SP for all OS – & security tools like MSBSA on servers & home editions.

    o The above applies to NT v4 too! (If the past won’t go away, it’s not the past!)

    o Add more support for more products to MSBSA.

    o Include new APIs in SPs for older OSs, if you want them used sooner by developers.

    o Make it easier for licensees to purchase installation media with the new SP at a nominal charge, like the SP media.

    o Use MSIs for more installations, including Jet & MDAC.

    o Service packs, feature packs, plus packs, power toys, security roll-ups, Windows Update Catalog, Automatic Update, download web site, obscure public hotfixes, hotfixes via support, hotfixes per incident, refreshes, SUS, SMS, third-party hotfix tools & wraps, products/features/components embedded in multiple products, subscriptions, betas, previews, unsupported goodies, community releases, … Consistency can be good, but seems unlikely. We want new features & bug fixes & stability and we want it yesterday.

Skip to main content