Microsoft and Open Source: When the Idea of a Single Path Collapsed

There was a time when the route to most computer users seemed to pass through Microsoft's gate. Windows was on their machines, Office was in their workplaces, and Visual Studio was in developers' hands. That dominance was real, and it did not come from nowhere. Microsoft built powerful products and supplied tools that made it easier for millions of people to create and distribute software. But technical strength does not give any company the right to decide which path everyone must take.

The distance between building excellent tools and turning those tools into mandatory gateways is at the heart of my objection to Microsoft, even though I have worked with nearly all of its products during my career.

Real Strength—and a History That Should Not Be Whitewashed

It would be unfair to deny Microsoft's influence on modern software development. Windows and its development environment created a vast market for software, and the company invested heavily in tools, documentation, and backward compatibility. One can criticize Microsoft sharply while acknowledging its enormous engineering ability.

But criticism of its monopolistic conduct is more than a personal impression. In the U.S. antitrust case, the court found that Microsoft possessed monopoly power in the market for Intel-compatible PC operating systems and documented practices it used to protect Windows from cross-platform software threats, including browsers and Java. The court's findings of fact

The message many developers received was clear: you could build inside the ecosystem, but leaving it might be costly. When the cost of leaving rises because your work depends on interfaces, tools, formats, and distribution channels controlled by one company, freedom of choice shrinks—even if entering that ecosystem is easy and attractive.

CLR: Engineering Brilliance or a New Center of Control?

With the arrival of .NET, Microsoft offered a powerful idea: different languages could produce intermediate code and run on the Common Language Runtime (CLR), benefiting from a common type system, libraries, execution services, and memory management. This was an engineering achievement that deserves respect. It made it easier for components written in different languages to work together and gave application developers real productivity gains. The Common Language Infrastructure (CLI) was also described in a public standard, ECMA-335, so it would be wrong to portray the entire concept as a closed technical secret. ECMA-335 standard

As a developer, however, I saw another side to that offer. The more a language or company depended on CLR, .NET libraries, and the platform's tools, the more its decisions became tied to a center over which Microsoft held considerable influence—particularly during the years when .NET Framework was primarily tied to Windows. A programming language is more than its syntax. It has a type system, a memory model, libraries, system interfaces, and build and deployment tools. Whoever controls those layers can influence the direction of the language built upon them.

Is there a document proving that Microsoft declared an intention to bring every programming language under CLR? I have no such evidence, and I do not want to attribute an undocumented motive to the company. What I am describing is my reading of the effects and incentives of its platform strategy: a compelling offer that invited others to build their languages and products within its world. I, like other developers, had every right to reject the idea that this world should become a mandatory point of reference for software development.

We should therefore be precise about the outcome: CLR was not a catastrophic technical failure. What failed was the idea that CLR could become the only path to which the world's languages and companies would have to submit. Strong languages, environments, and tools continued to thrive outside it. Native programming, open systems, and competing platforms kept advancing. Success in its own domains does not entitle .NET to monopolize the future of programming.

How Open Source Broke the Aura of a Single Center

The open-source community did not need one company as large as Microsoft. Its strength came from having many centers: operating systems, tools, compilers, and libraries that people could use, study, and develop without asking any one company's permission. As Linux, the web, and cross-platform tools grew, every company seeking developers had to operate in a world it could not seal off for itself.

Open source was not the only force behind Microsoft's transformation. The web, mobile devices, cloud computing, competition, and legal scrutiny also changed the market. But to dismiss the open-source community's influence would be to deny a change we watched happen: cross-platform support and participation in developing tools became important ways to earn developers' trust, rather than favors a company could grant whenever it chose.

Microsoft's own decisions show the scale of the shift. In 2014, it announced that the C# and Visual Basic compilers in Roslyn would become open source. It then announced that .NET Core, including the runtime and core libraries, would be opened, explicitly citing a cross-platform .NET and a stronger ecosystem among its reasons. Today Microsoft presents .NET as an open-source platform that runs on Windows, Linux, and macOS. These facts deserve recognition, but they do not erase the company's history or mean that everything it distributes is open source. Roslyn announcement · .NET Core announcement · .NET website

Even VS Code, which I use, reminds us to examine the details. The Code - OSS project's source code is published under the MIT license, while Microsoft's Visual Studio Code distribution has a different product license and includes Microsoft-specific additions. Openness is not a switch that is simply on or off. We should always ask: Which code is open? Who controls distribution? What remains closed? Official VS Code explanation

My Position as a Developer

Over the course of my career, I have used almost every Microsoft product. Today, in my regular work, I use little beyond Windows, Office on occasion, and VS Code. I do not deny the value of these tools or tell anyone else not to use them. But I do not want to build my technical future on the assumption that one company should stand at the center of every language, compiler, library, and deployment platform.

What open source broke was not Microsoft's capacity to innovate or succeed. The company remains powerful and has learned to work within the open world. What broke was the aura of the only path: the idea that developers must pass through one gate for their work to have a place in the market.

That, in my view, is the open-source community's real victory. It did not erase Microsoft. It compelled even a giant of its size to address developers in terms they value: interoperability, the ability to inspect the tools they rely on, cross-platform support, and the freedom to choose their own path. We must continue to defend those principles, whether the threat of a closed gate comes from Microsoft or any other company.