Local-First-Software (2019)

• Local-First-Software ist ein Ansatz, der die Vorteile cloudbasierter Zusammenarbeit und persönlicher Dateneigentümerschaft zugleich verwirklichen soll
• Bestehende Cloud-Apps sind zwar stark bei Echtzeit-Zusammenarbeit und Zugänglichkeit, verursachen aber Probleme bei Dateneigentum und langfristigem Zugriff
• Local-First-Software betrachtet lokalen Speicher als primären Ort der Datenablage und bietet Synchronisation sowie Kollaborationsfunktionen ergänzend an
• Solche Software bietet Vorteile bei Geschwindigkeit, Offline-Unterstützung, Privatsphäre und Nutzerkontrolle, bringt aber auch Umsetzungsaufwand etwa bei Echtzeit-Kollaboration oder geräteübergreifender Synchronisation mit sich
• Um Local-First-Software zu realisieren, werden verschiedene bestehende Technologiemodelle verglichen und analysiert; zugleich wird ausgelotet, ob sich künftig noch idealere Modelle entwickeln lassen

---

Grenzen von Cloud-Apps und Dateneigentum

• Die meisten Nutzer verwenden verschiedene Cloud-Apps wie Google Docs, Figma oder Slack für Dokumente, Design, Zusammenarbeit und viele weitere Zwecke
• Auf diese Dienste wird per Browser oder mobiler App zugegriffen, und meist werden die Daten auf Servern gespeichert
• Cloudbasierte Software bietet Vorteile bei Zusammenarbeit und ortsunabhängigem Datenzugriff, doch je mehr Zeit man in eine App investiert, desto größer wird der Wert der darin enthaltenen Daten
• Interviews mit Fachleuten zeigen, dass hinter den funktionalen Vorteilen von Cloud-Apps auch schwerwiegende Nachteile wie Verlust von Eigentum und Unsicherheit beim langfristigen Zugriff stehen
• Weil das Recht der Nutzer eingeschränkt ist, selbst erstellte Materialien und Daten zu bewahren und zu besitzen, entstehen sowohl psychologische Unsicherheit als auch reale Risiken

Was echter Datenbesitz bedeutet

• Daten, die in der Cloud gespeichert sind, wirken zwar wie „die eigenen“, doch die tatsächliche Kontrolle über Verwaltung und Zugriff liegt beim Cloud-Anbieter
• Wird ein Dienst eingestellt oder fällt ein Server aus, kann dies zu fehlendem Datenzugriff und Schwierigkeiten bei der langfristigen Datenerhaltung führen
• Im Kern geht es nicht um tatsächliche geistige Eigentumsrechte, sondern um das vom Nutzer empfundene Besitzgefühl und die Kontrolle über Daten
• Ältere Anwendungen mit lokalem Speicherfokus wie Texteditoren, Versionsverwaltung und diverse Werkzeuge garantieren vollständiges Dateneigentum und Autonomie

Vergleich der Vor- und Nachteile von Cloud und lokal

• „Cloud-App = Zusammenarbeit und Zugänglichkeit“, „lokale App = Eigentum und Autonomie“
• Es braucht keinen Entweder-oder-Ansatz, sondern die Suche nach der bestmöglichen Kombination beider Welten
• Dateneigentum und Echtzeit-Kollaboration stehen nicht zwangsläufig im Widerspruch; es ist möglich, ein Softwaremodell zu entwerfen, das beides erreicht
• Dies wird als Local-First-Software definiert, mit einer Grundstruktur aus lokalem Speicher, Netzwerken und ergänzenden Servern

Die 7 Ideale von Local-First-Software

• Bei Cloud-Apps fungiert der Server als „Masterkopie“ der Daten, wodurch jede Anfrage einen Hin- und Rückweg zum Server benötigt und Verzögerungen im Nutzererlebnis entstehen
• Local-First-Software behandelt dagegen die Kopie im lokalen Speicher als primäre Datenversion; die Synchronisation (über Server) erfolgt nachgelagert
• Dieser Perspektivwechsel bringt konkrete Vorteile bei Reaktionsgeschwindigkeit, Offline-Unterstützung und Datenkontrolle

1. Geschwindigkeit (hohe Reaktionsfähigkeit)

• Local-First-Apps verarbeiten alle Vorgänge im lokalen Dateisystem, wodurch ohne Wartezeit auf Serveranfragen eine unmittelbare Reaktionsfähigkeit erreicht werden kann
• Die Synchronisation wird unauffällig im Hintergrund ausgeführt, sodass das Nutzererlebnis zu keinem Zeitpunkt unterbrochen wird

2. Synchronisation über mehrere Geräte hinweg

• Moderne Nutzer arbeiten auf mehreren Geräten, daher ist auch für Local-First-Apps die Datensynchronisation zwischen Geräten unverzichtbar
• Synchronisation auf Dateiebene ist für einzelne Nutzer einfach, bei gleichzeitigem Bearbeiten durch mehrere Personen entstehen jedoch Konflikte

3. Offline-First

• Local-First-Software ermöglicht es, Daten jederzeit offline zu erstellen und zu bearbeiten; sobald die Netzwerkverbindung zurückkehrt, wird automatisch synchronisiert
• Der Austausch und die Synchronisation zwischen Geräten sind auf verschiedene Arten möglich, etwa über Bluetooth oder lokales Wi‑Fi
• Für echte Offline-Unterstützung werden lokal installierbare ausführbare Programme bevorzugt

4. Zusammenarbeit und Konfliktmanagement

• Herkömmliche Ansätze wie E-Mail-Anhänge oder Versionsverwaltungstools sind unpraktisch, wenn mehrere Personen gleichzeitig an derselben Datei arbeiten, weil Konflikte und manuelles Zusammenführen auftreten
• Cloud-Apps wie Google Docs verringern durch Echtzeit-Ko-Bearbeitung die Hürden und Konflikte der Zusammenarbeit
• Auch Local-First-Software kann Echtzeit-Zusammenarbeit sowie verschiedene Workflows wie Änderungsvorschläge und Freigaben ermöglichen, was ein wichtiges technisches Entwicklungsfeld ist

5. Langfristige Bewahrung von Daten

• Mit Local-First-Apps bleibt der Zugriff auf Daten auch dann gewährleistet, wenn der Softwarehersteller verschwindet
• Gängige Dateiformate wie Text, PDF oder JPEG können langfristig kompatibel bleiben; selbst bei inkompatiblen Formaten ist der Zugriff über virtuelle Maschinen oder Emulatoren möglich
• Ohne echte langfristige Datenerhaltung könnte das Problem eines digitalen dunklen Zeitalters Realität werden, in dem künftige Generationen heutige Daten weder lesen noch interpretieren können

6. Privatsphäre und Sicherheit

• Zentralisierte Cloud-Strukturen sind anfällig für verschiedene Sicherheitsvorfälle wie Hacks oder Missbrauch durch interne Mitarbeiter
• Wer mit personenbezogenen oder sensiblen Daten arbeitet, kann in einer Local-First-Architektur durch Ende-zu-Ende-Verschlüsselung Sicherheit und Datenunabhängigkeit erreichen
• Große Unternehmen wie Google können Daten intern auf vielfältige Weise nutzen, während Local-First-Software die Kontrolle den Dateneigentümern überlässt

7. Eigentum und Kontrolle der Nutzer

• Cloud-Dienstanbieter können den Datenzugriff willkürlich sperren oder einschränken, etwa durch fehlerhafte automatische Markierungen oder geänderte Richtlinien
• In einer Local-First-Umgebung entscheiden die Nutzer selbst über Nutzung, Änderung, Backup und Aufbewahrung ihrer Daten
• Es geht dabei nicht nur um juristisches Urheberrecht, sondern um die tatsächliche Autonomie und Datenkontrolle der Nutzer

Vergleich verschiedener Softwaremodelle

• E-Mail-Anhänge + lokale Dateien: stark bei Geschwindigkeit, Offline, langfristiger Bewahrung und Kontrolle, aber unpraktisch bei Zusammenarbeit und Gerätesynchronisation
• Cloud-Web-Apps (Google Docs, Trello usw.): stark bei Echtzeit-Kollaboration und Zugänglichkeit, aber schwach bei Geschwindigkeit, Offline, Eigentum und Privatsphäre
• Dateisynchronisationsdienste (Dropbox usw.): stark bei Geschwindigkeit, Offline, langfristiger Bewahrung und Kontrolle, aber mit Grenzen bei Zusammenarbeit und mobiler Nutzung
• Versionsverwaltungssysteme (Git usw.): stark bei Geschwindigkeit, Offline, langfristiger Bewahrung und Kontrolle, aber schwach bei Nicht-Textdateien und Echtzeit-Kollaboration
• Mobile Clients (Firebase, CloudKit usw.): stark bei Synchronisation und Offline, jedoch mit Grenzen bei personenbezogenen Daten, Privatsphäre und langfristigem Fortbestand des Dienstes
• Multi-Master-Replikation (DB, z. B. CouchDB): stark bei Offline und Synchronisation, aber schwer oder nur unzureichend bei Zusammenarbeit, Privatsphäre und Kontrolle im angestrebten Ideal

Perspektive von Softwareentwicklern und künftige Richtung

• Ideale Local-First-Software muss Offline-Betrieb, geräteübergreifende Synchronisation, Echtzeit-Kollaboration, Privatsphäre und Nutzerkontrolle von Anfang an entwerfen und implementieren
• In der Praxis gibt es jedoch noch keine offene Technologie, die all diese Ideale gleichzeitig erfüllt
• Neue Technologien aus aktueller Forschung in der Informatik, etwa Conflict-free Replicated Data Types (CRDTs) und verteilte Datensynchronisationsverfahren, könnten die entscheidende Grundlage für künftige Local-First-Software bilden

Fazit

• Local-First-Software ist eine wichtige Richtung, um Zusammenarbeit und Unabhängigkeit, Privatsphäre und Datensouveränität im digitalen Zeitalter ins Gleichgewicht zu bringen
• Sie vermittelt Fachleuten, Kreativen und anderen ein Gefühl von Eigentum an ihren Daten und langfristigem Schutz und könnte branchenübergreifend positive Veränderungen anstoßen
• Künftig braucht es weitere Forschung und Experimente zu besserer Infrastruktur, Entwicklungstools, Architekturen und Algorithmen, die diese Ideale verwirklichen

[GN⁺]

Hacker-News-Kommentare

• Das trifft bei mir hundertprozentig einen Nerv. Ich entwickle ebenfalls an einer Lösung für genau dieses Problem und bin es leid, meine Daten in die Cloud zu stecken und dann nur noch Abogebühren zu zahlen. Ich arbeite gerade an einer Fitness-Tracking-App und plane, das Sublime-Modell anzuwenden: einmal kaufen, dann einige Jahre Updates erhalten, Synchronisierung über alle Geräte hinweg und lebenslang nutzbar. Wenn man danach weitere Updates will, reicht es, die neue Version erneut zu kaufen. Das Ziel ist eine ausreichend hohe Qualität, sodass man sie auch einfach dauerhaft in diesem Zustand weiterverwenden kann. Für 90 % aller Software wünsche ich mir dieses Modell. Sie sollte zu einem fairen Preis kaufbar sein, das Produkt selbst muss gut sein, und wichtig ist eine Struktur, in der es auch ohne Cloud-Anbindung richtig funktioniert. Es geht nicht nur um Datenschutz, dieses Modell hat viele Vorteile. Es gibt noch offene Aufgaben wie Tooling, aber die technische Grundlage ist ausreichend vorhanden. Der größte Vorteil von Local-first-Software ist eine gesunde Incentive-Struktur. Es ist kein Modell, das auf Werbung, User-Tracking oder die Maximierung von „Engagement“ setzt, sondern eines, bei dem man für das Produkt selbst belohnt wird. Es fühlt sich wie wirklich nutzerzentrierte Software an.

  • Auch das Modell der Notiz-App Obsidian ist ein wirklich gutes Vorbild. Der Client ist kostenlos, der Sync-Service wird optional verkauft. Ein großer Vorteil ist, dass die Notizen Markdown-Dateien sind und man den Client daher nicht zwingend braucht.

  • Mich würde interessieren, wie die Synchronisierung ohne Cloud-Infrastruktur geplant ist.

  • Stimme voll zu. Wenn es okay ist, würde mich auch der Tech-Stack der Fitness-Tracking-App interessieren, besonders wie die geräteübergreifende Synchronisierung gelöst wird.

  • Es gibt viele reine lokale Apps, die sich über Werbung finanzieren, daher gilt „ohne Werbung“ nicht immer.

• In Berlin läuft gerade sehr aktiv die von Ink and Switch veranstaltete Local-first Software Conference (https://www.localfirstconf.com/), und dieses Jahr ist im November in San Francisco sogar noch die Sync Conf (https://syncconf.dev/) dazugekommen. Auf den jüngsten Konferenzen gab es auch Panel-Diskussionen mit den Co-Autoren des Papers selbst, was sehr hilfreich war, weil sie darüber gesprochen haben, was sie im Kontext von Entwickler-Tools für Local-first-Software gelernt haben. Das Video der Panel-Diskussion ist sehr zu empfehlen. In der Community setzt sich gerade „Sync“ als Kernelement von Local-first durch, und der Trend geht dahin, dass Dev-Tools wie Sync-Engines nur Unterstützungswerkzeuge für die technischen Eigenschaften von Local-first sind, aber nicht selbst Local-first. Eine Sammlung der Vorträge der letzten Jahre wurde auch hier hochgeladen. An Werkzeugen zur Unterstützung von Echtzeit- und asynchroner Zusammenarbeit wird derzeit intensiv gearbeitet, und mit dem Aufkommen von AI entsteht ein Marktumfeld, in dem solche Sync-Engines immer notwendiger werden. AI-Apps sind ihrem Wesen nach Multiuser-Kollaborationsumgebungen, daher leben wir in einer Zeit, in der die technische Grundlage der Sync-Engine-Community gebraucht wird.

• Zu diesem Thema gab es auch früher schon sehr lebhafte Diskussionen, es lohnt sich also, sie zu lesen, wenn man neugierig ist: 2019-05, 191 Kommentare
  2019-11, 241 Kommentare
  2020-07, 9 Kommentare
  2020-08, 134 Kommentare
  2021-02, 90 Kommentare
  2022-06, 30 Kommentare
  2023-10, 50 Kommentare

• Es wird argumentiert, dass nicht jede App ihre eigene Sync-Plattform haben muss. Dieser Trend scheint aus der für mobile Apps typischen Schwierigkeit entstanden zu sein, Programme miteinander zu kombinieren und zu modularisieren. Wenn man wirklich Local-first will, sollte man einfach das Dateisystem verwenden. Aus Nutzersicht kann man dann selbst aus verschiedenen bestehenden Lösungen wie Git oder Box wählen. Schon der Anmeldeprozess für die Sync-Lösung jeder einzelnen App ist ähnlich undurchsichtig und fehleranfällig wie SaaS selbst, was belastend ist.

  • Ich stimme zu, dass nicht jede App eine Sync-Engine braucht, aber ich halte das Dateisystem nicht für die Universallösung für Local-first. Dafür gibt es zwei Gründe. Der erste ist Concurrency. Wenn man nur wirklich strikt Local-first will, kann man irgendein Sync-System verwenden, aber ich möchte mehr als das. Zum Beispiel will ich die Erfahrung, dass meine Frau und ich beide auf unseren jeweiligen Handys unabhängig Änderungen vornehmen können, selbst wenn die Verbindung unterbrochen ist, und dass das alles automatisch sauber zusammengeführt wird. Ich wünsche mir eine wirklich natürliche Synchronisierung wie bei DropBox. Zweitens muss die Sync-Engine Datenstrukturen und ihre Bedeutung tief verstehen, um ein besseres Sync-Erlebnis umzusetzen. Git oder Box haben gegenüber diesem Wunsch nach semantischer Gleichzeitigkeit beim Bearbeiten diverse Grenzen.

  • Ich habe tatsächlich einen Ansatz implementiert, der nur das Dateisystem nutzt, aber es war schwierig, zwischen Clients zu koordinieren, wann Dateibearbeitung erlaubt sein sollte, sodass Konflikte letztlich unvermeidlich waren.

• Systeme mit Online-Abhängigkeit bringen zwangsläufig Wartungs- und Betriebskosten mit sich. Ohne ein Local-first- oder Local-only-Design gibt es keine langfristig vertrauenswürdigen Systeme. Vernetzte Haushaltsgeräte und Autos sind aus praktischer Sicht wirklich Beispiele für dumme Ingenieursarbeit.

  • Hinter all dem steckt letztlich das Abo-Geschäft. Unternehmen mit Abo-Modell erzielen mehr Umsatz, bekommen leichter Investitionen und gewinnen dadurch am Markt. Genau deshalb ist Local-first-Software verschwunden.

• Ich bin eher kritisch gegenüber der Sichtweise, Probleme der Cloud-Zuverlässigkeit technisch lösen zu wollen, also durch das Vermeiden zentralisierter Strukturen. Früher hat man die Probleme mangelnder Kontrolle und mangelnden Vertrauens bei Closed-Source-Software über Geschäftsmodelle gelöst, etwa durch Open-Source-Entwicklung oder Wartungsverträge. Ich behaupte, dass auch Cloud-Probleme solche geschäftsmodellbezogenen Lösungen brauchen. Man könnte zum Beispiel Standardverträge oder -lizenzen schaffen, in denen die Rechte der Nutzer festgelegt sind, und den Markt dahin lenken, nur Anbieter zu wählen, die solche zertifizierten Lizenzen umsetzen. Man könnte viele Klauseln hinzufügen: garantierte Datenportabilität, transparente Offenlegung der Datennutzung, klar definierte Verfahren bei Einstellung des Dienstes und so weiter. Natürlich ist das größte Hindernis die Frage, warum Anbieter so etwas überhaupt akzeptieren sollten. Aus Angst vor Kundenabwanderung könnten Anbieter bei solchen Lizenzen nur Jahresabos erlauben oder zusätzliche Gebühren verlangen.

  • Wenn sich geschäftliche oder politische Probleme technisch lösen lassen, halte ich das eher für den robusteren Weg. Denn so kann man gegensätzliche Interessen technisch von vornherein blockieren. Ein typisches Beispiel ist Verschlüsselung auf Client-Seite. Sich auf Datenschutzrichtlinien oder bürokratische Regeln zu verlassen, ist schwierig, weil die Versuchung zu groß ist und Überwachung wie Durchsetzung schwer sind. Wenn Daten mathematisch so verschlüsselt sind, dass sie auf dem Server nicht lesbar sind, verschwindet diese Sorge. Wenn der Server die Daten aber tatsächlich verarbeiten soll, landet man letztlich in einer Situation, in der man wirklich den eigenen Server nutzen muss.

  • Selbst wenn man das Problem per Vertrag für den Fall der Einstellung eines Dienstes löst und der Cloud-Anbieter bei einer Schließung Bescheid gibt und einen Datenexport ermöglicht, bleibt am Ende oft nur eine riesige JSON-Datei übrig. Wenn man nicht selbst eine App baut oder jemand anderes eine baut, ist das faktisch nutzlos. Die Absicht ist gut, aber es bleibt hinter einer lokalen App zurück, die die Daten einer ausgelaufenen Anwendung langfristig weiter nutzbar macht.

  • Auch eine Klausel zur garantierten Datenportabilität hilft nur begrenzt, weil echte groß angelegte Datenmigrationen in der Praxis schwierig sind und lange dauern. In Krisensituationen unter Zeitdruck wird es eher noch chaotischer. Selbst zwischen Open-Source-Datenbanken derselben Version ist das wegen dienstspezifischer Unterschiede nicht einfach. Am Ende ist es eine realistische Alternative, die Daten von Anfang an in der eigenen Umgebung zu halten und sie bei Bedarf zu „unpluggen“. Denkbar ist eine Kombination aus BYOC (Bring Your Own Cloud) und Open Source. Unser Unternehmen betreibt selbst ein BYOC-Datenprodukt, daher habe ich erfahren, dass diese Struktur tatsächlich machbar ist.

  • Selbst wenn man im Vertrag Verantwortlichkeiten für den Fall einer Cloud-Abschaltung festschreibt, ist nicht wirklich klar, wie man das in dem Moment tatsächlich durchsetzen und verwalten soll, wenn die Geschäftsaufgabe beschlossen wird.

  • Es geht nicht nur um Geschäftsfragen, sondern auch um Datensicherheit selbst. Der Hauptgrund, Abo- oder Cloud-Modelle zu meiden, ist für mich der Wunsch, meine Daten zu schützen. Daten, die ohne lokale Verschlüsselung übertragen werden, können letztlich jederzeit kompromittiert werden.

• Beim Lesen dieses Beitrags fühlte sich vieles erfrischend an. Ich finde, mehr Apps sollten Local-first werden. Wenn Nutzer keine Cloud-Synchronisierung wollen, muss diese Option unbedingt gewährleistet sein. Auch Brisqi (https://brisqi.com), das ich entwickle, basiert auf dieser Offline-first-Philosophie. Eine Local-first-App bedeutet im Grunde eine Struktur, die offline unbegrenzt vollständig funktioniert. Die Offline-Erfahrung ist der Standard, Cloud-Sync ist nur eine zusätzliche Verbesserung. Apps, die auf temporären Caches basieren, kann man nicht als Offline-first bezeichnen. Die Daten werden in einer lokalen Datenbank gespeichert, und echtes Offline-first bedeutet, dass die Daten unabhängig vom Internet erhalten bleiben. Die meisten Apps, die sich „Offline-first“ nennen, sind eher nur offline-tolerant, also mit begrenzter Offline-Unterstützung. Eine echte Offline-first-App zu bauen ist viel schwieriger als eine reine Online-Web-App. Man braucht unbedingt einen Mechanismus, der auch bei Übergängen zwischen Offline und Online zuverlässig synchronisiert, ohne Datenverlust. Wie ich das umgesetzt habe, steht im Blog (https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...).

• Diese Prinzipien ergeben auch dann Sinn, wenn man sich auf den Verbrauchermarkt konzentriert. Wir entwickeln derzeit bei Sentinel Devices (www.sentineldevices.com) eine Struktur für Industrieumgebungen wie SCADA und industrielle Automatisierung, in denen Daten niemals nach außen gelangen dürfen und Ausführung, Analyse und Entscheidungsfindung vollständig lokal auf der eigenen Hardware stattfinden. Wir bieten überhaupt keinen externen Server an. Diese Konzentration auf On-Device-Prinzipien ist für Kunden wie Anbieter gleichermaßen fast schon ein gedanklicher Befreiungsschlag. Viele Daten- und AI-Unternehmen ignorieren diesen Markt, weil es tatsächlich sehr schwierig ist, ihre Dienste direkt vor Ort beim Kunden bereitzustellen. Bei uns kommt es dagegen oft vor, dass Kunden es erst verstehen, wenn wir No-Connectivity und vollständig lokale Verarbeitung ausdrücklich hervorheben. Wenn sich im Consumer-Bereich mehr Vertrautheit mit Local-first entwickelt, könnte sich auch der Industriebereich schneller verändern.

  • Selbst die SCADA-Branche drängt in letzter Zeit komplett in die Cloud. Mit Slogans wie: „Steuern Sie Ihre Fabrik vom Smartphone aus.“ Aber damit wächst auch die Gefahr, dass sogar einfachen Hobby-Hackern die Kontrolle über Fabriken geöffnet wird.

  • Das Feld ist äußerst interessant, und ich unterstütze eure Arbeit. Eine Sache interessiert mich aber: Auf der Karriereseite steht, dass ausschließlich vor Ort eingestellt wird. Liegt das daran, dass Local-first-Entwicklung tatsächlich Arbeit ohne Remote erfordert, oder ist das eher ein Management-Thema?

• Auch meine Projekte (selfhostblocks, skarabox) wollen auf Basis von NixOS Self-Hosting für alle einfach machen. Deklarativ wird nahezu alles bereitgestellt: https, SSO, LDAP, Backups, ZFS-Snapshots und fast alles andere. Man kann die meisten Daten etwa in Vaultwarden oder Nextcloud speichern, und auch Dienste wie Home Assistant sind enthalten. Es ist eine Konkurrenz zu YUNoHost, aber mit besseren Zielen. SelfHostBlocks besteht aus mehreren Paket-Bausteinen, sodass jeder es frei erweitern und selbst hosten kann. Es ist eher ein Bibliotheksansatz als ein Framework. Es ist auch eine Alternative zu NAS, vollständig Open Source. Für Leute mit technischem Wissen mag es einfach sein, aber das Ziel ist, die Hürde so weit zu senken, dass auch normale Nutzer es auf Hardware installieren können, ohne sich mit nix oder der CLI auszukennen.

  • Solche Projekte unterstütze ich wirklich sehr. Es gibt unglaublich viele beeindruckende FOSS-Alternativen, aber faktisch lassen sie sich nur für Techniker leicht installieren, etwa auf dem Niveau von „docker compose up“, und für normale Nutzer bleibt das eine Hürde. Viele selbst hostbare Apps sind als Web-App + DB + Server + Frontend aufgebaut, aber in meinem Fall nutze ich sie faktisch nur auf einem einzigen Gerät. Ein vollständig lokales Desktop-Programm wäre genug, aber selbst das ist für Nicht-Entwickler praktisch unerreichbar. Zwischen qualitativ hochwertiger selbst hostbarer FOSS und tatsächlichen Nutzern besteht eindeutig ein Missverhältnis. Es braucht mehr Projekte, die genau diese Lücke schließen. Ich werde selfhostblocks auch ausprobieren und wünsche dem Projekt viel Erfolg.

  • Es ist großartig, dass hledger enthalten ist. Für Einsteiger in Plaintext-Buchhaltung ist es vielleicht etwas ungewohnt, aber es ist wirklich hervorragende Software.

  • Danke, dass ihr das so sauber gebaut habt.

• Beim Überfliegen des Artikels hatte ich den Eindruck, dass die meisten Kernpunkte zwar angesprochen werden, aber die Motivation im ersten Absatz etwas schwach wirkt. Es liest sich ein wenig wie: „Apfelkuchen ist lecker und nahrhaft, aber irgendwann könnte er plötzlich abbrennen und dabei sogar mein geliebtes Lätzchen verschwinden lassen.“