The annoying thing about commercial licenses isn't that you have to pay for them. It's that their pricing models are often problematic and can easily break some use cases due to expense. It also adds a lot of overhead in figuring out the license terms and your own corporate bureaucracy.<p>And of course changing the license is always annoying as you did not make an informed decision when you chose the license. You also never know if they might change the pricing model again.
Pretty sad to see. Although I have no significant proof to back my feelings, I sort of feel that the .NET ecosystem is still very corporate-minded and open source is not getting the love it deserves from the community. That is especially sad because modern C# and .NET are great tools for writing software.
> Security patches and critical bug fixes will continue for a transition period.<p>They're not explicit for how long this "transition period" will be, it sounds like a year.<p>We've seen this before with IdentityServer, and many other examples where maintainers switched to a commercial license, leaving behind a wake of businesses who aren't willing to tie themselves to a commercial license and would rather turn a blind eye to dwindling support.<p>IdendityServer4 was promised security updates until Nov 2022. Here we are over 2 years later and it's still a popular package.<p>And that's a security-critical part of the application! Some people even still go back to the pre-AGPL version of iTextSharp for PDF writing, and that switch was 15+ years ago.
As NServiceBus is more or less the defacto standard in this area (commercial distributed system platforms for .NET) and has a huge established customer base already, I don't really see that this will end well.<p>The huge charm of MassTransit _was_ that it was OSS.
The FAQ question about Jimmy is related to <a href="https://www.jimmybogard.com/automapper-and-mediatr-going-commercial/" rel="nofollow">https://www.jimmybogard.com/automapper-and-mediatr-going-com...</a>
>Will there be a non-commercial license for v9?<p>>As stated above, the transition plan includes ongoing patches and updates for v8. Developers can continue to use v8 during the transition, and won't be forced to upgrade to v9. To take advantage of new features and enhancements, developers would need to upgrade to the licensed version.<p>>Patches and updates to v8 through at least the end of 2026. That's 1.75 years from now, giving developers plenty of runway to plan their migration to v9. That's longer than the support window for some .NET versions!<p>It's a bad look to have a FAQ where you don't actually answer your own question.
I do not care, in all .NET microservice based and distributed application where I worked, we always used RabbitMQ, NATS, Kafka, Azure Service Bus or whatever messaging service was needed directly or maybe with a custom wrapper made by us.
Good luck. I personally dislike MassTransit as it's way too opinionated for what it does. I use whatever SDK I need for Azure Service Bus, Kafka etc. and perhaps slightly wrap it for my purposes.<p>As for the other bit around AutoMapper. I do my own mapping and so should you. MediatR and what it does you can implement yourself in a few hours that will cover 90% of use cases if you know what you're doing.<p>All in all I want less dependencies in my code. Everything is bloated to shit anyways.
It’s good software so good luck to them.<p>.Net OSS looks more and more like a failure, while fans will incessantly reiterate it’s technically OSS it’s certainly not spiritually and if anything it’s regressed in the last 2-3 years.<p>The bigger project I know of follow a similar model of open core + support and I would not bat an eye if they did the same. The remaining ecosystem seems to be convenience over whatever MS is doing and IO adapters.<p>At this stage it’s just another nail in the coffin and I’d be wary of picking up anything other than MS packages if using .Net.<p>I also wonder if eroding confidence will start snowballing and bring .Net back to framework days in practice.