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.
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.
Another, problem I have is they usually miss the small team/use case in a large organization. Vendors expect us to pay large org pricing, when there's no way we can justify it for a project if it's size. I've used Mass Transit because it has some useful features but it's not the core of our messaging or whatever so in the end the all or nothing pricing model means it will just end up getting ripped out.
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.
Yeah, with all the recent libraries going paid its looking pretty grim. Microsoft building their own version of many of the large libraries rather than just supporting them isn't helping either.
Microsoft seems doomed either way. Microsoft tried to drop their own implementations of OpenID/OAuth providers and they tried supporting IdentityServer and made it a part of some base templates and IdentityServer said that was the reason they "needed" to make it commercial and blamed Microsoft for directing too much traffic their way. If Microsoft builds their own library instead of pointing people to an open source offering it looks like favoritism and competition and "we need to go commercial to survive". If Microsoft points people to an open source offering it looks like "a flood of traffic and we need to go commercial to survive".
Microsoft even donates regularly to things like GitHub Sponsorships and the major open source foundations/conservatories, so even in the case of "too much traffic" it isn't like Microsoft is trying to shirk that bill, even though it is very easy to accuse them of that.
I think the real effect here is the .NET community is small and they all know each other. When people start thinking this way, it only takes a conference meetup for them to spread their opinion to the entire community.
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.
> Security patches and critical bug fixes will continue for a transition period.
They're not explicit for how long this "transition period" will be, it sounds like a year.
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.
IdendityServer4 was promised security updates until Nov 2022. Here we are over 2 years later and it's still a popular package.
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.
>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.
Doesn't really matter. For big, distributed apps at work I use Keycloak or something similar, maybe an own authorization service built on OPAL. For small apps I either use an authentication and authorization library I built myself or, if I don't need something too fancy I use Identity (the one MS provides).
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.
The huge charm of MassTransit _was_ that it was OSS.
>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.
>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!
It's a bad look to have a FAQ where you don't actually answer your own question.
Isn't FOSS about giving something cool to the community, to your fellow developers? If it's money you're after, why starting a FOSS project? How is it any different from bait-and-switch or rug pulls corporate is being shamed for?
I'm not angry with the authors, they have all the rights to go commercial if this is what they want. But I can't help but feel sad about it.
> How is it any different from bait-and-switch or rug pulls corporate is being shamed for?
Hard agree. If you want to turn a profit from your project, make it commercial from the beginning. I have no problems with commercial tools or products, but I do have a problem with starting something as open source, gaining adoption, then changing the license later on.
It's the same BS behavior from SaaS we love to call out, when companies make a generous free tier, get users locked in, then pull the rug.
Should the community help out and contribute back to FOSS projects they use? Absolutely, but at the same time, they are not obligated to either and if a dev has a problem with that, then don't release it as FOSS.
I've published a few small tools for sysadmins, and I never expected any kind of contribution back whether monetary or otherwise, and that's OK. I wrote them for myself, and will maintain them for myself as long as they are useful to me. Others are free to use them and I don't expect anything in return.
Not at all, FOSS licenses don't mean it is free of charge.
In fact, in the early days folks would get money out of distributions like Walnut Creek CDs.
Everyone talks about morality, what about the morality of feeling good getting that check at the end of the month in consulting services, without giving a dime to upstream?
I do not care much about Automapper. As for MediatrR I will spend a day or two to build my own message/event dispatching library, I don't need anything too fancy.
Yes, the proposition is much weaker there to close the source (if that is even possible without a CLA!) and take it paid.
AutoMapper is something you only use sparingly because genius mappings take a genius mind to understand, at which you can rather map manually than type any comments.
And, as you say, MediatR is eassily replaced because it is intentionally a slim library.
I doubt that Microsoft would by it. From what I remeber they were working on their own framework doing a similar thing, which was originally meant to release in .NET 9 but got pushed back.
Unless they want to throw all of that away I doubt it would make much financial sense for them.
But we have seen FluentAssertions parter with tool maker recently so I guess that's not entirely unreasonable.
I guess somone will have to create one. Same thing happened pretty quickly after FluentAssertions went paid.
It then becomes a question if someone is willing to put in the work to actually maintain that project.
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.
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.
All in all I want less dependencies in my code. Everything is bloated to shit anyways.
.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.
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.
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.
I also wonder if eroding confidence will start snowballing and bring .Net back to framework days in practice.
I find it interesting that bringing up .NET on HN manages to occasionally evoke incredibly poor quality replies like yours in a way that does not happen on Reddit. In fact, it seems to have better quality discourse which keeps surprising me. But if cheap jabs is what you're after - keep commenting.
HN has always hated anything out of Redmond, both justified and not. There's good reasons for it, the halloween documents and the EEE era are not easily forgotten so I sympathize somewhat, but not all corps are treated equally here. Google and Apple will regularly get a pass for doing the same stuff Microsoft did or does.
Outside of the SV bubble .NET will continue to be one of the most productive platforms to work within, and is continuing to grow in market share. Hardly a failure.
That being said, I do see the meaning behind where OP is coming from. There is a certain, shall we say, enterprise, culture around .NET (much like Java) that hasn't caught up yet, or hasn't fully embraced the new world of open source from Microsoft.
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.
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.
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.
Another, problem I have is they usually miss the small team/use case in a large organization. Vendors expect us to pay large org pricing, when there's no way we can justify it for a project if it's size. I've used Mass Transit because it has some useful features but it's not the core of our messaging or whatever so in the end the all or nothing pricing model means it will just end up getting ripped out.
It does seem to be quite common to cover hobbyists and huge companies, but nothing in between.
I know a few people who will likely have to stop using CockroackDB because the license costs would be higher than their entire revenue.
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.
Yeah, with all the recent libraries going paid its looking pretty grim. Microsoft building their own version of many of the large libraries rather than just supporting them isn't helping either.
Microsoft seems doomed either way. Microsoft tried to drop their own implementations of OpenID/OAuth providers and they tried supporting IdentityServer and made it a part of some base templates and IdentityServer said that was the reason they "needed" to make it commercial and blamed Microsoft for directing too much traffic their way. If Microsoft builds their own library instead of pointing people to an open source offering it looks like favoritism and competition and "we need to go commercial to survive". If Microsoft points people to an open source offering it looks like "a flood of traffic and we need to go commercial to survive".
Microsoft even donates regularly to things like GitHub Sponsorships and the major open source foundations/conservatories, so even in the case of "too much traffic" it isn't like Microsoft is trying to shirk that bill, even though it is very easy to accuse them of that.
It gets love alright, the same as in other ecosystems, using tools without paying the authors.
Not everyone is employed at big corp, with enough time to keep FOSS tooling as side gig.
Maybe if everyone gave back as they expect to be paid themselves, this wouldn't be a common thing.
Turns out shareware and demos was a better business model than FOSS giving everything away, unless one is building a portfolio for being hired.
I think the real effect here is the .NET community is small and they all know each other. When people start thinking this way, it only takes a conference meetup for them to spread their opinion to the entire community.
> .NET ecosystem is still very corporate-minded and open source is not getting the love it deserves from the community.
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.
> Security patches and critical bug fixes will continue for a transition period.
They're not explicit for how long this "transition period" will be, it sounds like a year.
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.
IdendityServer4 was promised security updates until Nov 2022. Here we are over 2 years later and it's still a popular package.
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.
Further below
>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.
>We've seen this before with IdentityServer
Doesn't really matter. For big, distributed apps at work I use Keycloak or something similar, maybe an own authorization service built on OPAL. For small apps I either use an authentication and authorization library I built myself or, if I don't need something too fancy I use Identity (the one MS provides).
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.
The huge charm of MassTransit _was_ that it was OSS.
>Will there be a non-commercial license for v9?
>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.
>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!
It's a bad look to have a FAQ where you don't actually answer your own question.
As usual, if you care about those FOSS libraries, tools authors also have bills to pay themselves.
All the best with commercial endevours.
Isn't FOSS about giving something cool to the community, to your fellow developers? If it's money you're after, why starting a FOSS project? How is it any different from bait-and-switch or rug pulls corporate is being shamed for?
I'm not angry with the authors, they have all the rights to go commercial if this is what they want. But I can't help but feel sad about it.
> How is it any different from bait-and-switch or rug pulls corporate is being shamed for?
Hard agree. If you want to turn a profit from your project, make it commercial from the beginning. I have no problems with commercial tools or products, but I do have a problem with starting something as open source, gaining adoption, then changing the license later on.
It's the same BS behavior from SaaS we love to call out, when companies make a generous free tier, get users locked in, then pull the rug.
Should the community help out and contribute back to FOSS projects they use? Absolutely, but at the same time, they are not obligated to either and if a dev has a problem with that, then don't release it as FOSS.
I've published a few small tools for sysadmins, and I never expected any kind of contribution back whether monetary or otherwise, and that's OK. I wrote them for myself, and will maintain them for myself as long as they are useful to me. Others are free to use them and I don't expect anything in return.
Not at all, FOSS licenses don't mean it is free of charge.
In fact, in the early days folks would get money out of distributions like Walnut Creek CDs.
Everyone talks about morality, what about the morality of feeling good getting that check at the end of the month in consulting services, without giving a dime to upstream?
The FAQ question about Jimmy is related to https://www.jimmybogard.com/automapper-and-mediatr-going-com...
I do not care much about Automapper. As for MediatrR I will spend a day or two to build my own message/event dispatching library, I don't need anything too fancy.
Yes, the proposition is much weaker there to close the source (if that is even possible without a CLA!) and take it paid.
AutoMapper is something you only use sparingly because genius mappings take a genius mind to understand, at which you can rather map manually than type any comments.
And, as you say, MediatR is eassily replaced because it is intentionally a slim library.
Take a look at Rebus https://github.com/rebus-org/Rebus
Judging by the woooly explanation of pricing maybe this is a low-fi, and clumsy, play to get bought out by a tool maker, or even Microsoft?
I doubt that Microsoft would by it. From what I remeber they were working on their own framework doing a similar thing, which was originally meant to release in .NET 9 but got pushed back. Unless they want to throw all of that away I doubt it would make much financial sense for them.
But we have seen FluentAssertions parter with tool maker recently so I guess that's not entirely unreasonable.
Damn. Hope there would be a viable open-source fork as there are non-financial reasons to exclude commercial licenses.
I guess somone will have to create one. Same thing happened pretty quickly after FluentAssertions went paid. It then becomes a question if someone is willing to put in the work to actually maintain that project.
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.
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.
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.
.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.
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.
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.
I also wonder if eroding confidence will start snowballing and bring .Net back to framework days in practice.
I find it interesting that bringing up .NET on HN manages to occasionally evoke incredibly poor quality replies like yours in a way that does not happen on Reddit. In fact, it seems to have better quality discourse which keeps surprising me. But if cheap jabs is what you're after - keep commenting.
HN has always hated anything out of Redmond, both justified and not. There's good reasons for it, the halloween documents and the EEE era are not easily forgotten so I sympathize somewhat, but not all corps are treated equally here. Google and Apple will regularly get a pass for doing the same stuff Microsoft did or does.
Outside of the SV bubble .NET will continue to be one of the most productive platforms to work within, and is continuing to grow in market share. Hardly a failure.
That being said, I do see the meaning behind where OP is coming from. There is a certain, shall we say, enterprise, culture around .NET (much like Java) that hasn't caught up yet, or hasn't fully embraced the new world of open source from Microsoft.
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.