AppFlowy: Flutter-Oberfläche, Rust-Kern und AGPLv3 als Notion-Alternative
AppFlowy ist ein KI-gestützter kollaborativer Arbeitsbereich und Open-Source-Alternative zu Notion für Projekte, Wikis und Notizen, mit Flutter und Rust gebaut und selbst hostbar.
Auf einen Blick
- Was ist das?
- AppFlowy ist ein in Flutter und Rust geschriebener Arbeitsbereich für Projekte, Wikis und Teams mit KI-Funktionen. Das Projekt steht unter AGPLv3, erscheint weiterhin in 0.x-Versionen und liefert einen Self-Hosting-Weg samt Kollaborations-Infrastruktur.
- Für wen ist es gedacht?
- AppFlowy passt zu Teams und Einzelpersonen, die einen Notion-ähnlichen Arbeitsbereich selbst betreiben wollen und bereit sind, eine Software in der 0.x-Phase einzusetzen. Es passt nicht zu Organisationen, die eine Netzwerkanwendung auf Basis von AppFlowy anbieten wollen, ohne ihren eigenen Quellcode offenzulegen; die AGPLv3 verlangt genau das bei Netzwerknutzung.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 6 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Dart, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was AppFlowy sein will: Flutter, Rust und drei Leitwerte
AppFlowy ist ein Arbeitsbereich, der Projekte, Wikis und Teams an einer Stelle zusammenführen soll, laut Repository-Beschreibung mit KI-Unterstützung und ohne Kontrollverlust über die eigenen Daten. Die Positionierung ist aus dem README klar ablesbar: Es nennt AppFlowy eine quelloffene Alternative zu Notion. Technisch besteht das Projekt aus zwei Teilen, einer Oberfläche in Flutter und einem Kern in Rust; als Hauptsprache des Repositories ist Dart eingetragen.
Diese Zweiteilung erklärt den Anspruch. Flutter liefert eine Codebasis für mehrere Plattformen, Rust übernimmt die Teile, bei denen es auf Speichersicherheit und Geschwindigkeit ankommt. Das README formuliert daraus drei Werte: Datenschutz zuerst, verlässliche native Erfahrung und gemeinschaftsgetriebene Erweiterbarkeit.
Ehrlicher als die meisten Projektbeschreibungen ist der Abschnitt zur Motivation. Das README schreibt offen, dass man Notion im Funktionsumfang und im Design nicht übertreffen wolle, jedenfalls derzeit nicht, und dass mehr Funktionalität nicht die Priorität sei. Stattdessen gehe es um Bausteine, mit denen andere eigene Anwendungen bauen können. Wer AppFlowy als fertigen Notion-Ersatz erwartet, liest hier eine Absage.
AppFlowy installieren: Releases, FlatHub, Snapcraft, App Store, Play Store
Für Anwender listet das README mehrere Bezugswege. Die Desktop-Fassungen für macOS, Windows und Linux liegen auf der Releaseseite des Repositories. Daneben werden FlatHub unter der Kennung io.appflowy.AppFlowy, Snapcraft und Sourceforge genannt.
Bei Mobilgeräten gibt es eine Einschränkung, die in der Praxis zählt: Im Play Store wird Android 10 oder neuer vorausgesetzt, und ARMv7 wird ausdrücklich nicht unterstützt. Ältere oder schmale Geräte fallen damit heraus. Für iPhone existiert ein Eintrag im App Store.
Wer nicht auf die fertigen Pakete angewiesen ist, findet zwei dokumentierte Wege. Für den Eigenbetrieb verweist das README auf eine Schritt-für-Schritt-Anleitung unter dem Titel Step-by-step Self-Hosting Guide, und für den Bau aus dem Quellcode gibt es eine eigene Dokumentationsseite unter docs.appflowy.io. Beide Wege liegen außerhalb des README, der Einstieg führt also über die Projektdokumentation.
Zum Entwicklungsstart verweist das README ebenfalls auf die Dokumentation, und zwar auf betriebssystemspezifische Anleitungen. Konkrete Befehle für den Bau nennt das README nicht. Das ist vertretbar, weil Flutter-Toolchains sich zwischen den Plattformen stark unterscheiden, verlagert aber die erste Hürde in die Dokumentation.
Self-Hosting und die Kollaborations-Infrastruktur bei AppFlowy
Der Punkt, an dem sich AppFlowy von einem reinen Notizprogramm unterscheidet, ist die Selbsthosting-Option. Das README verweist auf eine Anleitung, die den Weg von null bis zum Produktivbetrieb beschreiben soll. Damit ist klar, dass zu AppFlowy mehr gehört als eine Desktop-Anwendung: Ein gemeinsames Bearbeiten mehrerer Personen braucht eine Instanz, die Sitzungen und Daten vermittelt.
Das README umreißt diese Schicht mit dem Begriff Kollaborations-Infrastrukturdienste und richtet sich damit ausdrücklich an Unternehmen und Bastler, die darauf eigene Anwendungen aufbauen wollen. Diese Ansprache ist der eigentliche Kern der Mission, nicht der fertige Arbeitsbereich.
Für die Evaluierung folgt daraus eine konkrete Frage: Was genau selbst betrieben wird und welche Teile der KI-Funktionen dabei an externe Dienste gehen, muss in der Self-Hosting-Anleitung nachgelesen werden. Das README selbst nennt dazu keine Einzelheiten, keine Ports, keine Konfigurationsschlüssel und keine Systemanforderungen. Wer eine Entscheidung über den Eigenbetrieb trifft, sollte die Anleitung vollständig lesen, bevor er Ressourcen einplant.
Übersetzungen unter /frontend/resources/translations und inlang
Ein Abschnitt des README, der in Projekten dieser Größe oft fehlt, beschreibt den Übersetzungsweg. Es gibt drei Varianten. Man kann die JSON-Dateien unter /frontend/resources/translations unmittelbar bearbeiten, man kann den Online-Editor von inlang über die Projektadresse nutzen, oder man ergänzt fehlende Texte mit `npx inlang machine translate`.
Die dritte Variante ist aufschlussreich, weil sie Maschinenübersetzung als regulären Weg nennt. Für ein Projekt mit einer großen Oberfläche ist das praktisch, heißt aber auch, dass die Qualität einzelner Sprachfassungen schwanken kann und niemand jede Zeile gegenliest. Wer AppFlowy in einer bestimmten Sprache einsetzt, sollte die betroffenen Dateien prüfen, statt auf Vollständigkeit zu vertrauen.
Zur Mitarbeit verweist das README auf einen Beitragsleitfaden und stellt Vorlagen für Funktionswünsche und Fehlermeldungen bereit. Die Planung liegt offen: Es gibt eine Roadmap in der Dokumentation sowie ein öffentliches Projektboard auf GitHub. Wer wissen will, ob ein bestimmter Baustein kommt, findet dort mehr als im README.
AGPLv3 bei AppFlowy und was die Netzwerklausel bedeutet
AppFlowy ist unter AGPLv3 lizenziert, die Lizenzdatei liegt im Repository. Diese Wahl hat für ein Projekt mit Serverkomponente eine unmittelbare Folge: Die AGPL behandelt Nutzung über ein Netzwerk als Verbreitung. Wer also eine angepasste Fassung von AppFlowy betreibt und sie Dritten über das Netz zugänglich macht, muss den Quellcode dieser Fassung bereitstellen.
Für einen Endanwender, der AppFlowy einfach benutzt, ändert sich nichts. Für ein Unternehmen, das AppFlowy als Grundlage eines eigenen Dienstes einsetzt, ist es die entscheidende Frage, und sie lässt sich nicht mit einem Hinweis auf die AGPL abschließen: Welche Pflichten im Einzelfall entstehen, hängt daran, was genau verändert und wie der Dienst angeboten wird. Das README beschränkt sich auf den Hinweis auf die Lizenzdatei und gibt keine Auskunft zu dieser Einordnung.
Dass das Repository unter AGPLv3 steht und nicht unter einer permissiveren Lizenz, passt zur im README betonten Priorität von Datenschutz und Eigenbetrieb. Die andere Seite der Medaille ist die Bindung: Eine kommerzielle Weiterverwertung ohne Offenlegung ist bei dieser Lizenz nicht vorgesehen.
Stand der Versionen und Notion als Vergleichspunkt
Im Material verzeichnete Veröffentlichungen sind 0.13.1 vom 9. August 2026, 0.13.2 vom 11. August 2026 und 0.14.0 vom 28. August 2026. Drei Veröffentlichungen innerhalb eines Monats sprechen für ein sehr aktives Projekt. Die führende Null spricht eine andere Sprache: Es gibt keine 1.0, und damit keine Zusage, dass sich Schnittstellen oder Datenformate zwischen Nebenversionen nicht ändern. Für den produktiven Einsatz sollte man deshalb ein Update-Fenster einplanen und prüfen, ob ein Sprung von 0.13 auf 0.14 bestehende Daten unangetastet lässt.
Der Vergleich mit Notion ist im README selbst angelegt. Notion ist ein gehosteter Dienst mit geschlossener Codebasis; die Daten liegen dort beim Anbieter, und Anpassungen sind auf das beschränkt, was die Plattform zulässt. AppFlowy bietet Quellcode, eine selbst betreibbare Instanz und eine einheitliche Codebasis für mehrere Plattformen, verlangt dafür den Betrieb und akzeptiert laut README einen geringeren Funktionsumfang. Das ist kein Nachteil per se, sondern ein Tausch: Kontrolle gegen Bequemlichkeit.
Wer zwischen beiden wählt, sollte die Frage nicht nach dem Funktionskatalog entscheiden, sondern danach, wo die Daten liegen dürfen und wer den Betrieb übernimmt. Für eine Einzelperson, die lediglich Notizen ordnen will, ist der gehostete Dienst weniger Arbeit. Für ein Team mit Vorgaben zum Datenstandort ist AppFlowy die diskutierbare Option.
Redaktionelles Fazit
AppFlowy passt zu Teams und Einzelpersonen, die einen Notion-ähnlichen Arbeitsbereich selbst betreiben wollen und bereit sind, eine Software in der 0.x-Phase einzusetzen. Es passt nicht zu Organisationen, die eine Netzwerkanwendung auf Basis von AppFlowy anbieten wollen, ohne ihren eigenen Quellcode offenzulegen; die AGPLv3 verlangt genau das bei Netzwerknutzung. Wer den Umstieg prüft, sollte drei Punkte zuerst klären: ob die eigenen Plattformen abgedeckt sind, denn Android setzt Version 10 voraus und ARMv7 wird nicht unterstützt, ob der Self-Hosting-Weg die eigene Kollaborations-Infrastruktur einschließt, und ob die im README genannten KI-Funktionen mit dem eigenen Datenschutzkonzept vereinbar sind. Danach lohnt ein Blick in die Roadmap unter docs.appflowy.io, weil sich dort ablesen lässt, welche Bausteine noch fehlen.
Community-Notizen