# MediatR and MassTransit Going Commercial: What This Means For You
> MediatR, AutoMapper, and MassTransit are moving to commercial licenses after more than a decade of free open source. Here's why the maintainers made that call, and the practical options if your projects depend on them.
Published: 2025-04-05. Author: Milan Jovanović.
Canonical: https://milanjovanovic.tech/blog/mediatr-and-masstransit-going-commercial-what-this-means-for-you
MediatR, AutoMapper, and MassTransit all announced moves to commercial licensing in 2025.
The announcements kept the existing open source versions available, with MassTransit v8 security patches planned through 2026.
Your options are to buy a license, stay on the current version, switch to alternatives like Mapster or Rebus, or write the functionality yourself.
Big changes are happening in the .NET ecosystem.
Three powerhouse libraries - MediatR, AutoMapper, and MassTransit - are moving to commercial licenses.
Not so long ago, Fluent Assertions also announced its plans to move to a commercial license.
As someone who's built countless systems with these tools over the past decade, I have thoughts.
And some strong opinions.
## The Libraries We Love (And Sometimes Hate)
If you're a .NET developer, you likely use at least one of these:
[**AutoMapper**](https://github.com/AutoMapper/AutoMapper) (794.7M downloads) transforms objects from one type to another.
It removes mountains of tedious mapping code that nobody enjoys writing.
One line replaces twenty.
**I personally despise AutoMapper and mapping libraries in general**, but I can't deny their popularity.
[**MediatR**](https://github.com/jbogard/MediatR) (286.6M downloads) implements the [**mediator pattern**](https://milanjovanovic.tech/blog/cqrs-pattern-with-mediatr).
It decouples requests from the objects handling them, promoting separation of concerns.
There's also the [**pipeline behavior**](https://milanjovanovic.tech/blog/mediatr-pipeline-behaviors) feature, which allows you to add cross-cutting concerns.
I'm a huge fan and use it regularly in my projects.
[**MassTransit**](https://github.com/MassTransit/MassTransit) (130.0M downloads) makes distributed messaging simple.
It wraps message brokers like [**RabbitMQ and Azure Service Bus**](https://milanjovanovic.tech/blog/using-masstransit-with-rabbitmq-and-azure-service-bus) with an elegant API.
Building event-driven systems becomes approachable.
This is another tool I love and often recommend.
These libraries aren't just popular - they're transformative.
They've shaped how we build .NET applications.
## The Maintainer's Reality
Both announcements tell a similar story.
Source: [AutoMapper and MediatR Going
Commercial](https://www.jimmybogard.com/automapper-and-mediatr-going-commercial/)
Jimmy Bogard (AutoMapper, MediatR) writes:
> You can see exactly where my contributions cratered and flat-lined. And that's just commits—issues, PRs, discussions, all my time dried up.
His OSS work was previously sponsored by his former employer.
When he went independent, that support vanished.
His focus shifted to his consulting business.
Source: [Announcing MassTransit
v9](https://masstransit.io/introduction/v9-announcement)
Similarly, MassTransit has grown from "a single assembly that supported MSMQ" in 2007 to over thirty NuGet packages.
Its success created demands that are impossible to meet through volunteer work alone:
- Full-time development resources
- Enterprise-grade support
- Long-term sustainability
Both maintainers face the same dilemma: how do you support widely used libraries when nobody pays you to do it?
## The Commercial Transition
Here's what's happening:
**AutoMapper and MediatR**: Jimmy hasn't shared specific timing or pricing yet.
He states, "Short term, nothing will change."
**MassTransit**: Moving from v8 (open source) to v9 (commercial) with this timeline:
- Q3 2025: v9 prerelease for early adopters
- Q1 2026: v9 official release under commercial license
- Through 2026: v8 security patches continue
MassTransit's pricing targets:
- Small/medium businesses: $400/month or $4000/year
- Large enterprises: $1200/month or $12000/year
- Support for ISVs and consultants who build client applications
None of this is set in stone.
The pricing aspect should be final by the time the commercial version is released.
## Why I Respect This Decision
Both maintainers waited over a decade before making this move.
They've contributed immense value to our community for free.
Their announcements show careful consideration.
They're not abandoning users:
- Existing versions remain open source
- Security patches will continue
- Commercial licenses support sustainable development
I honestly hope none of the above changes in the future.
The work they do is valuable.
Writing these libraries from scratch would cost your team far more than their license fees.
## Your Options Now (With My Take)
If your project uses these libraries, you have choices:
1. **Purchase the commercial license**
This supports continued development and gets you new features and official support.
2. **Stay on the current open source version**
MassTransit v8 and current MediatR/AutoMapper will remain available.
Security patches will continue through 2026 for MassTransit.
For MassTransit specifically, I'd consider staying on v8 for the long term if possible.
3. **Switch to alternatives**
For AutoMapper: consider [Mapster](https://github.com/MapsterMapper/Mapster) or **manual mapping** (my recommendation).
For MediatR: explore [FastEndpoints](https://github.com/FastEndpoints/FastEndpoints) or [**build a simple mediator yourself**](https://milanjovanovic.tech/blog/stop-conflating-cqrs-and-mediatr).
For MassTransit: look at raw client libraries like [RabbitMQ.Client](https://www.nuget.org/packages/rabbitmq.client/) and
[Azure.Messaging.ServiceBus](https://www.nuget.org/packages/Azure.Messaging.ServiceBus),
and another option to consider is [**Rebus**](https://milanjovanovic.tech/blog/implementing-the-saga-pattern-with-rebus-and-rabbitmq).
4. **Write equivalent functionality yourself**
MediatR isn't too complex to build on your own.
I recommend giving it a try as an excellent coding exercise - it's probably the simplest way to move away from MediatR.
For AutoMapper, many teams have deep integrations with business logic in custom mappers.
This makes extracting and replacing it difficult.
Expect significant tech debt if you don't address this.
MassTransit, on the other hand, does so many things (and does them well) that migrating away would be challenging.
[**Saga support**](https://milanjovanovic.tech/blog/implementing-the-saga-pattern-with-masstransit) or the [**request-response messaging**](https://milanjovanovic.tech/blog/request-response-messaging-pattern-with-masstransit)
features are hard to replicate.
The only real alternative is diving into raw client libraries for your chosen message transport.
Each option involves tradeoffs. The right choice depends on your project needs and budget.
## A Shift to Fundamentals
These changes have made me reflect on something important: we should never lose sight of fundamentals.
We've been pampered and spoiled by these awesome libraries.
It's easy to lose sight of the actual problems they're solving and how they work under the hood.
People know how to use MediatR, but they don't understand the mechanisms behind it.
The same goes for MassTransit.
It abstracts away so many complexities of working with message brokers that it's possible to use it without knowing how RabbitMQ or Azure Service Bus actually works.
Remember this: using a library that abstracts something away doesn't excuse you from understanding the patterns and tools you're using.
The **fundamentals are still there** and always have been.
This might be the perfect opportunity to deepen your knowledge of what's happening beneath these abstractions.
## A Reality Check
Open source isn't free. Someone pays - either with time or money.
I'm honestly tired of seeing developers complain about these changes.
Who are they to demand software for free?
The entitlement is astounding.
These maintainers have provided immense value for over a decade without asking for anything in return.
We've enjoyed years of exceptional tooling without directly funding it.
Now we face a reckoning.
As businesses reap massive productivity gains from these libraries, it's reasonable to ask: shouldn't some of that value flow back to the creators?
I hope these projects thrive under their new models.
They've earned support after years of thankless work.
Both my [**Pragmatic Clean Architecture**](https://milanjovanovic.tech/pragmatic-clean-architecture) and
[**Modular Monolith Architecture**](https://milanjovanovic.tech/modular-monolith-architecture) courses currently use MediatR and MassTransit extensively.
I plan to keep them on MediatR v12 and MassTransit v8 in the short term.
However, I'll also be updating them to show migration paths away from these libraries.
What's your take?
Will you stick with the open versions, pay for licenses, or explore alternatives?
Thanks for reading.
And stay awesome!
---
## Frequently asked questions
### Why did MediatR and AutoMapper go commercial?
In 2025, Jimmy Bogard announced that MediatR and AutoMapper would move to commercial licenses. His open source work had been sponsored by a former employer, and once that support ended his contributions dried up, so commercial licensing became the path to sustainable development.
### Is MassTransit v9 free or commercial?
MassTransit announced in 2025 that v9 would ship under a commercial license, with a prerelease planned for Q3 2025 and the official release in Q1 2026. Version 8 remained open source, with security patches planned through 2026.
### How much did MassTransit say v9 would cost?
The pricing targets announced in 2025 were $400 per month or $4000 per year for small and medium businesses, and $1200 per month or $12000 per year for large enterprises. The numbers were not final at announcement time.
### What are the alternatives to MediatR?
Options include FastEndpoints or writing a simple mediator yourself. MediatR isn't too complex to build on your own, and doing that is probably the simplest way to move away from it.
### What are the alternatives to AutoMapper?
Mapster and manual mapping are the main alternatives. Many teams have business logic buried deep in custom mappers, which makes extracting and replacing AutoMapper difficult, so expect significant work if those integrations run deep.
### What are the alternatives to MassTransit?
You can drop down to raw client libraries like RabbitMQ.Client or Azure.Messaging.ServiceBus, or consider Rebus. Migrating is challenging because MassTransit features like saga support and request-response messaging are hard to replicate.