Wenn Sie ein Google Doc teilen, behalten Sie die Schlüssel. Die URL bleibt dieselbe. Sie bearbeiten, der Empfänger sieht Ihre Änderungen. Das Dokument ist ein gemeinsames Objekt mit einem einzigen kanonischen Zustand, und Sie sind sein Hüter. Wenn Sie ein reWritable teilen, sieht die Sache anders aus.
Sie laden Ihre .html-Datei beim Share-Dienst hoch. Der gibt Ihnen eine URL zurück. Sie verschicken sie. Der Empfänger öffnet sie und sieht Ihr Dokument. So weit sieht das nach Teilen aus.
Aber beim Hochladen hat der Server still etwas Entscheidendes getan: Er hat dem Dokument eine neue Identität aufgeprägt. Die veröffentlichte Kopie hat eine andere DOC_UUID als die Datei auf Ihrer Festplatte. Der IndexedDB-Namespace pro Container ist ein anderer. Die Undo-Historie auch. Ein Edit-Log zwischen den beiden gibt es nicht. Die Veröffentlichung ist keine gehostete Ansicht Ihres Dokuments. Sie ist ein Geschwister, geboren im Moment der Veröffentlichung und mit Ihnen nur dem Anschein nach verwandt.
Es gibt keinen PUT-Endpunkt, kein Owner-Token, keinen Pfad, der sagt: „Dieses Share gehört mir, hier ist das Update.“ Das Dokument, das der Empfänger bekommt, ist das Dokument, das Sie hochgeladen haben, unveränderlich ab dem Moment der Veröffentlichung, egal wie lange die URL noch funktioniert.
Was Teilen eigentlich ist
Ich glaube, die meisten Sharing-Oberflächen werfen zwei Dinge zusammen: Dokumente verteilen und eine kanonische Referenz pflegen. Die Cloud-Produktivitätstools haben beides verschmolzen. Die URL ist zugleich der Weg, auf dem das Dokument zu Ihnen kommt, und der Ort, an dem es lebt. Bearbeitet jemand das Dokument, funktioniert die URL weiter, nur das Dokument dahinter ändert sich.
Das funktioniert, weil die URL das Dokument ist. Die Bytes auf Ihrem Bildschirm sind eine gerenderte Ansicht eines Zustands auf einem Server. Sie haben das Dokument nicht, Sie haben ein Fenster darauf.
reWritable geht von einer anderen Festlegung aus. Das Dokument ist die Datei. Die .html-Datei auf Ihrer Festplatte ist keine Ansicht von irgendetwas, sie ist die Sache selbst. Öffnen Sie sie zweimal, bekommen Sie dasselbe Dokument. Schicken Sie sie jemandem, dann hat er sie: vollständig, dauerhaft und unabhängig von Ihnen oder einem Server.
Ein Sharing-Modell, bei dem der Herausgeber das geteilte Dokument weiter bearbeiten könnte, würde das zerstören. Wer die URL am Dienstag öffnet, sähe ein Dokument, und dieselbe URL zeigte am Mittwoch ein anderes. Die eigene Kopie, falls man sie heruntergeladen hat, würde sich von „dem Share“ entfernen, sobald der Herausgeber etwas ändert. Hat man v1 gelesen oder v2? Waren die Bytes, die man mit ⌘S gesichert hat, „das Dokument“ oder nur einer seiner vorübergehenden Zustände?
Das Fork-on-share-Modell umgeht die Frage, indem es die URL gedanklich zum Kurier macht und nicht zur Adresse. Was sie zustellt, ist eine Datei, völlig eigenständig, und sie gehört ab dem Moment ihrer Ankunft dem, der sie öffnet.
Das Read/Write-Web, konsequent zu Ende gedacht
Dieser Ansatz knüpft an einen viel älteren Gedanken an. Der erste Webbrowser, WorldWideWeb, den Tim Berners-Lee 1990 auf einem NeXT-Computer baute, war ein Browser-Editor. Man konnte eine Seite öffnen, Text markieren, ihn mit einem anderen offenen Dokument verlinken und das Ergebnis speichern. Das Web war als Read/Write-Medium gedacht: Jeder Leser war auch Autor, jede Seite ließ sich an Ort und Stelle bearbeiten. Berners-Lee hat im Rückblick klar gesagt, dass jeder, der das Web nutzt, ursprünglich einen Ort zum Schreiben haben sollte, und dass der erste Browser genau deshalb als Editor gebaut wurde.
Gekommen ist stattdessen ein Verteilmedium, in dem vor allem gelesen wird und die Autorschaft bei Spezialisten und Plattformen liegt. Die Cloud-Produktivität hat später einen Teil der Schreibbarkeit zurückgeholt (Google Docs, Notion, Figma), aber zu anderen Bedingungen. Das Dokument zog von Ihrem Rechner in die Datenbank eines anderen um. Die URL ersetzte die Datei. Teilen wurde zu „Zugriff auf einen Datensatz gewähren, den ich kontrolliere“. Bearbeiten wurde zu etwas, das auf einem Server passiert und davon abhängt, dass der Server weiter mitspielt.
Ein Detail aus dem ursprünglichen WorldWideWeb-Editor sagt in dieser Hinsicht viel. Bearbeiten und Speichern schrieb im Browser von 1990 ins lokale Dateisystem zurück. HTTP PUT, das Protokoll, um bearbeitete Dateien auf einen entfernten Server zurückzuschreiben, kam erst Jahre später mit HTTP/1.1 dazu. Das allererste Read/Write-Web war ein Modell der lokalen Dateibearbeitung: Sie schrieben Ihre Datei lokal, Sie stellten sie von einem Rechner bereit, den Sie kontrollierten, andere holten und lasen sie. Der Autor hielt die Bytes.
Das ist das Substrat, das die Cloud-Ära hergegeben hat. Google Docs behielt „jeder kann Autor sein“ und gab „die Datei gehört Ihnen“ auf. Solid, das jüngere Projekt von Berners-Lee, behält „die Datei gehört Ihnen“, aber unter einer URL auf einem persönlichen Server, und bewahrt damit die später hinzugekommene Annahme, die URL sei die kanonische Identität.
Ein reWritable ist anders. Die Datei ist das Dokument. Der Editor ist in der Datei. Verteilen heißt, die Datei zu übergeben. Fork-on-share ist das, was Teilen bedeuten muss, sobald Sie sich auf alle drei Punkte festlegen.
Das ist nicht der einzige Weg durch die Diagnose von Berners-Lee. Solid ist ein anderer, und ein schlüssiger. Aber es könnte der Weg sein, der dem am treuesten bleibt, was der Browser von 1990 wirklich war: Bytes auf einem Rechner, den Sie kontrollieren, lokal bearbeitet und geteilt, indem man sie weitergibt.
Aussäen statt Synchronisieren
Es gibt einen praktischen Grund, Fork-on-share zu mögen, den die philosophische Einordnung bisher zu wenig betont hat. Änderungen auf einen Server zurückzuschreiben ist im allgemeinen Fall schwer. Schwer sind nicht die Netzwerkaufrufe, die sind trivial. Schwer sind die Fragen, die diese Aufrufe aufwerfen. Wer darf schreiben, und wie weist er das nach? Was bedeutet „die aktuelle Version“, wenn zehn Leute etwas geändert haben? Wenn zwei Personen in derselben Stunde denselben Absatz bearbeiten: Wessen Änderung gewinnt, und können wir beide behalten?
Wir haben Systeme, die diese Fragen ernst nehmen. Git ist das bekannteste: drei Jahrzehnte Designarbeit, die vielen Menschen ermöglichen soll, in eine gemeinsame Historie eines gemeinsamen Artefakts zu schreiben, mit Merge-Werkzeugen, Branch-Regeln, Code-Review-Workflows und einer ganzen Soziologie darüber, wie Projekte das alles handhaben. Git ist brillant. Git ist auch, nach jedermanns Maßstab, kompliziert. Die meisten Dokumente sind diesen Apparat nicht wert. Die meisten Menschen werden ihn nicht lernen. Die meisten Workflows kippen beim ersten Merge-Konflikt um.
Es lohnt sich, genauer hinzusehen, was an Git eigentlich schwer ist. Das Verteilungsmodell (clone gibt Ihnen eine vollständige Kopie, Ihre lokalen Operationen bleiben lokal, der Baum gehört Ihnen) ist der einfache Teil. Schwer ist alles, was aus dem Zurückschreiben folgt: Push, Pull, Merge, Rebase, Konfliktlösung, das Umschreiben der Historie. Das alles gibt es, weil Git über Forks hinweg eine stimmige gemeinsame Historie aufrechterhalten will. Nimmt man dieses Ziel weg, verschwindet auch die Schwierigkeit.
Die Cloud-Produktivitätssuiten sind einen anderen Weg gegangen: Sie haben die Fragen verschwinden lassen, indem „das Dokument“ zu etwas wurde, das auf einem Server lebt und über das der Server entscheidet. Es gibt keinen Merge, weil niemand eine Kopie hat, aus der er mergen könnte. Alle bearbeiten denselben Datensatz. Es gibt keine Berechtigungsfrage zwischen den Benutzern, weil der Server das zentral durchsetzt. Es gibt keine Versionsfrage, weil der Server ein Audit-Log führt. Das funktioniert. Es setzt aber auch voraus, dass der Server für immer existiert, vertrauenswürdig bleibt und nicht von jemandem gekauft wird, der mit Ihrem Dokument andere Pläne hat als Sie.
reWritables schreiben Änderungen nicht zurück, reWritables sind das Saatkorn.
Wenn Sie ein reWritable veröffentlichen, bringen Sie ein frisches Saatkorn in die Welt: ein stabiles, eigenständiges, fertig ausgebildetes Artefakt, das jemand anderer einpflanzen kann. Das Original, das Sie behalten, gehört Ihnen. Das Saatkorn, das Sie ausgebracht haben, gehört dem, der es aufhebt, und zwar in dem Moment, in dem er es aufhebt. Es gibt keine Berechtigung auszuhandeln, weil nichts zurückfließt. Es gibt keinen Versionskonflikt, weil jedes Saatkorn für sich steht, datiert auf den Moment, in dem es gepflanzt wurde. Es gibt keine Konfliktlösung, weil nie zwei Personen in denselben Datensatz schreiben.
Wenn der Empfänger seine Kopie ändert und seine Fassung veröffentlicht, sät er wieder aus. Die Abstammung lässt sich vielleicht daran erkennen, wovon die Dokumente handeln (womöglich merken Sie: „Ah, das stammt von dem Retrospektiven-Template ab, das ich gemacht habe“), aber erzwungen wird sie nirgends. Es gibt keinen Parent-Pointer in der Datei, keinen Diff zum Original und keinen Merge, der in der Zukunft wartet. Jedes veröffentlichte Dokument ist ein frisches Artefakt und mit dem, was vorher kam, nur durch Ähnlichkeit verbunden.
Das kommt dem viel näher, wie Ideen tatsächlich reisen. Sie veröffentlichen ein Rezept, eine Freundin ändert es, sie veröffentlicht ihres, deren Freundin ändert es weiter, und sechs Monate später kursiert eine Version, die niemand „das kanonische Rezept“ zu nennen versucht, weil das niemand braucht. Das Rezept lebt in der Welt als Population von Artefakten, und jedes gehört ganz dem, der heute Abend danach kocht.
Fork-on-share benennt, was im Moment der Veröffentlichung passiert. Aussäen benennt das größere Muster, das sich mit der Zeit herausbildet. Die schwierigen Probleme des Zurückschreibens (Berechtigungen, Versionierung, Konflikte) werden nicht gelöst. Man verweigert sich ihnen, durch die Wahl eines Modells, in dem sie gar nicht entstehen.
Wo sich Fork-on-share bezahlt macht
Abstrakte Designentscheidungen sind nur so gut wie die Situationen, in denen sie sich auszahlen. Ich denke, für Templates, Starter und Playbooks ist das Saatkorn-Modell am natürlichsten: Hier ist ein Starter, passen Sie ihn an. Ein Template für die wöchentliche Retrospektive, ein Formular für Incident-Reports, ein Trainingsplan, ein Kickoff-Dokument für ein Projekt. Empfänger bekommen ihre eigene Kopie und entwickeln sie unabhängig weiter. Das Original ändert sich weiter, ohne dass ihre Kopien unter ihnen wegdriften. Zum Vergleich ein Notion-Template: Dort können sich Änderungen des Herausgebers auf eine Weise ausbreiten, mit der „Duplikate“ nicht immer etwas anzufangen wissen. Fork-on-share macht das Verhältnis im Moment der Verteilung explizit: Hier ist ein Snapshot, und was Sie damit machen, ist Ihre Sache. Zusammen mit ⌘K muss der Empfänger die Struktur des Templates nicht verstehen, um es anzupassen. Er sagt, was er will, und das Dokument schreibt sich selbst um.
Was man dafür aufgibt
Das Fork-Modell gibt einiges auf, das erwähnt werden sollte:
Keine Zusammenarbeit im Sinn von Google Docs. Zwei Personen, die dasselbe Share bearbeiten, bekommen jede ihren eigenen privaten Fork, sobald sie ⌘K anrühren. Es gibt keinen Merge, keinen Sync und keine Konfliktlösung, die in das Share eingebaut wäre. Wenn zwei Personen zu einem einzigen Dokument kommen wollen, ist der Workflow wie bei E-Mails mit Anhängen: A bearbeitet, A veröffentlicht, B lädt seine Kopie herunter, B bearbeitet, B veröffentlicht zurück, A lädt herunter. Nicht „alle gleichzeitig im selben Dokument“.
Keine veränderliche kanonische URL. Stabile URLs können Sie haben, also dauerhafte Share-Links, die eingefrorene Dokumente ausliefern, aber keine einzelne URL, die immer „die neueste Fassung“ liefert. Ein Update heißt neu veröffentlichen, und das heißt: neue URL. Die neue URL zu verteilen ist selbst wieder Sache des Herausgebers. Die nächste Analogie sind Git-Commit-Hashes und nicht Branch-Pointer: Jede Referenz zeigt auf bestimmte Bytes, nie auf ein bewegliches Ziel.
Kein Rückruf. Etwas verschickt, das Sie bereuen? Wer ⌘S gedrückt hat, besitzt das Dokument für immer, denn genau das heißt es, dass eine Datei eine Datei ist. reWritable-Shares haben die Semantik von E-Mails, nicht die Bearbeiten-und-Löschen-Semantik von Slack. Einmal verteilt, immer draußen.
Und was ist mit der Kontrolle?
Wer von zwei Jahrzehnten Cloud-Produktivität geprägt ist, wird zu Recht fragen: Warum sollten Sie das akzeptieren? Sie erzeugen unverbundene Versionen eines Dokuments, die weiß Gott wo liegen, auf Festplatten, die Sie nicht sehen, in Zuständen, die Sie nicht nachverfolgen können. Geben Sie da nicht Kontrolle auf, die Sie vielleicht brauchen?
Der Großteil dieser Kontrolle ist theoretisch. Die allermeisten geteilten Dokumente werden nach dem Teilen nie aktualisiert, nie zurückgezogen und von ihren Herausgebern nie aktiv verfolgt. „Ich kann es zurückholen“ und „Ich sehe, wer es geöffnet hat“ sind Beruhigungen, keine gelebte Praxis. Was Sie bei Fork-on-share aufgeben, ist meist die Option, nicht die Nutzung. Was der Empfänger gewinnt (Dauerhaftigkeit, Eigentum, Unabhängigkeit davon, dass Sie weiter mitspielen), nutzt er wirklich, jedes Mal, wenn er die Datei öffnet.
Die Kontrolle, die Sie im Cloud-Modell behalten, ist gemietet. Die Plattform kann die Bedingungen ändern, das Format abkündigen, Ihnen den Zugriff auf Ihr eigenes Dokument entziehen oder von einem Akteur gekauft werden, dessen Pläne von Ihren abweichen. Die „Kontrolle“ über Ihr geteiltes Google Doc ist an Google delegiert und wird in Ihrem Namen nach dessen Ermessen ausgeübt. Sie haben nicht die Kontrolle behalten, sondern ein Service-Level-Verhältnis zu einem Verwahrer. Fork-on-share tauscht dieses Verwahrverhältnis gegen echtes Eigentum: Bytes auf Festplatten, die denen gehören, die sie halten.
Die Sorge vor dem Wildwuchs ist weitgehend ein Artefakt der Cloud-Ära. Dateien vermehren sich ohne zentrale Nachverfolgung, seit es Computer gibt: jeder E-Mail-Anhang, jedes heruntergeladene PDF, jedes Foto auf dem Telefon eines Freundes. Damit haben wir jahrzehntelang gelebt, ohne es als grundsätzliches Problem der Datei zu behandeln. Die Angst vor „verschiedenen Versionen, die herumschwirren“ gehört zu der kurzen historischen Anomalie, in der Dokumente in zentralen Datenbanken lebten und sich dieser Ort wie die Heimat des Dokuments anfühlte. Verteilung auf Dateiebene ist kein Rückschritt. Sie ist der Normalzustand des Computing, der nach einem Umweg zurückkehrt.
Manches, was „Kontrolle“ heißt, ist eher Überwachung. „Ich will wissen, wer mein Dokument liest“ ist manchmal ein berechtigtes Anliegen, öfter aber Analytics im Governance-Kostüm. Beim Cloud-Sharing ist auf der Seite des Lesers Telemetrie eingebaut: wann er es geöffnet hat, wie lange er darin war, was er markiert hat, ob er es weitergegeben hat. Fork-on-share verweigert sich dieser Asymmetrie. Sobald die Datei zugestellt ist, ist das, was der Leser damit macht, seine Sache.
Und die Fälle, in denen zentrale Kontrolle wirklich zählt, sind andere Fälle. Laufende Finanzdaten, gemeinsame Lagerbestände, regulatorische Dokumente, die eine einzige kanonische Fassung zeigen müssen: Hier braucht es einen Server, der entscheidet, und reWritable will dafür gar nicht das Werkzeug sein. Manche Artefakte sollten Dateien sein, manche Datensätze. Die Cloud-Ära hat beides verwechselt, weil sie alles durch dieselben Produktivitätssuiten geschleust hat. Fork-on-share ist das Modell für die Datei-Seite dieser Linie, nicht für alles, was je in einem Google Doc gelandet ist.
Nichts davon lässt den Kompromiss verschwinden. Sie geben wirklich die fortlaufende Beziehung des Herausgebers zu den geteilten Bytes auf. Aber Sie bekommen etwas Bestimmtes dafür: einen Empfänger, dem wirklich gehört, was er in der Hand hält, ein Artefakt, das nicht von Ihnen abhängt, um weiter zu existieren, und ein Verteilungsmodell, das keinen Verwahrer braucht, der es sich anders überlegen kann. Für die Dokumente, die Dateien sein sollten, ist das der Tausch, den Sie wollen.
Der Fork ist der Boden, nicht die Decke
Fork-on-share ist eine Aussage darüber, was eine Veröffentlichung bewirkt: Sie erzeugt eine souveräne Kopie in den Händen des Empfängers. Es ist keine Aussage darüber, dass die Kopien von Herausgeber und Empfänger für immer unverbunden bleiben müssen. Zwei reWritables, jedes ganz in der Hand seines Eigentümers, könnten sich im Prinzip darauf einigen, zusammenzufinden: Last-Write-Wins, Merge im CRDT-Stil, Abgleich über Patches oder etwas ganz anderes. Eine solche Synchronisierung wäre ein Opt-in-Handshake zwischen zwei souveränen Dokumenten, von ihnen selbst ausgehandelt und jederzeit wieder aufkündbar. Kein Server, der Updates an Empfänger schiebt. Kein einzelner kanonischer Datensatz, den alle anderen nur ansehen.
Die Mechanismen dafür gibt es in reWritable heute nicht. Aber Fork-on-share ist die Voraussetzung dafür, sie sauber ergänzen zu können. Das aktuelle Modell unterstützt schon jetzt freiwillige Komposition auf der lokalen Festplatte: Container auf demselben Rechner, die sich dafür entscheiden, in einen gemeinsamen Bus zu veröffentlichen, mit Namespaces und per Opt-in. Synchronisierung zwischen souveränen reWritables über Rechnergrenzen hinweg wäre dasselbe Muster in einem anderen Maßstab: Annäherung durch gegenseitige Vereinbarung, nicht durch Unterordnung unter einen zentralen Datensatz.
Der Fork ist der architektonische Boden. Was Forks dann miteinander anstellen, ist offen.
Postskriptum
Fork-on-share ist ein Ansatz unter mehreren, Solid, Google Docs und Git sind andere Beispiele. Keiner davon ist überall richtig. Die Argumentation oben ist die stärkste Fassung, die ich für diesen Ansatz formulieren kann, ein Beweis ist sie nicht. Es ist ein Experiment im schlichten Sinn: Ich baue Dinge, um zu sehen, ob sie noch Sinn ergeben, wenn andere Leute sie ausprobieren. Das ist der Teil, der mir Spaß macht. Wenn Sie es ausprobieren und einen Nutzen finden, würde ich gern davon hören. Wenn Sie an die Grenzen stoßen, auch davon.
Aus dem Englischen übersetzt: zum Originalbeitrag