Sechs Fragen, bevor du dich für eine Open-Source-Komponente entscheidest

Du stehst vor einer Komponente, die du brauchst. Ein Identity-Provider, ein Postgres-Operator, eine GitOps-Engine, eine Build-Pipeline. Du musst entscheiden, ob du sie wrappst, also ein fertiges Open-Source-Stück mit einer dünnen Schale aus eigenem Code in Betrieb nimmst, oder ob du sie selbst baust. Beide Pfade haben einen Preis, beide haben einen Nutzen. Was du brauchst, ist nicht ein dreihundertseitiges Architektur-Lehrbuch, sondern eine Methode, die du heute Nachmittag anwenden kannst.

Ich habe in den letzten Jahren mehrere mittelständische Plattformen vom Hyperscaler-Default zurück auf eine eigenständige Stack-Wahl migriert, und dabei jede dieser Wahlen ein paar Mal getroffen. Aus der Praxis sind sechs Achsen herausgefallen, die zusammen die Wrap-oder-Build-Frage so übersetzen, dass am Ende eine ehrliche ADR steht — keine politische Rechtfertigung, sondern eine nachvollziehbare Architektur-Entscheidung.

Sechs Achsen. Eine Frage pro Achse. In dieser Reihenfolge — die nicht akademisch sortiert ist, sondern empirisch: vom häufigsten Killer zum zynischsten Detail.

1. Reife — ist die Komponente architektonisch stabil?

Reife ist nicht dasselbe wie Alter. Eine zwölf Jahre alte Komponente, deren letzte Architektur-Erneuerung sechs Monate zurückliegt, ist nicht reif. Reife setzt eine stabile Architektur voraus, die seit mindestens zwei Jahren nicht grundlegend bewegt worden ist.

Drei Mess-Signale, die ich abklopfe:

• Stabile Major-Version (1.0+) seit mindestens 24 Monaten.
• Mehr als drei unabhängige produktive Adoptionen, idealerweise öffentlich nachvollziehbar (Case Studies, Konferenz-Talks).
• Konsistente Doku-Linie — keine drei Doku-Generationen, von denen zwei veraltet sind.

Wer eine unreife Komponente wrappt, wrappt etwas, das sich noch grundlegend verändern wird. Jede Major-Architektur- Änderung zwingt deine Companion-Schicht zur Neuschreibung. Wer das zwei oder drei Mal mitmacht, hat in Wahrheit selbst gebaut — nur unter dem Tarnmantel des Wrappings.

2. Maintainerschaft — wer pflegt das, und für wie lange?

Maintainerschaft entscheidet, ob die Komponente in fünf Jahren noch existiert, ob sie eine Lizenz-Wende mitmacht, und ob ein Maintainer-Burnout das Projekt zum Erliegen bringt. Drei strukturelle Muster sind im Markt unterwegs:

• Stiftungs-Verankerung (CNCF, Apache, Eclipse, OpenJS): verteilte Governance, CLA-Disziplin, formale Reife-Stufen. Das ist die strukturelle Versicherung gegen plötzliche Lizenz-Wechsel und Maintainerschafts-Brüche.
• Single-Sponsor mit klarer Strategie (Sidero Labs für Talos, Zitadel AG für Zitadel): ehrlich, funktioniert, braucht aber einen Plan-B in der ADR.
• Single-Maintainer — eine Person, kein Backup. Ohne expliziten Fork-Plan keine Wrapping-Wahl.

Das diagnostische Werkzeug: schau dir die Liste der unabhängigen Top-Contributor über die letzten zwölf Monate an. Wenn 95 % der substanziellen Commits aus einer einzigen Firma kommen, ist dein Bus-Faktor faktisch Firma, nicht Person — und eine Firma kann sehr schnell ihre Strategie ändern.

3. Lizenz — und was passiert, wenn sie sich ändert?

Lizenz wird in vielen Architektur-Diskussionen entweder ignoriert (»Apache 2.0, passt«) oder zur ersten Frage gemacht. Beides ist falsch. Eine reife Komponente mit klarer Maintainerschaft übersteht eine Lizenz-Krise; eine unreife mit unklarer Maintainerschaft nicht. Deshalb ist Lizenz Achse drei, nicht Achse eins.

Was ich bevorzuge: Apache 2.0 und MIT (unproblematisch), MPL 2.0 (moderate Copyleft, fürs Wrapping unkritisch). Wo ich vorsichtig werde: AGPL und SSPL — sie können auf SaaS-Wrapper überspringen. Was ich nicht als Open Source werten würde: BSL, ELv2, Commons Clause (Source-Available ist nicht Open Source).

Eine Faustregel: Projekte mit Contributor License Agreement (CLA) bei Single-Sponsor und kommerzieller Strategie sind anfällig für Lizenz-Wenden. Projekte ohne CLA sind faktisch immun — ein einseitiger Wechsel bräuchte die Zustimmung aller bisherigen Beitragenden.

Schreib in deine ADR eine Zeile, die explizit fragt: Was passiert, wenn diese Komponente morgen die Lizenz wechselt? »Wir forken« ist legitim, aber teuer. »Wir wechseln auf Y« ist besser, wenn Y existiert. »Wir hoffen« ist nicht akzeptabel.

4. Standard-Konformität — würde ein Wechsel deine Konsumenten betreffen?

Diese Achse misst, ob die Komponente einen anerkannten Standard sauber implementiert (OIDC, OpenAPI, Kubernetes- API, OCI, S3) oder ob sie eine hauseigene Variation eines Standards fährt. Sie ist die wichtigste Versicherung gegen API-Lock-in.

Ein Drei-Frage-Test, den ich in der ADR-Sitzung stelle:

• Welche Endpoints konsumieren meine Anwendungen?
• Sind diese Endpoints standard-spezifiziert oder hauseigen?
• Gibt es eine zweite OSS-Komponente, die denselben Standard bedient — und falls ja, in welcher Reife?

Bei OIDC-IdPs ist die Linie sauber: die OIDC-Discovery-URL, der Authorization-Endpoint und der Token-Endpoint sind in der Spec festgelegt. Wenn dein IdP diese Endpoints korrekt bedient, kannst du ihn austauschen, ohne dass irgendein Konsument das merkt — vorausgesetzt, du migrierst die Tenant-Daten ordentlich.

5. Companion-Lücke — wie viel Eigen-Code drumherum?

Die Companion-Lücke ist die häufigste versteckte Eigenbau-Quote. Wenn 80 % deines Stacks aus reifer OSS besteht und 20 % Companion-Code, ist das immer noch primär Wrapping. Wenn 40 % Companion-Code, ist es eine Mischform, in der du dir die Frage stellen solltest, ob die OSS-Wahl überhaupt die richtige war. Wenn 60 % Companion-Code, hast du in Wirklichkeit selbst gebaut und die OSS nur als Frame benutzt.

Das praktische Maß, das ich verwende: Personenwochen produktiver Companion-Arbeit pro Jahr.

• Bis 4 Personenwochen pro Jahr: sehr gut gewählt.
• 4-20 Personenwochen pro Jahr: tragbar, aber teuer.
• Über 20 Personenwochen pro Jahr: tendenziell falsch gewählt — du baust de facto selbst, nur in einem fremden Architekturrahmen.

Diese Schätzung wird im ersten Jahr falsch sein. Im zweiten und dritten Jahr wird sie scharf. Wenn deine Engineering- Crew eine Wrapper-Wahl verteidigt, frag nach dieser Zahl. Wenn sie keine Antwort hat, ist die Achse noch nicht durchgedacht.

6. Migrationsfähigkeit — kommst du auch wieder raus?

Diese Achse ist zynisch, deshalb steht sie zuletzt. Sie stellt die Frage: wenn alles andere stimmt, kommen wir trotzdem wieder raus? Niedrige Migrationsfähigkeit ist kein automatischer Ablehnungs­grund — manche der besten Wahlen haben hohe Migrations­kosten, weil ihre Stärke gerade in der Tiefe der Verzahnung liegt.

Vier konkrete ADR-Fragen:

• Wo liegen die Daten — Standard-DB, proprietäres Format, interner Event-Store?
• Lassen sich die Daten exportieren? In welchem Format?
• Existiert eine Migrations­strecke zu mindestens einer alternativen Komponente, getestet?
• Wie lange würde die Migration mit deinen heutigen Ressourcen realistisch dauern?

Standard-Konformität (Achse 4) und Companion-Lücke (Achse 5) verstärken oder schwächen die Migrationsfähigkeit gegenseitig. Eine Komponente mit standard-konformer API und kleiner Companion-Schicht ist migrierbar, fast egal wie tief sie sonst sitzt. Eine mit hauseigener API und großer Companion ist es nicht.

Wie das in der Praxis aussieht: GitOps-Engine-Wahl

Lass uns die Matrix einmal in Aktion sehen. Setting: Plattform-Team eines Mittelständlers, 25 Engineers, mehrere produktive Kubernetes-Cluster, bisher manuelle Rollouts. Aufgabe: GitOps einführen. Kandidatenfeld: FluxCD, ArgoCD, Werf.

Drei Befunde:

Erstens, FluxCD und ArgoCD sind beide valide. Die Matrix produziert kein einsames Verdikt, sondern zwei ehrenwerte Kandidaten. Der Tie-Breaker wird kontextabhängig: wenn das Team ein UI für Self-Service-Rollouts will, gewinnt ArgoCD. Wenn es ein komponierbares Toolkit aus Bausteinen bevorzugt (Source-Controller, Helm-Controller, Kustomize-Controller), gewinnt FluxCD. Beides ist legitim.

Zweitens, Werf scheidet nicht an einer einzelnen Killer-Achse aus. Es schneidet auf Achse 1, 2, 4 und 5 mit »3« ab — was bedeutet, dass es kein Ablehnungs­grund ist, aber konsistent eine Stufe unterhalb der beiden Spitzen- Kandidaten liegt. In einem Stack, in dem Werfs Stärken (Build und Deploy aus einer Hand) zentral wären, könnte es trotzdem gewinnen. In diesem Setting tut es das nicht.

Drittens, der Plan-B-Eintrag ist hier billig. Sollte die ausgewählte Engine in 24 Monaten architektonisch abdriften, ist der Wechsel zwischen FluxCD und ArgoCD ein Drei-Wochen-Projekt, weil beide denselben Standard nutzen (Git-State + Helm/Kustomize). Das ist die direkte Auszahlung hoher Werte auf Achse 4 und 6 — die kommt jetzt, nicht erst in der Krise.

Was du jetzt mitnehmen kannst

Die nächste Wrap-oder-Build-Sitzung in deinem Team läuft anders, wenn ihr diese sechs Achsen vor der Sitzung am Whiteboard habt. Eine pro Achse stehen drei bis fünf Minuten ehrliche Bewertung, am Ende habt ihr eine ADR mit einer Score-Spalte und einer Begründungs-Spalte. Keine Punkte-Summe — die Verteilung zählt, nicht der Mittelwert.

Drei Heuristiken, die sich in der Praxis bewährt haben:

• Wenn auf Achse 1 oder 2 ein Wert unter 3 steht: warten, eine Alternative wählen, oder explizit als »Adoption mit Risiko-Vorbehalt« in der ADR markieren.
• Wenn auf Achse 3 oder 4 ein Wert unter 3 steht: die Wahl ist möglich, aber sie produziert in zwei bis drei Jahren eine Lizenz- oder Migrations-Krise. Beides darf passieren, wenn der Stack das verkraftet.
• Wenn auf Achse 5 oder 6 niedrige Werte stehen: die Companion-Schicht früh sauber schneiden, damit sie austauschbar bleibt. Schlechte Werte hier sind nicht tödlich, aber sie binden Ressourcen langfristig.

Und vor allem: die Matrix misst die Komponente, nicht die Passung. Dein Stack-Kontext bleibt das letzte Wort. Eine Komponente, die in einem Cloud-Native-Mittelstand-Stack mit Bravour besteht, kann in einem regulierten Datenkontext durchfallen, und umgekehrt. Die Achsen geben dir die Sprache, in der du das ehrlich diskutieren kannst — das Verdikt sprichst immer noch du.