Letzten Herbst saß ich in einem Erstgespräch mit einem Maschinenbauer aus dem Schwäbischen, 180 Mitarbeiter, ERP selbst entwickelt, .NET 8, seit 2015 gewachsen. Der Entwicklungsleiter zeigte mir stolz die Architektur: sauber geschnittene Handler, alles über MediatR orchestriert, AutoMapper zwischen Domäne und DTO. Lehrbuch.
Ich fragte: „Was passiert, wenn das teuer wird?" Er schaute mich an wie jemanden, der fragt, ob die Sonne morgen aufgeht. „Das ist Open Source." — Ja. War es.
Was Jimmy Bogard geschrieben hat
Jimmy Bogard, der Autor von AutoMapper und MediatR, hat Anfang 2025 angekündigt, beide Projekte zu kommerzialisieren. Nicht aus Gier, sondern aus Notwendigkeit: Seit er Headspring verlassen hat und solo als Consultant arbeitet, ist seine OSS-Contribution-Kurve schlicht auf null gefallen — weil ihm kein Arbeitgeber mehr die Zeit bezahlt. Er ist ehrlich darüber: Das Modell „Ich baue es, weil ich es kann" trägt nicht mehr. Konkrete Preise oder Lizenzbedingungen gibt es noch nicht; er arbeitet sie gerade aus und will transparent dabei sein. Was er klar kommuniziert: Er will weder Entwickler bestrafen noch auf Microsoft zeigen. Er will einfach, dass seine Arbeit bezahlt wird — damit die Projekte nicht still und leise sterben.
Das ist kein Drama. Das ist Realität.
Wie das in einem KMU landet — und warum es mehr Brisanz hat als in einem Konzern
In einem 5000-Personen-Unternehmen mit 80 Entwicklern ist eine neue Lizenzlinie für zwei NuGet-Pakete ein Procurement-Ticket. Jemand füllt ein Formular aus, Legal nickt, fertig. Der Schmerz: eine Stunde.
In einem KMU mit 4 Entwicklern, einem Budget, das der Geschäftsführer persönlich abzeichnet, und einer Eigenentwicklung, die seit 8 Jahren im Betrieb läuft, ist dasselbe Ereignis ein Projekt.
Ich sehe in meinen Mandaten drei typische Konstellationen, und für jede ist die Antwort eine andere:
Konstellation 1: MediatR und AutoMapper tief eingebaut, keine Ressourcen zum Ablösen.
Das sind die gefährlichsten Mandanten in dieser Situation. Nicht weil die Tools schlecht sind — sondern weil die Abhängigkeit unsichtbar gewachsen ist. 400 Handler, AutoMapper-Profile in jedem Assembly, alles verdrahtet. Hier ist „wir migrieren raus" keine Option, die man mal eben beschließt. Selbst wenn die Lizenz moderat ausfällt: Der Lock-in ist real. Meine Empfehlung hier ist immer gleich — jetzt, solange noch nichts kostet, mindestens einen Architekturschnitt machen, der die Abhängigkeit kapselt. Eine IMappingService-Abstraktionsschicht ist kein großer Aufwand, aber sie gibt dir Optionen.
Konstellation 2: MediatR als CQRS-Pattern-Träger, die eigentliche Logik ist sauber. Hier ist die Lage entspannter. MediatR ist bei vielen Teams ein reines Infrastruktur-Convenience-Tool — der eigentliche Wert liegt im Schnitt der Handler, nicht im Framework. Wenn das Modell funktioniert, gibt es genug Alternativen: Wolverine, ein einfaches Command-Bus-Interface selbst gebaut in zwei Stunden, oder einfach direkte Service-Aufrufe, wenn die Codebase klein genug ist. Der Wechsel ist schmerzhaft, aber machbar.
Konstellation 3: AutoMapper als Daten-Transformations-Kleber. Das ist die Variante, die mich am meisten beschäftigt. Ich habe Mandanten, bei denen AutoMapper hunderte von Mapping-Konfigurationen hält — und gleichzeitig niemand mehr weiß, warum manche davon so konfiguriert sind. AutoMapper hat über die Jahre viel Komplexität möglich gemacht, die eigentlich nicht hätte entstehen sollen: Custom Value Resolvers, Conditional Mapping, verschachtelte Projektion bis in den Query-Layer. Das ist kein Vorwurf an das Tool, aber es ist ein Muster, das ich regelmäßig in Altbeständen sehe. Hier ist eine Kommerzialisierung ehrlich gesagt ein willkommener Anlass, die Frage zu stellen: Brauchen wir das noch — oder räumen wir auf?
Was der Artikel nicht sagt — und was für KMU trotzdem relevant ist
Bogard schreibt aus einer Welt, in der seine Zielgruppe mehrheitlich größere Entwicklungsorganisationen sind, die sein Tooling professionell nutzen. Er denkt in Communities, GitHub-Sponsoren, Paying Clients. Das ist legitim.
Was in dieser Perspektive fehlt: die KMU-Realität von Legacy-Code, der schon länger läuft als das Team, das ihn betreut. Teams, in denen der Senior, der AutoMapper eingeführt hat, längst zu SAP gewechselt ist. Codebases, die niemand mehr vollständig versteht. Eigentümer, die auf die Frage „Was kostet uns das neue Lizenzmodell?" sofort zurückfragen: „Wie viel kostet es uns, das loszuwerden?"
Das ist keine Schwäche dieser Teams. Das ist die normale Realität von 30- bis 300-Mann-Unternehmen, die Software als Mittel zum Zweck betreiben — nicht als Kerngeschäft.
Meine konkrete Empfehlung
Wenn du gerade eine .NET-Eigenentwicklung betreibst und AutoMapper oder MediatR im Einsatz hast: Mach jetzt einen Inventur-Sprint. Nicht um alles wegzuwerfen — sondern um zu wissen, was du hast.
Konkret: Zähle die AutoMapper-Profile. Zähle die MediatR-Handler. Schätze grob ab, wie viele davon „echte Logik" tragen und wie viele nur Strukturkleber sind. Danach weißt du, ob du im Fall einer Lizenzpflicht in einem 2-Tage- oder einem 6-Monate-Projekt steckst.
Zweitens: Wenn du gerade neu anfängst oder eine Refactoring-Runde planst — nimm die Kommerzialisierungs-Ankündigung als Anlass, bewusst zu entscheiden statt automatisch zu greifen. Mapping-Code, der explicit ist, ist maintainable. Mapping-Code, der durch Convention-Magic im Profil versteckt ist, ist eine Zeitbombe. Das gilt unabhängig davon, ob AutoMapper am Ende 0 oder 500 Euro pro Jahr kostet.
Und drittens — und das ist der Punkt, den Bogards Artikel indirekt bestätigt: OSS-Nachhaltigkeit ist ein echtes Problem. Projekte, die von einer Person in deren Freizeit gehalten werden, tragen ein Risiko, das in einer Business-Kritikalitäts-Einschätzung auftauchen sollte. Das ist kein Grund zur Panik, aber es ist ein Argument dafür, Abhängigkeiten zu kennen — und nicht erst dann, wenn ein Breaking-Change oder eine Lizenzpflicht auf dem Tisch liegt.
Bogard macht das Richtige. Er ist transparent, er überstürzt nichts, und er versucht nicht, die Community zu überrumpeln. Für die meisten Großprojekte wird das kein existenzielles Thema. Für den Maschinenbauer aus dem Schwäbischen — und die vielen ähnlichen Mandanten, die ich kenne — ist es ein nützlicher Weckruf.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper and MediatR Going Commercial
Wenn du wissen willst, wie tief deine Abhängigkeit von AutoMapper oder MediatR wirklich sitzt — oder was ein realistischer Ausstiegsaufwand wäre — reden wir 30 Minuten Klartext.
— Bernhard