You are absolutely right, that is not a .NET specific issue, it was just very little time between these big libraries going commercial. I think that there is a deeper issue here. Maintaining an open source project is hard work and is rarely compensated, I can even understand the motivation of the mantainers that decided to put their projects under a commercial license.
Businesses and developers profit from foss software, but the chances that anything, be it money or support via contributions, is given back are low. I don't think that it is desirable to go closed source to solve that issue, but I also don't have a good solution at hand.
I think only MassTransit among them has any potential for "material" consequences.
MediatR and Automapper were candidates for removal/factoring out in modern applications even before the announcement (mediatr is a bit controversial because it is often misused and makes logic harder to follow but is popular regardless).
For MassTransit, I think enterprises which use it will have to decide if they want to stay for now on v8 and develop it by themselves or pay for v9, or migrate elsewhere. Luckily, there are quite a few choices for messaging from Kafka to NATS to Pulsar and RabbitMQ is used almost everywhere anyway. Or you can do gRPC streams, or SignalR. Pick your requirements and you have many good choices.
MediatrR is useful for CQRS or if you structure your app around event dispatching. I use it some time, but now I will spend a day or two writing a library because I don't need anything fancy.
Automapper is not a concern. With AI you can map a class to another very fast and have better performance.
For MassTransit I don't care. I work with microservices since at least 5 years and we either used RabbitMQ, NATS, Kafka, Azure Service Bus directly or write our own wrapper.
Feels very rare to have this kind of rug pull at the library level though, it's telling the only library in that list is a Java framework (a fellow 'enterprisey' language).
I'm not saying maintainers are obligated to work forever and never ask for money, but it's happened a lot with .NET relative to how package-light development tends to be compared to say Javascript.
Automapper and Mediatr just got announced this week.
Fluent Assertions (literally just, a fluent API for asserts) recently went commercial.
It just feels like there's a certain lethargy in the .NET ecosystem that lends itself to these switch ups. As in, .NET leans slightly towards people banging on your door because their strictly 9-5 enterprise project needs to hit some deliverable and they see their issue as your problem... while JS leans slightly towards tinkerers tinkering with stuff who are often just as needy, but are also slightly more inclined to detour to work with you, and less pressured in general.
Comments
You mean the same way MongoDB and many other open source products went commercial?
It has nothing to do with .NET. It happens with all languages and all platforms.
You are absolutely right, that is not a .NET specific issue, it was just very little time between these big libraries going commercial. I think that there is a deeper issue here. Maintaining an open source project is hard work and is rarely compensated, I can even understand the motivation of the mantainers that decided to put their projects under a commercial license.
Businesses and developers profit from foss software, but the chances that anything, be it money or support via contributions, is given back are low. I don't think that it is desirable to go closed source to solve that issue, but I also don't have a good solution at hand.
I think only MassTransit among them has any potential for "material" consequences.
MediatR and Automapper were candidates for removal/factoring out in modern applications even before the announcement (mediatr is a bit controversial because it is often misused and makes logic harder to follow but is popular regardless).
For MassTransit, I think enterprises which use it will have to decide if they want to stay for now on v8 and develop it by themselves or pay for v9, or migrate elsewhere. Luckily, there are quite a few choices for messaging from Kafka to NATS to Pulsar and RabbitMQ is used almost everywhere anyway. Or you can do gRPC streams, or SignalR. Pick your requirements and you have many good choices.
MediatrR is useful for CQRS or if you structure your app around event dispatching. I use it some time, but now I will spend a day or two writing a library because I don't need anything fancy.
Automapper is not a concern. With AI you can map a class to another very fast and have better performance.
For MassTransit I don't care. I work with microservices since at least 5 years and we either used RabbitMQ, NATS, Kafka, Azure Service Bus directly or write our own wrapper.
Redis, Akka, Hashicorp, CockroachDB, etc. Seems to be a common occurrence everywhere.
Feels very rare to have this kind of rug pull at the library level though, it's telling the only library in that list is a Java framework (a fellow 'enterprisey' language).
I'm not saying maintainers are obligated to work forever and never ask for money, but it's happened a lot with .NET relative to how package-light development tends to be compared to say Javascript.
Automapper and Mediatr just got announced this week.
Fluent Assertions (literally just, a fluent API for asserts) recently went commercial.
It just feels like there's a certain lethargy in the .NET ecosystem that lends itself to these switch ups. As in, .NET leans slightly towards people banging on your door because their strictly 9-5 enterprise project needs to hit some deliverable and they see their issue as your problem... while JS leans slightly towards tinkerers tinkering with stuff who are often just as needy, but are also slightly more inclined to detour to work with you, and less pressured in general.