In the Free Source community, discussing this subject probably goes back to the announcement of the GNU project, including the microkernel project GNU Hurd, by Richard Stallman in 1983. The microkernel architecture, first proposed by the MACH project of the Carnegie Mellon University, should have overcome design limitations of monolithic operating systems by providing only a thin (but extendable) software layer above the running hardware which offers full flexibility (and thus greater possibilities) to the system user. It didn't have only friends, though. One of its most prominent opponents was Linus Torvalds, the founder of the Linux operating system, which was first released in 1991. Torvalds not only chose the monolithic approach, he openly described existing microkernels as crap. (Others weren't speaking nicely about Linux, either.)
Over time, every corner of the software world was subject to similar debates. While the conservatives argued for the speed of monolithic products and raised panic about the implications of the complexity of modular systems, the evangelists praised the possibilities of flexibility, configurability, re-usability and interoperability.
The evangelists developed efficient component frameworks like ORBit and popular toolkits like GTK+ and, on top of them, complete development environments like the desktop environment GNOME. But the environments became somewhat monolithic themselves in respect to size, speed, interdependencies, and interoperation with other environments. GNOME is a very good example. It started as a concurrent to the already-existing KDE and didn't share a component nor even a protocol with KDE in the beginning. The size of the installed codebase was a few hundreds of megabytes. While there were only a few native desktop applications, non-native applications showed unexpected behavior because of lack of support for the new GNOME strategies.
Developing functional, modular environments turned out to be a highly sophisticated long-term business with less usability and interoperability than expected. Monolithic environments like MS Windows and applications like MS Word still ruled the software market, and they provided even more functionality than GNOME and KDE together. In fact, many desktop environmentalists began believing that without having their own MS Office-like super-applications, the whole Free Source market could be proven obsolete by the proprietary competitors. In consequence, even component model fundamentalists like Miguel de Icaza started projects like Gnumeric, an MS Excel clone, and Evolution, an MS Outlook clone.
On the other side, monolithic software development had already changed to a modern, mixed approach. The developers wanted to profit from modern strategies like object-oriented programming (OOP) and the available component models (CORBA, COM, and others). The new approach proposed making extensive use of the environment underneath. However, the most-criticized disadvantages of monolithic software, the low re-usability and interoperability, remained. Besides, only a few of the Free monolithic projects like OpenOffice or Mozilla could attract enough developers to maintain the huge codebase.
It turned out that both sides were only half successful, and that a combination of both models was the best way to overcome the inherent limitations. However, this is just a halfhearted solution compared to a real innovative strategy aiming at overcoming this situation. Miguel de Icaza, instead, propagates a brand-new development environment called .Net, which is out to conquer the Free software market soon -- though it's being developed by Microsoft. To not miss the deadline, Miguel started the mono project, a Free implementation of the .Net programming language C#, and invested a lot in promoting his great new vision.
However, even Microsoft doesn't seem to believe that .Net will overcome the era of monolithic products. The effort to integrate all of MS Office into .Net shows that only the next step in software development history is being taken: the era of modular monolithic applications. The .Net approach only translates the advantages of both software development models into a consistent (though quite big and complex) modern software development strategy. Microsoft doesn't change anything fundamental except that it, at least for itself, ends the controversy and draws its conclusions.
The reason for this philosophical change is quite economical. The future success of Microsoft is doomed to be based on a sane component model to avoid being passed by its competitors in the long run. This is because Microsoft is the developer of hundreds of products, defacto standards and other greater projects which have grown very complex over time and have to be mastered quickly and efficiently. The typical customer is not interested in such details and wants solutions that match his individual situation. This is true for both end-users and application developers, and it forces Microsoft to provide customer-centric frontends with well-known behavior. In other words, Microsoft must be able to feed its own needs as well as every customer wish with .Net. This also explains why Microsoft will not give away control over it.
The Free Source market doesn't have a central instance. However, from the bird perspective, it is one big, interdependent system which is organizing itself automagically like a fuzzy (but functional) alternative to .Net. This .free doesn't show a clear beginning nor a clear end, but if you want to have an overview, you just have to browse the DVD of your favorite distributor. The Free Source market has already taken a similar (but more random) approach to that of Microsoft, but the individual Free Source developer is too small to see it.
So, what is the moral of the story? The winner is both? No, actually not. Is it .Net? This may happen if we don't have an eye on it. Actually, at the moment, there is no clear winner. It seems that there are only clear losers. As explained above, both the monolithic and the component model can only coexist halfheartedly. On the other hand, .Net and .free, though they appear to be two different ways of creating a natural response to this problem, are not overcoming the inherent problems, but just trying to make the best of the situation. The .Net approach is the most consequent because it not only really fits all the parts together with just a single strategy, it comes with all the nifty stuff needed to reach the goal. There is really a lot that .Net includes which may make it the better approach already. This is also because other proprietary strategies like Java do not go so far and are developing in quite isolated ways. The .free approach doesn't even look like ever being able to reach this consistency because it develops too randomly to ever find a baseline that at least most free developers will agree on.
Here we come to the biggest thread of all. Even .Net can only offer, but not fulfill. And even Microsoft is too small to provide the software world with every piece of code the customers can think of. Therefore, it needs the help of other software houses, which means that the success of the .Net approach is in the hands of the proprietary software market. However, this market itself is not as flexible and open as .Net. Though .Net shows the potential, it may fail because it ends as the playdoll of commerce.
The .free-market, on the other hand, has the liberty and openness to make the new approach a success. However, this market can't even decide on a programming language. Even industry standards like CORBA and XML do not capture every Free developer's heart and mind. The potential may be left unused. This would mean that .Net is the best way to go.
What can we do to prevent this? We can try to agree. Not about the the right programming language, nor the right desktop environment, but we can try to agree on good practices and standards, regardless of how many programming languages we use to implement them in the end.
Fortunately, some groups, like FreeDesktop.org, still remember the good old rites like those celebrated by the X Consortium; they first discuss solutions and agree on them, and afterwards implement the code appropriately. Unfortunately, there are only a few such groups, and their manpower is low. Also, they are often too quick in developing the prototype and only documenting the particular API; remember CORBA and IDL. Nevertheless, we may see more people turning to this more scientific approach to software development in the near future. It may help us find good practices and standards we can all agree on -- at least in theory. Maybe then we'll come to the question of who is the winner, monolithic or modular development. Maybe then we'll ask: Who is the winner, .Net or .free?