The software industry is quite unlike any other because (in principle at least) no problem needs to be solved more than once. Each piece of software can build on all the previous pieces.
This puts many companies (especially ones like Microsoft, who make platforms - software which is designed to be built upon) in the curious position of having their partners also be their competitors in many situations. On the one hand, we want to make things as easy as possible for our partners, releasing rich software frameworks to help them improve their time to market. On the other hand, we want to make things as difficult as possible for our competitors by keeping our product code secret.
How do you define the line between product and framework? The extremes are easy - low level functions which are applicable for just about any product (like those for copying a string or creating a window) are clearly frameworks. High level functions like the code in Visual Studio for performing common refactorings or manipulating the solution explorer window are clearly product code because they are really only applicable to Visual Studio (or equivalent products).
But there's a whole spectrum of functionality in the middle which makes it very difficult to draw a hard boundary. Take the command bar code for example. This is the code for manipulating menus, toolbars and commands and allowing users to customize the product by moving menu items and toolbar buttons around and adding new ones. It was invented (and is maintained) by the Office team but is also used by Visual Studio since we have many of the same problems to solve. Currently, command bar functionality is not made available to developers outside of Microsoft. If you want to have customizable toolbars and menus in your own product, you have to add it yourself. But this would be useful for all sorts of other applications, so perhaps we should make it a framework and let other companies use it. The Office team might disagree, since it could make it easier for their competitors to catch up with them.
I think that as a company, Microsoft is (very slowly and gradually) moving from being a "products" company to a "frameworks" company - we're gradually releasing more and more things in such a way that others can build upon them, as it becomes less of a strategic advantage to keep them to ourselves. If we released the command APIs now it probably wouldn't make much of a difference Office's competitors because:
- They all have their own, incompatible ways of providing equivalent functionality - it would be a very big job for them to switch to using command bars.
- Command bars only work on Windows and Office's competitors are all cross-platform.
I think we will continue to introduce new innovations in "product only" form (like the "ribbon" stuff in the latest version of Office) and then turn them into frameworks some years later, once it becomes strategically more favorable for us to do so.
I like this trend because it promotes the idea of "software as a science" (in the sense of creating things that others can build upon) and ultimately helps to advance the "automate everything" cause.