Dieser Blogpost ist auch auf Deutsch verfügbar

TL;DR

If a company is looking for a sovereign chat solution, it often ends up in the licensing trap: open source in the shop window, a license at checkout. In enterprise chat, Matrix is the only actively developed open protocol that can be reimplemented as a standard. Until now, nobody has bothered, because a chat system was traditionally too complex for a small team. Agentic software development changes that. A self-built Matrix server for enterprise use, Apache-2.0 licensed, three runtime components, no licensing dependencies: that’s Nebu — openly licensed, available on GitHub github.com/innoq/nebu and openCode https://gitlab.opencode.de/nebu/nebu-server. Pure self-made sovereignty.

This post is part of a series.

  • Part 1: AI Features for Jira Data Center – No Atlassian Cloud Required
  • Part 2: Nebu: Self-made sovereignty (this post)

Inspired by the Digital Independence Day and its call for “recipes” for digital sovereignty, we share our own approaches to topics that matter to our customers – every first Sunday of the month.

If you google “Slack alternative open source”, you’ll get results quickly. Mattermost, Rocket.Chat, Element. All open source, all promising. Their websites promise enterprise communication without vendor lock-in, complete with UI screenshots that look just like Slack. Channels, threads, file sharing, integrations. You think: This could work. So you click through the feature lists.

And then you see the “Enterprise” column: SSO integration, LDAP connectivity, compliance exports, clustering. All behind a commercial license. The Community Edition is cut down so far that you can’t run it in production as a company. Not by accident—on purpose. That’s how the business model works. The Community Edition exists so you can try the product. It does not exist so you can run it in production.

What’s frustrating: in other software categories, the open-source world solved this problem long ago. Nextcloud is the best example. A company can install Nextcloud, run it in production, and retain full control over its data. SSO works in the Community Edition. Clustering is possible. There’s a vibrant community evolving the product, plus a commercial support option—but no artificial feature barrier that blocks production use. Enterprise chat is different. There is no Nextcloud for chat. There’s only a storefront with a license cashier.

And that’s the real issue: nothing changes about sovereignty. If you move from Slack to Mattermost Enterprise, you’re swapping the badge, not the dependency. The invoice comes from a different vendor, and someone else still sets the roadmap. That’s not sovereign.

The licensing trap

What shows up in enterprise chat isn’t an isolated case. It’s a business model with its own name: Open Core. The idea sounds reasonable at first: the core of the software is open source; anyone can use it, modify it, and run it. The community benefits, and the company behind it makes money with enterprise features, support, and hosting. That’s the theory.

In practice, it looks different. The Community Edition is deliberately stripped down until it’s useless for professional use. Not because the features are technically hard. But because those features are what make the Enterprise Edition commercially valuable. SSO is the most obvious example, because in virtually every company above a certain size it’s table stakes. If employees can’t log in via centralized identity management, you’re running an isolated solution. And that feature reliably sits behind the license wall.

You see the same pattern with clustering, audit logging, compliance exports. It’s never niche functionality that’s missing. It’s always the features without which you can’t operate the system in production in an enterprise context. That’s not an accidental gap. It’s the architecture of the business model.

And this model isn’t limited to chat software. In 2024, Redis moved from a permissive open-source license to a restrictive one. The Community Edition can do clustering, but without automatic shard management, without multi-tenancy, and without the high availability you need for production. If you need that, you end up on Redis Enterprise. Same open-core pattern—this time in infrastructure. HashiCorp did the same in 2023 with Terraform and Vault. MongoDB went down the same road years earlier. The license you relied on when you adopted the software can change years later, and there’s nothing you can do about it. Then you’re left with a choice: pay, migrate, or accept the risk. None of those options is sovereign.

The problem is not that companies pay for software. Funding good software is right and important. The problem is that “open source” gets used as a promise of independence, while the business model behind it systematically prevents that independence. If you move from Slack to Mattermost Enterprise, you get a new logo on the invoice. The dependency structure is the same.

A protocol, not a product

With Matrix, the situation differs from Mattermost or Rocket.Chat. Matrix is not a company product offering a Community Edition as bait. Matrix is an open standard. The protocol is publicly specified, actively developed, and defines how servers and clients communicate. Anyone can write their own implementation, and existing clients will work with it without changes. Element, Cinny, FluffyChat: all of these clients speak the Matrix protocol and connect to any server that correctly implements the Client-Server API.

That’s a crucial difference. If you build your own Mattermost server, you don’t have clients. If you build your own Matrix server, you instantly have an entire ecosystem of mature clients that just work.

But this is exactly where the problem starts. On the server side, it looks bleak. Synapse, the best-known and most mature implementation, is licensed under AGPLv3. That means: any modification must be published as open source as soon as the server is provided over a network. For companies that need a customized permission model or industry-specific compliance functions, that’s a deal-breaker. Dendrite and Conduit are Apache 2.0 licensed, but neither is production-ready. No real clustering, open performance questions, no enterprise feature set.

The gap is real: there is no Matrix server that combines a permissive license, horizontal scalability, and the features companies and public-sector organizations need. The choice is Synapse with licensing issues, immature alternatives, or Element’s commercial solution—which merely shifts the dependency problem elsewhere.

I’d been thinking this for a while: why doesn’t anyone build it themselves? The protocol is open, the clients exist. What’s missing is the server. But a chat system is complex. Business-critical. Thousands of users depend on it working, administered by two or three admins. In classic software projects, you need a specialized team that knows distributed systems, real-time communication, and cryptography. That’s expensive and hard to justify for a single project. As a one-person show, it’s simply not feasible. Not because the knowledge is unavailable, but because the architecture, implementation, and sheer breadth of technical decisions are too much for one person.

So the thought stayed just that—a thought. Until the conditions changed.

So I’m building it myself

Agentic software development—working with LLM-assisted agents that independently solve sub-tasks—has changed what a single person can accomplish. Not because an LLM writes better code than an experienced developer. But because it reduces conceptual work to a level that used to be unthinkable. What previously required months of architecture work by a specialized team can now be worked out in structured sessions—if you have the right process and can evaluate the results.

What matters is the distinction: this is not vibe coding. Not a one-shot run where you tell an LLM “build me a chat server” and hope something usable comes out. The Matrix community has already lived through that. In January 2026, Cloudflare published a Matrix homeserver on Cloudflare Workers, marketed as “production-grade” with a deploy button. Matthew Hodgson from the Matrix Foundation dismantled the implementation within hours publicly: no state resolution, no permission checks, no real authentication. Hodgson compared it to “a filesystem that ignores permissions, or a blockchain without a consensus mechanism.” The community immediately recognized the typical traits of LLM-generated code: TODO comments in critical security logic, plausible structure without functional depth. Shortly after publication, Cloudflare had to update the post with a disclaimer, reframing it as a proof of concept.

What’s happening here instead is spec-driven development with the BMAD framework: a structured process for agentic product development. A flow that goes from product vision through architectural decisions to epics and implementation plans. The result is not code you accept blindly, but real engineering: a complete Product Requirements Document, a well-considered architecture, clean epics. Produced by a human, supported by agents.

I tried it. Not as an experiment, but with a concrete product vision: a Matrix-compatible enterprise chat server. Apache 2.0. Horizontal clustering. SSO by default. GDPR-ready with audit logs and compliance access. Everything the licensing trap keeps from me, I’ll build myself.

The result is called Nebu. Named after the Nebuchadnezzar from the film The Matrix—the ship that freed people from the Matrix.

Remove complexity wherever possible

The first architectural decision was the most important: implement only the Matrix Client-Server API and skip federation entirely. Federation—the ability for different Matrix servers to communicate—is the most complex part of the protocol. State resolution, server-to-server authentication, key exchange: that’s roughly 40% of the overall complexity. Enterprise deployments run on their own instance anyway. Dropping federation isn’t a compromise; it’s a deliberate decision to drastically reduce complexity. And the key point: all standard clients still work without any changes.

The licensing trap in my own design

Then came the moment that perfectly captured this article’s core thesis. I look at the first blueprint. Redis for session caching, NATS for the internal message bus. Both standard choices, both technically fine. Then I check the licenses. Redis: SSPL since 2024. For production clustering you need a commercial license. I stare at my own design and realize: the licensing trap that brought me to this project in the first place is baked into my first blueprint. And it got worse: if you look at what Element Server Suite Pro uses under the hood, you’ll find Synapse Pro with Redis as a central component for worker communication when scaling horizontally. Redis—under SSPL since 2024. The vendor that’s supposed to free you from Slack dependency builds its solution on a component that is itself caught in the licensing trap.

So: out it goes. Elixir brings everything you’d otherwise need external components like Redis or NATS for. The built-in in-memory store ETS replaces Redis—no network hop, no extra license. Process groups take over the internal message bus. Elixir distribution with TLS connects the cluster nodes. No external dependency, everything in one platform.

I don’t know Elixir in depth myself. But I do know WhatsApp runs on Erlang/OTP, and OTP’s actor model was built for exactly this kind of real-time messaging. With agentic development, I don’t need Elixir expert knowledge. I need the architectural decision that Elixir is the right choice—and the ability to evaluate the results. The agent does the rest.

And this is where an advantage hides in plain sight: because I’m not writing the code myself, the technology choice can be driven purely by the product vision. Elixir is the optimal language for real-time messaging. Go is optimal for HTTP gateways. In a classic project, I’d have to compromise because the team only knows certain languages. Everything would probably end up in Go because the available developers can do Go. That would work—but without the benefits of a language optimized for this exact use case. And even if you pick the optimal stack, you suddenly need Go developers and Elixir developers, which makes the team larger and the project more expensive. With agentic development, that compromise goes away. The best technology for the job wins—not the one that happens to be available on the team.

The result: three components, no proprietary licenses

In the end, there are three runtime components: a Go binary for the API and media gateways; an Elixir/OTP release for core messaging, session management, and presence; PostgreSQL as the database. No Redis. No NATS. All components are Apache 2.0 or BSD licensed. No additional licenses. No dependency chain.

Authentication is OIDC-first. Nebu does not manage passwords. Identity comes exclusively from an external OIDC provider—whether that’s Dex, Keycloak, or Azure AD doesn’t matter. The protocol abstracts the provider. This has a concrete security benefit: no in-house password management eliminates a whole category of vulnerabilities.

On top of that: compliance access with a two-person approval principle and an immutable audit log; cryptographic signatures on every message for message integrity; and full-text search directly via PostgreSQL FTS without an external search component. Everything that elsewhere requires an enterprise license is part of the architecture from day one.

The foundation: twelve Architecture Decision Records, eight development phases, a complete database schema. What it turned into: a Matrix server that works with Element and FluffyChat. SSO via OIDC from the very first instance. docker compose up, ten minutes, running. Audit log and compliance access with two-person approval principle are included without a paywall. Everything under Apache 2.0: github.com/innoq/nebu and https://gitlab.opencode.de/nebu/nebu-server.

The new equation

What Nebu shows is not a one-off. It’s a pattern and this pattern has two variants.

The first is the Nebu variant: there’s an open protocol or open standard, but no usable implementation with a suitable license. In that case, building it yourself is the answer. That sounds like a lot—and it’s not trivial. But you don’t start from scratch. Most of it is handled by proven foundational technologies that remain untouched: Go, Elixir/OTP, PostgreSQL, and all the surrounding infrastructure. The protocol is specified as an open standard and doesn’t need reinventing. The Matrix ecosystem provides finished clients; they work without customization. What remains is the actual server implementation. That’s a substantial project, but not one that requires a team if the process is right.

The second variant applies to far more companies: an open-source solution with a suitable license exists, it’s stable, it covers 90–95% of requirements. But the last 5% are missing. A specific permission model, an integration the vendor doesn’t prioritize, a compliance feature only your industry needs. Until now, the answer was: buy the commercial version or pay an expensive service provider to get up to speed in the repository. The SAP effect: it fits 90% for everyone, but the last 10% are the most expensive because you need an integrator deep enough inside the system to adapt the application to your domain.

Agentic development fundamentally changes that math. Getting up to speed in a foreign repository, understanding the architecture, finding the right extension points—that’s exactly what an agent can do. Not perfectly, not without oversight, but fast and thorough enough to make a fork realistic where it previously wasn’t economically viable. The missing feature that forced you into a buy decision can now be built in-house.

The classic counterargument is maintenance: a fork that drifts from upstream, creates merge conflicts, and ultimately depends on one developer who must never quit. That argument applies to code written directly into the fork. With spec-driven development, you instead produce a specification of your customizations, which an agent reapplies on every upstream update. That’s still a hypothesis—but one Nebu itself will prove.

Both variants lead to the same outcome: the trade-off between “open source, but incomplete” and “complete, but dependent” dissolves. Not for every problem. But for any where the gap between what’s freely available and what you actually need is manageable.

Who benefits? Companies with an in-house IT team that had no real alternative at the last license renewal. Organizations with strict compliance requirements. Public-sector bodies with on-prem mandates. What it takes: a senior developer who can own code, domain, and architecture together; a structured process; and the decision to actually do it.

At the decision-maker level, you can reduce the approach to a simple equation. A Mattermost Enterprise license for 500 users is in the tens of thousands of euros per year; an Element server contract in a similar range; plus integrator costs and ongoing dependency on the vendor’s pricing and roadmap. On the other side are LLM usage costs for the architecture work, the working time of a senior developer, and infrastructure costs for running it yourself. You have to budget staff time when introducing new software in any case, regardless of the alternative. In a greenfield project like Nebu, the LLM costs were in the low hundreds; in a fork that reuses 90% of the architecture, that’s effectively the cap. No annual license renewal where the price goes up because the vendor knows switching costs are higher. No risk that a license change like Redis or HashiCorp can call your infrastructure into question overnight. What remains is an asset the company owns—one that can be developed further internally and whose costs are predictable.

Limits, honestly stated

This approach is not a cure-all, and it shouldn’t be sold as one.

Agent-generated architecture and code must be evaluated by someone who understands the consequences. An architecture can sound plausible and still contain fundamental flaws. Agentic development accelerates execution, not the judgment you need to bring. The Cloudflare disaster shows what happens when that evaluation is missing: plausible-looking code that fails when it matters and a community that loses trust.

Not everything should be built in-house. Kubernetes, PostgreSQL, nginx, Keycloak: for proven infrastructure, there’s no justification for developing your own solutions. The approach works where a real gap exists. Where the gap doesn’t exist, it’s waste.

Operations and maintenance remain your responsibility. Sovereignty also means owning security patches, database migrations, backups, and monitoring. That’s not a downside—it’s the price of control. If you can’t or don’t want to cover that internally, you should assess that honestly before you start.

Self-made sovereignty

The licensing trap works because it rests on an assumption: that “building it yourself” is too expensive, too complex, and too risky. That companies have no choice but to pay or accept it. That assumption was true for a long time. It isn’t anymore.

Agentic software development has changed the equation. Not because it makes developers obsolete, but because it enables a single experienced developer to do what used to require a team: choose the best technology for the job, independent of which languages are available on the team; get up to speed in a foreign repository and implement the missing 5%; or, if necessary, build an entire implementation from scratch because no existing product meets the requirements with the right license.

Nebu shows that this path is viable. Not as a thought experiment, but as an ongoing project: Apache 2.0, three runtime components, no licensing dependencies. Element and FluffyChat connect. [github.com/nebu] — a project that would not exist as a one-person show without agentic development.

Any company staring at a feature matrix today and looking at the locked “Enterprise” column now has a new option. Not “live with it” or “pay for it.” But: build it yourself. The tools are here. The processes are proven. The barrier is lower than ever. If you have a product vision and someone who can evaluate it, you have everything you need today to turn a dependency into your own solution.

Digital sovereignty used to be a resource problem. Today it’s a decision. I made mine.

Glossary

Agentic software development — Software development with LLM-assisted agents that independently solve multi-step tasks: writing code, analyzing repositories, running tests. Unlike a single prompt, agents work in structured, iterative processes under human guidance.

BMAD framework — A framework for structured agentic product development, developed by the BMAD community (bmad-method.org). BMAD systematically moves from product vision to architectural decisions to implementation-ready epics.

Spec-Driven Development (SDD) — A development approach where requirements and changes are expressed as a formal specification before an agent turns them into code. Unlike unstructured code generation, SDD focuses on specification before implementation, making the process traceable and repeatable when needed.

Open Core — A business model where the core of a software product is published as open source, while business-critical features are placed behind a commercial license.

License types in this article — Permissive licenses (Apache 2.0, BSD, MIT) allow free use and modification, including commercially. AGPL (Affero GPL) is a copyleft license that requires source-code publication when provided over a network. SSPL (Server Side Public License) and BSL (Business Source License) are restrictive licenses that limit commercial use and are used in the article as examples of license changes.

Matrix protocol — An open standard for decentralized, encrypted real-time communication. The protocol specifies how servers and clients interact. Anyone can write their own implementation, and existing clients like Element, Cinny, or FluffyChat work with any standards-compliant server.

Federation — The ability of Matrix servers to communicate across servers. Similar to email, users on different servers can exchange messages. Technically, it’s the most complex part of the protocol.

OIDC (OpenID Connect) — An authentication standard that delegates identity verification to an external provider. In practice: login via the existing corporate identity provider instead of in-house passwords.

Elixir/OTP — A programming language and platform running on the Erlang VM. OTP (Open Telecom Platform) provides built-in tools for concurrent, fault-tolerant, distributed systems. WhatsApp uses the same platform for large-scale real-time messaging.

ETS (Erlang Term Storage) — An in-memory data store built into the Erlang/OTP platform. In Nebu, ETS replaces the external Redis component for session caching and temporary data.

Sources

TAGS