A new feature proposed for the forthcoming .NET 9 has sparked comment from open source developers: why does Microsoft not support existing projects in the same space, that of eventing frameworks and processing messages from queue providers.
The new feature, described as Eventing Framework in .NET 9, is open for discussion on GitHub, and promises to expose APIs for registering event providers for “various queue implementations,” register event handlers, expose APIs for serializing and deserializing messages, support middleware, and support metrics and tracing.
When the feature was announced two months ago, a developer in the discussion was quick to ask, “Why not support existing OSS tools like Wolverine or MediatR or something else instead of building from scratch in-house?”
Wolverine implements a .NET message bus, and MediatR implements a mediator with requests and responses, notifications and events.
Ian Cooper, whose Brighter framework enables building messaging applications with .NET, said: “The .NET space is perhaps more richly served than any other ecosystem with messaging tools, both commercial, commercial support and solely OSS. Competition amongst those projects has created a strength in offerings that other languages don’t have. When MS enters the space that diversity and competition will be crushed, leading to less innovation and choice.”
Blake Niemyjski, an open source developer whose Foundatio project supports messaging and queues, expressed his hope that “this doesn’t follow the path of IDistributedCacheClient that I’ve seen used by very few. Please engage early and often with leaders who have been in this space a long time.”
Microsoft’s David Fowler, distinguished engineer, said “apologies for the confusion and concern … the idea was to focus on small subset of event handling … principally for the Azure Functions folks but generic enough for everyone.” He added: “this is not a work area that’s been approached with malice towards or ignorance of the various libraries that exist in the ecosystem.”
Jeremy Miller, co-founder of JasperFx which supports the Marten and Wolverine libraries, responded that “its very existence will stop .NET developers from even researching or considering other options” and added that “users will demand more use cases and it will grow over time to meet a larger subset of the functionality in existing tooling.”
That said, there are developers who like the notion of Microsoft delivering a first-party solution for a feature important to enterprise applications. “This is a fantastic initiative,” said one. “We are using MassTransit now, and we would love to have a robust built-in solution.” MassTransit is a framework for building distributed applications with .NET.
Aaron Stannard is CEO founder of Petabridge, whose open source project Akka.NET (a port of the Akka JVM project) implements an Actor model for distributed systems. He said the issue illustrates “a problem that is entirely unique to the .NET ecosystem: single vendor monoculture,” and accused developers who support it as “cheering on the destruction of options.”
Some of the loudest voices in this debate have a stake in the success of .NET open source projects and the discussion is in that context. It remains true though that the relationship between Microsoft and the open source .NET community is uneasy, despite the existence of the .NET Foundation, and that the direction of .NET development is largely driven by one company.
The reason for this new feature? As Fowler said, “principally for the Azure Functions folks” or put another way, that Microsoft itself desires it to happen, rather than it being an organic demand from the community.
The other side of this debate is that .NET is well liked overall by developers, who benefit from the fact that it remains a strategic investment for Microsoft. Even Stannard, in his largely negative post, acknowledged that “.NET’s been on a great trajectory since it went cross-platform.”