Ein Smartphone kann dir gehören und trotzdem den Interessen anderer dienen. Du hast es bezahlt, hältst es in der Hand und darfst über Kratzer und Hülle entscheiden. Aber wer entscheidet über Updates, vorinstallierte Dienste, Datenerfassung, Bootloader und Lebensdauer?
Genau deshalb ist die neue Formulierung auf der postmarketOS-Webseite stark: nicht bloß „Full Control“, sondern „Regain Control“ – Kontrolle zurückgewinnen. Der Satz erkennt an, dass Kontrolle längst verteilt wurde: an Hersteller, Plattformen, Werbenetzwerke und geschlossene App-Ökosysteme.
Kontrolle besteht aus mehreren Ebenen. Quellcode muss prüfbar sein. Software muss verändert und ersetzt werden können. Daten und Dienste müssen exportierbar sein. Und es braucht einen Rückweg, wenn eine Änderung scheitert.
Open Source garantiert das nicht automatisch. Ein öffentliches Repository kann schlecht dokumentiert, ungetestet oder verlassen sein. Aber offener Code schafft die Voraussetzung dafür, dass Aussagen überprüft, Probleme gemeinsam bearbeitet und Arbeiten von anderen fortgesetzt werden können.
Für mein Fairphone FP4 wird das konkret. Reparierbare Hardware ist ein starkes Stück Souveränität. Doch ein austauschbarer Akku allein reicht nicht, wenn die Software zum Endpunkt wird. Umgekehrt hält ein freier Kernel kein Gerät am Leben, dessen Display oder Akku nicht ersetzt werden kann. Langlebigkeit braucht beides: reparierbare Hardware und langfristig pflegbare Software.
Ein weiterer aktueller Änderungsvorschlag für die postmarketOS-Startseite schärft den Abschnitt „Connecting Projects and People“. Die Kernaussage: postmarketOS baut nicht alles selbst neu. Das Projekt verwendet vorhandene freie Arbeit, verbessert sie und gibt Änderungen möglichst an Linux, Bibliotheken, Dienste und Anwendungen zurück.
Das ist keine Schwäche. Souveränität bedeutet nicht, jedes Rad allein neu zu erfinden. Sie bedeutet, gemeinsame Grundlagen prüfen, beeinflussen und notfalls ersetzen zu können.
Eine Momentaufnahme der offenen Arbeiten im pmaports-Projekt vom 25. Juli 2026 zeigt, wie breit diese Zusammenarbeit ist:
Diese Liste ist keine fertige Funktionszusage. Ein „Draft“ ist ein Entwurf. „Request for test“ verlangt praktische Prüfung. Eine bestandene Pipeline bestätigt nur die definierten automatischen Tests. „Merged“ bedeutet, dass eine Änderung in einen Zweig übernommen wurde – nicht, dass sie auf jeder Hardware zuverlässig funktioniert.
Gerade diese Unterschiede machen das Projekt glaubwürdig. Eine rote Pipeline kann mehr Vertrauen schaffen als eine grüne Werbebroschüre, wenn sie ein Problem vor der Auslieferung sichtbar macht.
Bei mobilen Linux-Systemen schauen Nutzer zuerst auf Gerätebilder und Funktionslisten. Dahinter steht eine weniger sichtbare Frage: Wer reagiert, wenn sich Kernel, Compiler, Oberfläche oder Hardwareunterstützung verändern?
In der aktuellen Arbeitsliste stehen technische Änderungen und Zuständigkeitswechsel nebeneinander. Für den PinePhone Pro werden sowohl ein neuer Kernelstand als auch Maintainer-Anpassungen vorgeschlagen. Für Xiaomi beryllium möchte jemand die Pflege übernehmen. Andere Änderungen warten ausdrücklich auf Maintainer-Review.
Das ist entscheidend. Ein neuer Kernel ohne Menschen, die Fehlerberichte einordnen und reale Geräte testen, ist kein nachhaltiger Fortschritt.
Auch Archivierung gehört zu ehrlicher Pflege. Ein archivierter Port wird nicht automatisch wertlos oder gelöscht. Das Projekt kennzeichnet jedoch, dass aktuelle Verantwortung fehlt. Neue Maintainer können ihn später wiederbeleben. Eine kürzere, ehrliche Geräteliste ist besser als eine lange Liste technischer Versprechen ohne belastbare Pflege.
Lange Gerätenutzung entsteht nicht durch einen grünen Aufkleber. Sie entsteht durch kleine, fortlaufende Arbeiten:
Jede Änderung wirkt klein. Zusammen entscheiden sie darüber, ob ein Gerät nur theoretisch startet oder im Alltag benutzbar bleibt.
Dasselbe gilt beim Selbsthosting. Ein Matrix-Homeserver bleibt nicht souverän, weil Synapse einmal installiert wurde. Datenbankmigrationen, Backups, Medien, Zertifikate, .well-known, Nginx und Zugangstokens benötigen dauerhafte Pflege. Ein offener Bauplan ersetzt keine Instandhaltung.
postmarketOS ist keine fertige Lösung für jeden Menschen und jedes Gerät. Kamera, Modem, Energiemanagement, Bankanwendungen und Sicherheitsanforderungen müssen konkret geprüft werden. Ein Fairphone FP4 mit mobilem Linux ist nicht automatisch alltagstauglich, nur weil das Ziel richtig ist.
Doch das Projekt zeigt, wie digitale Souveränität praktisch aussehen kann: Arbeit wird sichtbar. Zuständigkeiten werden öffentlich. Grenzen werden benannt. Verbesserungen fließen in gemeinsame Projekte zurück.
Die entscheidende Frage lautet deshalb nicht nur: „Ist der Code offen?“
Wir sollten fragen:
Kontrolle zurückzugewinnen heißt nicht, alles allein zu machen. Es heißt, gemeinsam genutzte Technik prüfen, verändern und notfalls verlassen zu können.
Diskussion: https://treff.darknight-coffee.eu
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/
Wenn dir das Projekt hilft: Spendenlinks sind im Blog.
