In „Die Fork-Gefahr“ 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 Organization wird entscheiden wer das Projekt ist und wer die Abspaltung, denn es hällt 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 der Repository an, mit der kompletten Historie, wenn es keine andere Möglichkeit für sie gibt, dran zu kommen, damit sie nicht ohne die historischen Daten anfangen 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 Fehl schlä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 Kommunikationsphade 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,[43] 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 is 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 Wesentlich vermeiden Sie die Abspaltung indem Sie zu ihm werden.
Alle Ratschläge hier, gehen davon aus, dass Sie als letztes Mittel eine Abspaltung machen. Nutzen Sie alle anderen Möglichkeiten vor Sie eine Abspaltung anfangen. Es bedeutet fast immer Entwickler zu verlieren, lediglich mit einem ungewissen Versprechen, später neue zu bekommen. Es bedeutet auch mit einem Wettbewerb um die Aufmerksamkeit der Nutzer anzufangen: Jeder der dabei ist die Software herunterzuladen, wird sich fragen müssen: "Hmm, will ich diesen oder den anderen?" Welcher auch immer Sie sind, 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 als Gesamtes gesund ist: Die Tüchtigsten überleben, was letztendlich bedeutet, dass jeder bessere Software bekommt. Das mag aus Sicht des Ökosystems wahr sein, ist aber nicht aus Sicht eines 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 eine Abspaltung zu machen, bei einer Debatte nicht als extreme Technik benutzen sollten—"Macht die Sache auf meine Art, oder ich werde das eine Abspaltung vom Projekt machen!"—da jeder sich darüber im klaren ist, dass eine Abspaltung welche es nicht schafft Entwickler von dem ursprünglichen Projekt anzulocken, wahrscheinlich nicht lange überleben wird. Alle Beobachter—nicht nur die Entwickler, sondern auch die Nutzer und die Packet Verwalter der Betriebssysteme—werden ihr eigenes Urteil darüber machen welche Seite sie wählen. Sie sollten desshalb sehr abgeneigt zu einer Abspaltung erscheinen, damit wenn Sie es letztendlich doch machen, Sie glaubhaft behaupten können, dass es der einzige übrige Weg war.
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 sind, und im privaten für eine Abspaltung sind, es wahrscheinlich nicht laut sagen, wenn Sie wissen, dass ihr Arbeitgeber dagegen ist. Viele Programmierer freie Software denken gerne, dass eine freie Lizensierung des Codes bedeutet, dass keine eine Firma die Entwicklung dominieren kann. Es ist wahr, dass die Lizenz, im letztendlichen Sinne die Freiheit garantiert—wen andere dringend genug das Projekt Abspalten wollen, und die Resourcen dazu haben, können sie das. In der Praxis sind die Entwicklermannschaften mancher Projekte größtenteils durch ein Unternehmen finanziert, und es hat keine Sinn so zu tun, als ob die Unterstützung dieses Unternehmens keinen Unterschied macht. Wenn es die Abspaltung ablehnt, werden seine Entwickler wahrscheinlich nicht daran teilnehmen, selbst wenn sie es insgeheime wollen.
Wenn Sie trotzdem zu dem Schluss kommen, das Sie eine Abspaltung machen müssen, sollten Sie zunächst im privaten dafür Unterstützung sammeln, und es dann in einem nicht feintlichen Ton bekannt geben. Selbst wenn Sie wütend oder entäuscht von den derzeitigen Verwaltern sind, sollten Sie es nicht in der Nachricht sagen. Halten Sie einfach leidenschaftslos fest, war 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 tritt. 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 Nutzer schwieriger indem Sie sie dazu zwingen einen Streit um die Identität auseinanderzufuseln.
Letztlich, können Sie die Sachen 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 wilkommen.