Die Woche: Totalitäre Open-Source-Entwicklung
Ob ein Patch aufgenommen wird, entscheidet bei vielen Open-Source-Projekten allein der Maintainer. Man ist daher gut beraten, sich über die Gepflogenheiten des Projekts zu informieren, bevor man Patches einreicht, die keine Chance auf Integration haben.
Manchmal könnte man den Eindruck bekommen, dass Open-Source-Entwickler gar nicht wollen, dass man ihnen hilft, sondern dass sie ihr Projekt am liebsten ganz allein programmieren möchten. Oft berücksichtigen sie gerade einmal Bugfixes, während Patches mit tollen neue Features etliche Versionen lang ganz offensichtlich ignoriert werden, sodass man seine eigenen Patches immer wieder überarbeiten muss, damit man diese neuen Funktionen wenigstens selbst benutzen kann.
Doch der erste Eindruck täuscht. Prinzipiell freuen sich so gut wie alle Maintainer, wie man die Projekt-Verantwortlichen nennt, über Hilfe von außen – allerdings ist nicht jeder Patch, der per E-Mail hereinkommt, auch automatisch hilfreich. Das liegt oft daran, dass die Maintainer sehr konkrete Vorstellungen davon haben, wie ihr Projekt aussehen und in welche Richtung es sich entwickeln soll.
Tatsächlich arbeiten vor allem kleinere Open-Source-Projekte nach totalitären Prinzipien: Der Maintainer ist hier meist der Urvater des Projekts, es ist also sein Kind. Und genau so, wie Nachbarn und Bekannte gerne Tipps zur Kindererziehung geben können, man letztlich aber selbst entscheidet, wie man sein Kind wirklich behandelt, können andere Programmierer gern Vorschläge machen oder fertige Patches einreichen – es ist jedoch Sache des Maintainers, zu entscheiden, welche Teile er davon tatsächlich verwendet.
Das beste Beispiel für eine solche totalitäre Open-Source-Entwicklung ist der Linux-Kernel. Letztlich ist es dem Linux-Vater Linus Torvalds vorbehalten, zu entscheiden, welche Funktionen er in "seinen" Kernel integriert und welche er vielleicht auf später verschiebt oder gar ganz verwirft.
Bei anderen Projekten wie zum Beispiel Debian findet man immerhin demokratische Ansätze. Dort werden die Maintainer von den Entwicklern gewählt – eine Basisdemokratie, wo die Anwender darüber entscheiden, was letztlich gemacht wird, ist aber auch das nicht. Und selbst wenn der Debian-Maintainer demokratisch gewählt wurde, wird nicht darüber abgestimmt, welche Patches er integriert und welche nicht.
Die Gründe, warum Patches nicht berücksichtigt werden, sind meist, dass sie auf die falsche Weise, bei der falschen Person oder in einem Zustand eingereicht werden, in dem sie nur mit viel Arbeit integriert werden können. Auch Programmierfehler oder ein schlechter Programmierstil sorgen dafür, dass ein Patch ohne ihn auch nur einmal ausprobiert zu haben, im Mülleimer landet.
Wer sich an der Open-Source-Entwicklung beteiligen möchte, tut also gut daran, zunächst einmal die Gepflogenheiten des jeweiligen Projekts kennenzulernen. Während es bei größeren Projekten fast immer eine Entwickler-Mailing-Liste gibt, die man abonnieren und aufmerksam verfolgen sollte, kommunizieren die Entwickler kleinerer Projekte oft direkt untereinander. Daher ist es ratsam, in diesen Fällen die auf der Projektseite angegebene Kontaktperson oder den Maintainer direkt anzusprechen und zu fragen, ob überhaupt Interesse an dem eigenen Patch besteht und in welcher Form man ihn einreichen soll.
Grundsätzlich gilt: Je weniger Mühe ein Maintainer hat, einen Patch zu integrieren, desto eher wird er ihn berücksichtigen. Daher sollte man als Basis für seine Patches nicht die aktuelle stabile Programmversion verwenden, sondern die allerneueste Entwicklerversion – möglicherweise sind dort ja schon einige der Funktionen oder Bugfixes enthalten. Außerdem wäre ein Patch auf Basis des Stable-Release möglicherweise gar nicht mehr auf die Entwicklerversion anwendbar, sodass der Maintainer die Arbeit hätte, zunächst den Patch auf die neue Version zu portieren, bevor er ihn überhaupt berücksichtigen kann.
Dass man sich beim Programmierstil an den des Maintainers oder der anderen Entwickler hält, was die Benennung von Variablen und Funktionen, aber auch das Einrücken der Zeilen angeht, sollte eigentlich selbstverständlich sein – ist es in der Praxis aber leider nicht. Bevor ein Maintainer den Code stupide abschreibt, dabei die Variablennamen ändert und die Einrückung korrigiert, beschäftigt er sich möglicherweise lieber mit dem nächsten Patch, bei dem das alles gar nicht nötigt ist.
Ein großes Problem sind Sammelpatches, die gleich mehrere Funktionen enthalten oder an verschiedenen Ecken des Projekts eigentlich unabhängige Änderungen durchführen. Diese finden eigentlich nur dann den Weg in die offiziellen Projekt-Quellen, wenn der Maintainer sämtliche Funktionen in dieser Weise auch wirklich integrieren möchte – was jedoch selten der Fall sein dürfte. Nur einzelne Funktionen, die er gut heißt, kann er aus solchen Sammelpatches jedoch nur mit großer Mühe herauspicken, weshalb es für ihn einfacher ist, den Patch insgesamt zu verwerfen.
Besser ist es daher, wenn man für jede Funktion und jeden Bugfix einen einzelnen Patch erstellt und diese auch einzeln einreicht. Das führt manchmal zu dem Problem, dass sich Patch B nicht mehr ohne weiteres anwenden lässt, wenn Bugfix A eingefügt wurde. In diesen Fällen reicht man zusätzlich einen weiteren Patch ein, der beide Änderungen enthält – so kann der Maintainer wählen, ob er vielleicht nur den Bugfix einsetzen möchte, oder nur die neue Funktion, oder aber beides. Auch schadet es nie, dem Maintainer anzubieten, bei Bedarf einen Sammelpatch mit den von ihm gewünschten Funktionen bereitzustellen.
Das ist manchen Gelegenheitsentwicklern jedoch zu aufwendig, oder aber sie sind mit der vom Maintainer vorgegebenen Roadmap für das Projekt nicht einverstanden. Dann greifen manche zur Anarchie, setzen sich über die Vorgaben des Maintainers hinweg und tun stattdessen, was sie selbst für richtig halten – es entsteht ein Fork. Dank Open Source ist dies praktisch immer möglich, allerdings nicht immer sinnvoll.
Denn damit begibt man sich selbst in die Rolle des Maintainers, und sofern man nicht zukünftig seine Freizeit damit verbringen möchte, das Programm nach den Wünschen irgendwelcher fremden Leute weiterzuentwickeln, installiert man sich selbst als neuen totalitären Herrscher. Für das Projekt bedeutet ein Fork fast immer einen Rückschritt: Wo reicht ein fremder Entwickler zukünftig seine Patches ein? Beim Original, oder dem Fork? Und wie weit will man die Projekte auseinander driften lassen? Will man alle Patches, die das Original-Projekt einfügt, auch für den eigenen Fork umschreiben?
Eine totalitäre Software-Entwicklung hat also durchaus ihre Vorteile, da es hier jemanden gibt, der das Gesamtprojekt im Auge hält und darauf achtet, dass die Entwicklung in die (nach seiner Meinung) richtige Richtung geht. Natürlich wäre eine basisdemokratische Entwicklung für die Anwender wünschenswert – allerdings wollen sich die wenigsten Open-Source-Entwickler vorschreiben lassen, was sie in ihrer Freizeit programmieren und was nicht. (mid) (mid)
