Open Source CRM oder proprietär? Was den Unterschied wirklich ausmacht

Digitale Souveränität steht 2026 auf jeder CRM-Agenda. In Auswahlprojekten wird daraus schnell eine Lizenzanforderung. Warum dieser Schluss zu kurz greift und welche drei Bereiche stattdessen getrennt entschieden werden müssen.

Dieser Beitrag richtet sich an IT- und Fachbereichsverantwortliche, in deren CRM-Anforderungskatalog „Open Source“ oder „digitale Souveränität“ bereits als Punkt steht, und die klären wollen, ob dort das Richtige steht.

88 % der befragten Unternehmen halten digitale Souveränität für wichtig oder sehr wichtig (Böcker Ziemen & ADITO, 2026). Im Auswahlprozess wird aus dieser Erwartung regelmäßig eine konkrete Anforderung. Der Quellcode soll offen sein, die Server sollen im eigenen Haus stehen. Souveränität wird mit Kontrolle gleichgesetzt und Kontrolle mit Open Source.

Der Reflex ist verständlich. Er vermischt aber drei Entscheidungen, die technisch, vertraglich und wirtschaftlich wenig miteinander zu tun haben.

Drei Bereiche, die regelmäßig zu einem verschmolzen werden

Jedes Softwareprodukt lässt sich entlang von drei Bereichen beschreiben:

• Lizenz: Wer darf den Quellcode einsehen, ändern und weitergeben? Open Source, Open Core, Source Available oder proprietär.
• Betriebsmodell: Wo läuft das System und wer betreibt es? Beim Hersteller als SaaS, bei einem Hosting-Partner, im eigenen Rechenzentrum.
• Vertrag: Wer haftet, wer patcht, wer ist erreichbar? Community-Support ohne Zusage, kommerzieller Supportvertrag oder Gewährleistung mit SLA.

Logisch sind diese Bereiche unabhängig. Praktisch hängen sie zusammen: Nach unserer Marktbeobachtung haben viele proprietäre CRM-Anbieter den Eigenbetrieb aus dem Portfolio genommen, und im Open-Source-CRM-Markt sind belastbare Enterprise-SLAs die Ausnahme. Es existieren trotzdem alle Kombinationen: proprietäre Systeme im Eigenbetrieb hinter der eigenen Firewall, Open-Source-CRM als gehostete Cloud-Lösung mit Abo-Preis, offene Codebasen mit kommerziellem Supportvertrag, geschlossene Produkte ohne jede belastbare Zusage. Wer eine seltene Kombination will, muss allerdings damit rechnen, dass der Kreis der Anbieter klein wird.

Daraus folgt eine Zuordnung, die den Rest der Diskussion strukturiert:

Wer Datenhoheit und Serverstandort steuern will, entscheidet über das Betriebsmodell. Wer Haftung, Reaktionszeiten und Compliance-Nachweise braucht, entscheidet über den Vertrag. Wer das Recht will, den Produktkern zu verändern oder verändern zu lassen, entscheidet über die Lizenz.

Die Begriffe, sauber getrennt

Open Source bezeichnet Software, deren Quellcode unter einer Lizenz veröffentlicht ist, die der Open Source Definition der Open Source Initiative (OSI) entspricht und von dieser als solche anerkannt wurde. Einsehen, Ändern und Weitergeben sind erlaubt, die Weitergabe allerdings fast immer unter Bedingungen. Copyleft-Lizenzen wie die General Public License (GPL) und die Affero GPL (AGPL) verlangen, dass der Quellcode bei der Verbreitung abgeleiteter Werke unter derselben Lizenz offengelegt wird. Die AGPL erweitert diese Pflicht in § 13 auf veränderte Fassungen, mit denen Nutzer über ein Netzwerk interagieren. Für ein CRM kann das insbesondere relevant werden, wenn eine modifizierte Fassung als netzwerkbasierter Dienst bereitgestellt wird. SuiteCRM etwa steht unter AGPL-3.0.

Vorsicht bei herstellereigenen Lizenzen: Der Begriff wird im Markt anders verwendet, als die Definition trägt. Vtiger veröffentlicht seine Open-Source-Edition unter der Vtiger Public License 1.1, einer MPL-Ableitung, die weder in der Liste der OSI-anerkannten Lizenzen noch als Standardbezeichner in der SPDX License List geführt wird. Das ist keine Wertung des Produkts, aber ein Beleg dafür, dass „Open Source“ als Kaufkriterium nur dann trägt, wenn die konkrete Lizenz geprüft wurde.

Open Core meint einen frei verfügbaren Kern mit kostenpflichtigen, proprietären Erweiterungen. Odoo ist das bekannteste Beispiel im CRM- und ERP-Umfeld: Die Community-Edition steht unter LGPL-3.0, die Enterprise-Edition unter einer proprietären Lizenz.

Source Available ist ein Sammelbegriff für Modelle, bei denen der Quellcode einsehbar ist, die Nutzungs-, Änderungs- oder Weitergaberechte aber stärker eingeschränkt sind als bei Open Source. Welche Rechte konkret bestehen, hängt von der jeweiligen Lizenz ab.

Proprietär oder Closed Source heißt: kein Zugang zum Quellcode. Angepasst wird über die mitgelieferten Werkzeuge, Konfigurationsebenen und Schnittstellen.

Die Lizenz regelt Rechte am Code. Sie sagt nichts über Funktionsumfang, Sicherheitsniveau, Servicequalität oder Gesamtkosten. Und die Trennlinie ist ohnehin durchlässig: Der Open Source Security and Risk Analysis Report findet Jahr für Jahr in 96 bis 98 Prozent der untersuchten Codebasen Open-Source-Komponenten, zuletzt in 98 Prozent (Black Duck, 2026). Die Stichprobe ist nicht repräsentativ, sie besteht aus 947 Codebasen, die im Rahmen von Audits und Due-Diligence-Prüfungen gescannt wurden. Die Größenordnung ist trotzdem aussagekräftig: Wer proprietär kauft, kauft in aller Regel ein Produkt, das offene Komponenten enthält und für dessen Pflege ein Hersteller einsteht.

Was Open Source wirklich liefert und was ihm nur zugeschrieben wird

Vier Vorteile hängen tatsächlich an der Lizenz:

1. Keine nutzerabhängigen Lizenzgebühren. Der Kostenblock skaliert nicht mit dem Headcount.
2. Anpassbarkeit bis in den Kern, ohne Herstellerbeteiligung und ohne Priorisierungsschleife.
3. Prüfbarkeit von Code und Abhängigkeiten. Audits und Pentests brauchen keine Erlaubnis.
4. Der Fork, also die persönliche Kopie des Open Source Codes, als Notausgang, wenn ein Projekt oder ein Anbieter ausfällt.

Der Fork verdient eine Einschränkung, die in Vergleichen meist fehlt. Wer den Kern verändert, verlässt den Upgradepfad und wartet die Abweichung dauerhaft selbst. Er ist eine Versicherung, deren Prämie ab dem Tag der Inanspruchnahme läuft und die mit jedem Major-Release teurer wird. Zugleich gilt: Das Recht muss nicht im eigenen Haus ausgeübt werden. Community, Distributoren oder ein zweiter Integrator können es stellvertretend tun. Das Recht ist damit auch ohne eigenes Entwicklungsteam nicht rein theoretisch.

Drei häufig genannte Vorteile hängen dagegen nicht an der Lizenz, sondern am Betriebsmodell: volle Datenhoheit, kontrollierter Serverstandort und Unabhängigkeit von einer einseitigen Abschaltung. Alle drei liefert auch eine proprietäre On-Premise-Installation. Umgekehrt liefert sie ein Open-Source-CRM, das als SaaS beim Anbieter läuft, gerade nicht. Wer diese Punkte in ein Lastenheft schreibt, beschreibt ein Betriebsmodell und sollte es auch so formulieren.

Was ein Herstellervertrag liefert und was nur behauptet wird

Auf der anderen Seite steht die vertragliche Absicherung: Gewährleistung, SLA mit definierten Reaktionszeiten, Eskalationswege, Auftragsverarbeitungsvertrag, dokumentierter Datenstandort, Compliance-Nachweise. Dazu eine finanzierte Roadmap mit Dokumentation, Lokalisierung und planbaren Lifecycle-Zusagen sowie ein deutlich niedrigerer interner Kompetenzbedarf.

Zwei Einschränkungen gehören dazu. Erstens ist die Haftung keine unlimitierte Garantie: Herstellerverträge enthalten praktisch immer Haftungsobergrenzen und Ausschlüsse. Der Unterschied zu Open-Source-Lizenzen, die Haftung standardmäßig vollständig ausschließen, bleibt trotzdem oft erheblich.

Zweitens ist Support ein Attribut des Geschäftsmodells, nicht der Lizenz. Red Hat, SUSE und Nextcloud liefern vergleichbare Zusagen auf offener Codebasis. Im CRM-Markt ist dieses Modell seltener als in der Infrastruktur, aber es existiert und ist die Option, die in der Gegenüberstellung „Open Source oder Hersteller“ am häufigsten unterschlagen wird.

Vertrag und Lizenz sind nicht gleich haltbar

Ein Punkt, den ein Hersteller ungern selbst macht, gehört trotzdem hierher: Vertrag und Lizenz haben unterschiedliche Halbwertszeiten. Ein Supportvertrag läuft aus und wird neu verhandelt. Eine Preiserhöhung zur Verlängerung, ein Eigentümerwechsel beim Anbieter, eine Produktabkündigung, all das trifft die vertragliche Absicherung. Eine einmal erteilte Open-Source-Lizenz bleibt davon unberührt.

Praktisch heißt das: Der Vertrag ist das schärfere Instrument innerhalb der Laufzeit, die Lizenz das haltbarere darüber hinaus. Wer sich für die vertragliche Seite entscheidet, sollte deshalb nicht nur SLA und Reaktionszeiten verhandeln, sondern die Zusagen, die über die aktuelle Laufzeit hinausreichen: garantierte Supportzeiträume, Preisobergrenzen oder Gleitklauseln bei Verlängerung, Exportformate, definiertes Verhalten bei Abkündigung. Das ist der Teil der Verhandlung, der übersprungen wird, weil er in Jahr eins nichts kostet.

Sicherheit ist keine Lizenzfrage

Das Argument, geschlossener Code sei sicherer, weil ihn niemand sieht, ist ein Irrtum. Angreifer arbeiten mit Binaries, Fuzzing und Reverse Engineering. Security through Obscurity verzögert, sie verhindert nicht. Umgekehrt ist auch offener Code kein Schutz: Log4Shell (CVE-2021-44228) zeigte, dass Einsehbarkeit keine Prüfung ersetzt; die Exchange-Schwachstellenkette um ProxyLogon (CVE-2021-26855 ff.) und MOVEit Transfer (CVE-2023-34362) zeigten dasselbe für die proprietäre Seite.

Diese Beispiele belegen allerdings nur, dass es in beiden Modellen schwere Vorfälle gibt. Eine belastbare Evidenz, dass offene oder geschlossene Software im Mittel sicherer ist, existiert nicht. Was sich stattdessen messen lässt, ist die Reife des Schwachstellenmanagements: Update-Frequenz, Time-to-Patch, CVE-Historie, Erreichbarkeit eines Security-Kontakts, Umgang mit Abhängigkeiten. Wie relevant der letzte Punkt ist, zeigt derselbe OSSRA-Datensatz: 92 Prozent der geprüften Codebasen enthielten Komponenten, die vier Jahre oder länger veraltet waren (Black Duck, 2026). Diese Kennzahlen sind bei beiden Modellen erhebbar. Der Unterschied liegt im Nachweisweg. Bei Open Source über eigene Prüfung, bei proprietärer Software über Zertifizierungen, Pentestberichte und vertragliche Zusagen.

Die riskanteste Variante des Irrtums lautet: „Wir hosten selbst, also sind wir sicher.“ Self-Hosting verlagert die Verantwortung für Härtung, Patching und Monitoring vollständig ins eigene Haus. Es reduziert sie nicht.

Was der Cyber Resilience Act an der Frage verändert

Zum 11. September 2026 greifen die ersten Pflichten der Verordnung (EU) 2024/2847, des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden: Frühwarnung binnen 24 Stunden, Detailmeldung nach 72 Stunden, Abschlussbericht binnen 14 Tagen nach Bereitstellung einer Behebungsmaßnahme bei Schwachstellen beziehungsweise binnen eines Monats nach der Detailmeldung bei schweren Vorfällen. Gemeldet wird über die Single Reporting Platform der ENISA an ENISA und das zuständige nationale CSIRT, in Deutschland das CERT-Bund des BSI. Die vollständigen Produktpflichten, darunter Secure by Design, Sicherheitsupdates über den gesamten Supportzeitraum und die Pflicht zur Software-Stückliste (SBOM), greifen ab dem 11. Dezember 2027.

Für Open Source sieht die Verordnung Erleichterungen vor. Frei verfügbare Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, fällt nicht unter die Herstellerpflichten. Wo die Grenze verläuft, hat die EU-Kommission mit ihrem Leitfaden vom 27. Juli 2026 konkretisiert (Europäische Kommission, 2026). Als kommerziell gelten insbesondere der Verkauf der Software, eine kostenpflichtige Enterprise-Version und die Monetarisierung über angebundene Dienste. Ausdrücklich nicht kommerziell sind dagegen freiwillige Spenden, Sponsoring, öffentliche Förderung sowie bezahlter Support, Schulung und Beratung, solange die Software selbst frei verfügbar bleibt. Ein Open-Core-Anbieter mit kostenpflichtiger Enterprise-Version fällt damit regelmäßig unter die Herstellerpflichten. Open-Source-Stewards, die Ökosysteme verwalten, haben eigene, reduzierte Pflichten, unterliegen aber der Meldepflicht.

Damit verschiebt sich die Souveränitätsdebatte an einer entscheidenden Stelle: von der Frage, wer den Code ändern darf, hin zu der Frage, wer die regulatorische Pflicht trägt. Der Adressat hängt dabei am Bereitstellungsmodell, nicht am Supportvertrag. Wer ein proprietäres oder ein Open-Core-Produkt kommerziell bezieht, hat einen Hersteller mit vollem Pflichtenprogramm. Wer ein frei verfügbares Projekt selbst betreibt, hat ihn nicht, und ein eingekaufter Supportvertrag ändert daran nach dem Kommissionsleitfaden nichts; der Supportgeber kann allenfalls als Open-Source-Steward mit reduzierten, aber bestehenden Meldepflichten in der Verantwortung stehen (Europäische Kommission, 2026).

Die Betreiberpflichten kommen ohnehin obendrauf. In Deutschland ist das NIS2-Umsetzungsgesetz am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten. Es verpflichtet Einrichtungen ab 50 Beschäftigten oder mit einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über zehn Millionen Euro zu Risikomanagement und Meldeprozessen (§§ 28, 30, 32 BSIG), allerdings nur, wenn sie in einem der Sektoren der Anlagen 1 und 2 BSIG tätig sind. Betroffen sind schätzungsweise rund 29.500 Einrichtungen gegenüber zuvor etwa 4.500 (Institut der Wirtschaftsprüfer, 2026), nicht der Mittelstand in der Breite. Ob Ihr Unternehmen dazugehört, ist zuerst eine Sektor- und dann eine Größenfrage.

Die Kostenfrage: Jahr 1 gegen Jahr 5

Bei Open Source entfallen Lizenzkosten, nicht die Gesamtkosten. Hosting, Implementierung, Betrieb, Security, Integrationen und Upgrades bleiben. Sie wandern vom Lieferanten in die eigene Personalstruktur. Ein belastbarer Vergleich rechnet deshalb nicht Lizenzpreis gegen null, sondern denselben Positionskatalog über fünf Jahre.

Die entscheidende Größe ist dabei nicht der Lizenzpreis, sondern die dauerhaft verfügbare interne Betriebskapazität. Sie ist keine gleitende Kostenposition, sondern eine Stufe, und sie ist zugleich ein Verfügbarkeitsrisiko: Vakanz, Krankheit und Fluktuation treffen eine interne Stelle, nicht einen Supportvertrag. Wer diese Stelle über fünf Jahre nicht seriös zusagen kann, hat den Kostenvergleich noch nicht geführt.

Für einen Herstellerbeitrag ist das Ergebnis unbequem, aber es ist das Ergebnis jeder ehrlichen Rechnung: Ab einer bestimmten Nutzerzahl wird der Lizenzblock zur dominierenden Position, und dann ist Open Source wirtschaftlich attraktiv. Wo dieser Punkt liegt, entscheidet nicht der Listenpreis, sondern das Verhältnis aus Nutzerzahl mal Subskriptionspreis auf der einen und dauerhaftem internem Betriebsaufwand auf der anderen Seite. Diese Rechnung ist mit den eigenen Zahlen zu führen, nicht mit Marktdurchschnitten.

Zwei Positionen werden dabei regelmäßig unterschätzt. Auf der Open-Source-Seite der Versionssprung: Je tiefer angepasst wurde, desto teurer wird er. Auf der proprietären Seite die Kostenentwicklung bei wachsender Nutzerzahl.

Was digitale Souveränität tatsächlich verlangt

Gefragt nach ihren konkreten Anforderungen nennen Unternehmen klare Zugriffsregeln (57 %), Datenschutz-Compliance (50 %), einen nachvollziehbaren Speicherort (49 %), Transparenz über Verarbeitung und beteiligte Partner (49 %) sowie Daten unter europäischem Recht (41 %) (Böcker Ziemen & ADITO, 2026).

Keine dieser fünf Anforderungen setzt ein Änderungsrecht am Quellcode voraus. Sie verlangen Governance, Dokumentation und Rechtsraum.

Beim Rechtsraum lohnt eine Präzisierung, die in Ausschreibungen oft fehlt. 79 Prozent halten Sitz und Datenverarbeitung des Anbieters in der EU für wichtig oder sehr wichtig (Böcker Ziemen & ADITO, 2026). Begründet wird das häufig mit dem US-amerikanischen CLOUD Act. Dieser knüpft jedoch an die Jurisdiktion des Anbieters an, nicht an den Standort der Festplatte: Herausgabepflichten bestehen für Daten in dessen Besitz, Gewahrsam oder Kontrolle, unabhängig davon, ob die Daten innerhalb oder außerhalb der Vereinigten Staaten gespeichert sind. Ein Rechenzentrum in Frankfurt löst das Problem nicht, wenn der Betreiber US-Recht unterliegt. Das härtere Kriterium ist die Beherrschungsstruktur des Vertragspartners, nicht der Serverstandort, und der CLOUD Act ist dabei nicht einmal der weitreichendste Zugriffstitel. Formulieren Sie die Anforderung deshalb über Sitz, Eigentümerstruktur und anwendbares Recht des Vertragspartners.

Ebenfalls selten mitbedacht: Bei einem vollständig intern betriebenen Self-Hosting kann ein externer Auftragsverarbeiter entfallen. Werden jedoch externe Dienstleister etwa für Betrieb, Administration oder Support einbezogen und erhalten diese Zugriff auf personenbezogene Daten, ist die datenschutzrechtliche Rollenverteilung gesondert zu prüfen. Ein großer Teil der Verantwortung verbleibt beim Unternehmen. Maximale Souveränität und maximale Haftungsverlagerung sind gegenläufige Ziele.

Was diese Zahlen tragen und was nicht

Gerade weil wir an der Studie beteiligt sind, gehört die methodische Einordnung dazu.

Erstens messen die zitierten Werte gestützte Zustimmung. Vorgelegte Aussagen zu Kontrolle, Transparenz und Rechtsraum erhalten erfahrungsgemäß hohe Zustimmung, weil ihnen im Fragebogen kein Preis gegenübersteht. Sie zeigen eine Erwartungshaltung, kein Kaufverhalten.

Zweitens fällt der Vergleich mit den Kriterienfragen auf. Als wichtigste Auswahlkriterien für einen CRM-Anbieter führen fachliche Kompetenz (56 %), Servicequalität (47 %) und Beratungsqualität (46 %); unter den Wechselgründen stehen unzureichende Funktionalität (41 %) und veraltete Technologien (33 %) vorn (Böcker Ziemen & ADITO, 2026). Souveränität erscheint dort in den ausgewiesenen Werten nicht. Belastbar ist das nur eingeschränkt, weil die Studie jeweils die häufigsten Nennungen zeigt und der Anbietersitz separat abgefragt wurde. Dort erreicht er 39 Prozent „sehr wichtig“ und liegt damit im Feld der übrigen Kriterien, nicht darüber.

Drittens ein Beispiel aus derselben Studie dafür, wie schnell solche Werte an Kontur verlieren: Die Management Summary nennt „79 % EU“ und „81 % Deutschland“ nebeneinander. Die 81 Prozent sind aber eine bedingte Größe, erhoben nur unter denen, für die EU-Speicherung bereits wichtig ist. Als Anteil aller Befragten läge der Wert deutlich niedriger.

Viertens der Rahmen: erhoben im vierten Quartal 2025, befragt wurden 250 Unternehmen ab 200 Mitarbeitenden, davon 86 Prozent mit aktiver Beteiligung an einer CRM-Einführung. Die Zahlen beschreiben diese Gruppe, nicht den Markt.

Wer Souveränität zum K.-o.-Kriterium erklärt, sollte deshalb intern beziffern, was sie kosten darf.

Die Frage hinter der Lizenzfrage

Hinter dem Wunsch nach Open Source stehen in Auswahlgesprächen meist drei Befürchtungen:

1. Das System passt nicht zu unseren Prozessen.
2. Wir kommen später nicht mehr heraus.
3. Wir sind einem einzigen Dienstleister ausgeliefert.

Prozessfit ist zunächst eine Frage der mitgelieferten Werkzeuge und ihrer Anpassungstiefe. Erst wenn diese Möglichkeiten nicht ausreichen und Änderungen am Produktkern erforderlich werden, gewinnt auch die Lizenz an Bedeutung.

94 Prozent halten eine flexibel individualisierbare Standardplattform für die optimale CRM-Lösung, 65 Prozent nennen einfache Integration als zentrale Anforderung, 62 Prozent nutzen bereits modulare oder hybride Architekturen (Böcker Ziemen & ADITO, 2026). Der erste dieser Werte beschreibt allerdings ziemlich genau die Produktkategorie des Studienpartners, deshalb ist er als Beleg mit Vorsicht zu behandeln. Was unabhängig davon gilt: Entscheidend ist die Anpassungstiefe der mitgelieferten Werkzeuge, also Masken, Prozesslogik, Datenmodell und Schnittstellen.

Dienstleisterunabhängigkeit hat zwei Hälften. Die erste ist das Eigentum am Customizing: Wem gehört das Projekt, wo ist es versioniert, kann ein zweiter Partner darauf zugreifen? Ein Open-Source-CRM, dessen Anpassungen undokumentiert bei einem externen Entwickler liegen, macht abhängiger als eine proprietäre Plattform mit sauber versioniertem Kundenprojekt.

Die zweite Hälfte ist die Größe des qualifizierten Anbietermarkts, und hier besteht eine strukturelle Asymmetrie. Bei offener Codebasis kann grundsätzlich jeder Dienstleister arbeiten. Bei proprietärer Software entscheidet der Hersteller über Partnerprogramm, Zertifizierung und Werkzeugzugang und damit darüber, wie groß der Wettbewerb um Ihr Projekt ist. Die Frage im Auswahlgespräch lautet deshalb nicht nur, ob ein zweiter Partner arbeiten darf, sondern wie viele es gibt und wer bestimmt, wer dazugehört.

Exit ist der Punkt, an dem proprietäre Software strukturell schwächer steht: kein Fork, kein Selbstfix, keine Weiterentwicklung ohne Hersteller. Absichern lässt sich das vertraglich über zugesicherte Supportzeiträume, dokumentierte Exportformate und im Ernstfall Source-Code-Escrow. Bei Escrow ist Nüchternheit angebracht: Hinterlegter Code ohne Buildkette, Dokumentation und Team ist selten betriebsfähig. Er ist ein Restrisikoinstrument, kein Ersatz für eine Exit-Strategie.

Neu in der Rechnung ist der EU Data Act (Verordnung [EU] 2023/2854), anwendbar seit dem 12. September 2025. Er verpflichtet Anbieter von Datenverarbeitungsdiensten zu Wechselunterstützung, definierten Übergangsfristen und Transparenz über Datenformate; Wechselentgelte laufen zum 12. Januar 2027 vollständig aus. Das ersetzt keine Exit-Klausel, verschiebt aber das Kräfteverhältnis und gehört in jede Ausschreibung, in der Exit ein Thema ist.

Drei Konstellationen, drei Antworten

Open Source im Eigenbetrieb passt, wenn dauerhaft eigene Entwicklungskapazität verfügbar ist, die Prozesse nah am Standard liegen, die Nutzerzahl den Lizenzblock zur größten Kostenposition macht und die Betriebsverantwortung bewusst übernommen wird.

Open Source mit kommerziellem Supportvertrag passt, wenn Lizenzhoheit und Prüfbarkeit gewünscht sind, Haftung und Reaktionszeiten aber nicht verhandelbar. Der Mittelweg kostet Geld, verbindet aber offene Codebasis mit vertraglicher Absicherung. Im CRM-Markt ist die Auswahl hier kleiner als in der Infrastruktur. Zu beachten ist die oben beschriebene Lücke: Ein Supportvertrag über frei verfügbare Software schafft keinen Hersteller im Sinne des CRA (Europäische Kommission, 2026).

Eine proprietäre Plattform passt, wenn wenig eigene Entwicklungs- und Betriebskapazität vorhanden ist und ein Hersteller einen wesentlichen Teil der technischen Verantwortung übernehmen soll. Besonders relevant wird das, wenn verbindliche SLA, klar definierte Eskalationswege, langfristige Lifecycle-Zusagen und belastbare Compliance-Nachweise gefordert sind.

Kein taugliches Kriterium ist die Unternehmensgröße allein. Ein Maschinenbauer mit 200 Beschäftigten und ohne eigenes IT-Team ist schlechter für Open Source gerüstet als ein Softwarehaus mit 30.

Eine Ausnahme räumt dieser Beitrag ausdrücklich ein: Im öffentlichen Einkauf kann Open Source formale Anforderung sein, aus Beschlusslage, Verwaltungsvorschrift oder politischer Zielsetzung. Dann steht die Lizenzfrage zu Recht am Anfang, weil sie nicht argumentativ, sondern normativ gesetzt ist. Die Argumentation dieses Beitrags gilt für privatwirtschaftliche Auswahlprojekte.

Neun Prüffragen für die Anbieterauswahl

1. Welche Anpassungen sind ohne Herstellerbeteiligung möglich: Oberfläche, Prozesse, Datenmodell, Schnittstellen?
2. Womit wird angepasst, und wie schnell ist jemand darin produktiv?
3. Wem gehört das Customizing-Projekt, und wo liegt es versioniert?
4. Wie viele qualifizierte Dienstleister gibt es, und wer entscheidet, wer dazugehört?
5. Überstehen Anpassungen ein Major-Upgrade?
6. In welchem Format und in welcher Frist bekommen wir Daten und Konfiguration bei einer Trennung heraus?
7. Was passiert bei Produktabkündigung, Preiserhöhung zur Verlängerung oder Übernahme des Anbieters?
8. Welche Zusagen gelten über die aktuelle Vertragslaufzeit hinaus, und welche enden mit ihr?
9. Gibt es eine SBOM, und wer meldet im Ernstfall innerhalb von 24 Stunden?

Keine dieser Fragen beantwortet sich mit „Open Source“ oder „proprietär“.

Fazit

Die Lizenz ist kein taugliches erstes Auswahlkriterium. Sie beschreibt Rechte am Code, während die meisten Anforderungen an Datenhoheit, Rechtsraum, Haftung und Prozessfit an Betriebsmodell und Vertrag hängen. Beim Exit liegt der Fall anders: Dort ist die Lizenz das haltbarere Instrument, und wer sie nicht hat, muss den Unterschied vertraglich ausgleichen.

Die tragende Frage lautet: Wie viel Betriebsverantwortung wollen und können wir dauerhaft übernehmen, und wer haftet, wenn das System ausfällt? Wer sie ehrlich beantwortet, hat den Kreis der infrage kommenden Modelle bereits eingegrenzt und die Lizenzfrage nebenbei mit.

Disclaimer

ADITO ist Hersteller eines proprietären xRM-Systems und damit Partei in dieser Debatte. Die Position dieses Beitrags fällt entsprechend nicht zufällig aus.

Der zitierte CRM-Report 2026 ist eine Studie von Böcker Ziemen in Kooperation mit ADITO. Wir belegen unsere Argumentation also teilweise mit einer Erhebung, an der wir beteiligt sind. Der Abschnitt „Was diese Zahlen tragen und was nicht“ ordnet ein, wo wir die Aussagekraft selbst begrenzt sehen. Feldzeit war das vierte Quartal 2025, befragt wurden 250 Unternehmen ab 200 Mitarbeitenden; die Fallzahlen einzelner Fragen weichen ab und sind jeweils angegeben.

Zur Einordnung dessen, was hier als Anpassbarkeit ohne Quellcodezugriff beschrieben wird: In ADITO werden Masken, Prozesse, Reports und Schnittstellen über eine eigene Entwicklungsumgebung angepasst, Kundenprojekte sind im eigenen Repository versionierbar und auch durch Drittpartner bearbeitbar, externe Systeme werden über REST und SOAP angebunden. Der Produktkern selbst ist nicht änderbar. Das ist eine bewusste Abgrenzung zu Open Source und keine Zwischenform.

Häufige Fragen

Quellenverzeichnis:

• Black Duck. (2026). 2026 Open Source Security and Risk Analysis Report: Software governance in the AI era. https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html 

• Böcker Ziemen & ADITO Software GmbH. (2026). CRM-Report 2026 [Studienbericht]. 

• Europäische Kommission. (2026, 27. Juli). Leitlinien zur Anwendung der Verordnung (EU) 2024/2847 (Cyberresilienzgesetz) [Anhang zur Mitteilung C(2026) 5252]. https://digital-strategy.ec.europa.eu/de/news/commission-publishes-new-guidance-support-businesses-implementation-cyber-resilience-act 
• Institut der Wirtschaftsprüfer. (2026). IDW Knowledge Paper: Das NIS-2-Umsetzungsgesetz (Stand 22.02.2026). https://www.idw.de/IDW/Medien/Knowledge-Paper/IDW-Knowledge-Paper-NIS2-2026-web.pdf