This blog post is also available in English

TL;DR

Wer als Unternehmen eine souveräne Chat-Lösung sucht, landet in der Lizenzfalle: Open Source im Schaufenster, Lizenz an der Kasse. Matrix ist im Bereich Enterprise-Chat das einzige aktiv weiterentwickelte offene Protokoll, das als Standard nachimplementiert werden kann. Bisher hat sich niemand die Mühe gemacht, weil ein Chat-System traditionell zu komplex für ein kleines Team war. Mit agentischer Softwareentwicklung ändert sich das. Ein selbst entwickelter Matrix-Server für den Enterprise-Einsatz, Apache-2.0-lizenziert, drei Laufzeit-Komponenten, keine Lizenzabhängigkeiten: das ist Nebu. Offen lizenziert, auf GitHub github.com/innoq/nebu und openCode https://gitlab.opencode.de/nebu/nebu-server verfügbar. Self-made Souveränität.

Dieser Blogpost ist Teil einer Reihe.

  • Teil 1: KI-Features für Jira Data Center – ohne Atlassian Cloud
  • Teil 2: Nebu: Self-made Souveränität (dieser Blogpost)

Inspiriert vom Digital Independence Day, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.

Wer „Slack Alternative Open Source” googelt, bekommt schnell Ergebnisse. Mattermost, Rocket.Chat, Element. Alles Open Source, alles vielversprechend. Die Websites versprechen Enterprise-Kommunikation ohne Vendor Lock-in, mit Screenshots von Benutzeroberflächen, die genauso aussehen wie Slack. Channels, Threads, Dateifreigabe, Integrationen. Man denkt: Das könnte funktionieren. Also klickt man sich durch die Feature-Listen.

Und dann sieht man die Spalte „Enterprise”: SSO-Integration, LDAP-Anbindung, Compliance-Export, Clustering. Alles hinter einer kommerziellen Lizenz. Die Community Edition ist funktional so weit reduziert, dass man sie als Unternehmen nicht produktiv betreiben kann. Nicht aus Versehen, sondern absichtlich. So funktioniert das Geschäftsmodell. Die Community Edition existiert, damit man das Produkt ausprobiert. Sie existiert nicht, damit man es produktiv einsetzt.

Das Frustrierende daran: Bei anderen Software-Kategorien hat die Open-Source-Welt das Problem längst gelöst. Nextcloud ist das beste Beispiel. Ein Unternehmen kann Nextcloud installieren, produktiv betreiben und hat dabei volle Kontrolle über seine Daten. SSO funktioniert in der Community Edition. Clustering ist möglich. Es gibt eine lebendige Community, die das Produkt weiterentwickelt, und eine kommerzielle Option für Support, aber keine künstliche Feature-Schranke, die den produktiven Einsatz verhindert. Bei Enterprise-Chat sieht es anders aus. Dort gibt es keine Nextcloud. Dort gibt es nur Schaufenster mit Lizenzkasse.

Und das ist das eigentliche Problem: An der Souveränität ändert sich nichts. Wer von Slack zu Mattermost Enterprise wechselt, tauscht die Flagge, aber nicht die Abhängigkeit. Die Rechnung kommt von einem anderen Absender, und die Roadmap bestimmt jemand anderes. Souverän ist das nicht.

Die Lizenzfalle

Was bei Enterprise-Chat sichtbar wird, ist kein Einzelfall. Es ist ein Geschäftsmodell mit eigenem Namen: Open Core. Die Idee klingt zunächst vernünftig: Der Kern der Software ist Open Source, jeder kann ihn nutzen, verändern und betreiben. Die Community profitiert, das Unternehmen dahinter verdient Geld mit Enterprise-Features, Support und Hosting. Soweit die Theorie.

In der Praxis sieht es anders aus. Die Community Edition wird gezielt so beschnitten, dass sie für den professionellen Einsatz unbrauchbar ist. Nicht, weil die Features technisch schwierig wären. Sondern weil sie den kommerziellen Wert der Enterprise Edition ausmachen. SSO ist dabei das offensichtlichste Beispiel, weil es in praktisch jedem Unternehmen ab einer bestimmten Größe eine Grundvoraussetzung ist. Wer seine Mitarbeiter nicht über das zentrale Identity Management anmelden kann, betreibt eine Insellösung. Und genau dieses Feature sitzt zuverlässig hinter der Lizenzschranke.

Das gleiche Muster findet sich bei Clustering, bei Audit-Logging, bei Compliance-Exporten. Es sind nie die Nischen-Features, die fehlen. Es sind immer die Features, ohne die ein produktiver Betrieb im Unternehmenskontext nicht möglich ist. Das ist keine zufällige Lücke. Es ist die Architektur des Geschäftsmodells.

Und dieses Modell ist nicht auf Chat-Software beschränkt. Redis wechselte 2024 von einer permissiven Open-Source-Lizenz zu einer restriktiven. Die Community Edition kann zwar Clustering, aber ohne automatisches Shard-Management, ohne Multi-Tenancy und ohne die Hochverfügbarkeit, die ein produktiver Betrieb verlangt. Wer das braucht, landet bei Redis Enterprise. Dasselbe Open-Core-Muster, nur diesmal bei der Infrastruktur. HashiCorp machte 2023 dasselbe mit Terraform und Vault. MongoDB ging denselben Weg schon Jahre früher. Die Lizenz, auf die man sich bei der Einführung verlassen hat, kann sich Jahre später ändern, ohne dass man irgendetwas dagegen tun kann. Man sitzt dann vor der Wahl: zahlen, migrieren oder das Risiko akzeptieren. Keine dieser Optionen ist souverän.

Das Problem ist nicht, dass Unternehmen für Software bezahlen. Gute Software zu finanzieren ist richtig und wichtig. Das Problem ist, dass „Open Source” als Versprechen der Unabhängigkeit verwendet wird, während das Geschäftsmodell dahinter genau diese Unabhängigkeit systematisch verhindert. Wer von Slack zu Mattermost Enterprise wechselt, hat ein neues Logo auf der Rechnung. Die Abhängigkeitsstruktur ist dieselbe.

Ein Protokoll, kein Produkt

Bei Matrix liegt der Fall anders als bei Mattermost oder Rocket.Chat. Matrix ist kein Produkt eines Unternehmens, das eine Community Edition als Köder anbietet. Matrix ist ein offener Standard. Das Protokoll ist öffentlich spezifiziert, aktiv weiterentwickelt und definiert, wie Server und Clients miteinander kommunizieren. Jeder kann eine eigene Implementierung schreiben, und die bestehenden Clients funktionieren damit ohne Änderungen. Element, Cinny, FluffyChat: all diese Clients sprechen das Matrix-Protokoll und verbinden sich mit jedem Server, der die Client-Server-API korrekt implementiert.

Das ist ein entscheidender Unterschied. Wer einen eigenen Mattermost-Server baut, hat keine Clients. Wer einen eigenen Matrix-Server baut, hat sofort ein ganzes Ökosystem an ausgereiften Clients, die einfach funktionieren.

Aber genau hier beginnt das Problem. Auf der Serverseite sieht es düster aus. Synapse, die bekannteste und ausgereifteste Implementierung, ist AGPLv3-lizenziert. Das heißt: Jede Modifikation muss als Open Source veröffentlicht werden, sobald der Server über ein Netzwerk bereitgestellt wird. Für Unternehmen, die ein angepasstes Berechtigungsmodell oder branchenspezifische Compliance-Funktionen brauchen, ist das ein Ausschlusskriterium. Dendrite und Conduit sind zwar Apache 2.0 lizenziert, aber beide nicht produktionsreif. Kein echtes Clustering, offene Performance-Fragen, kein Enterprise-Featureset.

Die Lücke ist real: Es gibt keinen Matrix-Server, der gleichzeitig eine permissive Lizenz hat, horizontal skaliert und die Features mitbringt, die Unternehmen und Behörden brauchen. Die Wahl besteht zwischen Synapse mit Lizenzproblem, unreifen Alternativen oder der kommerziellen Element-Lösung, die das Abhängigkeitsproblem nur verlagert.

Ich hatte diesen Gedanken schon länger: Warum baut das eigentlich niemand selbst? Das Protokoll ist offen, die Clients sind da. Was fehlt, ist der Server. Aber ein Chat-System ist komplex. Unternehmenskritisch. Tausende Nutzer, die darauf angewiesen sind, dass es funktioniert, verwaltet von zwei oder drei Admins. In klassischen Softwareprojekten braucht man dafür ein spezialisiertes Team, das sich mit verteilten Systemen, Echtzeit-Kommunikation und Kryptografie auskennt. Das ist teuer, und für ein einzelnes Projekt kaum zu rechtfertigen. Als One-Man-Show ist es schlicht nicht zu schaffen. Nicht weil das Wissen fehlt, sondern weil Architektur, Implementierung und die schiere Breite der technischen Entscheidungen für eine einzelne Person zu viel sind.

Also blieb der Gedanke ein Gedanke. Bis sich die Rahmenbedingungen geändert haben.

Also baue ich es selbst

Agentische Softwareentwicklung, also die Arbeit mit LLM-gestützten Agenten, die eigenständig Teilaufgaben lösen, hat verändert, was eine einzelne Person leisten kann. Nicht weil ein LLM besseren Code schreibt als ein erfahrener Entwickler. Sondern weil sie die Konzeptionsarbeit auf ein Maß reduziert, das vorher undenkbar war. Was früher Monate Architekturarbeit mit einem spezialisierten Team erforderte, lässt sich heute in strukturierten Sessions erarbeiten, wenn man den richtigen Prozess hat und die Ergebnisse beurteilen kann.

Wichtig ist dabei die Unterscheidung: Das hier ist kein Vibe-Coding. Kein One-Shot-Run, bei dem man einem LLM sagt „bau mir einen Chat-Server” und hofft, dass etwas Brauchbares herauskommt. Die Matrix-Community hat diese Erfahrung bereits gemacht. Im Januar 2026 veröffentlichte Cloudflare einen Matrix-Homeserver auf Cloudflare Workers, beworben als „production-grade” mit Deploy-Button. Matthew Hodgson von der Matrix Foundation zerlegte die Implementierung innerhalb von Stunden öffentlich: keine State Resolution, keine Permission-Checks, keine echte Authentifizierung. Hodgson verglich es mit „einem Dateisystem, das Berechtigungen ignoriert, oder einer Blockchain ohne Konsens-Mechanismus.” Die Community erkannte die typischen Merkmale von LLM-generiertem Code sofort: TODO-Kommentare in kritischer Security-Logik, plausible Struktur ohne funktionale Tiefe. Cloudflare musste den Artikel kurz nach Veröffentlichung mit einem Disclaimer als Proof of Concept nachbessern.

Was hier stattdessen passiert, ist Spec-Driven Development mit dem BMAD-Framework, einem strukturierten Prozess für agentische Produktentwicklung. Ein Ablauf, der von der Produktvision über Architekturentscheidungen bis hin zu Epics und Implementierungsplänen führt. Das Ergebnis ist kein Code, den man blind übernimmt, sondern echtes Engineering: Ein vollständiges Product Requirements Document, eine durchdachte Architektur, saubere Epics. Gemacht von einem Menschen, unterstützt von Agenten.

Ich habe es ausprobiert. Nicht als Experiment, sondern mit einer konkreten Produktvision: Ein Matrix-kompatibler Enterprise-Chat-Server. Apache 2.0. Horizontales Clustering. SSO by default. DSGVO-tauglich mit Audit-Log und Compliance-Zugriff. Alles, was die Lizenzfalle mir vorenthält, baue ich selbst.

Das Ergebnis heißt Nebu. Benannt nach der Nebuchadnezzar aus dem Film Matrix, dem Schiff, das die Menschen aus der Matrix befreit hat.

Komplexität rausnehmen, wo es geht

Die erste Architekturentscheidung war die wichtigste: Nur die Matrix Client-Server API implementieren, auf Federation komplett verzichten. Federation, also die Fähigkeit, dass verschiedene Matrix-Server miteinander kommunizieren, ist der komplexeste Teil des Protokolls. State Resolution, Server-to-Server-Authentifizierung, Key Exchange: das macht rund 40% der Gesamtkomplexität aus. Enterprise-Deployments laufen ohnehin auf der eigenen Instanz. Der Verzicht ist kein Kompromiss, sondern eine bewusste Entscheidung, die Komplexität drastisch zu reduzieren. Und das Entscheidende: Alle Standard-Clients funktionieren trotzdem ohne Änderungen weiter.

Die Lizenzfalle im eigenen Entwurf

Dann der Moment, der die ganze These dieses Artikels auf den Punkt bringt. Ich schaue mir den ersten Blueprint an. Redis für Session-Caching, NATS für den internen Message-Bus. Beides Standardentscheidungen, beides technisch völlig in Ordnung. Dann schaue ich mir die Lizenzen an. Redis: SSPL seit 2024. Für produktives Clustering braucht man eine kommerzielle Lizenz. Ich starre auf meinen eigenen Entwurf und merke: Die Lizenzfalle, die mich überhaupt erst zu diesem Projekt gebracht hat, steckt in meinem ersten Blueprint. Und es ging weiter: Schaut man sich an, was Element Server Suite Pro unter der Haube hat, findet man Synapse Pro mit Redis als zentraler Komponente für die Worker-Kommunikation beim horizontalen Skalieren. Redis, das seit 2024 unter SSPL steht. Der Vendor, der einen aus der Slack-Abhängigkeit befreien soll, baut seine Lösung auf einer Komponente auf, die selbst in der Lizenzfalle steckt.

Also: raus damit. Elixir bringt alles mit, was sonst externe Komponenten wie Redis oder NATS erfordern würden. Der eingebaute In-Memory-Store ETS ersetzt Redis, ohne Netzwerk-Hop und ohne zusätzliche Lizenz. Process Groups übernehmen den internen Message-Bus. Elixir Distribution mit TLS verbindet die Cluster-Nodes. Keine externe Abhängigkeit, alles aus einer Plattform.

Ich kenne mich mit Elixir selbst nicht im Detail aus. Aber ich weiß, dass WhatsApp auf Erlang/OTP läuft, und dass das Aktor-Modell von OTP für genau diese Art von Echtzeit-Messaging gebaut wurde. Mit agentischer Entwicklung brauche ich kein Elixir-Expertenwissen. Ich brauche die Architekturentscheidung, dass Elixir die richtige Wahl ist, und die Fähigkeit, die Ergebnisse zu bewerten. Den Rest übernimmt der Agent.

Und genau hier liegt ein Vorteil, der leicht übersehen wird: Weil ich den Code nicht selbst schreibe, kann die Technologiewahl rein anhand der Produktvision erfolgen. Elixir ist die optimale Sprache für Echtzeit-Messaging. Go ist optimal für HTTP-Gateways. In einem klassischen Projekt müsste ich Kompromisse eingehen, weil das Team nur bestimmte Sprachen beherrscht. Wahrscheinlich wäre alles in Go gelandet, weil die verfügbaren Entwickler Go können. Das wäre funktional, aber ohne die Vorteile einer Sprache, die für genau diesen Anwendungsfall optimiert ist. Und selbst wenn man sich für den optimalen Stack entscheidet, braucht man plötzlich Go-Entwickler und Elixir-Entwickler, was das Team größer und das Projekt teurer macht. Mit agentischer Entwicklung fällt dieser Kompromiss weg. Die beste Technologie für den Job gewinnt, nicht die, die gerade im Team verfügbar ist.

Das Ergebnis: drei Komponenten, keine Lizenz

Am Ende stehen drei Laufzeit-Komponenten: Ein Go-Binary für die API- und Media-Gateways. Ein Elixir/OTP-Release für Core Messaging, Session Management und Presence. PostgreSQL als Datenbank. Kein Redis. Kein NATS. Alle Komponenten Apache 2.0 oder BSD-lizenziert. Keine weiteren Lizenzen. Keine Abhängigkeitskette.

Die Authentifizierung läuft OIDC-first. Nebu verwaltet keine Passwörter. Identität kommt ausschließlich vom externen OIDC-Provider, ob das Dex, Keycloak oder Azure AD ist, spielt keine Rolle. Das Protokoll abstrahiert den Provider. Das hat einen konkreten Sicherheitsvorteil: Kein eigenes Passwort-Management bedeutet eine ganze Kategorie von Sicherheitslücken weniger.

Dazu: ein Compliance-Zugriff mit Vier-Augen-Prinzip und unveränderlichem Audit-Log, kryptografische Signaturen auf jeder Nachricht für Nachrichtenintegrität, und Volltextsuche direkt über PostgreSQL FTS ohne externe Suchkomponente. Alles, wofür anderswo eine Enterprise-Lizenz fällig wird, ist von Anfang an Teil der Architektur.

Das Fundament: Zwölf Architecture Decision Records, acht Entwicklungsphasen, vollständiges Datenbankschema. Was daraus geworden ist: Ein Matrix-Server, der mit Element und FluffyChat funktioniert. SSO via OIDC ab der ersten Instanz. docker compose up, zehn Minuten, läuft. Audit Log und Compliance-Zugriff mit Vier-Augen-Prinzip inklusive — ohne Paywall. Alles unter Apache 2.0: github.com/innoq/nebu / https://gitlab.opencode.de/nebu/nebu-server

Die neue Gleichung

Was Nebu zeigt, ist kein Einzelfall. Es ist ein Muster. Und dieses Muster hat zwei Ausprägungen.

Die erste ist die Nebu-Variante: Es gibt ein offenes Protokoll oder einen offenen Standard, aber keine brauchbare Implementierung mit passender Lizenz. In diesem Fall ist Eigenentwicklung die Antwort. Das klingt nach viel, und es ist auch nicht trivial. Aber der Einstieg beginnt nicht bei null. Den Großteil übernehmen bewährte Basis-Technologien, die unangetastet bleiben: Go, Elixir/OTP, PostgreSQL und die gesamte Infrastruktur drumherum. Das Protokoll ist als offener Standard spezifiziert und muss nicht neu erfunden werden. Die fertigen Clients bringt das Matrix-Ökosystem mit, sie funktionieren ohne Anpassung. Was bleibt, ist die eigentliche Server-Implementierung. Das ist ein substanzielles Projekt, aber kein Projekt, das ein Team erfordert, wenn der Prozess stimmt.

Die zweite Variante betrifft deutlich mehr Unternehmen: Eine Open-Source-Lösung mit passender Lizenz existiert, ist stabil, deckt 90–95% der Anforderungen ab. Aber die letzten 5% fehlen. Ein spezifisches Berechtigungsmodell, eine Integration, die der Vendor nicht priorisiert, ein Compliance-Feature, das nur in der eigenen Branche gebraucht wird. Bisher war die Antwort: die kommerzielle Version kaufen oder einen teuren Dienstleister beauftragen, der sich ins Repository einarbeitet. Der SAP-Effekt: passt zu 90% für jeden, doch die letzten 10% sind die teuersten, weil ein Integrator nötig ist, der tief genug drin ist, um die Anwendung an die eigene Domain anzupassen.

Mit agentischer Entwicklung ändert sich diese Rechnung grundlegend. Sich in ein fremdes Repository einarbeiten, die Architektur verstehen, die richtigen Stellen für eine Erweiterung finden: genau das kann ein Agent. Nicht perfekt, nicht ohne Kontrolle, aber schnell genug und gründlich genug, um einen Fork realistisch zu machen, der vorher wirtschaftlich nicht vertretbar war. Das fehlende Feature, das bisher zur Buy-Lösung gezwungen hat, lässt sich jetzt selbst einbauen.

Das klassische Gegenargument ist die Wartung: ein Fork, der vom Upstream abschneidet, Merge-Konflikte produziert und am Ende von einem Entwickler abhängt, der auf keinen Fall kündigen darf. Dieses Argument gilt für Code, der direkt in den Fork geschrieben wird. Bei Spec-Driven Development entsteht stattdessen eine Spezifikation der eigenen Anpassungen, die ein Agent bei jedem Upstream-Update erneut anwendet. Das ist noch eine These. Aber eine, die Nebu selbst beweisen wird.

Beide Varianten führen zum selben Ergebnis: Der Kompromiss zwischen „Open Source, aber unvollständig” und „vollständig, aber abhängig” löst sich auf. Nicht für jedes Problem. Aber für jedes, bei dem die Lücke zwischen dem, was frei verfügbar ist, und dem, was tatsächlich gebraucht wird, überschaubar ist.

Wer profitiert davon? Unternehmen mit eigenem IT-Team, die bei der letzten Lizenzverlängerung keine echte Alternative hatten. Organisationen mit strengen Compliance-Anforderungen. Behörden mit On-Premise-Pflicht. Was es braucht: einen Senior Developer, der Code, Fachlichkeit und Architektur gemeinsam verantworten kann, einen strukturierten Prozess und die Entscheidung, es tatsächlich zu tun.

Auf Entscheider-Ebene lässt sich der Ansatz auf eine einfache Rechnung reduzieren. Eine Mattermost-Enterprise-Lizenz für 500 Nutzer liegt bei mehreren zehntausend Euro jährlich, ein Element-Server-Vertrag in ähnlicher Größenordnung, dazu Integratorkosten und die laufende Abhängigkeit von Preisgestaltung und Roadmap des Vendors. Auf der anderen Seite stehen LLM-Nutzungskosten für die Architekturarbeit, die Arbeitszeit eines Senior Developers und Infrastrukturkosten für den eigenen Betrieb. Dass Personalzeit bei der Einführung neuer Software einzuplanen ist, gilt für jede Alternative gleichermaßen. Bei einem Greenfield-Projekt wie Nebu lagen die LLM-Kosten im niedrigen dreistelligen Bereich; bei einem Fork, der 90% der Architektur übernimmt, ist das der Deckel. Keine jährliche Lizenzverlängerung, bei der der Preis steigt, weil der Vendor weiß, dass die Wechselkosten höher sind. Kein Risiko, dass ein Lizenzwechsel wie bei Redis oder HashiCorp über Nacht die eigene Infrastruktur infrage stellt. Was bleibt, ist ein Asset, das dem Unternehmen gehört, das intern weiterentwickelt werden kann und dessen Kosten planbar sind.

Grenzen, ehrlich benannt

Dieser Ansatz ist kein Allheilmittel, und er sollte nicht als solches verkauft werden.

Agentisch generierte Architektur und Code müssen von jemandem bewertet werden, der die Konsequenzen versteht. Eine Architektur, die plausibel klingt, kann trotzdem grundlegende Fehler enthalten. Die Beschleunigung durch agentische Entwicklung gilt für die Umsetzung, nicht für das Urteilsvermögen, das man mitbringen muss. Das Cloudflare-Desaster zeigt, was passiert, wenn diese Bewertung fehlt: plausibel aussehender Code, der im Ernstfall versagt, und eine Community, die das Vertrauen verliert.

Nicht alles sollte selbst gebaut werden. Kubernetes, PostgreSQL, nginx, Keycloak: Für bewährte Infrastruktur gibt es keine Rechtfertigung, eigene Lösungen zu entwickeln. Der Ansatz funktioniert dort, wo eine reale Lücke besteht. Wo die Lücke nicht existiert, ist er Verschwendung.

Betrieb und Wartung bleiben eigene Aufgaben. Souveränität bedeutet auch eigene Verantwortung für Security-Patches, Datenbankmigrationen, Backups und Monitoring. Das ist kein Nachteil, sondern der Preis der Kontrolle. Wer das nicht intern abbilden kann oder will, sollte das ehrlich einschätzen, bevor er anfängt.

Self-made Souveränität

Die Lizenzfalle funktioniert, weil sie auf einer Annahme beruht: Dass „selber bauen” zu teuer, zu komplex und zu riskant ist. Dass Unternehmen keine andere Wahl haben, als zu zahlen oder zu akzeptieren. Diese Annahme war lange richtig. Sie ist es nicht mehr.

Agentische Softwareentwicklung hat die Gleichung verändert. Nicht weil sie Entwickler überflüssig macht, sondern weil sie einem einzelnen erfahrenen Entwickler ermöglicht, was vorher ein Team erfordert hätte. Die beste Technologie für den Job wählen, unabhängig von den Sprachen, die im Team verfügbar sind. Sich in ein fremdes Repository einarbeiten und die fehlenden 5% selbst einbauen. Oder, wenn es sein muss, eine ganze Implementierung von Grund auf neu aufsetzen, weil kein bestehendes Produkt die Anforderungen mit der richtigen Lizenz erfüllt.

Nebu zeigt, dass dieser Weg gangbar ist. Nicht als Gedankenexperiment, sondern als laufendes Projekt: Apache 2.0, drei Laufzeit-Komponenten, keine Lizenzabhängigkeiten. Element und FluffyChat verbinden sich. [github.com/nebu] — Ein Projekt, das es als One-Man-Show ohne agentische Entwicklung nicht geben würde.

Jedes Unternehmen, das heute vor einer Feature-Matrix sitzt und die gesperrte Enterprise-Spalte betrachtet, hat eine neue Option. Nicht „leben damit” oder „zahlen dafür”. Sondern: selbst machen. Die Werkzeuge sind da. Die Prozesse sind erprobt. Die Hürde ist so niedrig wie nie. Wer eine Produktvision hat und jemanden, der sie beurteilen kann, hat heute alles, was es braucht, um aus einer Abhängigkeit eine eigene Lösung zu machen.

Digitale Souveränität war lange ein Ressourcenproblem. Heute ist sie eine Entscheidung. Ich habe meine getroffen.

Glossar

Agentische Softwareentwicklung — Softwareentwicklung mit LLM-gestützten Agenten, die eigenständig mehrstufige Aufgaben lösen: Code schreiben, Repositories analysieren, Tests ausführen. Im Unterschied zu einem einzelnen Prompt arbeiten Agenten in strukturierten, iterativen Prozessen mit menschlicher Steuerung.

BMAD-Framework — Ein Framework für strukturierte agentische Produktentwicklung, entwickelt von der BMAD-Community (bmad-method.org). BMAD führt systematisch von der Produktvision über Architekturentscheidungen bis zu implementierungsfertigen Epics.

Spec-Driven Development (SDD) — Entwicklungsansatz, bei dem Anforderungen und Änderungen als formale Spezifikation formuliert werden, bevor ein Agent sie in Code umsetzt. Im Unterschied zu unstrukturierter Code-Generierung legt SDD den Fokus auf Spezifikation vor Implementierung, sodass der Prozess nachvollziehbar und bei Bedarf wiederholbar ist.

Open Core — Geschäftsmodell, bei dem der Kern einer Software als Open Source veröffentlicht wird, während unternehmenskritische Features hinter einer kommerziellen Lizenz stehen.

Lizenztypen im Artikel — Permissive Lizenzen (Apache 2.0, BSD, MIT) erlauben freie Nutzung und Modifikation, auch kommerziell. AGPL (Affero GPL) ist eine Copyleft-Lizenz, die bei Bereitstellung über ein Netzwerk die Veröffentlichung des Quellcodes verlangt. SSPL (Server Side Public License) und BSL (Business Source License) sind restriktive Lizenzen, die kommerzielle Nutzung einschränken und im Artikel als Beispiele für Lizenzwechsel dienen.

Matrix-Protokoll — Offener Standard für dezentrale, verschlüsselte Echtzeit-Kommunikation. Das Protokoll spezifiziert, wie Server und Clients interagieren. Jeder kann eine eigene Implementierung schreiben, und bestehende Clients wie Element, Cinny oder FluffyChat funktionieren mit jedem standardkonformen Server.

Federation — Die Fähigkeit von Matrix-Servern, serverübergreifend miteinander zu kommunizieren. Ähnlich wie bei E-Mail können Nutzer verschiedener Server Nachrichten austauschen. Technisch der komplexeste Teil des Protokolls.

OIDC (OpenID Connect) — Authentifizierungsstandard, der die Identitätsprüfung an einen externen Provider delegiert. In der Praxis bedeutet das: Login über den bestehenden Unternehmens-Identity-Provider statt über eigene Passwörter.

Elixir/OTP — Programmiersprache und Plattform, die auf der Erlang-VM läuft. OTP (Open Telecom Platform) bietet eingebaute Werkzeuge für nebenläufige, fehlertolerante und verteilte Systeme. WhatsApp nutzt dieselbe Plattform für Echtzeit-Messaging in großem Maßstab.

ETS (Erlang Term Storage) — In die Erlang/OTP-Plattform eingebauter In-Memory-Datenspeicher. In Nebu ersetzt ETS die externe Komponente Redis für Session-Caching und temporäre Daten.

Quellen

TAGS