Microsoft needs to quickly incorporate real-world feedback into its products
One of the most intriguing aspects of Linux and the open-source development process is the perceived ability to get real-world experiences back into the core product. If you create new code that significantly improves the open-source product, your creation ideally could become part of the core product. In that way, open-source products potentially combine the shared wisdom of all the users and developers.
In contrast, Microsoft receives feedback about its products but revises its products in a closed process. Because Microsoft's product-development process isn't open, I'm left with several questions: What does Microsoft do with customer feedback? Does Microsoft incorporate the combined wisdom and experiences of its customers into future Microsoft products? If so, how?
Often the people who first use a product find its flaws and pave the way for improvements. For example, Microsoft solicits feedback through its Joint Development Program (JDP) for some of its largest customers and earliest adopters. Microsoft Consulting Services (MCS) helps JDP companies implement the beta versions of Microsoft software—both to help test the new code and to see it working in real, large-scale environments.
Unfortunately, these discoveries don't make it back into the OS in a timely manner. Microsoft fixes bugs and quickly makes the fixes available. But the real-world implementation experiences don't become part of the product until the next major release—perhaps 3 or more years after they're discovered. Yes, these experiences show up as white papers on Microsoft's Web site. But why not incorporate the shared wisdom into the configuration wizards?
Wizards? We Don't Need No Stinking Wizards!
In the real world, Win2K early adopters (the first 20 percent of customers who bought the product) don't rely on the wizards. They're too immersed in the details of deploying Win2K to find wizards valuable. However, those who aren't early adopters (about 80 percent of buyers) rely on wizards—or want to—whether they admit it or not. They don't have time to figure out how this stuff works. They have jobs to do, and they're hoping that Microsoft encapsulated the shared wisdom of the early adopters into the product so that their jobs will be easier.
Microsoft has been fairly negative about the open-source development process. Microsoft lets only a few companies view source code, and also charges a fee. By creating an open-source process for developing the administration wizards, Microsoft and its customers could produce something of real value to IT administrators.
To create such a process, Microsoft would have to change its philosophy about how it develops wizards. First, Microsoft would have to rewrite its wizard code to be more scriptable—allowing easy programming for an IT administrator. This model is similar to how Quest Software developed its FastLane Migrator tool. Quest Software loaded the FastLane products with wizards but built the products on a robust scripting engine.
Second, Microsoft would need to create an open-source process for submitting wizard scripts for possible product inclusion and a rules-based engine for executing scripts based on the thousands of installation conditions that exist in the real world. The result would be wizards that incorporate the shared experiences of real-world installations.
Microsoft's failure to incorporate lessons learned into successive products isn't limited to the server environment. When Microsoft launched Windows XP, the company asked for and received feedback about the Home Networking wizard. But instead of using this information to improve all home networking products on XP, Microsoft used the information to improve its Microsoft-branded home networking products. Microsoft's home networking products work on all Windows OSs, so by improving the hardware, the company applied its home networking experiences to a potentially larger audience. But Microsoft should have made these changes available for XP to benefit all Microsoft's home networking hardware partners and users.
Driving Users to Linux
Microsoft's failure to use feedback in future products has driven some people toward Linux, which, in theory, incorporates the shared experiences of many users and developers in its open-source code. Microsoft has talked about creating a more open-code environment. Here's a way the company can demonstrate its commitment to open source, the Windows community, and the IT administrators who have to deploy the products: Put all the Windows wizards into the open-source developer community. Give developers full access to the code and a process to submit changes to a wizard community for inclusion into the product. When users get ready to install a particular Windows-based technology, the OS will first look for the latest version of the wizard and offer up-to-date, fully tested help with installation and configuration.
In the real world, IT administrators' number-one problem is digesting all the technology that vendors push down our throats. In the real world, we still have NT machines that have been humming along for years and don't require our attention. In the real world, getting projects approved without attaching the overly optimistic Return on Investment (ROI) that our chief financial officers (CFOs) want is hard. So if Microsoft can incorporate real-world wisdom quickly into its products, or at least let the open-source community do it for them, then administrators' jobs will get easier.