Most of the time, .NET is my platform of choice. It’s versatile, consistent, and well-tooled. It’s rarely glamorous. Yes, we get excited about the latest C# innovation, and there are occasional hot technologies (Blazor now, Silverlight in the distant past). But if a hotshot developer says .NET is a for people who work at banks — well, they’re not entirely wrong.

There’s nothing wrong with being boring sometimes. Line-of-business applications run the world. But it becomes a problem when the corporate side of Microsoft technology gets in the way of the progress we really want to see. And nowhere is that more visible than in the world of open-source software.

Here’s the problem. This year, Microsoft successfully shifted from the closed-source, Windows-centric .NET Framework to the open-source, cross-platform .NET 5—basically rebuilding their software development engine while still flying the plane. It was a hugely ambitious six-year project that began with the announcement of the first version of .NET Core. (If you still think Microsoft is a dinosaur, this is proof that it’s more velociraptor than plodding brontosaurus.)

But .NET 5 still lives in an ecosystem where Microsoft is a benevolent dictator, open-source projects are viewed with suspicion, and community involvement unfolds on the margins. Compared to any other modern platform, .NET is a stubborn monoculture. And if that doesn’t change, we’ll sacrifice the future for short-term security.

The culture problem

The reasons for .NET’s fragile ecosystem are many — and most of them point back at Microsoft. Principal Program Manager Immo Landwerth sums up the problem like this:

“Historically, we’ve taught customers to expect all the features to come from Microsoft. Since we can’t build everything, especially not at a pace at which other OSS ecosystems evolve, the set of trusted libraries for .NET must grow beyond just Microsoft.”

If you’ve programmed on .NET, you know that this vision is at odds with the current culture. Today, the majority of .NET developers still build their projects using Microsoft components and their own code, with no community contributions. They use a tech stack ordained by Microsoft rather than a set of tools they chose themselves. It’s almost a matter of identity.

Compare that to JavaScript, where even the simplest project is likely to draw on a half-dozen libraries, and different app-building frameworks compete and coexist. There’s a cost to this chaos, but there’s also a huge benefit. That’s because the open-source projects in the JavaScript ecosystem don’t just patch gaps, they drive enthusiasm, promote engagement, and spread developer expertise to the people who get involved (and the people who follow their work). This is a dramatically different universe from the .NET ecosystem, where every open-source project — without exception — is fighting hard just to be noticed.

A question of trust

When Microsoft frames the problem, they often describe it as an issue of trust, as in “How do we get people to trust third-party products?” This question has a kernel of truth. But it also hides a real problem. Developer trust is not just — or even primarily — an issue of quality. Most .NET developers don’t avoid third-party solutions because their quality is unknown. They’re afraid that a product that seems like an innovative extension to the .NET ecosystem today will become obsolete tomorrow, when Microsoft sets a new preferred direction. The combination of Microsoft’s tight control and reputation for sudden hairpin turns — even on their own products — encourages risk-adverse business developers to become even more conservative.

The greatest danger for any OSS creator or adopter is that Microsoft will suddenly unveil its own solution to the same problem. Paul Stovell, founder of Octopus Deploy, puts it well:

“If Microsoft wants to make a document database, a messaging framework, a unit test framework or a deployment automation tool, it only needs to be 1/10th as good before the conversation immediately becomes ‘Why should we use you over the Microsoft thing?’ Microsoft becomes the default option, even if they’re the last to the game.”

The question isn’t theoretical. Stovell was asked the “Why you, not Microsoft” question while exhibiting at Build — the twist being that Microsoft’s competing product had only been announced minutes earlier. Another variation of the same problem played out with AppGet, which Microsoft courted and then obliterated with its own official competitor.

Even if Microsoft doesn’t have a competitor, the mere possibility that they might is enough to paralyze developers. Consider the situation with .NET MAUI, a Microsoft project to unify rich desktop and mobile apps. It’s release is at least a year out, but it still gives pause to anyone who’s willing to consider Uno Platform, an OSS solution for the same problem domain that’s available today.

Even officially promoted solutions face a difficult climate. Consider the very visible and highly touted Xamarin project, which struggled to grow until it was acquired by Microsoft, thereby making it an official part of the .NET stack. Microsoft can’t acquire the entire the entire ecosystem. But even if it could, a Microsoft-only world is a limited world. And a Microsoft-built solution doesn’t just kill the product in replaces, it also saps the motivation of potential OSS creators. They know it’s just not worth investing their time in an environment they can’t control or fully know. A benevolent dictator is still a dictator, able to turn on you at any time.

That’s the real trust gap. It isn’t between .NET developers and open-source software, but between the community and Microsoft. And it fuels a dangerous cycle. Less certainty means less people willing to build and adopt OSS solutions, which means these projects evolve slowly (if at all), and fall farther behind — or just disappear from the community altogether.

Don’t pick winners and losers

The good news is that Microsoft recognizes the problem. They’ve formed a working group to discuss the challenges of growing the .NET ecosystem. They’ve posted an influential whitepaper that states “We need to normalize the practice that application developers can depend on libraries that aren’t controlled by Microsoft.”

But Microsoft casts a long shadow. How closely can they manage their ecosystem without owning it — and then suffocating it? In the past, Microsoft has dabbled with ideas like endorsements and recognition in an official .NET maturity ladder. Intended to be a quality guarantee that promotes trust, the effect is often far different, sidelining small startup projects that can’t get attention.

Microsoft’s best intervention is to support library makers, not pick winners and losers. They would do well to offer better support to OSS developers, collaborate with them on documentation, guide them on quality issues, and advocate for them in the developer community. They could give developers better visibility into their long-term roadmaps. They could sponsor employees to maintain popular third-party libraries. They don’t need to make projects successful, but to make room for third-party success.

After all, community projects drive enthusiasm for the platform, and without enthusiasm the developer ecosystem won’t stay healthy. The Microsoft products of today may not need open-source software. But Microsoft needs OSS developers to grow into the future.