Why Microsoft makes a mistake with the MSDN subscription changes.
Eric Sink blogs his thoughts into the world about Team System, the pricing, MSDN and the recent uproar about all of this. I agree with him about the positioning of Team System, the pricing related to that positioning, the MSDN licensing as it is now and how it is misunderstood.
Though I think a lot of the uproar isn't about the fact that small ISV's or independent consultants want to use an enterprise targeting system like Team System (or as Sink put it: want to use a Boeing 747 to get to McDonalds). I think the real reason behind a lot of the negativity about the new MSDN model is fed by the fact that these developers, myself included, simply want to buy a package from Microsoft which allows them to write software, use sourcecontrol, have unit-tests, use fancy designers and do bugtracking/issue management.
In the past year, Microsoft bombed us with their Team System propaganda and a lot of people were very pleased to see Microsoft made a fully integrated system which did everything: allowed you to architect webservices, test your application with fully integrated test tools, use bugtracking/issue management and much more. This was what they're waiting for for years.
Microsoft offers developers a set of MSDN subscription flavors. These are often bought by ISV's to get every tool they need for a lower price (i.e.: per developer, the licensing costs are lower, if you buy for each developer a universal subscription). Because the universal subscription has everything you needed as a developer, it was the obvious choice: VS.NET enterprise architect was included, VSS and a lot of other tools/servers required for development of n-tier applications (the type of application most developed).
With the propaganda fed to these developers and ISV's for the past year about Team System and its functionality, the obvious expectation was that to get your hands on it, a MSDN universal subscription would be enough. After all, that was the package you bought for a developer if you want all developer tools that developer needed, right?
Though, this isn't the case with the new MSDN subcription model. For the first time, the MSDN flavors require a choice to be made: are you an architect? A developer? A tester? And if you need more developer tools, you have to pay more money. A bit strange, because, an ISV buys the MSDN package to get all the tools needed for development in one easy to purchase package.
These two things: the choice you have to make which team system functionality you want to use (the client version) and the requirement to shell out more money for the functionality you actually need, are the real reasons why people are upset.
Let's start with the first, the choices. I'm a small ISV, and with me a lot of people are. Because we have to make a choice what each developer at our small ISV is: architect, developer or tester (according to Microsoft), these developers can only use one of the three available applications while these developers need all three, as they wear more hats (often all three), not one. It's as if developers at small ISV's don't need to write tests or don't require an integrated test suite (I use testdriven.net, very good, but not as feature rich as Team System's features), and it is as if developers at a small ISV's don't need an architectural toolkit to design webservices or other higher-level design system. These small ISV's get VS.NET Enterprise Architect today when they purchase MSDN universal licenses for their developers (or should I say: testers/architects?). So Microsoft apparently changed their minds what developers at these small ISV's do.
Let me be blunt: Microsoft doesn't get it when it comes to what their customers need. That's right: need, not: want. These are two different things. If you as a developer can't use a feature you need, you'll be angry. If you as a developer can't use a feature you want, it's too bad, life goes on. Why doesn't Microsoft get what their customers need? The vast majority of developers in the world aren't large corporate developers, but work at small(er) ISV's. They were buying the MSDN subscriptions to get the tools they need. As times change and Microsoft did build the functionality these ISV's need now and in the future (real sourcecontrol, real integrated testing system, real bugtracking/issue management), they want to purchase that functionality from Microsoft using the MSDN subscriptions. Because that was the most affordable package to buy for a developer.
Though, they're not able to do that anymore, not by using MSDN subscriptions. They have to make a choice: who's the architect here, and who's the tester? What if there are just two people in the ISV? Buy three MSDN premium packages to get the applications for all three hats? Or is Microsoft really thinking developers at small ISV's don't test, don't need sourcecontrol, don't really need issue-management/bugtracking and don't need higher order designers for the applications they need? Oh, do I hear you say... "but you can buy it for a little more extra $$$" ? Ok, fair enough, but what's the use of having MSDN subscriptions if they're not enough? Why not make these MSDN subscriptions worth purchasing so they still contain the tools these ISV need? Why belittle small ISV's by forcing them to make a choice because their developers don't seem to test and use bugtracking systems and use sourcecontrol systems?
The other point, the money required to get the the functionality you want, is related to the first and is also related to the hype built up in the past year. As expectations grew higher and higher, and as developers saw that what Microsoft was creating was what they needed, it's a bit of a pain to understand that what a developer needs now comes at a price of $10,000.= instead of a $2,500.= (or thereabout). (looking at functionality, not at positioning, which is marketing/business related, not developer/feature related). There is only one question possible here: why?. Why did Microsoft bypass the small(er) ISV, by not offering the tools they need, while the functionality is there?
Personally, I can understand the pricing for Team Foundation Server as it is a product positioned at the enterprise teams. What I don't get is why I can't buy a package from Microsoft for a reasonable price, which gives me a Visual Studio.NET 2005 with integrated testing, bugtracking, issue management and higher level designers for services. Because I don't need them because I don't have 8,000 employees? The functionality is there, it just has to be packaged.
So what's there to do? Well, for small(er) ISV's, it's perhaps more efficient now to simply not purchase a MSDN subscription anymore, but buy a VS.NET professional edition per developer and buy /get the other services elsewhere, for example Source Gear's Vault. Or use subversion + the NCover/NUnit tools and a free Linux-based bugtracking system. Because, why would a small ISV still look at Microsoft for the tools it needs? After all, according to Microsoft, developers at a small ISV have just one single task...