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.
Comments
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.