There’s work beyond the runtime, too.

They wrote a gRPC library [1],and a high performance JSON library [2]. Granted, these are .NET libraries, but still.

[1] https://github.com/grpc/grpc-dotnet [2] https://docs.microsoft.com/en-us/dotnet/standard/serializati...

I think that you're making a good point, and at the same time I think that tasking MS Devs with rewriting parts of their ecosystem is a bit of a minefield for any company, but especially Microsoft.

Long-term they need people to make good contributions to the ecosystem and I imagine it would be hard for third parties to sustain interest if it was a known risk that MS would rewrite whatever they were contributing.

I think you're spot on about the ecosystem being as important (or even more important?) than the core technology, and I'd love to hear peoples' thoughts on how to encourage such an ecosystem.

Couldn't they just submit patches (even if they were large ones) rather than truly rewriting under the MS banner? That seems like less of a risk to me. If an open source community is happy with their D code (to make a huge generalization), that's their prerogative.

This is not a MS project, but this thing called Hot Chocolate here (https://github.com/ChilliCream/hotchocolate) is very incredible. It is the best GraphQL framework I've worked on with excellent /EF(core)?/ support (even better than that of Hasura and dgraph) on the .NET ecosystem and overall software engineering. Maybe I can even swap the data source out with MongoDB as well, since it actually accepts IQueryable as the resolver source.

.NET is so incredibly underrated...

IIRC correctly, you may run into service scope issues if you just use a Mongo collection as an IQueryable directly, but there is a first class integration for Mongo from Chillicream: https://chillicream.com/docs/hotchocolate/integrations/mongo...

A lot of the library ecosystem still feels dominated by companies who make their money selling library code. If more successful, open-source friendly companies adopt .Net to create higher-level products and services one would hope that would help contribute to a more well maintained and more friendly licensed ecosystem.

My sense is that things are improving though.

I'm not entirely sure where you get that 'feeling' from if you work on anything .NET related. If you're on the outside looking in, there's 270,000 packages listed on NuGet.org

That's progress, but it's also about the same number as maven central had in 2010.

I took the reply to mean that from the outside the sheer number of Nuget packages looks encouraging, but the situation from the inside is different. Although it reads a bit ambiguous.

dotnet ecosystem is.. I think it's coming along, but there are some quality gaps in certain areas that are odd compared to say Python or Golang. dotnet is MS baby so you would think there may be official SSH and WinRM libraries? Not so fast. There is a community SSH lib now that is looking good is has been active, but nothing from MS as far as I can tell. WinRM? I THINK the powershell project has this functionality inside it but it's nothing official that's published separately.

I'm planning on starting an OSS project using dotnet in the fall that is very system oriented so libraries like these are important to me. Also keeping an eye on asp dotnet, blazor, and etc.. Been lurking dotnet for over a decade.

What are some of the libraries you're thinking of?

I'd like to see them to roll their own identity platform after IdentityServer went close source.

.NET already has an identity platform (ASP.NET Identity) that provides authentication/authorization with various backends. IdentityServer is a token server that speaks OAuth/OIDC and provides federation to other user directories (ASP.NET Identity or Azure Directory or anything else).

IdentityServer4 is still open-source and available. There's a new version by Duende with commercial licensing, or various alternatives like OpenIddict [1]. OAuth/OIDC is a well-supported standard so you can also use servers in other languages like Ory [2].

Microsoft's team did consider making their own token server but there was considerable pushback from the community because it would have a negative effect on open-source, and wouldn't add anything new compared to existing projects while taking resources from other framework features.

1. https://github.com/openiddict/openiddict-core 2. https://www.ory.sh/open-source

I agree. However a very difficult space. From one side they have commercials offerings (Active Directory and the variant within Azure). On the other the identity and authorization space has dozens of standards and the security space is changing primitives every day. It is extremely expensive and is permanently blocking resources from doing other things. That is also the reason IdentityServer is now under commercial license.

Who is "them"? Microsoft? https://docs.microsoft.com/en-us/azure/active-directory/deve...

that lets you connect to identity platforms.

Identity server is still open source, it just has a much more restrictive license and is paid.

https://github.com/DuendeSoftware/IdentityServer

That's not open source. The term "open source" (in the context of computer software) refers to a specific set of criteria (with some disagreement on philosophy and minor details[1][2][3]) that include the right to modify, redistribute and to use for any purpose. The term originates from the open source movement which branched off from the free software movement.

If open source meant simply that the source code is available, Windows would also have to be considered open source, as Microsoft makes the code available to some of its customers. This is not how the term is generally understood.

[1] https://www.gnu.org/philosophy/free-sw

[2] https://opensource.org/docs/definition.html

[3] https://www.debian.org/intro/free

IdentityServer is still Apache 2.0, that has not changed.

ok, not closed, but restricted use. I think Microsoft should do (or buy Duende) their own platform. I've swapped to using keycloak, which is really nice, but it's a whole different world than .net

IdentityServer is not closed source, it is still Apache 2.0.

The Confluent.Kafka one, the AWS .NET SDK (though this is improving), the old MySQL one was really bad.

My impression from reading the code and GitHub issues is that they're not maintained by real ".NET people" who are plugged in to all the fine details and best practices of the framework and the runtime.

StackExchange.Redis is a good example of one that is independent of MS but still very high quality.

I'm the author of what you might call the "new" MySQL ADO.NET library: https://github.com/mysql-net/MySqlConnector

I agree with your impression that developers of the other library don't seem to be "plugged in to" the .NET ecosystem. As an independent developer (not affiliated with Oracle or Microsoft), I've been able to influence GitHub PRs that shape the ADO.NET API for .NET 6.0, just by showing up and contributing; I haven't seen anyone from the Oracle MySQL team participating. Meanwhile, they violate basic principles of the .NET Framework Design Guidelines that have been around for over a decade (https://docs.microsoft.com/en-us/dotnet/standard/design-guid...), which makes their library feel alien to a .NET programmer (regardless of the quality issues it might have).

Yeh I should have mentioned MySqlConnector as another example of a high quality .NET library, my apologies.

We ripped out the Oracle MySQL library at work and put MySqlConnector in. The high quality documentation made it really easy to understand and make adjustments for the differing behaviors between the 2 libraries. Any time I've poked into the code to try to understand some fine detail of it, I've always found it very easy to quickly understand what could be going on. It's great.

Agreed. It's ridiculous that .NET still doesn't have XPath 2 support after so many years. I really wish they'd hire a PM with enterprise experience, as they seem heavily focused on public facing web technologies e.g. the new native JSON serializer has all kinds of weird limitations based on 'security risks' that don't actually exist outside of public facing websites.

XSLT/XPath/XQuery 2.0+ has little first party support in general, in all programming ecosystems that I can think of. I think the problem is that it's all much more complicated than the originals, and meanwhile XML has become legacy tech - not that it's going away anytime soon, but it's kind of like the COBOL of data.

.NET caters to the enterprise, or at least it used to. It's irrelevant what other ecosystems prioritise. What makes you say that XML is legacy tech? In the financial industry XML is used extensively. For example, FpML underpins a massive part of global finance, and it is a regularly updated standard. COBOL has been superceded by other languages; I'm not aware of any technology that can replace the XML-based FpML schema.

"Legacy" is perhaps not the best word to describe it; what I mean is that new technologies, protocols etc being developed generally avoid XML. So new products and libraries don't have to deal with it that much. And older ones are already written relying on older versions of XPath etc, so there isn't a strong incentive to upgrade there. Even if we're talking about libraries that are still getting updated to reflect changes in the standards.

The comparison with COBOL is fairly straightforward. There's still plenty of COBOL code running in prod around the world - but you don't see much clamoring to add new features to it.

Oh, and .NET doesn't really cater specifically to the enterprise these days. It was definitely true back when it was first released (remember all the emphasis on SOAP?), and for a while after. But .NET Core was an attempt to broaden its scope, and it very much succeeded.

I should add that I'm not particularly happy about this. I did a lot of XSLT 2.0 and XQuery 2.0 back in mid-00s, using Saxon, and I still miss many aspects of it. The new "best thing" seems to be JSON, but, while the syntax is certainly nicer, the tooling ecosystem around it is still nowhere near what we had back then.

> .NET caters to the enterprise, or at least it used to.

.NET is for enterprises who don't treat tech as frozen in time the instant it gets adopted now.