The Problem of Open Source in the Microsoft World

I hope that this post will reach more than the usual readers of this blog, so let me introduce my open source resume:

I am not a zealot , you will not find me waving the GPL flag and stroming Microsoft HQ to liberate the captive code there. I do believe in open source software, and in the value of a community around the basic blocks of software.

The open source community in .Net is big, but it is only a fraction of the size of the open source community in other environments (Java, for instnace), compared to the number of users. This issue has been raised several times, it is certainly not a new one. Enough time has passed since .Net 1.0 was released to make the old excuses about ".Net is new", or "the Java guys has a lot more time to experiment with stuff" to lose any strength.

This disparity can be explained by looking at the basic facts of the .Net community. .Net has a central vendor (Mono is marginal at best), Microsoft. This puts Microsoft in a position where they have the ear of every .Net developer, team lead and architect (to say nothing about PHBs). And Microsoft isn't doing anything to foster a healthy OSS community around .Net.

What do I mean by not doing anything to help build an OSS community? Let us look at the Java land, and take a couple of OSS projects there, shall we? JUnit and Ant are two good examples, both of those are examples of projects built by the community, to solve problems that their developers were facing. What is the current status of those projects in the Java land? Well, they have excellent tool support by all the major IDEs, they are accepted as the way you do things in Java. This is a common theme in the Java world, actually. Hibernate and EJB 3.0 are another example, and I am pretty sure that I can carry on for quite a while.

Due to the distributed nature of Java (no single source, even though Sun can dictate stuff), the libraries and tools are competing on merit, and usually the best tools (best may also mean the first, btw) are accepted as the basis from which further work is done.

In .Net, however, the situation is far different. Let us take the same example  in .Net, we have both NUnit and NAnt in the .Net world. In 2005, Microsoft came with Visual Studio 2005, which included similar technologies to both NUnit and NAnt.

The answer to NAnt was MsBuild, which is based on the same principals of NAnt (xml based, declarative, extendable, etc). Now, to be fair to Microsoft, NAnt is GPL'ed, so technically they can't use it for Visual Studio. I am sure that they could have work something with the developers.

The answer to NUnit was MS Test, which has the same model as NUnit (attributes based, etc). It has incompatible syntax with NUnit (or any other .Net Unit Testing framework), and is severly limited compared to NUnit. In this case, NUnit has a commercial friendly license, so Microsoft could certainly have used it.

Now, a developer on the .Net platform has to choose between NUnit vs. MS Test, NAnt vs. MsBuild, etc. Microsoft's tools tend to come with a lot more tools, including fancy UI, wizards, etc. The problem is that when you need to make a change in those tools, you have a lot of wieght to move. Take for example the Abstract Test Case which MS Test doesn't support. At the core, it is an issue of removing BindingFlags.DeclaredOnly from the code that selects the test methods to execute. The problem is that Microsoft can't do that, they need to change the UI, the wizards, etc to be able to support this. Suddenly a very easy change turns into a big undertaking, with implications that can cost quite a bit of money and time.

You can see this pattern repeated over and over if you just take a look at the OSS tools that Microsoft is trying to replace with its own. Some quick examples from the top of my head:

• NDoc and Sandcastle (again, NDoc is GPL'ed, again, I am pretty sure that they could have talked with the developer to change the license).
• Log4net and the Logging Application Block.
• Castle Windsor/Spring.Net and Object Builder.

I get the sense that a lot of time, a functionality that already exists in the open (often with license that allows commercial use) is being passed on because it is not from Microsoft. The only OSS Project that I know of that is going to be integrated into the toolset is the WIX installer, which is a Microsoft project.

What I would have liked to see is Microsoft working with the OSS community to provide better tools for developers based on the best-of-breed tools that already exists. There is nothing more annoying than having to learn (again) how to write a build script to automate the deployment of a project, but in MsBuild instead of NAnt. Or remembering to put [TestClass] instead of [TestFixture].

I do not want new products from Microsoft that does the same thing as existing OSS products. They don't have the same level of maturity as an OSS project that is several years old, and I hate the answer "Well, it may not do [critical feature that I need] like [oss does], but this is Microsoft, and it will definately do it in the next version." (which I got for several times, for several different products, from Microsoft people / consultants).

I think that saying this is tantamount to saying: "We built an inferior product, missing critical features that you need. We inversted in [better UI / integration with Office / etc] and didn't get to this. We are Microsoft, so you will use our stuff anyway, and maybe we will fix it next version". I want to see official Microsoft people recommending the use of OSS products like NHibernate, instead of saying "do it manually, or wait a year and do it in LINQ". There are a good number of projects that sprung up in the .Net ecosystem to fill in voids in what Microsoft is offerring. Duplicating this functionality is a waste of energy. Both for Microsoft and the community.

Microsoft should leverage the successful open source projects to make life easier for developers. The Java model is a very compelling one. Let us take leave of ours senses for a moment and assume that Microsoft has decided that it wants to add support for NHibernate in Visual Studio. What would happen? Better documentations, a lot more samples, probably better, easier tools. The core functionality would remain, and a whole new fucntionality would be added. Everyone would benefit (well, maybe except the DLinq team :-) ).

Returning to the real world, the OSS community in .Net biggest weakness is that the OSS community doesn't include Microsoft itself. And no, CodePlex doesn't really count. CodePlex doesn't bring Microsoft and OSS togetherer in the sense that it is not a place from which things go into the CLR or into the standard tool set. To take a simple example, the Mvp.Xml project. It contains functionality that is essential to heavy users of XML on .Net (of which I am not, btw). Was there any code migrated from Mvp.Xml to System.Xml? Would there be any such code?

As it stands today, I don't think that this is likely. I would like to change this attidute from Microsoft.

Some interesting links on this subject are from a discussion a few months back about whatever microsoft should financially support OSS projects (link 1, link 2, link 3).

Print | posted on Saturday, December 09, 2006 2:06 AM