Openness Needs an Operating System

A personal reflection on what open educational infrastructures could look like — and why “open” does not mean that everyone has to do everything on their own.

When we talk about digital educational infrastructure, we quickly fall into familiar oppositions. Open or closed. Public or private. Platform or fragmentation. Centralized or federal. Linux or Apple.

I believe these oppositions are misleading. At least if we genuinely want digital education to work not only in strategy papers, but in everyday practice: for schools, teachers, learners, states, municipalities, providers, and civil society actors.

For me, openness is not a romantic idea of completely unregulated freedom. Openness does not mean that every school has to understand every interface by itself, assess every application by itself, negotiate every contract by itself, and operate every integration by itself. That would not be openness. That would be overload.

At the same time, educational infrastructure must not become a black box. Not a closed system in which a few institutions decide who may participate, which rules apply, and which forms of innovation become visible at all. When public money flows into digital educational infrastructure, the result has to be more than a single product, a single portal, or a single service. It has to create shared digital foundations.

That is why I strongly support the principle of Public Money, Public Code. What is publicly funded should, wherever possible, be publicly usable, inspectable, reusable, and further developable. Because in the end, everyone benefits.

But in the context of educational infrastructure, Public Money, Public Code is actually still too narrow. This is not only about code. It is about reusable infrastructure, open standards, transparent processes, shared operational knowledge, and governance that does not hide restrictions, but makes them visible and accountable.

Why “operating system” is a better metaphor than “platform” #

In educational digitalization, we often talk about platforms, clouds, or digital learning spaces. These terms are not wrong, but they carry baggage. A platform quickly sounds like a marketplace, a portal, or a monopoly. A cloud sounds like storage and data centers. A learning space sounds ambitious, but also rather abstract.

I find the operating-system metaphor more useful.

An operating system is not the application I use to write, calculate, learn, or communicate. It is the layer underneath. It manages identity, rights, data, security, interfaces, and basic services. Ideally, it stays in the background. The applications shine — not the operating system.

That is how we should think about educational infrastructure: not as yet another portal that wants to replace everything else, but as a federal educational operating system. A shared layer that reliably provides things that every app, every state, every municipality, and every school should not have to reinvent.

This includes identity and login. Entitlements and licenses. Assessment processes for data protection, security, accessibility, interoperability, and AI criteria. Standards for data and interfaces. And increasingly also AI services that are not implemented somewhere inside each individual application, but become available as a vetted, data-minimizing, and reliable system layer.

This perspective changes the debate. It is no longer about whether “the one platform” should be able to do everything. It is about which basic services and infrastructures a publicly accountable digital education system needs so that many different applications, contents, and pedagogical approaches can build on top of it.

Ideally, the infrastructure does not take center stage #

A good educational operating system would ideally be barely noticeable.

A teacher logs in with a school account and can use the services they are entitled to use. Learners find purchased or authorized content where learning actually happens — not only in the portal or with the provider where a license was once acquired. Providers do not have to build 16 plus x different integrations, submit 16 different sets of evidence, and maintain 16 different technical special cases. States and school authorities do not have to clarify from scratch every single time whether a service is compliant with data protection, secure, accessible, and interoperable.

Log in once (VIDIS). Carry rights and licenses cleanly across services (LicenceConnect). Assess transparently once instead of again and again (eduCheck digital). Make media and offers discoverable (SODIX). Do not lock learning and usage data into each individual app (AIS). Do not let AI grow as shadow infrastructure, but think of it as a controlled system service.

This is not the opposite of openness. It is a precondition for making openness practically usable.

Because without such shared services, openness often exists only on paper. There may be many offerings, but each one requires its own accounts, its own contracts, its own assessments, its own interfaces, its own data models, and its own support channels. The result is not diversity, but fragmentation.

Openness does not mean: no rules #

Perhaps the most important point is this: open infrastructure needs rules.

At first, this sounds paradoxical. Especially those who care about open systems, open source, and Public Code often react strongly against access requirements, assessment procedures, and curation. I understand that. Curation can become gatekeeping. Assessment procedures can slow down innovation. Standards can be written in ways that only large providers can realistically meet. Governance can concentrate power.

But the alternative is not automatically better. Without shared rules, there are individual arrangements. Without standards, there are special cases. Without assessment procedures, responsibility shifts to individual schools, school authorities, or teachers. Without shared infrastructure, providers keep rebuilding the same basic functions again and again: login, roles, rights, licensing logic, data protection processes, AI integration, monitoring, interfaces.

That is expensive, error-prone, and unfair. Large actors can cope with it. Small providers, open projects, civil society initiatives, and schools often cannot.

The decisive question is therefore not whether there are rules. The decisive question is what kind of rules they are.

Are they transparent? Are they proportionate? Can they be discussed publicly? Can different actors help shape them? Are there open reference implementations? Can components be replaced, forked, inspected, and further developed? Are there clear pathways for new providers, open-source projects, and non-commercial initiatives?

If yes — and that has to be the goal — then rules are not a barrier. They are the infrastructure on which a market and an ecosystem can emerge in the first place.

If no, curation becomes gatekeeping. And that is exactly what we have to guard against.

Public Money, Public Code — but understood more broadly #

Public Money, Public Code is often first understood as a software principle: when the state funds software, the source code should be open so that others can inspect, use, improve, and adapt it.

That remains central. Especially in education, where trust, data protection, security, and long-term availability matter so much, public code is not a nice-to-have. It is a prerequisite for digital sovereignty. But when it comes to educational infrastructure, we should think about reuse more broadly.

First: code reuse. Publicly funded software components should be openly licensed wherever possible. Not every line of code automatically becomes a community project. But openness creates the possibility to inspect security, find bugs, reduce dependencies, and share further development. Especially where public bodies solve similar problems, closed code is often simply inefficient.

Second: infrastructure reuse. It is not enough for code to be theoretically open if operating it is so specific, expensive, or undocumented that no one can realistically reuse it. Open educational infrastructure needs operable components, documentation, deployment paths, interface descriptions, test environments, and clear responsibilities. Reuse also means that other states, municipalities, institutes, or projects can build on something without starting from zero. Even beyond the school sector itself.

Third: standards and process reuse. Sometimes the most important part is not the code, but the jointly developed procedure: assessment criteria, role models, data protection templates, contractual modules, metadata profiles, interface conventions. If every state has to repeat the same legal, organizational, or semantic clarification, we waste public energy. Ideally, this also works across state and national borders.

Fourth: knowledge reuse. Experiences from operations, support, accessibility, data protection, security, and pedagogical practice should flow back into the system. Open infrastructure is not just a Git repository. It is a learning commons.

This is especially important in a federal system. Federal does not have to mean that everyone builds everything separately. Federal can also mean: we share foundations so that diversity becomes possible above those foundations.

Standards are not enough — but without standards, it does not work #

An operating system lives from stable interfaces. The same is true for education.

Technical standards such as OpenID Connect, xAPI, or LTI are important. But technology is only one layer. Systems also have to fit together semantically: What does a learning event mean? How do we describe competencies? Which metadata do educational media need? Which terms do we use collectively?

Then comes the organizational layer: Who assesses what? Which processes apply? Which roles do states, school authorities, providers, and schools have? And finally, the legal layer: data protection, data processing agreements, contracts, responsibilities.

Only when these layers work together does real interoperability emerge. A standards document alone does not create an open ecosystem. A system becomes open when others can reliably build on it.

This is also where many digitalization debates become too technical. Of course we need APIs. Of course we need interfaces. Of course we need standards. But if the legal clarification is missing, if processes are unclear, if metadata is understood differently, or if no one is responsible for operations, then even the most elegant interface will not help much.

Open standards need governance. And governance, in turn, needs openness.

Do not gloss over the question of power #

Whoever builds and operates infrastructure exercises power.

This is true for private platforms just as much as for public infrastructure. Whoever manages identity decides on access. Whoever defines assessment criteria decides on market entry. Whoever sets data models helps determine which pedagogical practices become visible and interoperable. Whoever operates AI gateways helps decide which models, safeguards, and usage patterns are possible.

This power does not disappear because we call it “infrastructure.” It only becomes less visible.

That is why the governance question is central: Who sets the rules? Who controls those who set the rules? How are schools, states, providers, open-source communities, data protection experts, researchers, and civil society involved? How are criteria updated? How can one object? How are wrong decisions corrected? How do we prevent well-intentioned curation from structurally favoring large actors?

A federal educational operating system must limit its own power. It needs open interfaces, public documentation, comprehensible criteria, independent review, participation by those who will later work with it, and real opportunities for reuse.

The benchmark should be: Does this infrastructure lower the barriers for good offerings? Does it make access easier for schools? Does it make data protection and security the default? Does it enable smaller and open projects to participate? Does it reduce duplicate work? Does it give learners and institutions more control over data?

If the answer is yes, then it is not curating against openness, but for openness.

AI makes the infrastructure question more urgent #

With the growing use of AI, educational infrastructure is no longer only a matter of login and licenses.

If every application builds its own AI integration, new dependencies, new data protection risks, new opacity, and new inequalities emerge. Schools and school authorities would then have to clarify for each individual solution: Which data flows where? Which models are used? Is user data used for training? Which safeguards apply? How are costs controlled? How are outputs logged, reviewed, or pedagogically embedded? For smaller EdTech providers in particular, this can be challenging.

A shared AI layer could provide relief: with pseudonymization, clear contracts, monitoring, guardrails, billing, access to models, and standardized interfaces for applications. Not every educational app has to build its own AI infrastructure. It can rely on vetted system services. Economically, this may also make sense through economies of scale.

But here, too, the same principle applies: precisely because such a layer is powerful, it has to be designed openly and accountably. AI in and as educational infrastructure must not become a new black box.

Linux or Apple? #

In the end, the tension remains.

A purely open system, imagined like Linux in the best sense, enables maximum freedom, forkability, and innovation from the edges. But it often shifts the burden of integration, security, and support to those with the least capacity to carry it.

A strongly curated system, imagined like Apple in the best sense, offers reliability, comfort, and data protection by default. But it creates dependency and raises the question of power: Who controls the curator?

For education, neither image is sufficient on its own.

A federal educational operating system has to be open enough for public investments to become shared foundations. It has to be curated enough so that schools do not drown in complexity. It has to be stable enough for providers to invest. And it has to be transparent enough so that this stability does not turn into closure.

The real question is therefore not: open or curated?

The question is: How much curation does openness need in order to become effective in everyday school life — and how much openness does curation need in order to remain legitimate?

My answer would be: quite a lot of both.

But only if we design it deliberately. With open standards. With public code wherever possible. With reusable infrastructure. With shared governance. With clear rights to data. With transparent assessment procedures. And with the goal of not building the next big portal, but the foundations on which many good things can emerge.

Openness, then, is not a state one decides on once. It is an ongoing design task.