Jimmy Bogard’s April 16, 2025 licensing update describes a proposed commercialization path for AutoMapper and MediatR, including a dual-license model.1 At that point, the exact tiers and pricing were still being worked out.
For businesses using those libraries, the right response is to identify the installed versions, understand the applicable terms and assess the options. An announcement about a future model does not tell you everything about the software already running.
There is also a reasonable maintenance question behind the announcement. Widely used libraries require ongoing work. A dependency can arrive on the build server without an invoice while still depending on somebody’s sustained effort.
The planning failure would be assuming that the arrangement can never change. “Free forever, maintained indefinitely” is a lovely purchasing specification. It is less obviously a business model.
First establish what the application actually uses
Begin with an inventory of direct and indirect dependencies, their versions and where they matter to the application. A library appearing in a package list may support a narrow feature or be woven through the codebase.
Record the license attached to the relevant release and the terms proposed for a future upgrade. Have the responsible reviewer confirm what those terms mean for the organization’s use.
Separate the library from the architectural idea
MediatR can support a mediator-style approach to handling requests. AutoMapper can reduce repetitive mapping between object types. Neither is identical to the broader design idea it helps implement.
A team can use vertical slices without making one library the definition of its architecture. Bogard’s writing on vertical-slice architecture concerns how features and their responsibilities are organized, not simply whether a package is installed.3
That distinction helps when evaluating alternatives. Replacing a library may leave the important design intact, or it may expose how tightly the application has coupled itself to that implementation.
When off-the-shelf stops fitting, see how we approach custom development.
Measure the cost of changing your mind
For a fictional application, an object-mapping library might appear in a few carefully isolated places. Replacing it with explicit mapping could be manageable.
In another application, mapping behavior may be spread across many features, including conventions developers have come to rely on. Removing the package then requires understanding and testing those behaviors.
Count the verification and maintenance work, not just the new lines of code. Replacing a dependency to avoid a future charge can become an impressively expensive way to continue saying the dependency budget is zero.
Choose between paying, waiting and replacing deliberately
Commercial licensing can be reasonable when the library delivers continuing value and the terms fit the business. Evaluate the final offer when it exists rather than guessing from an early announcement.
Waiting can also be reasonable while the relevant details are unresolved, provided the current version’s maintenance and compatibility position remains understood. Record a review date and the conditions that would trigger action.
Check out this blog: .NET 10 is an LTS release. Your dependencies would like a word.
Give a replacement a bounded reason
If the library adds little value, creates excessive coupling or no longer fits the operating requirements, replacement may make sense independently of the licensing change.
Try a representative feature before committing to a broad rewrite. Verify the outcome, inspect the new complexity and decide whether the replacement improves the application’s maintainability.
Martin Fowler’s technical-debt discussion is useful background here: carrying an imperfection and paying to remove it are decisions that depend on their consequences.2 A new licensing model can prompt a review without making every existing design choice a mistake.
I would keep this conversation practical and respectful. Understand the maintainer’s proposal, establish what applies to the business and compare complete options once the necessary facts are available.
The useful outcome is a dependency the team can explain, maintain and budget for. Whether that involves a license or a carefully chosen alternative matters less than having made the decision with the actual application in view.