This week we were at DevConnections in Las Vegas. It was an ideal opportunity to chat to customers past, future, and present, to participate in the official launch of Visual Studio 11 beta, to meet with partners, and to hear the news.
One item of news that I’m sure you’ve already heard of is that Microsoft have decided to open source ASP.NET, or, to be more precise, ASP.NET MVC (which, admittedly, has been open source since v1), the ASP.NET Web API, ASP.NET Web Pages (aka, Razor), and the System.Json assembly. What’s also new is that they are now taking contributions and patches to the source, something they haven’t done before. (Blog post from ScottGu.) This effort doesn’t alter what you are doing now with ASP.NET (it will continue to be part and parcel of Visual Studio, for example), but it will mean that ASP.NET will broaden its appeal to non-Microsoft projects. (Blog post from Miguel De Icaza, CTO of Xamarin, the vendor for the Mono products.)
We also had the opportunity to have a one-on-one chat with Jason Zander (Corporate VP for Visual Studio) about this announcement and about what’s coming up with regard to Visual Studio 11 and beyond. Whereas a lot of what we talked about is private, there was one thread that came up again and again in our discussion: tooling. You see, with the announcement of the open sourcing of ASP.NET, Microsoft are essentially saying that it’s the development tools that are significant and not necessarily the run-time code. They’d rather give away the run-times and emphasize the market for the Visual Studio ecosystem, than try and sell the whole kit and caboodle. Even more important, I would say, is the fact that ALM-type tools (Application Lifecycle Management) are already the major market in development tools.
With Visual Studio, that means TFS (Team Foundation Service). Or more properly, taking into account the other big Microsoft announcement of this week, Team Foundation Service on Windows Azure. (Blog post from Brian Harry, PUM for Team Foundation.) This new service, currently in preview mode, is fascinating since it moves a lot of development build processes to the Cloud. In essence, think of TFS as a bunch of build servers in Windows Azure, ready to compile, to unit test, or to run any type of other process as part of the build (let’s say, as a wild, er, rushed example, some kind of code issues analysis program). The service allocates a build VM from a pool, runs the build script, and once the build is done and the results copied, releases the VM back to the pool.
In other words, the developer tooling market is growing in importance and reach. Not only for these “big iron” tools, but for smaller, more focused tools as well. The “code” you buy will get less important, but the tooling and development aids you get with it will evolve to be much more significant and relevant. (See my fourth point in a previous blog post of mine.) If you like, developers aren’t going to want to choose from a buffet of vendors for pieces and parts as they’ve perhaps done in the past, they’ll want the whole enchilada from one, and the tooling needed to get the most from it.