Wenn ich auf einer Party davon erzähle, dass ich freie Software schreibe, wird mir heutzutage nicht mehr mit leerem Blick begegnet; vielmehr ist die Reaktion "Ach ja, Open Source – wie Linux?". Und ich nicke eifrig zustimmend: "Ja, genau! Das mache ich.". Es ist angenehm, nicht mehr so ganz am Rand zu stehen. In der Vergangenheit war die nächste Frage leicht vorhersehbar: "Wie verdient man denn dabei Geld?". Als Antwort fasste ich die wirtschaftlichen Hintergründe von Open Source kurz zusammen: Es gibt Organisationen, die daran interessiert sind, dass eine bestimmte Software existiert, ohne sie verkaufen zu müssen, sie wollen schlicht sicher gehen, dass sie verfügbar ist und gepflegt wird: als Werkzeug, und nicht als Ware. In letzer Zeit jedoch dreht sich die nächste Frage nicht immer um Geld. Die Wirtschaftlichkeit von Open-Source-Software Im Prinzip sind die Begriffe "Open Source" und "Frei" in diesem Kontext Synonyme. Sie werden in im Kapitel ausführlicher behandelt. ist nicht mehr so rätselhaft, und viele Nicht-Programmierer verstehen mittlerweile – oder sind zumindest nicht überrascht darüber – , dass manche damit ihr Geld verdienen. Stattdessen ist die Frage, die ich immer häufiger höre, "Ach ja, wie funktioniert das eigentlich?". Dafür hatte ich keine gute Antwort parat, und je mehr ich versuchte eine zu finden, desto bewusster wurde mir, was für ein komplexes Thema es wirklich ist. Ein Open-Source-Projekt zu leiten, ist nicht unbedingt wie die Leitung einer Firma (stellen Sie sich vor, ständig mit einer Gruppe von Freiwilligen über die Natur Ihres Produkts diskutieren zu müssen, von denen Sie den meisten noch nicht einmal begegnet sind!). Es ist auch nicht wie die Leitung einer gewöhnlichen, gemeinnützigen Organisation oder eines Staates. Es gibt Ähnlichkeiten zu all dem, aber ich bin langsam zu dem Schluss gekommen, dass freie Software in dieser Hinsicht einzigartig ist. Es gibt vieles womit man sie sinnvoll vergleichen kann, aber nichts womit man sie gleichsetzen kann. Tatsächlich geht die Annahme etwas weit, dass man ein Open-Source-Projekt überhaupt "führen" könne. Ein Open-Source-Projekt kann begonnen und durch interessierte Beteiligte beeinflusst werden, oft sogar relativ stark. Aber niemand kann es sich aneignen, und solange es irgendwo Beteiligte gibt, die es fortführen wollen, kann es niemals von einer Partei stillgelegt werden. Jeder hat unendliche Macht; jeder hat keine Macht. Daraus ergibt sich eine interessante Dynamik. Das ist der Grund für dieses Buch. Freie Software-Projekte haben eine ausgeprägte Kultur entwickelt, mit einer Gesinnung, in der die Freiheit, Software zu entwickeln, die alles tut was man will, der zentrale Grundsatz ist. Das Ergebnis dieser Freiheit ist jedoch nicht eine Zerstreuung der einzelnen Beteiligten, so dass jeder seinen eigenen Weg mit seinem Code geht, sondern eine enthusiastische Zusammenarbeit. Tatsächlich ist die Kompetenz zur Zusammenarbeit eine der am meisten geschätzten Fähigkeiten in Open-Source-Software. Diese Projekte zu verwalten, ist wie das Angehen einer Art hypertrophisierten Kooperation, in der sowohl die eigen Fähigkeit mit anderen zusammenzuarbeiten, als auch neue Wege für diese Zusammenarbeit zu finden, konkrete Vorteile für die Software bringen kann. Dieses Buch versucht Techniken hierzu zu beschreiben. Es ist keineswegs vollständig, aber immerhin ein Anfang. Gute freie Software ist an und für sich schon ein würdiges Ziel, und ich hoffe, dass Leser die hierin nach neuen Wegen suchen, mit dem zufrieden sein werden, was sie hier finden. Darüber hinaus hoffe ich etwas von der Freude an der Arbeit mit einem motivierten Team von Open-Source-Entwicklern und der wundervoll direkten Art mit Benutzern zu interagieren, zu der Open Source ermutigt, vermitteln zu können. An einem erfolgreichen Open-Source-Projekt teilzunehmen, macht Spaß, und letztlich ist es das, was das ganze System am Laufen hält. Dieses Buch richtet sich an Softwareentwickler und Führungskräfte, die mit dem Gedanken spielen, ein Open-Source-Projekt zu starten, oder bereits eines begonnen haben, und sich nun fragen wie es weitergeht. Es sollte auch für alle hilfreich sein, die sich zum ersten Mal an einem Open-Source-Projekt beteiligen wollen. Der Leser braucht kein Programmierer zu sein, sollte jedoch grundsätzliche Konzepte der Softwareentwicklung wie Quellcode, Compiler und Patches kennen. Erfahrung mit Open-Source-Software, ob nun als Anwender oder als Entwickler, ist nicht nötig. Wer sich bereits an Open-Source-Projekten beteiligt hat, wird vielleicht manchen Abschnitt als überflüssig empfinden, und ggf. überspringen wollen. Aufgrund der potenziell breit gefächerten Erfahrung des Publikums habe ich versucht, Abschnitte klar zu kennzeichnen und darauf hinzuweisen, wann bereits mit der Materie vertraute Leser beruhigt weiterblättern können. Ein Großteil des Materials für dieses Buch stammt aus fünf Jahren Arbeit am Subversion-Projekt (). Subversion ist ein Open-Source-System zur Versionsverwaltungengl. Version Control, das von Grund auf neu geschrieben wurde, und als Ablösung für CVS konzipiert ist, dem Quasi-Standard für Versionsverwaltung in der Open-Source-Gemeinschaft. Das Projekt wurde von meinem Arbeitgeber, CollabNet (), im Frühjahr 2000 begonnen, und zum Glück verstand CollabNet, es gleich von Beginn an als echtes gemeinschaftliches, verteiltes Unterfangen zu betreiben. Von Anfang an bekamen wir großen Zulauf an Freiwilligen. Heute sind um die 50 Entwickler am Projekt beteiligt, von denen nur wenige bei CollabNet angestellt sind. Subversion ist in vielerlei Hinsicht ein klassisches Beispiel für ein Open-Source-Projekt, und ich griff darauf mehr zurück, als ich ursprünglich erwartet hatte. Zum Teil einfach aus Bequemlichkeit: Wenn ich nach einem Beispiel für ein bestimmtes Phänomen suchte, konnte ich mich meist spontan an einem Fall aus Subversion erinnern. Obwohl ich an anderen Open-Source-Projekten in unterschiedlichem Maß beteiligt bin, und mit Freunden und Bekannten rede, die ebenfalls an vielen weiteren beteiligt sind, wurde mir beim Schreiben schnell klar, dass ich meine Behauptungen durch Fakten stützen sollte. Allein auf der Grundlage dessen, was ich aus den öffentlichen Archiven ihrer Mailinglisten entnehmen konnte, mochte ich keine Äußerungen über Ereignisse in anderen Projekten machen. Würde jemand dasselbe mit Subversion versuchen, da bin ich sicher, läge er nur in der Hälfte der Fälle richtig. Wenn ich also Inspiration oder Beispiele aus Projekten nahm, mit denen ich keine direkte Erfahrung hatte, versuchte ich zuerst, mit einem Beteiligten aus dem Projekt zu reden, mit jemandem der wusste, was sich tatsächlich abgespielt hatte. Ich arbeite seit 5 Jahren an Subversion, habe aber schon seit 12 Jahren mit freier Software zu tun. Unter anderem haben folgende Projekte dieses Buch beeinflusst: Das GNU Emacs Text-Editor-Projekt der GNU Software Foundation, bei der ich ein paar kleine Pakete pflege. Concurrent Versions System (CVS), an dem ich intensiv mit Jim Blandy von 1994 bis 1995 arbeitete, seitdem aber nur sporadisch beteiligt bin. Die Open-Source-Projekte unter dem gemeinschaftlichen Namen Apache Software Foundation, insbesondere die Apache Portable Runtime (APR) und der Apache HTTP Server. OpenOffice.org, die Berkeley-Datenbank von Sleepycat, und die MySQL-Datenbank, an denen ich zwar nicht persönlich beteiligt war, die ich aber beobachtet und zu denen ich Kontakt gepflegt habe. GNU Debugger (GDB) (ebenso). Das Debian-Projekt (ebenso). Die Liste ist natürlich unvollständig. Wie die meisten Open-Source-Programmierer halte ich beiläufig Kontakt zu vielen verschiedenen Projekten, nur um ein allgemeines Gefühl für ihren Zustand zu behalten. Ich werde sie hier nicht alle beim Namen nennen, aber sie werden im Text an entsprechender Stelle erwähnt. Es hat vier mal länger gedauert dieses Buch zu schreiben, als ich ursprünglich geplant hatte, und die meiste Zeit davon fühlte ich mich, als würde beständig ein Konzertflügel über meinem Kopf schweben. Erst die Hilfe vieler Menschen hat es mir ermöglicht, dieses Buch fertigzustellen, ohne dabei den Verstand zu verlieren. Mein Redakteur, Andy Oram bei O'Reilly, war der Traum eines jeden Schriftstellers. Er kennt nicht nur das Thema (viele Vorschläge kamen von ihm), sondern hat auch die seltene Gabe zu verstehen, was man meint und kann einem helfen, es in die richtigen Worte zu fassen. Es war eine Ehre, mit ihm zu arbeiten. Danke auch an Chuck Toprek, der den Vorschlag zu diesem Buch direkt an Andy geleitet hatte. Brian Fitzpatrik hat das ganze Material durchgesehen, während ich es schrieb, was nicht nur dazu führte, dass das Buch besser wurde, sondern mich auch dann am Schreiben hielt, wenn ich lieber an jedem anderen Ort auf der Welt gewesen wäre, als vor dem Bildschirm. Auch Ben Collins-Sussman und Mike Pilato prüften meinen Fortschritt und waren stets erfreut, mit mir – manchmal sehr ausführlich – zu diskutieren, egal welches Thema ich in der Woche zu behandeln versuchte. Sie bemerkten auch, wenn ich erlahmte und munterten mich durch kleine Nörgeleien auf. Danke Jungs! Biella Coleman schrieb zur selben Zeit an ihrer Doktorarbeit, wie ich an diesem Buch. Sie weiß was es heißt, sich jeden Tag hinzusetzen und zu schreiben. Sie war ein inspirierendes Beispiel und bot mir ein mitfühlendes Ohr. Sie hat auch einen faszinierenden Anthropologen-Blickwinkel auf die Bewegung der freien Software und lieferte Ideen und Referenzen, die ich im Buch verwenden konnte. Alex Golub – auch ein Anthropologe mit einem Fuß in die Welt der freien Software, der ebenfalls zu der Zeit an seiner Doktorarbeit schrieb – bot am Anfang eine außerordentliche Unterstützung, was eine große Hilfe war. Micah Anderson schien irgendwie nie besonders bedrückt durch seine eigene Schreibarbeit, was auf eine krankhafte, Neid erzeugende Art inspirierend war. Er war aber immer mit Freundschaft, Gesprächsbereitschaft und (mindestens einmal) mit technischer Unterstützung zur Stelle. Danke Micah! Jon Trowbridge und Sander Striker gaben sowohl Aufmunterung als auch konkrete Hilfe – ihre breite Erfahrung hinsichtlich freier Software lieferte Material, an das ich sonst nie herangekommen wäre. Danke an Greg Stein, nicht nur für seine Freundschaft und zeitige Ermunterung, sondern dafür, dass er dem Subversion-Projekt gezeigt hat, wie wichtig der regelmäßige Code-Review für den Aufbau einer Entwickler-Gemeinschaft ist. Danke auch an Brian Behlendorf, der taktvoll in unsere Köpfen hämmerte, wie wichtig es ist, Diskussionen öffentlich zu führen; Ich hoffe, dass dieses Prinzip sich durchweg im Buch wiederspiegelt. Danke an Benjamin "Mako" Hill und Seth Schoen für verschiedene Gespräche über freie Software und ihre Politik; an Zack Urlocker und Louis Suarez-Potts dafür, dass sie sich Zeit für Gespräche aus ihren Terminkalendern nahmen; an Shane auf der Slashcode-Liste für die Erlaubnis, seinen Beitrag zitieren zu dürfen; und an Hagen So für seine enorm hilfreichen Vergleiche verschiedener Anbieter von Hosting-Paketen. Danke an Alla Dekhtyar, Polina und Sonya für ihre unermüdliche und geduldige Ermutigung. Ich bin sehr froh, unsere Abende nicht mehr vorzeitig beenden zu müssen (bzw. dies ohne Erfolg zu versuchen), um "das Buch" weiter zu schreiben. Danke an Jack Tepenning für seine Freundschaft, Unterhaltung, und seine sture Weigerung, eine einfache und falsche Analyse jemals einer schwierigeren aber richtigen vorzuziehen. Ich hoffe, dass ein Teil seiner langjährigen Erfahrung sowohl in der Softwareentwicklung als auch in der Softwareindustrie auf dieses Buch abgefärbt hat. CollabNet war besonders großzügig darin, mir eine flexible Zeitplanung zu erlauben, und beschwerte sich nicht, als ich viel länger brauchte als ursprünglich geplant. Ich kenne die komplexen Wege nicht, auf denen eine Betriebsleitung zu solchen Entscheidungen gelangt, aber ich vermute es hatte etwas mit Sandyha Klute, und später mit Mahesh Murthy, zu tun – meinen Dank ihnen beiden. Das gesamte Subversion-Team ist in den letzten fünf Jahren eine Inspiration gewesen, und vieles in diesem Buch habe ich durch die Zusammenarbeit in ihm gelernt. Ich werde hier nicht jeden beim Namen nennen, es sind einfach zu viele, aber ich beschwöre jeden Leser, dem ein Mitwirkender von Subversion über den Weg läuft, diesem ein Getränk seiner Wahl zu spendieren – ich jedenfalls habe das vor. Oftmals wetterte ich gegenüber Rachel Scollen über den Zustand des Buches; stets war sie bereit mir zuzuhören und irgendwie schaffte sie es immer, die Probleme kleiner zu machen als vor dem Gespräch. Das war eine ungeheurere Hilfe – Danke. Danke (nochmals) an Noel Taylor, der sich sicherlich fragte, warum ich noch ein Buch schreiben wollte, wenn man bedenkt wie oft ich mich beim letzten Mal beschwert hatte, dessen Freundschaft und Führung bei Golosá mir half, Musik und Kameradschaft in meinem Leben zu halten, selbst zu den betriebsamsten Zeiten. Danke auch an Matthew Dean und Dorothea Samtleben, Freunde und lange musikalische Leidensgenossen, die sehr verständnisvoll waren, als meine Ausreden für Proben sich stapelten. Megan Jennings blieb durchweg unterstützend und ehrlich interessiert an dem Thema, obwohl es ihr fremd war – eine großartige Stärkung für einen unsicheren Schriftsteller. Danke! Ich hatte vier sachkundige und gewissenhafte Kritiker für dieses Buch: Yoav Shapira, Andrew Stellman, Davanum Srinivas und Ben Hyde. Das Buch wäre sicherlich besser, wenn ich all ihre ausgezeichneten Vorschläge hätte aufnehmen können. Zeitmangel zwang mich leider, mich aufs Herauspicken zu beschränken, aber die Verbesserungen waren dennoch erheblich. Alle übrig gebliebenen Fehler sind voll und ganz mir zuzuschreiben. Meine Eltern, Frances und Henry waren wunderbare Unterstützer wie immer, und da dieses Buch weniger technisch ist als das letzte, hoffe ich, sie werden es etwas leserlicher finden. Schließlich möchte ich Karen Underhill und Jim Blandy danken, denen dieses Buch gewidmet ist. Die Freundschaft und das Verständnis von Karen haben mir alles bedeutet, nicht nur während ich an diesem Buch schrieb, sondern auch die letzten sieben Jahre hindurch. Ohne ihre Hilfe hätte ich es sicher nicht geschafft. Dasselbe gilt für Jim, einen echten Freund und Hacker von einem Hacker, der mir beibrachte was freie Software ist, ähnlich wie ein Vogel, der ein Flugzeug fliegen lehrt. Die Gedanken und Meinungen in diesem Buch sind meine eigenen. Sie stellen nicht unbedingt die Sicht von CollabNet dar oder die des Subversion-Projekts dar. Diese Buch wurde mit großzügiger Unterstützung der mg.softech GmbH ins Deutsche übersetzt, der ich an dieser Stelle danken möchte. Es ist ein gutes Beispiel für die gemeinsamen Interessen von Open-Source-Gemeinschaft und Wirtschaft, die sogar über die tatsächliche Produktion von offenem Quellcode hinausgeht. Als abgeschlossen möchte ich diese Übersetzung jedoch nicht betrachten, und ich lade Sie als Leser herzlich ein, sich an der Fertigstellung zu beteiligen. Ich bin mir sicher, Sie werden über manches in dem Buch stolpern und wir freuen uns natürlich über jeden Beitrag. Als ich mich vor einigen Jahren mit einer Projektmanagement-Frage an Google wandte, ahnte ich nichts davon, in welcher Ausführlichkeit ich sie beantwortet bekommen würde: ich fand mich mitten in einem Kapitel dieses großartigen Buches und im festen Griff einer spannenden Lektüre. Producing Open Source Software ist nicht nur selbst ein vorbildliches Beispiel eines Open-Source-Projekts, es stellt auch den Autor und seine vielen Übersetzer vor die besondere Herausforderung, mit einem atemberaubenden Fortschritt der Open-Source-Bewegung mitzuhalten. Die Alltagssprache der (deutschen) Softwareentwickler ist voll von englischem Fachjargon. Ich versuche von diesem so viel wie möglich zu übersetzen, um das Thema einem möglichst großen Kreis von Lesern (oftmals Open-Source-Anwender) zugänglich zu machen.