In my previous post I argued that Kitaplus, the Kita management software our daycare board chose, is a good product built on a smart business model. The company behind it understood that deep domain expertise in a regulated niche is a durable competitive advantage, and they packaged that expertise into something useful. I still think that's true. However, in this post I want to look at the same facts from a slightly different angle.

The UX nobody cares to fix

KiBiz.web is not good software. I want to be precise about this: not in a subjective or aesthetic sense, but in terms of basic usability. Opening a new tab can log you out. The browser back button does not work reliably. Core browser conventions that have been standard for twenty-five years are simply broken.

This is the result of a procurement model that removes quality incentives once the contract is signed. A requirements document is written, a tender is won, and the system is built and delivered. The contract then covers maintenance and ongoing operation. From that point, the vendor is paid to keep the system running and incorporate mandatory legal changes. There is no market pressure. The users, Jugendamt staff across NRW, have no choice in the matter. The buying organisation has limited technical capacity to evaluate ongoing quality. The next procurement cycle is years away.

The comparison that makes this concrete: the same company, facing actual market competition from Kita operators who can and do switch providers, built Kitaplus. It's a substantially better product by any measure, built by the same company, with the same technical capability, but a different incentive structure.

The conflict behind the moat

In the previous post I described the vendor's position as a moat: operating KiBiz.web gives them knowledge advantages that competitors cannot easily replicate. That framing was about the business logic. The same position, seen from a public interest perspective, is a conflict of interest.

The vendor builds and operates the public infrastructure. The same vendor sells the product that Kitas need precisely because that infrastructure is painful to work with directly. The LWL almost certainly knows this. Kitaplus is not a secret product. But knowing about a conflict of interest and having meaningful leverage over it are different things.

A better, more open, more accessible KiBiz.web would reduce the friction that creates at least some of the value of Kitaplus. There is no conspiracy required to explain why that improvement does not happen.

The gated knowledge we all paid for

Let's say the LWL decided tomorrow to put KiBiz.web out to tender again. Suppose the outgoing vendor was contractually required to hand over the full documentation and source code. Peter Naur's classic paper Programming as Theory Building tells us why this would still not be enough.

Naur argued that the most important knowledge about a software system is not the code or the documentation. It's the mental model held by the people who built and evolved the system over time: the understanding of why particular decisions were made, what edge cases were discovered and how they were handled, which parts of the specification turned out to be wrong and what replaced them in practice. This knowledge is not written down because it cannot be written down fully. It lives in the team.

The knowledge embedded in KiBiz.web after years of development and operation was produced with public money. In a formal sense it belongs to the public through contractual arrangements. In every practical sense it belongs to the company. Open-sourcing the codebase would not change this. A new team receiving that codebase would spend years reconstructing what the current team already knows implicitly.

This is not a problem unique to KiBiz.web. It is the predictable outcome of outsourcing not just the initial development of public software but its sustained operation and evolution to external vendors. Over time, the public hand loses not only the knowledge but the capacity to evaluate what it has lost.

Sovereignty is not about the flag

The focus of the digital sovereignty debate in Germany and Europe has been the dependency on US hyperscalers. Of course, that's a legitimate concern. But it has also drawn attention away from a problem closer to home: dependency on domestic private vendors for public software that nobody else is in a position to maintain.

A German Mittelstand company holding a practical knowledge monopoly over critical public infrastructure is not obviously preferable to an American one. Sovereignty is not only a question of where a company is registered or how large it is. It's also very much a question of who holds the theory of the program, and whether the public institutions that commissioned and paid for that knowledge retain any meaningful capacity to act independently of the vendor who now holds it.

Open source is a necessary part of the answer, but not a sufficient one. Without the internal competence to understand, evaluate and evolve what has been built, access to source code is a formal right with limited practical consequence.

Stefan Tilkov's argument, five years Later

In December 2020, Stefan Tilkov wrote two posts in German on public-sector IT that remain among the clearest statements of this problem I have read. Stefan was the face and voice of INNOQ, and for many of us there an intellectual presence whose absence is still felt.

His core argument was straightforward: the only sustainable path to competent public-sector IT is through permanent, well-paid, motivated internal staff who make the important decisions. External vendors can complement internal capacity, but dependence on them as a substitute for it leads reliably to bad outcomes.

He also addressed the open source question directly. Without the right incentives, he argued, open source produces only what people feel like building. It cannot substitute for institutional competence. The public hand needs people who understand the systems, not just licences that permit access to them.

What has changed since 2020? ZenDiS now exists. The Digitalservice Bund has been doing really good work. There are real attempts underway to build the kind of internal public-sector IT capacity Stefan described. These efforts are encouraging. But they're still modest relative to the scale of the problem, and they're working against decades of procurement culture and institutional habit that runs in the opposite direction.

The KiBiz.web situation is not an outlier. It's the default output of that culture, replicated across hundreds of public software contracts at every level of German administration.

What the kindergarten teaches

We chose Kitaplus because it was the right choice for our Kita, and we would make the same decision again. The conditions that made it the right choice are not conditions anyone designed deliberately. They accumulated through individually reasonable procurement decisions, standard contract structures, and gradual erosion of institutional technical capacity, each step unremarkable on its own.

Digital sovereignty does not begin with hyperscaler contracts or EU cloud policy. It begins with questions like this: who built this system, who operates it today, what do they know that nobody else does, and what would it actually take to change any of that?

The kindergarten, it turns out, is not a bad place to look for lessons about how public digital infrastructure works in practice.