VSInsider

Copy and Paste: Redmond's Open Source Strategy

• By Mark Michaelis
• 03/01/2011

On occasion I've been surprised that Microsoft has put significant effort into developing features and functionality already available within the developer ecosystem. Frequently, the functionality is even available for free via open source, so there doesn't really seem to be a "market" that Microsoft is trying to enter or gain a business advantage in. And yet, Microsoft invests significant time and money in creating functionality similar to what's already available -- frequently even using the open source implementation as a reference for requirements of what to do (or not to do).

Let's consider a few examples. When the Entity Framework was released, NHibernate (open source) and LLBLGen Pro, among others, were well-established players in the market. Ironically, Microsoft itself released LINQ to SQL at the same time as the Entity Framework, but later ended development on the technology.

Or consider Visual Studio Unit Testing, which was launched despite well-established open source alternatives, including NUnit, XUnit and MbUnit. There were also third-party unit testing solutions like TestDriven.NET and Resharper.

Finally, MSBuild fairly closely duplicated the functionality and approach provided by NANT (open source). Similarly, when it came to creating an unattended build server, there were and continue to be numerous solutions already on the market before Visual Studio Team Build was released. Similar solutions included CruiseControl.NET in open source and TeamCity for purchase.

Given the prevalence of available solutions, often for free, why would Microsoft develop similar proprietary solutions to solve (seemingly) the same problems?

Make It Microsoft
Let's face it, there are cases where Microsoft's control over Visual Studio development and the languages it supports enables the company to simply do things better.

In the object-relational mapping space, it wasn't until there were fundamental language features in the form of LINQ that developers began to experience a fully object-oriented API that interfaced with the relational database. Through the combination of LINQ and the Entity Framework, mapping a strongly typed, object-oriented programming API on top of a relational database became possible. And, because developers outside of Microsoft have essentially no ability to modify the C# language, only Microsoft could create a broad solution that penetrated the core of the language and integrated with Visual Studio so comprehensively. Microsoft frequently chooses to duplicate what might already be available in open source and third-party solutions simply because it's in a position to do it better.

There's also the benefit of being built-in. For many developers, installing third-party software -- especially open source software -- is considered a security risk and is prohibited by IT. These developers are clamoring for basic, best-practice software development processes and tooling (such as Visual Studio Unit Testing), which are built into Visual Studio and require no additional deployment or configuration work. Developers like these celebrate when Microsoft provides its own solution to something that's perhaps already freely available.

Developers who lack the time or resources to research and maintain a host of third-party solutions often feel the same way.

Entering New Markets
Then there's the allure of new business. There are many cases where Microsoft duplicates functionality available from third-party or open source solutions in order to gain a foothold in a new market.

Visual Studio Team Build is one such example. When Visual Studio Team System emerged as a solution for application lifecycle management (ALM), there was no significant contender that offered automated build, project tracking and collaboration, source code control, client-side developer tooling, and a reporting module that spanned the overall solution. Visual Studio Team System provided just such an offering, along with the integration across its parts that allowed them to work together.

Although virtually all of the individual categories of tools included with Visual Studio Team System were available from alternative sources, none provided the integration between the tool sets. In choosing to build Visual Studio Team Build as part of Visual Studio Team System -- even when there were competing third-party solutions -- Microsoft was intentionally entering the ALM space with its own offering.

There are, of course, numerous reasons why Microsoft would reproduce functionality already available from third parties or open source solutions. But most of those reasons boil down to three themes: Microsoft is in a unique position to accomplish work that others can't, deployment of a Microsoft solution is a customer requirement, or a market opportunity has compelled Microsoft to move into a new space.