Inhalt<\/strong><\/p>\n <\/p>\n 88 % der befragten Unternehmen halten digitale Souver\u00e4nit\u00e4t f\u00fcr wichtig oder sehr wichtig (B\u00f6cker Ziemen & ADITO, 2026). Im Auswahlprozess wird aus dieser Erwartung regelm\u00e4\u00dfig eine konkrete Anforderung. Der Quellcode soll offen sein, die Server sollen im eigenen Haus stehen. Souver\u00e4nit\u00e4t wird mit Kontrolle gleichgesetzt und Kontrolle mit Open Source.<\/p>\n Der Reflex ist verst\u00e4ndlich. Er vermischt aber drei Entscheidungen, die technisch, vertraglich und wirtschaftlich wenig miteinander zu tun haben.<\/p>\n Jedes Softwareprodukt l\u00e4sst sich entlang von drei Bereichen beschreiben:<\/p>\n Logisch sind diese Bereiche unabh\u00e4ngig. Praktisch h\u00e4ngen sie zusammen: Nach unserer Marktbeobachtung haben viele propriet\u00e4re 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\u00e4re Systeme im Eigenbetrieb hinter der eigenen Firewall, Open-Source-CRM als gehostete Cloud-L\u00f6sung 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.<\/p>\n Daraus folgt eine Zuordnung, die den Rest der Diskussion strukturiert:<\/p>\n Wer Datenhoheit und Serverstandort steuern will, entscheidet \u00fcber das Betriebsmodell. Wer Haftung, Reaktionszeiten und Compliance-Nachweise braucht, entscheidet \u00fcber den Vertrag. Wer das Recht will, den Produktkern zu ver\u00e4ndern oder ver\u00e4ndern zu lassen, entscheidet \u00fcber die Lizenz.<\/p>\n Open Source bezeichnet Software, deren Quellcode unter einer Lizenz ver\u00f6ffentlicht ist, die der Open Source Definition der Open Source Initiative (OSI) entspricht und von dieser als solche anerkannt wurde. Einsehen, \u00c4ndern 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 \u00a7 13 auf ver\u00e4nderte Fassungen, mit denen Nutzer \u00fcber ein Netzwerk interagieren. F\u00fcr ein CRM kann das insbesondere relevant werden, wenn eine modifizierte Fassung als netzwerkbasierter Dienst bereitgestellt wird. SuiteCRM etwa steht unter AGPL-3.0.<\/p>\n Vorsicht bei herstellereigenen Lizenzen: Der Begriff wird im Markt anders verwendet, als die Definition tr\u00e4gt. Vtiger ver\u00f6ffentlicht 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\u00fchrt wird. Das ist keine Wertung des Produkts, aber ein Beleg daf\u00fcr, dass \u201eOpen Source\u201c als Kaufkriterium nur dann tr\u00e4gt, wenn die konkrete Lizenz gepr\u00fcft wurde.<\/p>\n Open Core<\/strong> meint einen frei verf\u00fcgbaren Kern mit kostenpflichtigen, propriet\u00e4ren 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\u00e4ren Lizenz.<\/p>\n Source Available<\/strong> ist ein Sammelbegriff f\u00fcr Modelle, bei denen der Quellcode einsehbar ist, die Nutzungs-, \u00c4nderungs- oder Weitergaberechte aber st\u00e4rker eingeschr\u00e4nkt sind als bei Open Source. Welche Rechte konkret bestehen, h\u00e4ngt von der jeweiligen Lizenz ab.<\/p>\n Propriet\u00e4r oder Closed Source<\/strong> hei\u00dft: kein Zugang zum Quellcode. Angepasst wird \u00fcber die mitgelieferten Werkzeuge, Konfigurationsebenen und Schnittstellen.<\/p>\n Die Lizenz regelt Rechte am Code. Sie sagt nichts \u00fcber Funktionsumfang, Sicherheitsniveau, Servicequalit\u00e4t oder Gesamtkosten. Und die Trennlinie ist ohnehin durchl\u00e4ssig: Der Open Source Security and Risk Analysis Report findet Jahr f\u00fcr Jahr in 96 bis 98 Prozent der untersuchten Codebasen Open-Source-Komponenten, zuletzt in 98 Prozent (Black Duck, 2026). Die Stichprobe ist nicht repr\u00e4sentativ, sie besteht aus 947 Codebasen, die im Rahmen von Audits und Due-Diligence-Pr\u00fcfungen gescannt wurden. Die Gr\u00f6\u00dfenordnung ist trotzdem aussagekr\u00e4ftig: Wer propriet\u00e4r kauft, kauft in aller Regel ein Produkt, das offene Komponenten enth\u00e4lt und f\u00fcr dessen Pflege ein Hersteller einsteht.<\/p>\n Vier Vorteile h\u00e4ngen tats\u00e4chlich an der Lizenz:<\/p>\n Der Fork verdient eine Einschr\u00e4nkung, die in Vergleichen meist fehlt. Wer den Kern ver\u00e4ndert, verl\u00e4sst den Upgradepfad und wartet die Abweichung dauerhaft selbst. Er ist eine Versicherung, deren Pr\u00e4mie ab dem Tag der Inanspruchnahme l\u00e4uft und die mit jedem Major-Release teurer wird. Zugleich gilt: Das Recht muss nicht im eigenen Haus ausge\u00fcbt werden. Community, Distributoren oder ein zweiter Integrator k\u00f6nnen es stellvertretend tun. Das Recht ist damit auch ohne eigenes Entwicklungsteam nicht rein theoretisch.<\/p>\n Drei h\u00e4ufig genannte Vorteile h\u00e4ngen dagegen nicht an der Lizenz, sondern am Betriebsmodell: volle Datenhoheit, kontrollierter Serverstandort und Unabh\u00e4ngigkeit von einer einseitigen Abschaltung. Alle drei liefert auch eine propriet\u00e4re On-Premise-Installation. Umgekehrt liefert sie ein Open-Source-CRM, das als SaaS beim Anbieter l\u00e4uft, gerade nicht. Wer diese Punkte in ein Lastenheft schreibt, beschreibt ein Betriebsmodell und sollte es auch so formulieren.<\/p>\n Auf der anderen Seite steht die vertragliche Absicherung: Gew\u00e4hrleistung, 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.<\/p>\n Zwei Einschr\u00e4nkungen geh\u00f6ren dazu. Erstens ist die Haftung keine unlimitierte Garantie: Herstellervertr\u00e4ge enthalten praktisch immer Haftungsobergrenzen und Ausschl\u00fcsse. Der Unterschied zu Open-Source-Lizenzen, die Haftung standardm\u00e4\u00dfig vollst\u00e4ndig ausschlie\u00dfen, bleibt trotzdem oft erheblich.<\/p>\n Zweitens ist Support ein Attribut des Gesch\u00e4ftsmodells, 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\u00fcberstellung \u201eOpen Source oder Hersteller\u201c am h\u00e4ufigsten unterschlagen wird.<\/p>\n Ein Punkt, den ein Hersteller ungern selbst macht, geh\u00f6rt trotzdem hierher: Vertrag und Lizenz haben unterschiedliche Halbwertszeiten. Ein Supportvertrag l\u00e4uft aus und wird neu verhandelt. Eine Preiserh\u00f6hung zur Verl\u00e4ngerung, ein Eigent\u00fcmerwechsel beim Anbieter, eine Produktabk\u00fcndigung, all das trifft die vertragliche Absicherung. Eine einmal erteilte Open-Source-Lizenz bleibt davon unber\u00fchrt.<\/p>\n Praktisch hei\u00dft das: Der Vertrag ist das sch\u00e4rfere Instrument innerhalb der Laufzeit, die Lizenz das haltbarere dar\u00fcber hinaus. Wer sich f\u00fcr die vertragliche Seite entscheidet, sollte deshalb nicht nur SLA und Reaktionszeiten verhandeln, sondern die Zusagen, die \u00fcber die aktuelle Laufzeit hinausreichen: garantierte Supportzeitr\u00e4ume, Preisobergrenzen oder Gleitklauseln bei Verl\u00e4ngerung, Exportformate, definiertes Verhalten bei Abk\u00fcndigung. Das ist der Teil der Verhandlung, der \u00fcbersprungen wird, weil er in Jahr eins nichts kostet.<\/p>\n 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\u00f6gert, sie verhindert nicht. Umgekehrt ist auch offener Code kein Schutz: Log4Shell (CVE-2021-44228) zeigte, dass Einsehbarkeit keine Pr\u00fcfung ersetzt; die Exchange-Schwachstellenkette um ProxyLogon (CVE-2021-26855 ff.) und MOVEit Transfer (CVE-2023-34362) zeigten dasselbe f\u00fcr die propriet\u00e4re Seite.<\/p>\n Diese Beispiele belegen allerdings nur, dass es in beiden Modellen schwere Vorf\u00e4lle gibt. Eine belastbare Evidenz, dass offene oder geschlossene Software im Mittel sicherer ist, existiert nicht. Was sich stattdessen messen l\u00e4sst, ist die Reife des Schwachstellenmanagements: Update-Frequenz, Time-to-Patch, CVE-Historie, Erreichbarkeit eines Security-Kontakts, Umgang mit Abh\u00e4ngigkeiten. Wie relevant der letzte Punkt ist, zeigt derselbe OSSRA-Datensatz: 92 Prozent der gepr\u00fcften Codebasen enthielten Komponenten, die vier Jahre oder l\u00e4nger veraltet waren (Black Duck, 2026). Diese Kennzahlen sind bei beiden Modellen erhebbar. Der Unterschied liegt im Nachweisweg. Bei Open Source \u00fcber eigene Pr\u00fcfung, bei propriet\u00e4rer Software \u00fcber Zertifizierungen, Pentestberichte und vertragliche Zusagen.<\/p>\n Die riskanteste Variante des Irrtums lautet: \u201eWir hosten selbst, also sind wir sicher.\u201c Self-Hosting verlagert die Verantwortung f\u00fcr H\u00e4rtung, Patching und Monitoring vollst\u00e4ndig ins eigene Haus. Es reduziert sie nicht.<\/p>\n Zum 11. September 2026 greifen die ersten Pflichten der Verordnung (EU) 2024\/2847, des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen m\u00fcssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorf\u00e4lle melden: Fr\u00fchwarnung binnen 24 Stunden, Detailmeldung nach 72 Stunden, Abschlussbericht binnen 14 Tagen nach Bereitstellung einer Behebungsma\u00dfnahme bei Schwachstellen beziehungsweise binnen eines Monats nach der Detailmeldung bei schweren Vorf\u00e4llen. Gemeldet wird \u00fcber die Single Reporting Platform der ENISA an ENISA und das zust\u00e4ndige nationale CSIRT, in Deutschland das CERT-Bund des BSI. Die vollst\u00e4ndigen Produktpflichten, darunter Secure by Design, Sicherheitsupdates \u00fcber den gesamten Supportzeitraum und die Pflicht zur Software-St\u00fcckliste (SBOM), greifen ab dem 11. Dezember 2027.<\/p>\n F\u00fcr Open Source sieht die Verordnung Erleichterungen vor. Frei verf\u00fcgbare Software, die au\u00dferhalb einer Gesch\u00e4ftst\u00e4tigkeit bereitgestellt wird, f\u00e4llt nicht unter die Herstellerpflichten. Wo die Grenze verl\u00e4uft, hat die EU-Kommission mit ihrem Leitfaden vom 27. Juli 2026 konkretisiert (Europ\u00e4ische Kommission, 2026). Als kommerziell gelten insbesondere der Verkauf der Software, eine kostenpflichtige Enterprise-Version und die Monetarisierung \u00fcber angebundene Dienste. Ausdr\u00fccklich nicht kommerziell sind dagegen freiwillige Spenden, Sponsoring, \u00f6ffentliche F\u00f6rderung sowie bezahlter Support, Schulung und Beratung, solange die Software selbst frei verf\u00fcgbar bleibt. Ein Open-Core-Anbieter mit kostenpflichtiger Enterprise-Version f\u00e4llt damit regelm\u00e4\u00dfig unter die Herstellerpflichten. Open-Source-Stewards, die \u00d6kosysteme verwalten, haben eigene, reduzierte Pflichten, unterliegen aber der Meldepflicht.<\/p>\n Damit verschiebt sich die Souver\u00e4nit\u00e4tsdebatte an einer entscheidenden Stelle: von der Frage, wer den Code \u00e4ndern darf, hin zu der Frage, wer die regulatorische Pflicht tr\u00e4gt. Der Adressat h\u00e4ngt dabei am Bereitstellungsmodell, nicht am Supportvertrag. Wer ein propriet\u00e4res oder ein Open-Core-Produkt kommerziell bezieht, hat einen Hersteller mit vollem Pflichtenprogramm. Wer ein frei verf\u00fcgbares Projekt selbst betreibt, hat ihn nicht, und ein eingekaufter Supportvertrag \u00e4ndert daran nach dem Kommissionsleitfaden nichts; der Supportgeber kann allenfalls als Open-Source-Steward mit reduzierten, aber bestehenden Meldepflichten in der Verantwortung stehen (Europ\u00e4ische Kommission, 2026).<\/p>\n Die Betreiberpflichten kommen ohnehin obendrauf. In Deutschland ist das NIS2-Umsetzungsgesetz am 6. Dezember 2025 ohne \u00dcbergangsfrist in Kraft getreten. Es verpflichtet Einrichtungen ab 50 Besch\u00e4ftigten oder mit einem Jahresumsatz und einer Jahresbilanzsumme von jeweils \u00fcber zehn Millionen Euro zu Risikomanagement und Meldeprozessen (\u00a7\u00a7 28, 30, 32 BSIG), allerdings nur, wenn sie in einem der Sektoren der Anlagen 1 und 2 BSIG t\u00e4tig sind. Betroffen sind sch\u00e4tzungsweise rund 29.500 Einrichtungen gegen\u00fcber zuvor etwa 4.500 (Institut der Wirtschaftspr\u00fcfer, 2026), nicht der Mittelstand in der Breite. Ob Ihr Unternehmen dazugeh\u00f6rt, ist zuerst eine Sektor- und dann eine Gr\u00f6\u00dfenfrage.<\/p>\n 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 \u00fcber f\u00fcnf Jahre.<\/p>\n Die entscheidende Gr\u00f6\u00dfe ist dabei nicht der Lizenzpreis, sondern die dauerhaft verf\u00fcgbare interne Betriebskapazit\u00e4t. Sie ist keine gleitende Kostenposition, sondern eine Stufe, und sie ist zugleich ein Verf\u00fcgbarkeitsrisiko: Vakanz, Krankheit und Fluktuation treffen eine interne Stelle, nicht einen Supportvertrag. Wer diese Stelle \u00fcber f\u00fcnf Jahre nicht seri\u00f6s zusagen kann, hat den Kostenvergleich noch nicht gef\u00fchrt.<\/p>\n F\u00fcr 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\u00e4ltnis aus Nutzerzahl mal Subskriptionspreis auf der einen und dauerhaftem internem Betriebsaufwand auf der anderen Seite. Diese Rechnung ist mit den eigenen Zahlen zu f\u00fchren, nicht mit Marktdurchschnitten.<\/p>\n Zwei Positionen werden dabei regelm\u00e4\u00dfig untersch\u00e4tzt. Auf der Open-Source-Seite der Versionssprung: Je tiefer angepasst wurde, desto teurer wird er. Auf der propriet\u00e4ren Seite die Kostenentwicklung bei wachsender Nutzerzahl.<\/p>\n Gefragt nach ihren konkreten Anforderungen nennen Unternehmen klare Zugriffsregeln (57 %), Datenschutz-Compliance (50 %), einen nachvollziehbaren Speicherort (49 %), Transparenz \u00fcber Verarbeitung und beteiligte Partner (49 %) sowie Daten unter europ\u00e4ischem Recht (41 %) (B\u00f6cker Ziemen & ADITO, 2026).<\/p>\n Keine dieser f\u00fcnf Anforderungen setzt ein \u00c4nderungsrecht am Quellcode voraus. Sie verlangen Governance, Dokumentation und Rechtsraum.<\/p>\n Beim Rechtsraum lohnt eine Pr\u00e4zisierung, die in Ausschreibungen oft fehlt. 79 Prozent halten Sitz und Datenverarbeitung des Anbieters in der EU f\u00fcr wichtig oder sehr wichtig (B\u00f6cker Ziemen & ADITO, 2026). Begr\u00fcndet wird das h\u00e4ufig mit dem US-amerikanischen CLOUD Act. Dieser kn\u00fcpft jedoch an die Jurisdiktion des Anbieters an, nicht an den Standort der Festplatte: Herausgabepflichten bestehen f\u00fcr Daten in dessen Besitz, Gewahrsam oder Kontrolle, unabh\u00e4ngig davon, ob die Daten innerhalb oder au\u00dferhalb der Vereinigten Staaten gespeichert sind. Ein Rechenzentrum in Frankfurt l\u00f6st das Problem nicht, wenn der Betreiber US-Recht unterliegt. Das h\u00e4rtere 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 \u00fcber Sitz, Eigent\u00fcmerstruktur und anwendbares Recht des Vertragspartners.<\/p>\n Ebenfalls selten mitbedacht: Bei einem vollst\u00e4ndig intern betriebenen Self-Hosting kann ein externer Auftragsverarbeiter entfallen. Werden jedoch externe Dienstleister etwa f\u00fcr Betrieb, Administration oder Support einbezogen und erhalten diese Zugriff auf personenbezogene Daten, ist die datenschutzrechtliche Rollenverteilung gesondert zu pr\u00fcfen. Ein gro\u00dfer Teil der Verantwortung verbleibt beim Unternehmen. Maximale Souver\u00e4nit\u00e4t und maximale Haftungsverlagerung sind gegenl\u00e4ufige Ziele.<\/p>\n Gerade weil wir an der Studie beteiligt sind, geh\u00f6rt die methodische Einordnung dazu.<\/p>\n Erstens messen die zitierten Werte gest\u00fctzte Zustimmung. Vorgelegte Aussagen zu Kontrolle, Transparenz und Rechtsraum erhalten erfahrungsgem\u00e4\u00df hohe Zustimmung, weil ihnen im Fragebogen kein Preis gegen\u00fcbersteht. Sie zeigen eine Erwartungshaltung, kein Kaufverhalten.<\/p>\n Zweitens f\u00e4llt der Vergleich mit den Kriterienfragen auf. Als wichtigste Auswahlkriterien f\u00fcr einen CRM-Anbieter f\u00fchren fachliche Kompetenz (56 %), Servicequalit\u00e4t (47 %) und Beratungsqualit\u00e4t (46 %); unter den Wechselgr\u00fcnden stehen unzureichende Funktionalit\u00e4t (41 %) und veraltete Technologien (33 %) vorn (B\u00f6cker Ziemen & ADITO, 2026). Souver\u00e4nit\u00e4t erscheint dort in den ausgewiesenen Werten nicht. Belastbar ist das nur eingeschr\u00e4nkt, weil die Studie jeweils die h\u00e4ufigsten Nennungen zeigt und der Anbietersitz separat abgefragt wurde. Dort erreicht er 39 Prozent \u201esehr wichtig\u201c und liegt damit im Feld der \u00fcbrigen Kriterien, nicht dar\u00fcber.<\/p>\n Drittens ein Beispiel aus derselben Studie daf\u00fcr, wie schnell solche Werte an Kontur verlieren: Die Management Summary nennt \u201e79 % EU\u201c und \u201e81 % Deutschland\u201c nebeneinander. Die 81 Prozent sind aber eine bedingte Gr\u00f6\u00dfe, erhoben nur unter denen, f\u00fcr die EU-Speicherung bereits wichtig ist. Als Anteil aller Befragten l\u00e4ge der Wert deutlich niedriger.<\/p>\n 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\u00fchrung. Die Zahlen beschreiben diese Gruppe, nicht den Markt.<\/p>\n Wer Souver\u00e4nit\u00e4t zum K.-o.-Kriterium erkl\u00e4rt, sollte deshalb intern beziffern, was sie kosten darf.<\/p>\n Hinter dem Wunsch nach Open Source stehen in Auswahlgespr\u00e4chen meist drei Bef\u00fcrchtungen:<\/p>\n Prozessfit ist zun\u00e4chst eine Frage der mitgelieferten Werkzeuge und ihrer Anpassungstiefe. Erst wenn diese M\u00f6glichkeiten nicht ausreichen und \u00c4nderungen am Produktkern erforderlich werden, gewinnt auch die Lizenz an Bedeutung.<\/p>\n 94 Prozent halten eine flexibel individualisierbare Standardplattform f\u00fcr die optimale CRM-L\u00f6sung, 65 Prozent nennen einfache Integration als zentrale Anforderung, 62 Prozent nutzen bereits modulare oder hybride Architekturen (B\u00f6cker 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\u00e4ngig davon gilt: Entscheidend ist die Anpassungstiefe der mitgelieferten Werkzeuge, also Masken, Prozesslogik, Datenmodell und Schnittstellen.<\/p>\n Dienstleisterunabh\u00e4ngigkeit hat zwei H\u00e4lften. Die erste ist das Eigentum am Customizing: Wem geh\u00f6rt 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\u00e4ngiger als eine propriet\u00e4re Plattform mit sauber versioniertem Kundenprojekt.<\/p>\n Die zweite H\u00e4lfte ist die Gr\u00f6\u00dfe des qualifizierten Anbietermarkts, und hier besteht eine strukturelle Asymmetrie. Bei offener Codebasis kann grunds\u00e4tzlich jeder Dienstleister arbeiten. Bei propriet\u00e4rer Software entscheidet der Hersteller \u00fcber Partnerprogramm, Zertifizierung und Werkzeugzugang und damit dar\u00fcber, wie gro\u00df der Wettbewerb um Ihr Projekt ist. Die Frage im Auswahlgespr\u00e4ch lautet deshalb nicht nur, ob ein zweiter Partner arbeiten darf, sondern wie viele es gibt und wer bestimmt, wer dazugeh\u00f6rt.<\/p>\n Exit ist der Punkt, an dem propriet\u00e4re Software strukturell schw\u00e4cher steht: kein Fork, kein Selbstfix, keine Weiterentwicklung ohne Hersteller. Absichern l\u00e4sst sich das vertraglich \u00fcber zugesicherte Supportzeitr\u00e4ume, dokumentierte Exportformate und im Ernstfall Source-Code-Escrow. Bei Escrow ist N\u00fcchternheit angebracht: Hinterlegter Code ohne Buildkette, Dokumentation und Team ist selten betriebsf\u00e4hig. Er ist ein Restrisikoinstrument, kein Ersatz f\u00fcr eine Exit-Strategie.<\/p>\n 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\u00fctzung, definierten \u00dcbergangsfristen und Transparenz \u00fcber Datenformate; Wechselentgelte laufen zum 12. Januar 2027 vollst\u00e4ndig aus. Das ersetzt keine Exit-Klausel, verschiebt aber das Kr\u00e4fteverh\u00e4ltnis und geh\u00f6rt in jede Ausschreibung, in der Exit ein Thema ist.<\/p>\n Open Source im Eigenbetrieb passt, wenn dauerhaft eigene Entwicklungskapazit\u00e4t verf\u00fcgbar ist, die Prozesse nah am Standard liegen, die Nutzerzahl den Lizenzblock zur gr\u00f6\u00dften Kostenposition macht und die Betriebsverantwortung bewusst \u00fcbernommen wird.<\/p>\n Open Source mit kommerziellem Supportvertrag passt, wenn Lizenzhoheit und Pr\u00fcfbarkeit gew\u00fcnscht 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\u00fccke: Ein Supportvertrag \u00fcber frei verf\u00fcgbare Software schafft keinen Hersteller im Sinne des CRA (Europ\u00e4ische Kommission, 2026).<\/p>\n Eine propriet\u00e4re Plattform passt, wenn wenig eigene Entwicklungs- und Betriebskapazit\u00e4t vorhanden ist und ein Hersteller einen wesentlichen Teil der technischen Verantwortung \u00fcbernehmen soll. Besonders relevant wird das, wenn verbindliche SLA, klar definierte Eskalationswege, langfristige Lifecycle-Zusagen und belastbare Compliance-Nachweise gefordert sind.<\/p>\n Kein taugliches Kriterium ist die Unternehmensgr\u00f6\u00dfe allein. Ein Maschinenbauer mit 200 Besch\u00e4ftigten und ohne eigenes IT-Team ist schlechter f\u00fcr Open Source ger\u00fcstet als ein Softwarehaus mit 30.<\/p>\n Eine Ausnahme r\u00e4umt dieser Beitrag ausdr\u00fccklich ein: Im \u00f6ffentlichen 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\u00fcr privatwirtschaftliche Auswahlprojekte.<\/p>\n Keine dieser Fragen beantwortet sich mit \u201eOpen Source\u201c oder \u201epropriet\u00e4r\u201c.<\/p>\n Die Lizenz ist kein taugliches erstes Auswahlkriterium. Sie beschreibt Rechte am Code, w\u00e4hrend die meisten Anforderungen an Datenhoheit, Rechtsraum, Haftung und Prozessfit an Betriebsmodell und Vertrag h\u00e4ngen. Beim Exit liegt der Fall anders: Dort ist die Lizenz das haltbarere Instrument, und wer sie nicht hat, muss den Unterschied vertraglich ausgleichen.<\/p>\n Die tragende Frage lautet: Wie viel Betriebsverantwortung wollen und k\u00f6nnen wir dauerhaft \u00fcbernehmen, und wer haftet, wenn das System ausf\u00e4llt? Wer sie ehrlich beantwortet, hat den Kreis der infrage kommenden Modelle bereits eingegrenzt und die Lizenzfrage nebenbei mit.<\/p>\n ADITO ist Hersteller eines propriet\u00e4ren xRM-Systems und damit Partei in dieser Debatte. Die Position dieses Beitrags f\u00e4llt entsprechend nicht zuf\u00e4llig aus.<\/p>\n Der zitierte CRM-Report 2026 ist eine Studie von B\u00f6cker Ziemen in Kooperation mit ADITO. Wir belegen unsere Argumentation also teilweise mit einer Erhebung, an der wir beteiligt sind. Der Abschnitt \u201eWas diese Zahlen tragen und was nicht\u201c 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.<\/p>\n Zur Einordnung dessen, was hier als Anpassbarkeit ohne Quellcodezugriff beschrieben wird: In ADITO werden Masken, Prozesse, Reports und Schnittstellen \u00fcber eine eigene Entwicklungsumgebung angepasst, Kundenprojekte sind im eigenen Repository versionierbar und auch durch Drittpartner bearbeitbar, externe Systeme werden \u00fcber REST und SOAP angebunden. Der Produktkern selbst ist nicht \u00e4nderbar. Das ist eine bewusste Abgrenzung zu Open Source und keine Zwischenform.<\/p>\n Quellenverzeichnis:<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Open Source gilt oft als Voraussetzung f\u00fcr digitale Souver\u00e4nit\u00e4t. Doch bei der CRM-Auswahl greifen Lizenz, Betriebsmodell und Vertrag an ganz unterschiedlichen Stellen. Der Beitrag zeigt, welche Vorteile tats\u00e4chlich an Open Source h\u00e4ngen, wo propriet\u00e4re Systeme punkten und welche Fragen Unternehmen vor ihrer Entscheidung beantworten sollten.<\/p>\n","protected":false},"author":62,"featured_media":8270,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8,22],"tags":[127,128],"yoast_head":"\n\n
Drei Bereiche, die regelm\u00e4\u00dfig zu einem verschmolzen werden<\/h2>\n
\n
Die Begriffe, sauber getrennt<\/h2>\n
Was Open Source wirklich liefert und was ihm nur zugeschrieben wird<\/h2>\n
\n
Was ein Herstellervertrag liefert und was nur behauptet wird<\/h2>\n
Vertrag und Lizenz sind nicht gleich haltbar<\/h2>\n
Sicherheit ist keine Lizenzfrage<\/h2>\n
Was der Cyber Resilience Act an der Frage ver\u00e4ndert<\/h2>\n
Die Kostenfrage: Jahr 1 gegen Jahr 5<\/h2>\n
Was digitale Souver\u00e4nit\u00e4t tats\u00e4chlich verlangt<\/h2>\n
Was diese Zahlen tragen und was nicht<\/h2>\n
Die Frage hinter der Lizenzfrage<\/h2>\n
\n
Drei Konstellationen, drei Antworten<\/h2>\n
Neun Pr\u00fcffragen f\u00fcr die Anbieterauswahl<\/h2>\n
\n
Fazit<\/h2>\n
Disclaimer<\/h2>\n
H\u00e4ufige Fragen<\/h2>\n
\n Was ist ein Open Source CRM?<\/a>\n <\/h4>\n <\/div>\n
\n Ist ein Open Source CRM wirklich kostenlos?<\/a>\n <\/h4>\n <\/div>\n
\n Ab wann rechnet sich Open Source?<\/a>\n <\/h4>\n <\/div>\n
\n Ist Open Source Software sicherer als propriet\u00e4re Software?<\/a>\n <\/h4>\n <\/div>\n
\n Was bedeutet Source Available, und wie unterscheidet es sich von Open Core?<\/a>\n <\/h4>\n <\/div>\n
\n Brauche ich Open Source f\u00fcr digitale Souver\u00e4nit\u00e4t?<\/a>\n <\/h4>\n <\/div>\n
\n Wer haftet nach dem Cyber Resilience Act?<\/a>\n <\/h4>\n <\/div>\n
\n Welche Open Source CRM-Systeme gibt es?<\/a>\n <\/h4>\n <\/div>\n
![\"Whitepaper:](\"https:\/\/www.adito.de\/knowhow\/blog\/wp-content\/uploads\/CTA-CRM-Leitfaden-1-1024x339.png\")
<\/a><\/p>\n\n
\n
\n