Lamenting that many developers in the .NET community are reluctant to use libraries not built by Microsoft, Microsoft wants to help .NET developers make trust decisions and encourange them to trust in libraries that were developed by third parties.
In a document posted December 14 on GitHub, “Growing the .NET ecosystem,” Immo Landwerth, program manager for the Microsoft .NET Framework team, wrote that Microsoft has taught customers to expect all features to come from Microsoft. But since Microsoft cannot build everything, especially not at a pace at which other open source ecosystems evolve, the set of trusted libraries for .NET “must grow beyond just Microsoft.”
Microsoft must normalize the practice that application developers can depend on libraries not controlled by the company, Landwerth noted, adding that a culture shift at Microsoft will be required to achieve this. Thus a goal for the planned .NET 6 release is to promote a vision that includes trusting non-Microsoft libraries. .NET 5 just arrived in October while .NET 6 is expected in November 2021.
Landwerth wrote that there is a perception that other ecosystems, specifically Java, JavaScript, and Python, have more technological diversity and thus “an overall stronger open source ecosystem.” He also noted a perception that Microsoft “sucks the air” out of the .NET ecosystem because Microsoft solutions are usually promoted and are often tightly integrated into the platform, rendering existing solutions less attractive.
To address these issues, Landwerth wrote, Microsoft needs to engage with owners of existing libraries to increase their quality and tighten their integration into the .NET developer experience. Microsoft already has been doing this with gRPC, OpenTelemetry, and Apache Spark/Arrow, he added.
Also needed, Landwerth noted, is a change to the approach when net-new technologies are created for which there is no ecosystem yet. Instead of building everything, projects should be created in a manner such that Microsoft is not the sole maintainer. External contributors should be sought out. There is also an issue around support, Landwerth said, with a perception that Microsoft-produced code is always supported while code from elsewhere is not.
The document stressed that third-party experiences can be as good as first-party experiences, and concluded that a curated discovery and acquisition process is needed for optional components for .NET. With .NET 6 and support for mobile workloads, Microsoft is moving to a model where part of .NET is optional. This ensures the core product can be small and “snappy” to install while still supporting the full breadth of the .NET platform.