I don't think we can tell yet what will happen to Microsoft in the next few years. There are an awful lot of factors at work here, and most of them are pretty unpredictable. I suppose it's vaugely possible that MS might either sink completely or recover their complete control over all things Intel. But it's more likely that it'll be something in between.
I think a lot of the MS discussion is missing the most fundamental issue, though. We see a lot of heat about the surface issues: unfair or monopolistic business practices, misleading marketing, system stability, upgrades and bug fixes, etc. But I think these are all symptoms of a basic question: How should software be developed?
Okay, hang on here -- this isn't going to be a typical Open Source rant -- but it is going to be quite long -- bear with me
One of the most enlightening articles I've ever read about MS chronicled a journalist as he spent a week or so working inside MS. I wish I could remember where I saw it -- it was a couple months ago -- anyone else remember this? He said one thing about their development process that really helped me understand why MS software is the way that it is.
DISCLAIMER: I have no direct experience with MS. Everything I say about their development methods is based solely synthesis from others' reports and my observation of the software.
Apparently, within MS, each programmer can pitch their favorite feature to be included in the product. If the "powers that be" give it the go-ahead, then they're in charge of implementing it however they want. Sounds a lot like Open Source development so far, eh? But there's a couple of apparent differences that are very significant.
The first difference is whether the approval is given before or after there is working code. One of the basic tenets of Open Source development is, "show me the code." If the code is not available, or cannot be tested, then the decision can only be based on potential rather than actual benefits. Sometimes the perceived potential actually happens; other times it does not.
The second difference has to do with who gives the approval for a feature. In Open Source development, the system architect(s) give the final approval for including a feature in the official code base. At MS, the decision seems to be made at a managerial or marketing level. There are dangers with both methods: the system architects could ignore users' desires for a feature if it couldn't be integrated properly; the managerial/marketing people could ignore any difficulties with integrating the feature into the system.
The third difference is how much interaction the different teams have with each other. With Open Source development, the code from everyone is available -- whether it's in patches or a CVS tree or whatever. But at MS, apparently, there is very little cross-team code sharing going on. Without extensive code sharing, the teams will end up with many different solutions to the same problem, and often they will be slightly incompatible.
In other words, the MS development process seems to be aimed at including many independent features into the system, based primarily on the features' potential value, rather than how they interact within the system as a whole. Does this sound like MS products to you? It sure does to me -- I first started to realize this years ago when I upgraded to Word 6.0 on my computer, and it stopped recognizing my hard disk completely. Okay, one anecdote doesn't prove anything -- but this was my first major clue on how MS products sometimes don't work well with others, and the memory has stuck with me.
If this is an accurate understanding of the MS development process, then that leaves them in an interesting position in the market. In order to succeed in the market, MS must sell based on their strong points: independent features and the potential of new features. And the customers must believe that the feature lists and promised features are the most important criteria when choosing software.
There's an interesting parallel to the U.S. auto industry in the 1970's-80's. At that time, the U.S. auto makers were following a similar marketing plan -- sell the cars based on their appearance, and spend most of the development time and money re-designing their sheetmetal every year or two. This tactic worked as long as they had no direct competition. But the foreign car makers (primarily Japanese) spent more of their development time on system design and integrating more advanced technologies than they did on changing the visible features. They might not change the body style for five to ten years, but they continually improved the overall packages. Slowly, consumers started buying the well-designed cars -- not primarily because they were well-designed, but because they were more reliable and had better resale value. Fortunately, the U.S. auto makers realized this market shift and started putting their development time into good design rather than just appearance. Now we have well-designed cars from both U.S. and foreign auto makers, and the consumer has excellent choices.
I'd love to believe that the market will shift for computer software just like it did for cars, and that MS will learn from the market shift and do a better job with the overall design of their products. But this will depend on a number of things:
- Will the primary focus of consumers in the software market shift from feature lists to system reliability?
I'm not so sure -- people sure seem to accept software crashes a lot more than cars that won't start
- Will MS have direct competition that provides better reliability and system integration?
Again, I'm not sure -- I'd love to say that Linux is all the competition that MS needs, but we might need some commercial competition as well
- Will MS continue to manipulate the market with anti-competitive tactics?
While the DoJ vs MS suit may help a bit here, law suits alone will not stop these practices. The market must be aware of how it's being manipulated, and react negatively to the manipulation, or
- Will MS respond to shifts in the market by making changes to their development process and infrastructure?
It's hard to imagine such drastic changes to established corporate practice, but it did happen in the U.S. auto makers, so it's not impossible.
Whew! Brain dump -- thanks for your patience! ;)