Forks sind eine schlechte Sache, wenn's darum geht zwei sehr ähnliche Projekte zu warten. Die Menge der Maintainer wird praktisch halbiert, d.h. die Weiterentwicklung der einzelnen Projekte geht viel langsamer von Statten.

Freie Software verhindert das Forken nicht, aber man versucht auf jeden Fall einen Fork zu verhindern. Die Gefahr gab's ja bei Linux auch mal, wurde aber erfolgreich abgewandt.

Eine ganz andere Sache ist es, wenn Du eine freie Software X nimmst und daraus eine _andere_ freie Software Y machst, wobei X und Y _nicht_ praktisch gleich sind. In diesem Fall zeigt sich wirklich die Stärke der freien Software.

Bis eines der beiden Projekte gewinnen könnte, laufen beide parallel, d.h. dann auch mehr Aufwand. Es ist aber sehr unwahrscheinlich, dass ein Team plötzlich sagt: "Ok, die Andern haben so was Tolles gemacht, lasst uns aufhören und bei den Andern mitmachen!"

Konkurrenz ist schon gut, ein Fork _kann_ jedoch den Tod _beider_ Projekte zur Folge haben.

Ich sag' ja nicht, dass Forks gar keine Berechtigung hätten. Forks sollten gut überlegt sein, keine Handlung im Affekt. Wenn es _gute_ Gründe sind, ist's was Anderes. Trotzdem bestehen gewisse Risiken.

Falls der Fork aus Sympathiegründen geschieht sollte der Forkende sich sicher sein andere Leute mit ähnlichen Sympathien zu finden oder er geht das Risiko ein, dass sein Pfad stirbt. Es ist was Anderes, wenn es um bestehende Projekte wie Linux und *BSD geht. Diese sind nicht aus einem Fork, mit gemeinsamer Basis, entstanden.

Da hast Du schon recht, dem Benutzer der Software ist es mit grosser Wahrscheinlichkeit egal, was mit was verwandt ist. Falls aber ein Pfad stirbt oder die Entwicklung der einzelnen Projekte beeiträchtigt werden, dann ist's ihm nicht mehr egal, weil er dann keine Unterstützung für neue Features mehr hat. Dann heisst es wieder "Auf der Platform 'FooBar' gibt's das Features XYZ, warum hier nicht?" ... etc.

Genau. Das ist mir auch grade auffem Heimweg eingefallen. Wobei GNU Emacs und XEmacs nicht nur ein Split sind. Das ist ein ganzer Baum. :-) Da gab's noch Multics Emacs, Lucid Emacs (ok, da wurde später irgendwie XEmacs draus), EINE (EINE Is Not EMACS) und Epoch. Irgendwo gab's mal 'ne schöne ASCII-Art-Grafik *google*, ahja, hier, bei JWZ.

Die Gründe für die Entstehung von XEmacs waren übrigens IIRC vor allem patentrechtliche, weil GNU nur GPL'ten Code akzeptierte und deswegen viele nette existierende Features nicht in die Distribution durften. Es ging wohl immer mal wieder Code hin und her und meistens zieht der eine dem anderen nach bei neuen Features, aber manche Dinge sind einfach inkompatibel: z.B. hat die beiden Emacs-Lisps z.T. unterschiedliche Variablentypen. Und auch der erzeugte Byte-Code (*.elc) ist unterschiedlich.

Weitere (mehr oder weniger erfolgreiche) Forks, von denen mir die Gründe einigermaßen bekannt sind:

• PHP-Nuke vs PostNuke: Hier war der Fork-Grund, daß die Maintainer von PHP-Nuke niemand anders ran ließen und lieber neue Features bastelten statt Sicherheitslücken zu fixen. Naja, und da war der Fork von der Community recht bald da und bei Post-Nuke geht's anscheinend auch viel offener zu. Und man hört deutlich seltener was über PostNuke auf BugTraq als über PHP-Nuke, wo eigentlich spätestens alle zwei Wochen eine neue Lücke entdeckt wird.
• SSH.com vs OpenSSH: IIRC basiert die erste OpenSSH auf der letzten freien SSH von SSH Inc. Gründe? Lizenzrechtliches: Die SSH von SSH Inc. war irgendwann nicht mehr frei für Kommernzielle Anwendungen.
• OpenBSD vs MircoBSD: Man wollte was kompakteres, kleineres, performanteres. Ging wegen sozialen Inkompetenzen schnell und gründlich schief.
• KDE 1 vs TDE : Naja, TDE kann man eigentlich geschichtlich nicht als Fork sehen, allerhöchstens als sehr verspäteten. Technisch wär's aber einer, wenn KDE1 noch weiterentwickelt würde.
• XMosaic vs Netscape Navigator 1.0 vs MSIE 1.0 IIRC baut nicht nur das erste Netscape auf Mosaic auf. sondern auch der erste MSIE (wer kennt den noch? ;-)
• twm vs tvtwm (OK, ist arg lange her, kennt kaum einer noch ;-) tvtwm war eine twm-Version, die einen Virtual Desktop wie die meisten aktuellen Window Manager anbot. (War lange Zeit mein Lieblings-WM. Bis ich FVWM 1 entdeckte... ;-)

Was mir noch einfällt, wo ich aber zu wenig Ahnung von der Geschichte habe, ich entsprechend auch nicht sicher sagen kann, daß es Forks sind:

• vi vs vim
• gcc vs egcs (egcs war wohl eher so die unstable-Variante, aber anfangs war es IIRC auch "nur ein Fork" mit mehr Features, jetzt sind sie ja wieder vereinigt.)
• csh vs tcsh
• awk vs nawk vs gawk
• WU-FTPd vs WU-FTPd-Academ (letzterer ist eingeschlafen und wurde dann IIRC im Original wieder verwurstet)
• links vs elinks

Klassische Beispiele, wo es genügend forks gibt (meist pro OS einen) und sich jeder über die unterschiedlichen Kommandozeilen-Parameter aufregt: man, die ganzen File Utilities (ls, mv, cp, rm), tar, find, ftp, etc.

Auf jeden Fall keine echten Forks, sondern Neuimplementationen:

• OpenSSH vs lsh (Obwohl? Basiert lsh nicht auch auf der letzten freien SSH.com-Version?)
• cvs vs svn (aka Subversion)
• Emacs vs zile vs texmacs vs micro emacs etc.
• vi vs elvis vs vile (OK, da kenne ich die Details nicht 100%)
• pico vs nano: nano ist die Neuimplementation von pico unter GPL. Und deutlich flotter und sparsamer, wie das bei Neuimplementationen so üblich ist. lynx vs links vs w3m

Weiter sollte man noch daran denken, daß manches, was wie ein Fork aussieht, eigentlich nur eine Distribution oder Variante ist. In dieser Kategorie fallen mir Perl, ActivePerl und MacPerl ein, genauso aber Apache, Stronghold und Apache-SSL.

Tja offenbar weiss das noch niemand so genau:

It has been brought to the attention of the XFree86 Core Team that one of its members, Keith Packard, has been actively (but privately) seeking out support for a fork of XFree86 that would be led by himself. He is also in the process of forming a by-invitation-only group of vested interests to discuss privately concerns he has about XFree86 and the future of X. He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable. As a consequence, Keith Packard is no longer a member of the XFree86 Core Team."

Quelle: http://www.pclinuxonline.com/modules.php?name=News&file=a rticle&sid=4717 &mode=nested&order=0&thold=0

Er will's einfach nicht weitersagen ;-)

Keiths Meinung ist, dass dies so nicht sein muss. Die anderen erfolgreichen grossen OpenSource-Projekte geben Ihm recht.

Ich war anfangs auch skeptisch zum Thema Fork, aber nach dem Lesen seiner Argumente muss ich sagen: Ja, wenn sich das XFree86-Konsortium nicht schnellstens umorganisiert, ist ein Fork zwingend! Denn: Was ist schlimmer in einem Projekt wie XFree86? Fehlerhafter oder überhaupt kein Support für aktuelle Hardware?

Naja... Zumindest gibt gibt dieses Diary ein paar Einblicke in den Zustand des XFree Projektes und liefert mögliche Gründe für Keith's Aktivitäten.

Meine Schlussfolgerung, dass angesichts der Zustände ein Fork nicht das schlimmte wäre, hat aber bestand.