March 2005: Microsoft's developer tools division announces that the top tier of Visual Studio 2005, Visual Studio Team System, will run $10,939, more than triple the cost of the high-end SKU released two years prior.
September 2006: Microsoft's developer tools division announces that the upcoming Visual Studio 2005 Service Pack 1 may not be compatible with Windows Vista.
October 2006: Microsoft's developer tools division announces that the upcoming XNA Studio product SKU will not support Visual Basic, but instead only support Visual C#.
These instances, taken in isolation, may just point to minor communication gaps inside Microsoft, but taken as a whole, it points to a division that is placing its own profits above the needs of not only the customers, but Microsoft itself.
It's not hard to see why. If you read Microsoft's 2006 10-k and cut through the double-speak involved with having development tools intermixed with the server OS on the balance sheet, you can see that income over the last year for developer tools is close to flat at best. The income increase for the division is similar to the income increase that has followed each major release of SQL Server over the last decade.
In the past, when Microsoft didn't split income out, the developer tools division was seen as a cost, but a necessary cost. Microsoft's developer tools were generally cheaper than the competition, better than the competition, and were focused at taking advantage of new technologies being introduced by Microsoft's other divisions. While they were an expense, they resulted in a surge in ISV's and kept the majority of the software being developed firmly planted on Microsoft platforms. They may have been an expense, but their efforts directly contributed to the efforts of all other internal divisions, so the expense was really seen as essential.
When they split the divisions out in order to increase earnings transparency, the tools division needed to actually make money. They couldn't act as a loss-leader anymore. Unfortunately, the steps that have been taken put the tools division in direct opposition to the needs of Microsoft itself. Let's look at these steps one by one to prove the point.
Up until VSTS, Microsoft had a premium developer SKU: MSDN Universal. For an afforable annual fee per developer, a development house got all of Microsoft's development tools, development/test copies of all of Microsoft's server products, copies of Office, quarterly updates to the documentation library, and more. It was a cost people were accustomed to paying, and many a budget was designed expecting to pay that for the new premium SKU.
Businesses and developers were shocked to hear the base (non-discounted) price of nearly $11,000 per seat for Team Suite and nearly $5,500 for each individual Team Edition. This resulted in reduced uptake for Team Foundation Server, and an increase uptake in the mid-range SKU (MSDN w/ VS Pro), which was actually a savings for developers.
Microsoft's defense was that even though developers got all of everything before with MSDN Universal, they were getting more than "everything" now, so the cost had to go up. Customers didn't see it that way. They used to pay for a duck. It walked like a duck, swam like a duck and quacked like a duck. Now that they were being told that this duck was an endangered water emu, they didn't feel like paying triple for it.
S. Somasegar's announcement that they were going to risk Vista incompatibilities in order to get VS2005SP1 out to customers because "customers demanded it" rang false to me. Maybe it's the old blue badge in me, but the "customers demand it" justification was used for more bad decisions than just about anything else I can think of. Truth be told, many large developers won't install any new development tool from Microsoft until it hits the first service pack. The developer tools division is risking their latest and greatest tool not working on the latest and greatest operating system in an effort to get more sales to people who won't install Vista until Vista SP1.
In 2003, 52% of programmers worldwide used some version of Visual Basic. Even this month, according to the TIOBE index, available Visual Basic resources outnumber C# resources by over 3 to 1, and the trendlines show VB resources increasing at seven times the rate that C# resources were decreasing. Visual Basic game development resources pop up on a daily basis. The vast majority of Visual Basic game coders refer to themselves as hobbyist-level.
So, if you're developing a hobbyist-level game development tool targeting the .NET Framework, what do you do? If you're the XNA team, you evidently slash and burn your target market. Not only did the XNA team decide that VB wasn't worth a v1 release, but for the first time since November 2000, Microsoft is saying that VB isn't worth it as a game development solution. (In November 2000, Microsoft released DirectX 8.0, which supported VB through a type library. While not easy to use, nor full featured, it was a step towards proving VB's capabilities, and motivated Managed DirectX.) For a community like the BASIC community, which has been backed by Microsoft since the company's inception, it's a kick to the crotch.
So, dev tool guys, dumb question time. Would you be making these same product decisions if your earnings weren't being exposed? Would you be taking care of your other divisions and your customers if you didn't need to make that number on the balance sheet go higher?