Das Risiko beginnt nicht mit dem Kündigungsschreiben. Es beginnt Wochen vorher, wenn der Entwickler noch in jedem Repository eingeloggt ist, noch vollen Zugriff auf die Konzeptdokumente hat und bereits über den nächsten Schritt nachdenkt. Dieses Zeitfenster ist unauffällig und wirkt wie ein ganz normaler Dienstag. Genau dort verliert ein Start-up die klarste Aufzeichnung darüber, wer eigentlich was gebaut hat.
Was wirklich zur Tür hinausgeht
Selten ist es das fertige Produkt. Das Produktions-Repository ist meist in Ordnung: Es hat eine Commit-Historie, ein echtes Änderungsprotokoll, und mehr als eine Person kann dafür bürgen. Was verschwindet, ist alles drumherum. Ein privates Repository, das für einen frühen Prototypen angelegt wurde, bevor es das "richtige" überhaupt gab. Ein Konzeptdokument, das in eine private E-Mail eingefügt wurde, weil Slack an diesem Tag ausgefallen war. Ein Branch, den niemand gemerged hat, weil das Feature zurückgestellt wurde, der aber trotzdem die erste funktionierende Version einer Idee enthält, die das Unternehmen später unter anderem Namen ausgeliefert hat. Solange die Person noch im Team ist, wirkt nichts davon wichtig. Sobald sie es nicht mehr ist, wird alles davon strittig.
Ein technischer Mitgründer, der nach einem Zerwürfnis geht, ist die schärfste Form dieses Problems. Zwei Menschen können dieselben sechs Monate völlig unterschiedlich erinnern, und sobald die Beziehung zerbrochen ist, gibt es keine gemeinsame Darstellung mehr, wer welche Zeile zuerst geschrieben hat, wessen Skizze zur Architektur wurde oder wann eine bestimmte Idee tatsächlich entstand. Was bleibt, ist Erinnerung gegen Erinnerung, und das ist kein Beweis.
Es betrifft nicht nur Gründer. Ein Auftragnehmer, der die erste Version eines Features baute, bevor er fest angestellt wurde. Ein Praktikant, dessen Sommerprojekt still und leise zu einem zentralen Baustein des Produkts wurde. Ein Freelancer, der das ursprüngliche Architekturdiagramm entworfen hat. Sie alle hinterlassen dieselbe Art von Lücke, meist ohne dass es jemand bemerkt, bis ein Streit jemanden dazu zwingt, nach einem Beweis zu suchen, der nie aufbewahrt wurde.
Warum Versiegelung "bei grossen Meilensteinen" die Lücke offen lässt
Die meisten Entwicklungsteams, die überhaupt darüber nachdenken, denken im falschen Moment daran. Ein Release wird getaggt. Ein Vertrag wird unterschrieben. Das wird versiegelt, wenn überhaupt etwas versiegelt wird. Der explorative Branch, der das Release geprägt hat, der frühe Prototyp, der bewiesen hat, dass die Idee überhaupt funktioniert, das interne Konzeptdokument, auf dem das Release eigentlich beruht: All das erhält selten dieselbe Behandlung, weil niemand an eine Trennung dachte, während man noch gemeinsam Code schrieb. Das ist genau verkehrt herum. Das Material mit der schwächsten Papierspur ist genau das Material, an das sich ein ausscheidender Entwickler am klarsten erinnert und für das er oft den stärksten Instinkt hat, die Urheberschaft zu beanspruchen.
Was laufende Versiegelung tatsächlich schafft
Die Lösung ist nicht ein grösseres Rechtsteam. Es geht darum, Versiegelung als festen Bestandteil davon zu behandeln, wie technische Arbeit gespeichert wird, nicht als Schritt, der nur für Launches und Unterschriften reserviert ist. In der Praxis bedeutet das eine Gewohnheit, so selbstverständlich wie ein Merge in den Hauptzweig: Quellcode wird in regelmässigem Abstand versiegelt statt nur beim Release, ein Konzeptdokument wird an dem Tag versiegelt, an dem es mit dem Team geteilt wird, nicht erst wenn es fertig ist, und ein früher Prototyp wird in der Woche versiegelt, in der er zum ersten Mal läuft, statt Monate später, wenn überhaupt. Nichts davon hängt davon ab, dass sich jemand an eine mögliche Trennung erinnert. Es muss nur bereits die Art sein, wie das Team arbeitet. Unter Artikel 41 der eIDAS-Verordnung geniesst ein qualifizierter elektronischer Zeitstempel die Vermutung der Richtigkeit von Datum und Uhrzeit, die er angibt, sowie der Unversehrtheit der von ihm erfassten Daten. In der Schweiz hat eine Signatur, die über einen nach ZertES anerkannten Anbieter ausgestellt wurde, dieselbe Rechtswirkung wie eine handschriftliche Unterschrift. Keines der beiden Regelwerke interessiert sich dafür, wer noch angestellt ist, wenn ein Streit irgendwann auftaucht. Beide interessieren sich dafür, was wann festgehalten wurde, und das ist genau der Teil der Geschichte, der sich nicht ändert, je nachdem, wer ihn erzählt.
Man stelle sich zwei Gründer vor, die gemeinsam die erste funktionierende Version eines Produkts bauen und sich achtzehn Monate später im Streit trennen. Wurden der frühe Prototyp und das Konzeptdokument, das dazu führte, in der Woche versiegelt, in der sie entstanden, existiert eine datierte, manipulationssichere Aufzeichnung, unabhängig von der Erinnerung oder der aktuellen Beziehung der beiden. Wurden sie es nicht, läuft der Streit darauf hinaus, wer überzeugender auftritt, und das ist eine Position, in der keiner der beiden Gründer sein sollte.
Was das nicht leistet
Versiegelung ersetzt keinen Arbeitsvertrag und keine Klausel zur Übertragung von geistigem Eigentum, und sie entscheidet keinen Streit von sich aus. Ein Unternehmen braucht weiterhin die zugrunde liegenden Vereinbarungen, die überhaupt erst festlegen, wem Arbeitsergebnisse gehören. Was Versiegelung hinzufügt, ist die Beweisaufzeichnung, die ein Streit tatsächlich braucht, sobald diese Vereinbarungen bestehen: der Nachweis, was existierte, in welcher Form, und wann, den keine der beiden Seiten im Nachhinein still verändern kann.
Zur Gewohnheit machen, bevor jemand geht, nicht danach
Sobald jemand kündigt, ist es zu spät, mit der Versiegelung der wichtigsten Arbeit anzufangen. Die Start-ups, die diesen Streit vermeiden, sind jene, die Versiegelung von Anfang an zu einem Teil davon gemacht haben, wie sie technische Arbeit speichern, genauso wie sie Versionskontrolle zu einem Teil davon gemacht haben, wie sie sie schreiben. Hier sehen Sie, wie das für Software- und IP-Teams funktioniert, bevor die nächste Trennung, geplant oder nicht, die Frage dringend macht.
