Jimmy Bogard shipped AutoMapper 16.1 and MediatR 14.1 as part of the ongoing commercial chapter for both libraries. If you maintain .NET services of any age, one or both of these is somewhere in your dependency graph.
Vendor evaluation and buy-versus-build decisions are part of my job, so I want to write about the general problem rather than the specific release: what a team should actually do when a dependency it has relied on for years changes its terms.
The reflex reaction — outrage, or a rush to rip it out — is usually the expensive one.
First, Separate Cost From Coupling
These are two different problems and teams routinely conflate them.
Cost is a line item. Somebody can approve it or not, and the number is usually small next to an engineer-week.
Coupling is how deeply the library has shaped your code. This is the one that matters, and most teams have no idea what their number is until they go looking.
A library that appears in five files is a decision. A library whose idioms appear in five hundred files is an architecture. The second one isn't a dependency you can swap; it's a rewrite wearing a dependency's clothes.
So the first move is not a decision. It's an inventory.
Do the Inventory Properly
Count real usage, not package references:
- How many call sites, and are they concentrated or spread?
- Is it used at the boundary, or has it leaked into domain code?
- Does it appear in public API surface that other teams consume?
- Is its behaviour tested directly, or only incidentally through everything else?
That last one decides how safe any replacement can be. If nothing tests the mapping behaviour directly, you cannot swap the mapper safely at any price, because you have no way to know you preserved behaviour.
This inventory is worth doing even if you conclude you'll just pay. You'll have learned something true about your codebase, and the next time a dependency shifts, you'll already know where you're exposed.
Then Choose Among Four Options
Pay. Usually correct when coupling is high and the cost is modest. It is not a failure to pay for software your team depends on daily. Engineering time is more expensive than almost any license, and the people maintaining these libraries were doing it for free for a long time.
Stay on the last permissive version. Legitimate short-term, genuinely dangerous long-term. You've accepted no security patches and no framework-compatibility updates. Fine as a deliberate, dated decision with a review point. Dangerous as a default that nobody revisits, because in two years it becomes the reason you can't upgrade .NET.
Replace it. Honest only with a real number attached, which requires the inventory. The trap is that the first fifty call sites go quickly and convince everyone it's easy, and the last fifty contain every unusual case the library was quietly handling.
Remove the need. Sometimes the most interesting option. A mapping library exists because you have layers requiring translation. A mediator exists because you wanted decoupling from your controllers. Occasionally the right answer isn't a different library — it's noticing that a piece of indirection stopped earning its place several years ago. Explicit mapping code is verbose and it is also obvious, debuggable, and free.
The Broader Lesson
The uncomfortable truth this kind of event exposes: a free dependency is a bet that its maintainer will keep giving you their time.
That's not a criticism of anyone going commercial — it's an argument for knowing your exposure in advance. Teams that had already kept these libraries at arm's length, behind their own interfaces, found this a budget conversation. Teams that had let the idioms spread through the domain found it an architecture conversation.
The practical habit worth building: for any dependency deep in your codebase, be able to answer "what would it take to leave?" You don't have to be ready to leave. You have to know the number, because you will eventually be asked — by a license change, an abandonment, a security advisory, or an acquisition.
What I'd Do
For most teams, in most cases: pay, and use the inventory as the real deliverable. You get a clear-eyed map of your coupling and a maintained dependency, for less than the cost of the migration you were briefly considering at 11pm.
Then take one lesson forward — put new third-party idioms behind your own boundary from the start, so the next time this happens it's a procurement question rather than a quarter of work.
Source: AutoMapper 16.1 and MediatR 14.1 Released, Jimmy Bogard.
