Why is Microsoft Harming .NET Open-Source?

Hello, everybody. I'm Nick, and in this video, I will discuss whether Microsoft is harming open source by effectively making existing Nuget packages obsolete.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[crazyfxy]

Swashbuckle was stale from 2022 to 2024. People were waiting for updates and adaption for .NET 8 and at that time there was only a single maintainer with permissions on the GitHub repo. It's only understandable that Microsoft cannot rely on that framework and therefore created their own.

[vexxxG]

I think Microsoft should maybe create a programme like "Microsoft Approved" or something and grant the maintainers of the package a small donation and add people that work for Microsoft as maintainers of those packages. This way they can be sure people don't just cut off support for an existing package, those packages are updated to work with the latest dotnet version and others will also trust those packages as they are curated by Microsoft, but built by the community.

[Wfmike]

The alternative is 2000
node module packages with various obsolete transitive dependencies/critical vulnerabilities.

[mattfbk]

i think it's perfectly normal for microsoft to have their own built-in implementations, especially from corporate standpoint, they want to offer a feature complete package, even if it's just 'good enough', and good enough is always better then none, when the corporate overlords do not allow usage of external(not microsoft or other major 'brand') packages. they would be harming the OSS if they forked the current leading implementations and then promoted those

[dasfahrer]

Perfectly fine with this practice. I'd rather have a good library be officially adopted by the .NET framework than run the risk of the NuGet package no longer being supported by the author. Not to mention running into an old problem - DLL hell, but with NuGet packages.

[Looooooka]

I'll take anything that's fully supported by Microsoft over relying on solutions from smaller developers who might shut down tomorrow or decide to just break everything in the new version.

[barionlp]

i don’t see the problem. Microsoft is just improving their language (which they made open source, so improving the open source community). I think it is quite obvious that there are packages for everything a language does not have built in but it’s also obvious that as long the language is improving those things might be added. Especially if microsoft needs it for themselves i see how they don’t want to rely on 3rd party stuff. What they should do is talking to the creators and see what they learned from their project. Maybe even hire them.

[viniciusmedeiros]

It makes perfect sense for Microsoft to do this. It improves the language. And there are plenty of companies that have policies against using 3rd party libraries. It just makes sense.

[przemysawukawski]

I think MS does this because they were burned by using other libraries like Ocelot or IdentityServer that out of sudden either stopped being maintained or went proprietary, so MS lost control over its own solutions that were dependent on these libraries.

[johnkost]

Digital Darwinism .. and .. nobody gets fired for using Microsoft packages ..

[Sayuri]

I can't remember all the issues you mentioned on top of my head, but on a grander overview, here are my thoughts.

The fact that Microsoft is taking popular functionality and integrating it into the .NET library is a good thing. The thing with many libraries is that:
1) They usually have few maintainer with no big incentive to maintain the library.
2) Libraries are made by people with various levels of skills, affecting documentation, performance, security issues, and so on.

Hence integrating them into .NET means:
1) Microsoft level quality of performance, documentation, performance, security, etc.
2) A default go-to implementation that people can refer to when they want some functionality instead of hunting between hundreds of packages
3) A guarantee that the functionality will be maintained and remain backwards compatible.
4) By being the de-facto standard, most libraries will integrate with it, making it easier to interoperate different libraries

This is just a few things, I'm sure. But the point is, that while Microsoft may not be perfect, and there are certainly libraries with higher quality standards out there, Microsoft is still a cut above most libraries out there. If the default implementation isn't flexible enough, there is nothing stopping someone from making a more flexible library. If the argument is that a library will be a causality, then I really have to add two things. One, said authors can contribute to Microsoft's open source library. And two, software is a thing that affects us all.

Don't thinking of it in terms of, it's my baby, how dare they kill it. Microsoft is creating a better production for all of us, for the better good of the ecosystem. I see so many people complain just because some other library shows up. Do we start complaining when another product shows up on the market that competes with ours? Same thing. Good for the consumer.

[desertfish]

The number of downloads is a bad metric to base "usage" on, because the system packages will very often just be included as a transitive dependency most of the time without the program actually making use of it by itself.

[KNHSynths]

It really is a delicate issue. On the one hand, there's the fear that, in the long run, package creators will stop wasting their time, for fear that, if they succeed, Microsoft will integrate their own solution. And this is a real concern, since maintaining creativity is essential to keep a framework alive. But on the other hand, it's reassuring to work with coherent packages integrated into DotNet Core by Microsoft.
So it's hard to blame Microsoft, because we're definitely benefiting from integrating more tools into DotNet. Even if we might fear a drop in motivation for the independent creation of new tools.
But I want to remain optimistic: there will always be people with good ideas to share with the community, and Microsoft, for all its might, will never be able to recreate all the existing tools and packages.
But we do have the right to reflect on the situation.

[AndrewArnott]

Some divisions at Microsoft are loathe to take on a 3rd party dependency. So if they need functionality that an OSS player already developed, they'll avoid it and just commission someone to write an equivalent one in-house. And as long as it is in-house, some of those divisions ask the .NET team to deliver it instead of themselves. Result: .NET competes with OSS.
I find it very unfortunate, for the reasons you gave.
- Microsoft employee, speaking from personal experience rather than as a representative.

[Tony-dprl]

The reason why Java is such a pain in the butt is because of the variety of Open Source packages developers use and all the conflicting dependencies. Standardizing is a good thing in .NET ... but not for the OSS developers. I am also torn.

[ДмитрийКондратенко-бь]

I would say thanks to Microsoft if they develop internal package to work with Excel or PDF rather than try to substitute Swagger. Because to achieve building custom charts, graphics in Excel I had to use interop library which is not good solution nowadays.

[Dustyy]

I really look forward for an official Eventing Framework/Library from Microsoft. The current available abstractions (MassTransit, Wolverine etc.) all have a really bad API imho. Yea it's easy to set up and get it to run but as soon as you need more than the basic stuff it gets complicated fast in MassTransit atleast. The API seems to convoluted and messy. We need a new from the ground up library with a modern API, I don't care if it's from microsoft or anyone else but there is so much room for improvement. Wolverine is a whole framework which is not an option for us to use, it's kind of difficult to use as a standalone library.

[johnnm]

Ya'll remember how excited we were at the launch of Xamarin everybody wanted a Xamarin t-shirt.

[paradisefallen]

Find what people uses. Just sponsor that project. They don't need to do all the work themselfs

[joshuaeddy]

Microsoft copying/reimplementing your open source package should be viewed as a compliment. There is always room for improvement, as they tend to design for lowest common denominator vs massive features. Maybe something like Lamar should have become a service provider extension package vs full bore replacement, sort of like SimpleInjector's implementation, though I think they didn't go quite far enough either. If Microsoft stops providing interfaces or hooks, then they are actively killing OSS, which I believe they have in the past, but no recent ones come to mind.