Letzte Woche beim Kick-off einer .NET-Modernisierung, Maschinenbauunternehmen, 140 Mitarbeitende, Standort Süddeutschland. Ich schaue mir die Solution an — und in der Packages-Datei stehen, wie in neun von zehn Projekten dieser Größe, AutoMapper und MediatR. Nichts Ungewöhnliches. Der Lead-Entwickler zuckt mit den Schultern: "Haben wir schon immer genutzt, keine Probleme damit." Genau das ist der blinde Fleck.
Denn während dieser Entwickler seinen Kaffee trinkt, hat Jimmy Bogard gerade beschlossen, wie er dessen Arbeitgeber ab diesem Jahr eine Rechnung schickt.
Was Bogard ankündigt
Jimmy Bogard ist der Maintainer von AutoMapper und MediatR, zwei der meistgenutzten NuGet-Bibliotheken im gesamten .NET-Ökosystem. In seinem aktuellen Blogpost erklärt er transparent, warum er auf ein Dual-License-Modell umstellt: Als sein ehemaliger Arbeitgeber die Sponsorship wegfiel, war die Frage nicht mehr "wie weiter machen" sondern "wer bezahlt das eigentlich". Die Antwort: kommerzielle Unternehmen, die diese Libraries gewinnbringend einsetzen, sollen zahlen. Wer das nicht ist — OSS-Entwickler, Studenten, Startups unter einem bestimmten Umsatzschwellenwert, Non-Profits — bekommt die Libraries weiterhin kostenlos.
Kein Per-Seat-Modell, gestaffelte Unternehmenslizenzen, und Bogard selbst vergleicht die Kosten mit einem Bruchteil des IDE-Budgets für ein Team. Preise kommen in den nächsten Monaten.
Was in einem KMU wirklich passiert
Das Modell ist fair gedacht. Ich habe selten so viel Transparenz bei einer Lizenzumstellung gesehen. Das "keine Per-Seat-Lizenzen"-Versprechen ist für Unternehmen mit 30 bis 300 Entwicklern Gold wert — das spart genau die Bürokratie, die jeden Lizenzmanager in den Wahnsinn treibt. Stattdessen: Unternehmenslizenzen nach Stufen. Gut.
Und der Vergleich mit IDE-Kosten stimmt. Rider oder Visual Studio Enterprise für ein 20-köpfiges Team kostet im Jahr zwischen 15.000 und 30.000 Euro. Wenn AutoMapper und MediatR zusammen ein Zehntel davon kosten, ist das kein Budget-Problem — das ist ein Kommunikationsproblem. Der Einkauf versteht nicht, warum er für "kostenlose Software" plötzlich zahlen soll.
Was noch fehlt — und was zum Problem wird
Die Umsatzschwelle für "kleine Unternehmen" ist noch nicht definiert. Bogard schreibt "below some revenue/funding threshold" — das ist keine Zahl, das ist eine Absichtserklärung.
Warum das zählt: Ich sehe in meinen Mandaten regelmäßig Unternehmen, die sich selbst als "kleines Unternehmen" betrachten, obwohl sie 40 oder 60 Millionen Jahresumsatz machen. Ohne klare Grenze gibt es entweder Selbstbetrug ("wir sind sicher klein genug") oder Überreaktion ("wir migrieren alles raus, nur um auf der sicheren Seite zu sein"). Beides kostet mehr als die Lizenz.
Das eigentliche Problem für den Mittelstand ist aber nicht der Preis — es ist die Entdeckung. Die meisten KMUs wissen nicht genau, was in ihren Dependencies steckt. AutoMapper taucht oft transitiv auf, durch interne Libraries, durch ausgelagerte Entwicklungspartner, durch Copy-Paste aus alten Projekten.
Ich habe letztes Jahr bei einem Projektkunden die gesamte Dependency-Liste auditiert — 80 Mitarbeitende, custom ERP in .NET, aufgebaut über acht Jahre. Ergebnis: 14 NuGet-Pakete, bei denen der Lead-Entwickler keine klare Aussage machen konnte, warum sie drin sind. AutoMapper war viermal eingebunden, über verschiedene Module, teils in unterschiedlichen Versionen.
Die drei Szenarien, die kommen
Wenn die License-Pflicht greift, gibt es in der Praxis drei Wege:
Szenario 1: Das Unternehmen bemerkt es nicht, nutzt die Library weiter, und ist technisch im Verstoß. Passiert öfter als man denkt, besonders wenn die Entwicklung extern sitzt oder das Team rotiert hat.
Szenario 2: Ein Entwickler bemerkt es, meldet es nach oben — und es startet ein monatelanger Genehmigungsprozess für eine Lizenz, die vermutlich 500 bis 2.000 Euro im Jahr kostet. Ich habe das bei kommerziellen Entwicklungstools erlebt: Der Sachbearbeiter im Einkauf versteht den Unterschied zwischen einer Jahreslizenz und einem Wartungsvertrag nicht, und das Ticket liegt drei Monate auf einem Schreibtisch.
Szenario 3: Das Unternehmen entscheidet sich aus Prinzip dagegen und migriert weg. Je nach Codebasis kostet das zwischen einem Wochenend-Sprint (sauberes, modernes Projekt) und einer drei Monate langen Projektphase (gewachsene Codebasis, 400 Mapper-Profile, MediatR-Handler in jeder Schicht).
Alle drei Szenarien sind teurer als eine frühe, bewusste Entscheidung jetzt.
Was ich konkret empfehle
Erstens: Mach jetzt einen Dependency-Scan. dotnet list package --include-transitive in jedem Projekt, Ergebnis dokumentiert. Du willst keine Überraschungen, wenn die Lizenzseite live geht.
Zweitens: Entscheide nicht reflexartig. Wenn dein Team AutoMapper seit fünf Jahren einsetzt und zufrieden ist, ist "jetzt migrieren, weil das plötzlich Geld kostet" fast immer die schlechteste Option. Migration kostet Entwicklungszeit, Testaufwand, Risiko — und die Alternativen (Mapster, manuelles Mapping) sind kein freies Mittagessen, sondern andere Tradeoffs. Eine Unternehmenslizenz für ein mittelgroßes Team wird sich im niedrigen vierstelligen Jahresbetrag bewegen. Das rechnet sich fast nie nicht.
Drittens: Wenn du ein Softwarehaus bist, das für Kunden entwickelt — kläre jetzt vertraglich, bei wem die Lizenzpflicht liegt. Bei euch oder beim Kunden? Diese Frage ist in keinem Werkvertrag, den ich je gesehen habe, sauber geregelt. Und wenn Bogard anfängt, Compliance-Checks zu machen, ist "das haben wir nicht besprochen" keine Antwort.
Bogard macht die Ankündigung übrigens mit ausreichend Vorlauf. Das gibt Unternehmen Zeit, sich vorzubereiten — wenn sie es wollen. Die meisten werden warten, bis es brennt. Das ist keine Kritik an Bogard. Das ist Mittelstands-Realität.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper and MediatR Licensing Update
Wenn du wissen willst, ob dein .NET-Stack lizenz-kritische Dependencies hat — und was das konkret für dein Budget und deine nächste Roadmap bedeutet — buch dir 30 Minuten.
— Bernhard