In „Aufspaltbarkeit“ im Kapitel Kapitel 4, Soziale und politische Infrastruktur, haben wir gesehen, wie das Potential für eine Abspaltung (en. Fork) wichtige Auswirkungen darauf hat, wie ein Projekt geführt wird. Was passiert aber, wenn eine Abspaltung wirklich stattfindet? Wie sollten Sie damit umgehen, und welche Auswirkungen können Sie davon erwarten? Wann sollten Sie umgekehrt, eine Abspaltung anstoßen?
Die Antworten hängen davon ab, um welche Art von Abspaltung es sich handelt. Manche Abspaltungen sind aufgrund von freundlichen aber unüberbrückbare Meinungsverschiedenheiten, über die Richtung des Projekts; mehr sind vielleicht sowohl auf technische Argumente als auch auf zwischenmenschliche Konflikte zurückzuführen. Natürlich ist es nicht immer möglich, den Unterschied zwischen den beiden zu erkennen, da technische Argumente auch persönliche Anteile beinhalten können. Alle Abspaltungen haben gemeinsam, dass eine Gruppe von Entwicklern (oder manchmal auch nur ein Entwickler) sich entschieden haben, dass die Kosten mit manchen oder alle anderen Entwicklern zu arbeiten, jetzt schwerer wiegen als der Nutzen.
Wenn ein Projekt sich spaltet, gibt es keine definitive Antwort darüber, welche Abspaltung das "echte" oder "ursprüngliche" Projekt war. Lete werden umgangssprachlich davon sprechen, dass die Abspaltung A aus dem Projekt P kommt, als ob P weiter seinen natürlichen Lauf nimmt wärend A in neue Gebiete divergiert, was aber im wesentlichen eine Aussage darüber ist, wie dieser bestimmte Beobachter das Thema sieht. Es ist im Grunde genommen eine Frage der Sichtweise: Wenn eine ausreichend große Gruppe damit übereinstimmt, dann fängt die Behauptung an wahr zu werden. Es ist nicht so, dass es eine objektive Wahrheit von vornherein gibt, eine welche wir zunächst zweifelsfrei beobachten können. Sondern vielmehr, die Auffassungen sind die objektive Wahrheit, da ein Projekt – oder eine Abspaltung – letztendlich eine Entität ist, die sowieso nur in den Köpfen der Menschen existiert.
Wenn diejenigen, welche die Abspaltung anstoßen das Gefühl haben, dass sie aus dem Hauptprojekt einen neuen Ast entsprießen, ist die Frage der Wahrnehmung sofort und einfach beantwortet. Jeder, sowohl die Entwickler als auch die Nutzer werden die Abspaltung wie ein neues Projekt behandeln, mit einem neuen Namen (vielleicht auf dem alten Namen basierend, aber leicht davon zu unterscheiden), einer eigenen Webseite, und einer anderen Philosopie oder Ziel. Die Sache wird jedoch verwirrender, wenn beide Seiten der Meinung sind, die legitimen Wächter des ursprünglichen Projekts zu sein und desshalb ein Recht haben, ein Recht darauf haben, den ursprünglichen Namen zu benutzen. Wenn es eine Organization gibt, mit Markenrechte auf den Namen, oder rechtliche Kontrolle über die Domaine oder Webseiteb, ist die Angelegenheit über das Recht erledigt: Diese Organisation wird entscheiden wer das Projekt ist und wer die Abspaltung, denn es hält alle Karten in einem Krieg um die öffentliche Wahrnehmung. Natürlich kommen die Sachen meistens nicht so weit: Da jeder bereits weiß, wie die Machtverhältnisse sind, werden sie es vermeiden eine Schlacht zu kämpfen, dessen Ausgang sie bereits kennen, und einfach gleich zum Ende springen.
Zum Glück, gibt es selten Zweifel darüber, welches das Projekt ist, und welches die Abspaltung, denn eine Abspaltung ist im wesentlichen eine Vertrauensfrage. Wenn mehr als die hälfte der Entwickler für welche Richtung die Abspaltung auch immer vorschlägt sind, gibt es normalerweise keinen Grund eine Abspaltung zu machen – das Projekt kann einfach selber diese Richtung einschlagen, es sei denn es wird als Diktatur geführt mit einem besonders sturen Diktator. Wenn andererseits, weniger als die Hälfte dafür sind, ist die Abspaltung eindeutig eine Rebellion einer Minderheit, und is ist sowohl entgegenkommend, als auch vernünftig, dass es sich selber als einen Zweig sieht, und nicht als den Stamm.
Wenn jemand droht von ihrem Projekt eine Abspaltung zu machen, bleiben Sie ruhig und denken Sie an Ihre längerfristigen Ziele. Die bloße Existenz einer Abspaltung ist es nicht, was einem Projekt schadet; vielmehr ist es der Verlust von Entwickler und Nutzer. Ihr echtes Ziel ist es desshalb nicht, die Abspaltung zu unterdrücken, sondern diese schädlichen Auswirkungen zu minimieren. Sie können darüber sauer sein, oder der Meinung sein, dass die Abspaltung nicht gerecht und unprovoziert war, das aber öffentlich äußern kann einzig und alleine unentschlossene Entwickler entfremden. Statt dessen, sollten Sie Leute nicht dazu zwingen, exklusive Entscheidungen zu treffen, und so kooperativ sein, wie es bei einer Abspaltung machbar ist. Als erstes, sollten Sie nicht die commit Berechtigung zu ihrem Projekt von jemandem zurücknehmen, der sich entschieden hat an der Abspaltung zu arbeiten. Arbeit an der Abspaltung bedeutet nicht, dass die Person plötzlich seine Kompetenz an dem ursprünglichen Projekt zu arbeiten verloren hat; vorherige Committer sollten auch nacher Committer sein. Darüber hinaus, sollten Sie Ihr Wunsch ausdrücken, so kompatibel wie möglich mit der Abspaltung zu bleiben ausdrücken und sagen, dass Sie hoffen, dass die Entwickler die Änderungen zwischen beiden übernehmen wenn es angemessen ist. Wenn Sie administrativen Zugriff auf die Server des Projekts haben, sollten Sie der Abspaltung am Anfang öffentlich Hilfe bei der Infrastruktur anbieten. Bieten Sie ihnen zum Beispiel eine Kopie des Projektarchiv an, mit der kompletten Historie, wenn es keine andere Möglichkeit für sie gibt, daran zu kommen, ohne auf die die historischen Daten verzichten zu müssen (das muss je nach Versionsverwaltungssystem nicht unbedingt notwendig sein). Fragen Sie danach, ob es irgend etwas anderes gibt, was sie brauchen und geben Sie es ihene wenn möglich. Reißen Sie sich ein Bein aus, um zu zeigen, dass Sie ihnen nicht im Weg stehen, und dass Sie wollen, dass die Abspaltung nach seinen eigenen Verdiensten Erfolg hat oder fehlschlägt und sonst nichts.
Der Grund all das zu tun – und es öffentlich zu machen – ist nicht wirklich um der Abspaltung zu helfen, sondern um die Enwickler zu überreden, dass Ihre Seite eine sichere Sache ist, indem Sie möglichst nicht als rachsüchtig erscheinen. In einem Krieg machte es manchmal Sinn (aus strategischer Sicht, wenn auch nicht aus menschlicher Sicht) Leute dazu zu zwingen eine Seite zu wählen, bei freier Software macht es jedoch fast niemals Sinn. Nach einer Abspaltung arbeiten manche Entwickler sogar offen an beiden Projekten, und versuchen ihr möglichstes um beide kompatibel zu halten. Diese Entwickler helfen die Kommunikationspfade nach der Abzweigungung offen zu halten. Sie erlauben es ihrem Projekt von den Interessanten neuen Funktionen in der Abzweigung zu profitieren (ja, die Abzweigung kann Sachen haben, welche Sie haben wollen), und später die Wahrscheinlichkeit einer Zusammenführung vergrößern.
Manchmal wird eine Abzweigung derart erfolgreich, dass auch wenn es selbst von seinen Anstiftern zum Beginn als solches angesehen wurde, es zu der Version wird, die jeder bevorzugt, und letztendlich das Original aufgrund der großen Nachfrage ersetzt. Ein berühmtes Beispiel hierfür war die GCC/EGCS-Abzweigung. Die GNU Compiler Collection (GCC, vorher der GNU C Compiler) ist der beliebteste Open-Source-Compiler für nativen Code und auch einer der portabelsten Compiler der Welt. Aufgrund von Meinungsverschiedenheiten zwischen den Personen die es offiziell pflegten, und Cygnus Software,[58] einer der aktivsten Entwickler von GCC, machte Cygnus eine Abzweigung von GCC namens EGCS. Die Abzweigung war absichtlich nicht feindlich gesinnt: Die EGCS-Entwickler versuchten nicht, zu irgend einem Zeitpunkt, ihre Version von GCC als die neue ofizielle Version darzustellen. Statt dessen, konzentrierten sie sich darauf, EGCS so gut wie möglich zu machen, und Patches schneller einzubinden, als die offiziellen Entwickler von GCC. EGCS wurde beliebter, und irgendwann entschieden sich einige größere Vertreiber von Betriebssystemen EGCS anstatt von GCC als ihren standard Compiler auszuliefern. Zu diesem Zeitpunkt, wurde es für alle bei GCC klar, dass an dem Namen "GCC" festzuhalte, wärend jeder zu der EGCS-Abzweigung wechselte, jedem eine unnötigen Namensänderung auferlegen würde, aber nichts machen würde, um den Wechsel zu verhindern. GCC übernahm also den Code von EGCS und es gab wieder eine einzige GCC, nun aber durch die Abzweigung wesentlich verbessert.
Dieses Beispiel zeigt, warum Sie eine Abzweigung nicht immer als etwas ganz und gar schlechtes betrachten können. Eine Abzweigung mag zu der Zeit etwas schmerzhaft und unwillkommen sein, Sie können aber nicht unbedingt absehen ob es Erfolg haben wird. Sie und das übrige Projekt sollten desshalb ein Auge darauf halten, und bereit sein nicht nur alle Funktionen und Code aufzunehmen, wo es möglich ist, sonder im extreemsten Fall sogar der Abzweigung beizutreten wenn es den größten Teil der Aufmerksamkeit des Projekts einnimmt. Sie werden natürlich oft in der Lage sein den wahrscheinlichen Erfolg einer Abzweigung abzusehen, jenachdem wer ihm beitritt. Wenn die Abzweigung von dem größten Kläger im Projekt angefangen wird und von einer Handvoll verärgerten Entwickler die sich sowieso nicht konstruktiv verhalten haben, haben Sie im wesentlichen für Sie das Problem, durch die Abzweigung, erledigt, und Sie müssen sich wahrscheinlich keine Sorgen machen, dass es vom ursprünglichen Projekt irgend welche Schwung wegnimmt. Wenn Sie jedoch sehen, wie einflussreiche und geachtete Entwickler die Abzweigung unterstützen, sollten Sie sich fragen warum. Vielleicht ist das Projekt übermäßig restriktiv gewesen, und die beste Lösung ist es, einige oder alle Maßnahmen, die von der Abzweigung erwägt werden, in das Hauptprojekt einzubinden – im Wesentlichen vermeiden Sie die Abspaltung indem Sie zu ihr werden.
Alle Ratschläge hier gehen davon aus, dass Sie als letztes Mittel eine Abspaltung versuchen. Nutzen Sie alle anderen Möglichkeiten, bevor Sie diesen Schritt erwägen. Es bedeutet fast immer, Entwickler zu verlieren, lediglich mit einem ungewissen Versprechen, später neue zu bekommen. Es bedeutet auch, einem Wettbewerb um die Aufmerksamkeit der Benutzer zu beginnen: Jeder, der dabei ist die Software herunterzuladen, wird sich fragen müssen: "Hmm, will ich diesen oder den anderen?" In welcher Position Sie sich auch immer befinden, die Situation ist chaotisch, da eine Frage entsteht, die vorher nicht da war. Manche Leute behaupten nach dem üblichen Argument der natürlichen Auslese, dass Abspaltungen für das Ökosystem der Software in der Gesamtheit gesund ist: Die Tüchtigsten überleben, was letztlich bedeutet, dass jeder bessere Software bekommt. Das mag aus Sicht des Ökosystems wahr sein, trifft aber nicht die Sicht des einzelnen Projekts. Die meisten Abspaltungen sind nicht erfolgreich und die meisten Projekte sind mit einer Abspaltung nicht glücklich.
Damit einher geht, dass Sie die Drohung einer Abspaltung in einer Debatte nicht als extreme Technik benutzen sollten – "Macht die Sache auf meine Art, oder ich werde das Projekt spalten!" – da jeder sich darüber im Klaren ist, dass eine Abspaltung, die es nicht schafft Entwickler des ursprünglichen Projekts anzulocken, wahrscheinlich nicht lange überleben wird. Alle Beobachter – nicht nur die Entwickler, sondern auch die Benutzer und Packetverwalter der Betriebssysteme – werden ihr eigenes Urteil darüber fällen, welche Seite sie wählen. Sie sollten deshalb gegenüber einer Abspaltung sehr abgeneigt erscheinen, damit Sie, sollte es letztlich doch geschehen, glaubhaft machen können, es sei der einzig mögliche Ausweg gewesen.
Vergessen Sie nicht, alle Faktoren bei der evaluierung des möglichen Erfolgs von Ihrer Abspaltung in Erwägung zu ziehen. Wenn zum Beispiel viele der Entwickler in einem Projekt den gleiche Arbeitgeber haben, dann werden sie, selbst wenn Sie verärgert und im privaten für eine Abspaltung sind, es wahrscheinlich nicht laut sagen, wenn Sie wissen, dass ihr Arbeitgeber dagegen ist. Viele Programmierer freier Software denken gerne, dass eine freie Lizenzierung des Codes bedeutet, keine einzelne Firma könne die Entwicklung dominieren. Es ist wahr, dass die Lizenz im letztendlichen Sinne die Freiheit garantiert – wenn andere den dringenden Wunaxh hegen, das Projekt zu spalten, und die Ressourcen dazu haben, können sie das. In der Praxis sind die Entwicklerteams einiger Projekte zum Großteil durch ein Unternehmen finanziert, und es gibt keinen Grund so zu tun, als würde die Unterstützung dieses Unternehmens keinen Unterschied machen. Wenn es die Abspaltung ablehnt, werden seine Entwickler wahrscheinlich nicht daran teilnehmen, selbst wenn sie es insgeheim wünschten.
Wenn Sie trotzdem zu dem Schluss kommen, das Sie sich abspalten müssen, sollten Sie zunächst im privaten dafür Unterstützung suchen, und es dann ohne Feindseligkeit bekannt geben. Selbst wenn Sie wütend oder entäuscht von den derzeitigen Verwaltern sind, lassen Sie es nicht durchblicken. Halten Sie einfach leidenschaftslos fest, was Sie zu der Entscheidung geführt hat, und dass Sie gegenüber dem Projekt von dem Sie abspalten, keine Böswilligkeit hegen. Angenommen, Sie betrachten es als eine Abspaltung (im Gegensatz zu einer notgedrungenen Erhaltung des ursprünglichen Projekts), sollten Sie hervorheben, dass Sie den Code und nicht den Namen abspalten, und wählen Sie einen Namen, der nicht mit dem des ursprünglichen Projekts im Konflikt gerät. Sie können einen Namen wählen, welcher den ursprünglichen beinhaltet oder darauf verweist, so lange es nicht ein Tor für Verwirrung zwischen beiden aufmacht. Es ist natürlich in Ordnung markant auf der Webseite der Abspaltung zu erklären, dass es von dem ursprünglichen Projekt abstammt, und dass es hofft es zu ersetzen. Machen Sie nur nicht das Leben der Benutzer schwieriger indem Sie ihnen aufzwingen, ein Gerangel um die Identität auseinanderzufuseln.
Schließlich können Sie der Sache einen guten Start geben, indem Sie automatisch allen Entwicklern des ursprünglichen Projekts Commit-Rechte zu der Abspaltung geben, inklusive denen die nicht der Notwendigkeit einer Abspaltung zustimmten. Selbst wenn sie niemals den Zugang benutzen, ist Ihre Nachricht klar: Es gibt hier Meinungsverschiedenheiten, aber keine Feinde, und Sie heißen Beiträge aus jeder kompetenten Quelle willkommen.