the life and death of Virtual PC for Mac

Most of the other MacBU folks have been talking about VBA while I've been gone, and I don't think that there's anything that I can really add to that discussion. VBA is much less of an impact on the apps that I focus on, and some of our other WWDC announcements were more near and dear to my heart anyway. Let's instead talk about my favourite team at Microsoft: the Virtual PC team. (Dear Entourage, PowerPoint, and Remote Desktop Connection: Yes, I still love you guys, and no parent is supposed to have a favourite child, but the VPC guys give me brandy.)

The future of Virtual PC on the Mac had been in question for a year. The VPC team was happily working along on v8 (then code-named Oxygen), and an anvil dropped from the sky at the last WWDC. That anvil, of course, was the announcement of the move to Intel chips.

VPC is an application that sits quite close to the metal. Any change in the operating system or the chip architecture has a huge impact on VPC. Throughout the history of VPC, any change to the OS had the potential to break VPC in new and interesting ways. Remember the introduction of the G5? It took the VPC guys quite awhile to get VPC to run on the G5. It wasn’t a lack of effort. It was the combination of needing very specific expertise (which is to say, we couldn’t just throw more bodies at the problem) and needing some assistance from the folks over at Apple.

So here comes the Intel chip, and Leopard too. VPC v8 would need the same move to Xcode that every other major Mac application has needed to make. On top of that effort (which is a huge effort, as any Mac developer on a big project can tell you), VPC would require a re-architecture of the bits of VPC that were PPC-specific. We could re-architect VPC v7, we could port code from VPC:Win, we could re-code it from the ground up, or some combination therein.

We said that bringing VPC to the MacTels would be like doing a v1. That’s true, but it’s not the whole story. It’s not just that VPC v8 would be like doing a v1. It’s that VPC v9 could also be just like doing a v1, or maybe it would be VPC v10. There’s a huge engineering effort involved in making a v1 product. But when would we be able to focus our engineering efforts on improving performance or adding features instead of having to update the existing code to work on the latest OS release? What happens if there’s another major chip change?

’But what about Parallels? What about VMWare?’ I hear you ask. Parallels has got a v1 out there right now. VMWare is about to enter beta on their v1. One of the great things about a v1 is that you don’t have expectations. Your feature set is determined by what you can get working. It’s not determined by what you had working before. I think it’s v2 where life gets interesting. Can you build upon what you have? Can you get more people using it? It’s the early adopters who jump on a v1, and they’re not a big market (although they are a vocal one). In some respects, you get an easier job on v2: you get to add features, you get to fix bugs, you get to tweak performance. You get to make v2 a better product for your users.

But v2 is generally where you pick up the average user. VPC:Mac already has the average user as a part of our user base. For the average VPC user (who isn’t a Mac expert, and definitely isn’t a Windows expert), imagine buying VPC v8 and having very few new features over v7. A savvy user is more willing to let that slide because they’re aware of the enormous engineering effort behind moving to the MacTels. The average user, who doesn’t know or care about the change in chip, is going to be upset.

We made a hard decision. It wasn’t undertaken lightly. The team wasn’t happy about the decision. Ultimately, MacBU made the decision that Mac users would be better served if we focused our resources on making the next versions of our other offerings as strong as possible. The decision to move away from developing v8 made sense from a development and customer perspective, even if it was a hard decision to make. We spent months trying to come up with alternatives that made sense. While we were working through it, including working on the codebase, we gave the MacTel version of VPC its own code name: Lanai, for the place that we'd all like to go on holiday. (Roz wouldn't let us move our operations there, although we did ask.)

So where is the Virtual PC for Mac team? We got a lot of people from Connectix when we bought out VPC three years ago, after all. One of them moved to Redmond to become the General Program Manager of the MacBU team there. One of them is the Development Manager here in SVC. Another one is a Development Lead for Entourage. The PowerPoint tester in the office next to mine was a VPC tester in the Connectix days, and one of the other VPC testers just moved to the PPT team as well. Recently, with the death of VPC, the several remaining team members in dev, test, and program management have formed a new team at SVC to focus on some of the code that is shared across all of our apps. VPC:Mac might be dead, but it lives on in the great people that we have from that team who are contributing to the rest of our apps.