The VS Express dotNet saga


The article itself provides a decent summary, and the various discussions around the web provide a little more detail but let me summarize what you don't get from the article.

  • In about two years of communication, MS pressed TestDriven.net developer Jamie Cansdale to remove VS Express support from his product because
    1. His use of IntelliSense violated the Visual Studio SDK license
    2. He used publicly documented APIs in violation of the Visual Studio license
    3. He added a button to the VS Express Interface in violation of copyright
  • Jamie asked MS repeatedly to explain plainly how anything he had done violated any EULA's or copyrights
  • Jamie removed support from VS.net and expressly told MS he was doing so to get rid of the legal cloud hanging over his head
  • Eventually, he asked again for plain language explaining why he could not release his software
  • MS said "we don't need to rehash this"
  • Jamie re-released his software
  • MS had their legal team send him a letter threatening a lawsuit

So after this article comes out and gets a lot of press, Dan Fernandez, a VS team leader of some sort comes out with his blog entry spelling out that Jamie/TestDriven.net were in violation of the EULA, that Jamie's software is an illegal hack, that VS Express users aren't real developers anyways so why would they need unit testing, that Jamie's work threatens Microsoft's Visual Studio Business model, and that Visual Studio Express was a labor of love and was being given away for free because Microsoft just wanted to be nice.

Of course, everybody and their brother not working for Microsoft sees right through this - and there are tens or hundreds of comments posted spelling out that in two years MS has never stated how exactly TestDriven.net has violated the EULA.

Dan provides a weak follow up not really saying much of anything, but associating the terms "illegal", "code injection", and stating that anything that extends Visual Studio Express in any manner is a violation of the EULA.

Parsing it Out

After that long summary, there are a couple of interesting observations to be made. First off, Jamie is a guy who is in a tough position - he's been developing for the Microsoft platform for years and is now coming full circle to the realization that if he wants to build a business model based on a Microsoft environment, he is entirely dependent on Microsoft's continuing cooperation to do so.

Microsoft has bigger problems than one MVP extending Visual Studio. One of the big differentials between VS licensing levels is extensibility. Their existing partnership base pays a good deal of money to be able to add functionality to Visual Studio. If those partners decided to drop their partnerships to attack the VS Express marketplace, Microsoft loses in two ways - they lose partnership revenue, and they lose revenue from end users who would be upgrading solely to take advantage of an extension.

There is also the fact that Jamie's work represents an unaddressed security issue for all versions of Visual Studio - and that an real OSS buildup of VS extensions opens Visual Studio to the kinds of viral problems that have plagued IE and IIS. With an installed base of several million users, Microsoft could have a very rough road ahead of them. Not only that, but the alienation of such a strong developer base could really push developers in the direction of Mac OS and Linux platforms.

Microsoft had three choices - plug the security hole, change their method names, or pressure Jamie to stop. It's surprising that they chose the last option which is the least effective and the most problematic one. You'd think that two years into this process they would have achieved the critical mass to actually plug the security hole, but corporate environments aren't always built to deal with things logically.

At this point, Microsoft has no choice but to remove the functionality from VS Express (well, they could simply remove the VS Express product from their lineup), but we seem to be years away from them changing their design to be secure.

I've managed to stay away from dotNet development products for the most part, and I'm glad I did. My experience with MFC and older versions of VS showed me that the products were great, but there was very little in terms of community contributions to extend the code base or environments. Most everything available when I tried it out was poorly documented, coded poorly, and/or fee-based.



What visitors have to say about The VS Express dotNet saga