Hacker Remix

.NET library MassTransit going commercial with V9

38 points by 8-prime 21 hours ago | 36 comments

fabian2k 20 hours ago

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.

kcb 12 hours ago

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.

dontlaugh 19 hours ago

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.

xnorswap 20 hours ago

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

croes 20 hours 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.

DeathArrow 19 hours ago

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

mindcrash 10 hours 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.

The huge charm of MassTransit _was_ that it was OSS.

Lachstec 20 hours ago

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.

8-prime 20 hours ago

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.

WorldMaker 9 hours ago

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.

pjmlp 18 hours ago

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.

moomin 18 hours ago

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.

DeathArrow 19 hours ago

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

Lachstec 18 hours ago

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.

neonsunset 16 hours ago

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.

DeathArrow 15 hours ago

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.

donny2018 19 hours ago

Redis, Akka, Hashicorp, CockroachDB, etc. Seems to be a common occurrence everywhere.

BoorishBears 17 hours ago

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.