A commonly cited example of how .NET will change software deployment is the office application. Instead of one big application on a CD-ROM, you’ll choose which parts of the application you want, and those parts will be delivered over the network.
In theory, you will be charged only for the components that you use. So, Microsoft Word could be a lot cheaper if you only use the spell checker and leave the thesaurus, organization chart, and that awful office assistant uninstalled.
All the components that make up a .NET application can be loosely coupled and may communicate using XML. So, the text editor part of your word processor could talk to the spell checker using an open standard.
This creates opportunities for alternative service providers. Dictionary publishers can bundle up their intellectual property as .NET services, and start crowding into the Microsoft Office space with fancy spellcheckers. Corel was handpicked by Microsoft to be a .NET early adopter. Corel’s Derek Burney has this to say:
“What’s even more exciting: Imagine that the APIs, or the calling conventions for those formulas, are made public. It means third parties can write formulas, shove them on their own Web site, and then Quattro Pro can call those. “
Just as there may be dozens of Black-Scholes option pricing plugins available for spreadsheet users, you may eventually have dozens of choices for spellcheckers. And so on for drawing components - wouldn’t it be nice to use Adobe Illustrator to create diagrams inside Word instead of the limited drawing tools that come with Word? Or how about a drawing component that lets you scribble on your Bluetooth-enabled handheld, simultaneously updating the drawing in your Word document?
.NET Component Aggregators
Who is going to help you choose the components that will make up your office application? How will you know which components suck and which ones rule? Or more importantly, which option pricing plugins have portfolio-threatening bugs?
This is the same challenge that faces Linux users… which shell, which C compiler, which editor, and which desktop? These are all questions that the makers of Linux distributions help you answer. Sure, a given Linux distribution may come with dozens of desktops you can choose from, but only one of those is enabled by default. Novice users are going to stick with the default - they will let the distributor decide for them.
In the .NET future, when you can combine components from hundreds of suppliers to create desktop applications, who will you turn to when you need to choose your components? Some companies may choose a high-priced consultant, but perhaps the rest of us will turn to a component aggregator.
A .NET component aggregator would be a lot like a Linux distributor - they would provide an installation program that pulls these components together in a unified, integrated, and well-tested whole. Maybe lots of users will like the service that these aggregators provide, and we’ll start seeing hundreds of Microsoft Office distributions on CD-ROM, all slightly different!
Microsoft has knocked Linux for having so many distributions. However, the variety of distributions is a function of the fine-grained choices that can be made when assembling a Linux system - if there weren’t so many choices, there might be only one distribution.
When the .NET vision is realized, these sorts of fine-grained choices may be available to Microsoft’s users. But Microsoft needn’t worry, since they can always turn to the Linux community for a distribution model :-)