1 — Zusammenfassung
Die Erstellungskosten von Software sind kollabiert. Was vor wenigen Jahren ein finanziertes Team gebraucht hätte, entsteht heute in einer Werkstatt — und damit verschiebt sich die entscheidende Frage von „Können wir das bauen?“ zu „Für wen, und zu welchen Bedingungen?“.
Die eingeübte Antwort auf diese Frage lautet: Risikokapital, Werbefinanzierung, Datenverwertung. Sie war nie eine Aussage über Software, sondern eine über deren Ökonomie. Wer die Erstellung vorfinanzieren muss, braucht jemanden, der die Rechnung bezahlt — und am Ende zahlt sie die Nutzerin, mit Aufmerksamkeit, Daten oder Abhängigkeit. Genau diese Vorfinanzierung fällt gerade weg.
mana ist der Versuch, das praktisch durchzuspielen, statt darüber zu schreiben: ein gemeinnütziger Schweizer Verein, der zum Selbstkostenpreis baut und betreibt — ohne Investoren, ohne Werbung, ohne Datenverwertung, mit offenem Code, eigener Hardware und einer Abrechnung, die im Beleg steht statt im Quartalsbericht.
Fünf Zahlen, an denen sich die Lage festmachen lässt:
| 91 % | der Deutschen misstrauen US-Tech-Firmen im Umgang mit ihren persönlichen Daten (84 % EU-weit) [1] |
| €264 Mrd. | ökonomischer Drain pro Jahr durch die europäische Abhängigkeit von US-Software und -Cloud [2] |
| 65 % | des europäischen Public-Cloud-Marktes liegen bei drei US-Konzernen [3] |
| ~280× | ist der Preis für ein einmal erreichtes KI-Leistungsniveau in zwei Jahren gefallen [4] |
| 8 % → 1,7 % | ist der Abstand zwischen den besten offenen und den besten geschlossenen KI-Modellen binnen eines Jahres geschrumpft [4] |
Die ersten drei Zahlen sagen, warum eine Alternative gebraucht wird. Die letzten beiden sagen, warum eine kleine Organisation sie heute liefern kann.
Und was daraus bisher geworden ist: 149 Dienste laufen produktiv auf Vereins-Infrastruktur — 81 Anwendungen, 24 Plattform-Dienste, dazu Datenbanken, GPU-Dienste und statische Seiten (Stand 28. Juli 2026). Betrieben werden sie von einer Werkstatt, deren Hardware in Tägerwilen steht, nicht in einem Rechenzentrum.
Dieses Papier legt in vier Teilen dar: die Lage, die das nötig macht (Kapitel 2–3), die Ökonomie, die es möglich macht (Kapitel 4–5), das Modell, das daraus folgt (Kapitel 6–8), und den Stand dessen, was davon steht (Kapitel 9–11). Kapitel 11 ist die Liste dessen, was noch nicht funktioniert — sie gehört genauso dazu wie der Rest.
2 — Das Bündel
Software gibt Menschen Fähigkeiten. Das klingt banal, ist aber der präziseste Weg, über sie zu reden. Eine App ist selten interessant, weil sie eine App ist; sie ist interessant, weil danach jemand etwas kann, was er vorher nicht konnte.
Lesestoff aus dem Netz sammeln und in Ruhe lesen, statt ihn im Vorbeiscrollen zu verlieren. Das gesprochene Wort festhalten, sodass aus einem Gespräch Text wird. Sehen, was in der eigenen Region passiert — über jede Verwaltungsgrenze hinweg, weil Menschen nicht in Verwaltungsgrenzen leben. Eine Pflanze über Jahre beobachten und den Verlauf behalten. Für sich genommen ist jede dieser Fähigkeiten klein. Zusammen sind sie der Werkzeugkasten, mit dem ein digitaler Alltag bestritten wird.
Das Besondere an diesen Fähigkeiten ist nicht die Fähigkeit selbst. Die meisten gibt es irgendwo schon, oft in guter Ausführung. Das Besondere ist, woran sie bisher hing.
Wer Lesestoff sammeln wollte, bekam die Fähigkeit von einem Dienst, der von Verweildauer lebt — und dessen Sortierung deshalb nie neutral sein kann, weil eine neutrale Sortierung sein Geschäftsmodell beschädigen würde. Wer gesprochenes Wort transkribieren wollte, gab es an einen Anbieter, dessen Geschäftsmodell den Inhalt mitliest, oder zahlte ein Abonnement an ein Unternehmen mit Renditeerwartung. Wer wissen wollte, was in der Region passiert, landete auf einer Plattform, die Reichweite verkauft, und sah deshalb, was bezahlt wurde, nicht, was stattfindet.
Die Fähigkeit war nie allein zu haben. Sie kam im Bündel mit einer Abhängigkeit — und die Abhängigkeit war nicht der Preis für die Technik, sondern der Preis für ihre Finanzierung. Jemand hatte die Entwicklung vorgestreckt und wollte sie zurück, mit Zins. Weil die Nutzerin nicht genug zahlen konnte oder wollte, zahlte sie anders: mit Aufmerksamkeit, mit Daten, mit dem Verlust der Möglichkeit, wegzugehen.
Das ist das Bündel. Und die These dieses Papiers ist, dass es sich auflösen lässt — nicht durch bessere Absichten, sondern weil der Grund für seine Existenz wegfällt.
mana löst es so auf: dieselbe Fähigkeit, getragen von einem gemeinnützigen Verein, zum Selbstkostenpreis. Kein Werbekunde, dessen Interesse gegen das der Nutzerin steht. Kein Investor, dessen Rendite in jeder Produktentscheidung mitwiegt. Kein Anbieter, der morgen die Bedingungen ändert, weil er sie ändern kann. Der Code liegt offen, die Daten liegen auf Hardware des Vereins, und was eine Aktion kostet, steht im Beleg.
Damit ist die Frage, die dieses Papier stellt, nicht: Ist diese App besser? Sondern: Muss die Fähigkeit weiterhin an der Abhängigkeit hängen?
Der Rest des Papiers beantwortet diese Frage in zwei Schritten. Erst, warum die Frage dringend ist (Kapitel 3). Dann, warum sie sich überhaupt stellen lässt — warum eine Organisation ohne Kapitalgeber heute Software liefern kann, für die es vor fünf Jahren Kapital gebraucht hätte (Kapitel 4).
6 — Souveränität in Stufen
Unabhängigkeit ist kein Zustand, den man erklärt, sondern eine Schicht nach der anderen. Der Verein ordnet das in Stufen — und die Stufen-Einteilung ist zugleich die Stelle, an der sich prüfen lässt, ob ein Papier wie dieses ehrlich ist. Deshalb steht bei jeder Stufe, wo wir tatsächlich stehen.
Stufe 1 — unabhängige Erstellung. Erreicht. Code, Architektur und Produktentscheidungen liegen beim Verein. Keine Auftraggeber, die mitbestimmen, keine Investoren, keine Anteilseigner.
Stufe 2 — unabhängiger Betrieb. Im Aufbau. Hosting, Wartung und Pflege laufen auf eigener Hardware in eigener Verantwortung: ein Mac Mini in Tägerwilen als Hauptserver, eine GPU-Workstation für KI-Inferenz, eigener Objektspeicher. Kein Cloud-Anbieter, der uns kündigen oder über Nacht die Preise drehen kann; keine Managed-Datenbank, die wir nur als Lieferantenbeziehung kennen. Der Umbau ist nicht fertig: Reste geerbter Cloud-Anbindungen aus der Zeit vor dem Verein werden noch abgelöst.
Stufe 3 und darüber — Leitbild, nicht Roadmap. Eigene Modelle statt nur angebundener fremder, eigene Hardware-Pfade, perspektivisch ein dezentrales Netz aus Rechenleistung, die Mitglieder und befreundete Organisationen beisteuern und die der Verein zu einem föderierten Cluster bündelt. Daraus folgten zwei Eigenschaften, die ein einzelner Server nie erreichen kann: Ausfallsicherheit durch Verteilung, und föderiertes Training, bei dem jeder Knoten auf seinen Daten lernt und nur Gewichte geteilt werden.
Der letzte Absatz steht im Konjunktiv, und das ist Absicht. Diese Stufe ist ausgearbeitet, aber nicht gebaut. Ein Papier, das sie im Präsens beschriebe, wäre bei der ersten Nachfrage unglaubwürdig — und alles andere darin mit.
6.3 Der Sonderfall: die Entwicklung selbst
Es gibt eine fünfte Abhängigkeit, und sie ist die unbequemste.
Der Verein ist infrastrukturell weitgehend unabhängig. Gebaut wird heute allerdings mit einem KI-Werkzeug eines US-Anbieters. Das ist genau die Art von Abhängigkeit, die dieses Papier kritisiert, und sie sitzt an der empfindlichsten Stelle — nicht im Betrieb, sondern in der Herstellung.
Wir schreiben das hier hin, statt es in einer Fußnote zu erwähnen, weil ein Text über Souveränität, der seine eigene größte Abhängigkeit kleinschreibt, genau dort angreifbar ist, wo er stark sein will. Der Ablöse-Pfad ist ausgearbeitet und stufenweise angelegt: offene Terminal-Agenten als Werkzeugschicht, offene Coding-Modelle als Modellschicht, beides über den eigenen LLM-Dienst angebunden. Kapitel 4 erklärt, warum dieser Weg überhaupt gangbar geworden ist — der Rückstand offener Modelle liegt bei etwa drei Monaten, nicht mehr bei einem Jahr. Er ist aber noch nicht gegangen.
11 — Offene Punkte
Dieses Kapitel ist nicht das Kleingedruckte. Es ist der Grund, warum der Rest glaubwürdig sein kann.
11.1 Die eigene größte Abhängigkeit
Die Entwicklung selbst läuft heute über ein KI-Werkzeug und Modelle eines US-Anbieters (siehe 6.3). Der Ablöse-Pfad auf offene Werkzeuge und offene Modelle ist ausgearbeitet und stufenweise angelegt, aber noch nicht gegangen. Bis dahin gilt: infrastrukturell weitgehend unabhängig, in der Herstellung nicht.
11.4 Was dieses Papier nicht belegt
- Reichweite. Siehe 9.4.
- Die Kostenseite. Siehe 7.4.
- Die drei Vorbehalte aus 4.4 gelten unverändert: Der Frontier-Preis fällt nicht, die Produktivitätswirkung von KI bei erfahrenen Fachleuten ist umstritten, und die offene Modell-Spitze kommt fast vollständig aus China.
- Die Quellenhärte zweier Indizes aus Kapitel 3.1: Beim DSI ist das Eigeninteresse des Herausgebers zu berücksichtigen, beim EDRIX das unklare Trägerinstitut.
Wer eine dieser Lücken für gravierend hält, hat recht. Sie stehen hier, damit man darüber reden kann, statt sie zu finden.
A — Quellen
- Cluster17 für POLITICO / beBartlet, European Pulse, Feldzeit 13.–21. März 2026, n = 6.698 (ES, DE, FR, IT, PL, BE).
- Asterès, Studie zum ökonomischen Effekt der Abhängigkeit von US-Software und -Cloud; sekundär referenziert über Atlantic Council und CNBC.
- Europäische Kommission, Strengthening Europe's Tech Sovereignty (digital-strategy.ec.europa.eu); Marktanteilsangaben mehrfach belegt.
- Stanford HAI, AI Index Report 2025.
- European Digital Resilience Index (EDRIX) 2025, edrix.eu.
- Nextcloud GmbH, Digital Sovereignty Index, 7. August 2025.
- Edelman Trust Institute, Trust Barometer 2026, Feldzeit 25.10.–16.11.2025, n ≈ 34.000.
- Epoch AI, Kosten- und Fähigkeits-Zeitreihen; Epoch Capabilities Index, Oktober 2025.
- a16z, LLMflation (Wagniskapitalgeber — Eigeninteresse beachten).
- METR, Zeithorizont-Messungen 2025/2026.
- Scale AI, SWE-bench Pro, September 2025.
- METR, randomisierter Kontrollversuch zur Entwickler-Produktivität, Juli 2025.
Die vollständigen Quellenverzeichnisse mit Methodik, Feldzeiten und Vorbehalten werden in zwei internen Lageberichten geführt, die als Datenquelle dieses Papiers dienen und bei Änderungen dort zuerst aktualisiert werden.
10.3 Andockpunkte
Wer mitmachen will, kann das auf vier Wegen:
- Mitglied werden. Fördernd, aktiv oder als Betreiberin eines Rechenknotens.
- Beauftragen. Gemeinnützige Organisationen, Gemeinden und Vereine mit konkretem Software-Bedarf. Der Code bleibt beim Verein und kommt anderen zugute — das schlägt sich im Preis nieder.
- Beitragen. Code, Übersetzungen, Inhalte, Fehlerberichte, Rechenleistung.
- Nachbauen. Siehe 10.1. Rückfragen sind ausdrücklich willkommen; ein nachgebautes Modell ist der bessere Beleg als ein zitiertes.