Big, massive, complex apps with long histories, massive developer teams, and massive testing programs, are slow to change. Maybe all these features are easy to do for Office, as they have been easy with (some) other apps; and maybe no consequences or bugs will result from the changes. Maybe. Or maybe this really is something that needs to be done right, albeit slower than we’d like. An update which has to happen in parallel with whatever other updates/projects they are also working on. Two sets of changes at cross-purposes are not always simple to pull off.
So I give Microsoft credit in this case: at least they’re not waiting for the next big paid version, nor playing “wait and see.” I wonder how Adobe’s handling these features....
(And there’s a difference between a compatibility/fix update, which should get the maximum rush, vs. a feature update. It sounds like Office is already compatible with Lion, but if there are serious bugs, I’d expect them squashed sooner than “months.”)
Exactly. Steve Balmer couldn't spring for the $99?
The blog post makes it sound like Microsoft had to wait until Lion's release to begin working on adding the features, not like they'd had an opportunity since the first developer release at the end of February.
How do we know that work on these features isn’t partly done, and has long since been in progress? Yes, it’s amazing to think that changing one part of a software program could impact other parts, and that it could take months and months. But that is in fact the case sometimes. Is it the case here, or is the Mac BU just being slow and not caring? The latter might be true, I won’t deny--but I don’t think we have the evidence to accuse them yet.
P.S. I’m not biased: I use OpenOffice