Author: mbarkhau Date: Sun Apr 27 10:07:36 2008 New Revision: 1459 Log: Fixed minor typos
Modified: trunk/de/ch00.xml trunk/de/ch01.xml Modified: trunk/de/ch00.xml ============================================================================== --- trunk/de/ch00.xml (original) +++ trunk/de/ch00.xml Sun Apr 27 10:07:36 2008 @@ -8,15 +8,15 @@ <para>Wenn ich auf einer Feier bin, schauen mich Leute nicht mehr mit einem blanken Gesichtsausdruck an, wenn ich ihnen erzähle, dass ich freie Software schreibe. "Ach ja, Open Source, wie Linux?" ist jetzt -die immer häufigere Reaktion. "Ja, genau! Das mache ich.". Es ist +die immer häufigere Reaktion. "Ja, genau! Das mache ich.". Es ist schön, nicht mehr ganz zu einer Randgruppe zu gehören. In der -Vergangenheit konnte ich die Nächste Frage meistens schon erahnen: +Vergangenheit konnte ich die nächste Frage meistens schon erahnen: "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 direkt verkaufen zu müssen. Es geht -ihnen einfach darum, die Software nutzen zu können und weniger es -als Produkt verkaufen zu können.</para> +ihnen einfach darum, die Software zu nutzen und nicht so sehr es +als Produkt zu verkaufen.</para> <para>In letzer Zeit jedoch, drehte sich die nächste Frage nicht immer um Geld. Die Wirtschaftlichkeit von Open Source Software<footnote><para> @@ -30,8 +30,8 @@ dessen ist die Frage die ich immer häufiger höre, "<emphasis>Ach ja, wie funktioniert das eigentlich?</emphasis>".</para> -<para>Dazu hatte ich keine zufriedenstellende Antwort parat, und je mehr -ich versuchte eine zu finden, desto mehr wurde mir bewusst, was für ein +<para>Dafür hatte ich keine gute Antwort parat, und je mehr ich +versuchte eine zu finden, desto mehr wurde mir bewusst, 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 @@ -44,31 +44,31 @@ 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 <emphasis>angefangen</emphasis> werden und es kann durch -interessierte Beteiligte beeinflusst werden, oft sogar relativ stark. -Aber es kann niemals zum Eigentum eines einzelnen Besitzers gemacht +interessierte Beteiligte beeinflusst werden, oft sogar relativ stark, +aber es kann niemals zum Eigentum eines einzelnen Besitzers gemacht werden, und solange es irgendwo Beteiligte gibt, die daran interessiert sind es fortzuführen, kann es niemals von einer Partei stillgelegt werden. Jeder hat unendliche Macht; jeder hat keine Macht. Es ergibt sich daraus eine interessante Dynamik.</para> <para>Das ist der Grund für dieses Buch. Freie Software Projekte haben -eine ausgeprägten Kultur entwickelt, mit einer Gesinnung in dem die +eine ausgeprägte Kultur entwickelt, mit einer Gesinnung in dem die Freiheit Software zu entwickeln, die alles macht was man will, der zentrale Grundsatz ist. Das Ergebnis dieser Freiheit ist jedoch nicht -eine Zerstreuung der einzelnen Beteiligten, von denen jede ihren eigenen -Weg mit dem Code geht, sondern eine enthusiastische Zusammenarbeit. +eine Zerstreuung der einzelnen Beteiligten, die alle ihren eigenen +Weg mit dem Code gehen, sondern eine enthusiastische Zusammenarbeit. Tatsächlich ist die Kompetenz zur Zusammenarbeit, einer der am meisten geschätzten Fähigkeiten in Open Source Software. Diese Projekte zu -verwalten ist wie das Angehen einer Art Hypertrophisierten Kooperation, -indem nicht nur die eigen Fähigkeit mit anderen zusammenzuarbeiten, -sondern auch neue Wege zu finden mit ihnen zusammenzuarbeiten, konkrete -Vorteile für die Software bringen kann. Dieses Buch versucht Techniken -zu beschreiben um das zu erreichen. Es ist keineswegs vollständig, aber +verwalten ist wie das Angehen einer Art exzessive Kooperation, +indem die eigene Fähigkeit mit anderen zusammenzuarbeiten und neue Wege +zu finden mit ihnen zusammenzuarbeiten, konkrete Vorteile für die +Software bringen kann. Dieses Buch versucht Techniken zu beschreiben +um das zu erreichen. Es ist keineswegs vollständig, aber immerhin ein Anfang.</para> <para>Gute freie Software ist an und für sich schon ein würdiges Ziel, -und ich hoffe, dass Leser die nach neue Wege suchen es zu erreichen mit -dem was sie hier finden zufrieden sein werden. Darüber hinaus hoffe ich +und ich hoffe, dass Leser die nach neue Wege suchen es zu erreichen, mit +dem was sie hier finden, zufrieden sein werden. 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 Benutzer zu interagieren, wozu Open Source ermutigt, vermitteln zu können. An einem @@ -92,9 +92,9 @@ grundsätzliche Konzepte der Softwareentwicklung wie Quellcode, Compiler, und Patches kennen.</para> -<para>Vorhergehende Erfahrung mit Open Source Software, entweder als -Anwender oder als Entwickler ist nicht notwendig. Wer sich bereits an -Open Source Projekte beteiligt hat, wird zumindest manche Abschnitte +<para>Erfahrung mit Open Source Software, entweder als Anwender oder +als Entwickler ist nicht nötig. Wer sich bereits an Open Source +Projekte beteiligt hat, wird zumindest manche Abschnitte als überdrü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, für wen es @@ -106,19 +106,19 @@ <sect1 id="sources"> <title>Quellen</title> -<para>Ein Großteil des Rohmaterials für dieses Buch stammt aus fünf +<para>Ein Großteil der Materialien für dieses Buch stammen aus fünf Jahren Arbeit an dem Subversion Projekt (<ulink url="http://subversion.tigris.org/"/>). Subversion ist ein Open Source System zur Versionsverwaltung<footnote><para>engl. Version -Control</para></footnote>, welches von Grund auf neu geschrieben wurde, -und als Ablösung von CVS, der quasi Standard Versionsverwaltung in der -Open Source Gemeinschaft angedacht ist. Das Projekt wurde von meinem +Control</para></footnote>, dass von Grund auf neu geschrieben wurde, +und als Ablösung für CVS, der quasi Standard Versionsverwaltung in der +Open Source Gemeinschaft, gedacht ist. Das Projekt wurde von meinem Arbeitgeber, CollabNet (<ulink url="http://www.collab.net/"/>), im -Frühjahr 2000 angefangen und zum Glück verstand es CollabNet gleich von -Anfang an, es als echtes gemeinschaftliches, verteiltes Unterfangen zu +Frühjahr 2000 angefangen und zum Glück verstand CollabNet, es gleich von +Anfang an, als echtes gemeinschaftliches, verteiltes Unterfangen zu betreiben. Wir bekamen schon am Anfang eine sehr große Beteiligung durch freiwillige Entwickler. Heute sind ca. 50 Entwickler an dem Projekt -beteiligt, von denen nur wenige Mitarbeiter von CollabNet sind.</para> +beteiligt, von denen nur wenige für CollabNet arbeiten.</para> <para>Subversion ist in vielerlei Hinsicht, ein klassisches Beispiel für ein Open Source Projekt, und ich griff darauf mehr zurück, als @@ -127,17 +127,16 @@ konnte ich mich spontan an einem Fall aus Subversion erinnern. Obwohl ich an anderen Open Source Projekten in unterschiedlichem Maße beteiligt bin, und mit Freunden und Bekannten rede, die ebenfalls an vielen weitern -beteiligt sind, wird einem beim schreiben schnell bewusst, dass man alle +beteiligt sind, wird einem beim schreiben schnell klar, dass man alle Behauptungen überprüfen muss. Allein auf der Grundlage von dem was ich aus den öffentlichen Archiven ihrer E-Mail Verteiler<footnote>engl. -mailing list</footnote> entnehmen konnte, wollte ich jedoch keine -Äußerungen über Ereignisse in anderen Projekten machen. Wenn jemand das +mailing list</footnote> entnehmen konnte, wollte ich keine Äußerungen +über Ereignisse in anderen Projekten machen. Wenn jemand das mit Subversion versuchen würde, bin ich mir sicher, sie wären die Hälfte der Zeit richtig, die andere falsch. Als ich also Inspiration oder Beispiele aus Projekten mit denen ich keine direkte Erfahrung hatte nahm, versuchte ich zuerst mit einem Beteiligten aus dem Projekt zu -reden, jemand den ich vertrauen konnte zu wissen, was sich wirklich -abgespielt hat.</para> +reden, jemand der wusste, was sich wirklich abgespielt hat.</para> <para>Ich arbeite seit 5 Jahren an Subversion, aber ich habe seit 12 Jahren schon mit freier Software zu tun. Unter anderem, haben folgende @@ -145,8 +144,7 @@ <itemizedlist> <listitem><para>Das GNU Emacs Text Editor Projekt der GNU Software - Foundation, bei dem ich einige wenige kleinere Pakete - instand halte.</para> + Foundation, bei dem ich ein paar kleine Pakete pflege.</para> </listitem> <listitem><para>Concurrent Versions System (CVS), an dem ich intensiv mit Jim Blandy von 1994 bis 1995 arbeitete, seitdem aber nur @@ -158,8 +156,8 @@ </listitem> <listitem><para>OpenOffice.org, die Berkeley Datenbank von Sleepycat, und MySQL Datenbank, an denen ich zwar nicht persönlich - beteiligt gewesen bin, die ich aber beobachtet habe und in - manchen Fällen mit Beteiligten geredet habe.</para> + beteiligt gewesen bin, die ich aber beobachtet habe und + manchmal mit Beteiligten geredet habe.</para> </listitem> <listitem><para>GNU Debugger (GDB) (ebenso).</para> </listitem> @@ -167,11 +165,11 @@ </listitem> </itemizedlist> -<para>Selbstverständlich ist das keine vollständige Liste. Wie die -meisten Open Source Programmierer, behalte ich einen groben Überblick -über viele verschiedene Projekte, nur um ein allgemeines Gefühl für +<para>Die Liste ist natürlich unvollständige. Wie die meisten Open +Source Programmierer, behalte ich einen groben Überblick über viele +verschiedene Projekte, 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 den entsprechenden Stelle erwähnt. +nennen, aber sie werden im Text an entsprechender Stelle erwähnt. </para> </sect1> @@ -196,13 +194,13 @@ <para>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 am schreiben hielt zu Zeiten, an denen ich überall -lieber auf der Welt gewesen wäre, als vor dem Bildschirm. Ben -Collins-Sussman und Mike Pilato prüften meinen Fortschritt, und waren -immer gerne bereit mit mir—manchmal sehr ausführlich—zu +sondern mich auch am schreiben hielt, als ich überall lieber auf +der Welt gewesen wäre, als vor dem Bildschirm. Ben Collins-Sussman +und Mike Pilato prüften meinen Fortschritt, und waren immer gerne +bereit mit mir—manchmal sehr ausführlich—zu diskutieren, egal welches Thema ich in der Woche versuchte zu -behandeln. Sie bemerkten auch als ich langsamer wurde und wiesen als es -nötig wurde, dezent darauf hin. Danke Jungs.</para> +behandeln. Sie bemerkten auch als ich langsamer wurde und wiesen +bei Zeiten, dezent darauf hin. Danke Jungs.</para> <para>Biella Coleman schrieb zur selben Zeit an ihrer Doktorarbeit, wie ich an diesem Buch. Sie weiß was es heißt, sich jeden Tag @@ -214,11 +212,11 @@ ebenfalls zu der Zeit an seiner Doktorarbeit schrieb, war am Anfang eine besondere Unterstützung, was mir sehr geholfen hat.</para> -<para>Micha Anderson erschien irgendwie nie besonders unterdrückt +<para>Micah Anderson erschien irgendwie nie besonders unterdrückt durch seine eigene Schreibarbeit, was auf eine kranke, Neid erzeugende Art, inspirierend war. Er war aber immer mit Freundschaft, Gesprächsbereitschaft und (mindestens ein mal) mit technischer -Unterstützung zur Stelle. Danke Micha!</para> +Unterstützung zur Stelle. Danke Micah!</para> <para>Jon Trowbridge und Sander Striker gaben beide Aufmunterung und Konkrete Hilfe—ihre breite Erfahrung im Bezug auf freie @@ -229,7 +227,7 @@ zeitige Ermunterung, sondern dafür, dass er dem Subversion Projekt gezeigt hat, wie wichtig der regelmäßige Code Review für den Aufbau einer Gemeinschaft von Entwicklern ist. Danke auch an Brian Behlendorf, -der taktvoll in unseren Köpfen Hämmerte, wie Wichtig es ist Diskussionen +der taktvoll in unseren Köpfen Hämmerte, wie wichtig es ist Diskussionen öffentlich zu halten; Ich hoffe, dass dieses Prinzip sich durchweg im Buch widerspiegelt.</para> @@ -241,10 +239,10 @@ enorm hilfreichen Vergleiche verschiedener Anbieter von gebündeltem Hosting.</para> -<para>Danke an Alla Dekhtyar, Polina und Sonya für ihre unermüdliche und -geduldige Ermutigung. Ich bin sehr froh, nicht mehr unsere Abende -frühzeitig (bzw. ohne Erfolg) beenden zu müssen, um an "Das Buch" zu -arbeiten.</para> +<para>Danke an Alla Dekhtyar, Polina und Sonya für ihre unermüdliche +und geduldige Ermutigung. Ich bin sehr froh, nicht mehr unsere Abende +frühzeitig (bzw. ohne Erfolg) beenden zu müssen, um "Das Buch" weiter +zu schreiben.</para> <para>Danke an Jack Tepenning für seine Freundschaft, Unterhaltungen, und seine sture Weigerung, jemals eine einfache falsche Analyse einer @@ -252,7 +250,7 @@ seiner langjährigen Erfahrung sowohl in der Software Entwicklung als auch in der Software Industrie sich auf dieses Buch abgefärbt hat.</para> -<para>CollabNet war außergewöhnlich großzügig dabei mir eine flexible +<para>CollabNet war besonders großzügig dabei, mir eine flexible Zeitplanung zu erlauben, und beschwerte sich nicht als ich viel länger brauchte als ursprünglich geplant. Ich kenne nicht den komplexen Weg, wie die Betriebsleitung zu solchen Entscheidungen kommt, aber ich @@ -269,9 +267,9 @@ <para>Oft, als ich über den Zustand des Buches tobte, war Rachel Scollen bereit mir zuzuhören und irgendwie schaffte sie es immer die Probleme kleiner erscheinen zu lassen als vor dem Gespräch. Das war -eine ungemeine Hilfe—Danke.</para> +eine ungeheurere Hilfe—Danke.</para> -<para>Danke (nochmals) an Noel Taylor, der sich sicherlich fragte +<para>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 beschwert hatte, dessen Freundschaft und Führung bei Golosá mir half Musik und Kameradschaft in mein Leben zu halten, selbst @@ -284,9 +282,9 @@ <para>Ich hatte vier sachkundige und gewissenhafte Kritiker für dieses Buch: Yoav Shapira, Andrew Stellman, Davanum Srinivas und Ben Hyde. -Wenn es möglich gewesen wäre alle ihre ausgezeichneten Vorschläge mit -einzubeziehen wäre dies ein besseres Buch. Zeitmangel zwangen mich -leider dazu auszulesen und zu selektieren, aber die Verbesserungen +Das Buch wäre sicherlich besser, wenn es möglich gewesen wäre, alle +ihre ausgezeichneten Vorschläge mit einzubeziehen. Zeitmangel zwangen +mich leider dazu auszulesen und zu selektieren, aber die Verbesserungen waren dennoch erheblich. Alle übriggebliebenen Fehler, sind voll und ganz mir zuzuschreiben.</para> @@ -322,11 +320,11 @@ Übertragen, die ich an dieser Stelle danken möchte. Es ist ein gutes Beispiel für die gemeinsamen Interessen der Open Source Gemeinschaft und der Wirtschaft, die sogar über die tatsächliche Produktion von -offenem Quellcode hinausgeht. Als abgeschlossen möchte ich das Projekt -jedoch nicht bezeichnen, und ich lade Sie als Leser herzlich ein sich -an der Übersetzung zu beteiligen. Ich bin mir sicher, Sie werden über -manches in dem Buch stolpern und wir freuen uns natürlich über jeden -Beitrag, der die Lesbarkeit verbessert.</para> +offenem Quellcode hinausgeht. Als abgeschlossen möchte ich die +Übersetzung jedoch nicht bezeichnen, und ich lade Sie als Leser +herzlich ein sich daran zu beteiligen. Ich bin mir sicher, Sie werden +über manches in dem Buch stolpern und wir freuen uns natürlich über +jeden Beitrag.</para> </sect1> Modified: trunk/de/ch01.xml ============================================================================== --- trunk/de/ch01.xml (original) +++ trunk/de/ch01.xml Sun Apr 27 10:07:36 2008 @@ -4,12 +4,12 @@ <simplesect> -<para>Die meisten freie Software-Projekte schlagen fehl.</para> +<para>Nur wenige freie Software-Projekte sind erfolgreich.</para> <para>Man hört selten etwas von einem fehlgeschlagen Projekt. Nur erfolgreiche Projekte bekommen Aufmerksamkeit, und es gibt insgesamt so viele Open Source Projekte <footnote><para>Die beliebte Hosting -Seite SourceForge.net, verzeichnete Mitte April 2004 79,225 Projekte. +Seite SourceForge.net, verzeichnete mitte April 2004 79,225 Projekte. Natürlich ist das nicht einmal annähernd die Gesamtzahl der freien Software Projekte im Internet, sondern lediglich die Teilmenge die Sourceforge als Plattform gewählt haben.</para></footnote>, dass obwohl @@ -25,15 +25,15 @@ Sobald seine Nutzer Gemeinde aufhört zu wachsen, ohne die Entwickler Gemeinde übertroffen zu haben? Was ist wenn die Entwickler ihr Projekt verlassen, wenn sie merken, dass ein anderes Projekt die gleichen -Ziele hat und Sie unnötig einen Doppelten Aufwand betreiben, und wenn -sie sich diesem anderen Projekt anschließen und ihre früheren +Ziele hat und sie unnötig einen Doppelten Aufwand betreiben. Was ist +wenn sie sich diesem anderen Projekt anschließen und ihre früheren Anstrengungen mit einzubeziehen? Wurde das Projekt beendet, oder ist es nur umgezogen?</para> -<para>Aufgrund dieser Komplexität, ist es unmöglich ein genaue Ziffer -zur Ausfallquote zu geben. Einzelberichte aus über ein Jahrzehnt freier +<para>Durch diese Komplexität, ist es unmöglich die Ausfallquote +genau zu beziffern. Einzelberichte aus über ein Jahrzehnt freier Software, kurzes Stöbern auf SourceForge.net und ein wenig Googeln, -deutet jedoch alle auf den gleichen Schluss: die Rate ist extrem hoch, +deuten jedoch alle auf den gleichen Schluss: die Rate ist extrem hoch, wahrscheinlich in der Größenordnung von 90%–95%. Die Zahl wird größer wenn man überlebende aber nicht vernünftig laufende Projekte mit einbezieht: solche die zwar laufenden Code produzieren, aber weder ein @@ -42,16 +42,15 @@ <para>In diesem Buch geht es darum Versagen zu vermeiden. Es untersucht nicht nur wie man Sachen richtig macht, sondern wie man sie falsch -macht, damit Sie frühzeitig Probleme erkennen und korrigieren können. -Ich hoffe, dass Sie nach dem Durchlesen ein Repertoire an Techniken -haben, nicht nur um häufige Stolpersteine zu vermeiden, sondern auch um -mit dem Wachstum und der Pflege eines Projekts erfolgreich umzugehen. -Erfolg ist kein Nullsummenspiel, und in diesem Buch geht es nicht ums -Gewinnen oder der Konkurrenz voraus zu sein. Tatsächlich ist ein -wichtiger Teil beim Betrieb eines Open Source Projekts, die reibungslose -Zusammenarbeit mit anderen verwandten Projekten. Auf lange Sicht, trägt -jedes erfolgreiche Open Source Projekt zu dem Wohl der gesamten Welt der -freien Software bei.</para> +macht, um frühzeitig Probleme erkennen und korrigieren zu können. +Ich hoffe Ihnen zeigen zu können, wie man häufige Stolpersteine +vermeidet, und erfolgreich mit dem Wachstum und der Pflege eines +Projekts erfolgreich. Erfolg ist kein Nullsummenspiel, und in diesem +Buch geht es nicht darum zu Gewinnen oder der Konkurrenz voraus zu sein. +Tatsächlich ist ein wichtiger Teil beim Betrieb eines Open Source +Projekts, die reibungslose Zusammenarbeit mit anderen verwandten +Projekten. Auf lange Sicht, trägt jedes erfolgreiche Open Source +Projekt zum Wohl der gesamten Welt der freien Software bei.</para> </simplesect> @@ -61,29 +60,28 @@ selben Gründen fehlschlagen, wie proprietäre Software Projekte. Freie Software hat sicherlich kein Monopol auf unrealistische Anforderungen, vage Spezifikationen, unzureichende Verwaltung von Ressourcen, zu kurze -Entwurfsphasen, oder irgend eines der anderen Kobolde die der Software -Industrie bereits wohl bekannt sind. Es gibt einen gewaltigen menge -Schriftstücke zu diesem Thema und ich werde sie in diesem Buch nicht -versuchen zu duplizieren. Statt dessen werde ich versuchen die -spezifischen Probleme freier Software zu beschreiben. Wenn ein freies -Software Projekt an die Wand gefahren wird dann ist es oft weil die -Entwickler (oder die Projektleiter) nicht die einzigartigen Probleme von -Open Source Software zu würdigen wussten, auch wenn sie durchaus auf die -bekannteren Probleme der Closed-Source Entwicklung vorbereitet -waren.</para> +Entwurfsphasen, oder ein anderes der bekannten Kobolde aus der Software +Industrie. Es gibt eine gewaltige menge Schriftstücke zu diesem Thema +und ich werde sie in diesem Buch nicht versuchen zu reproduzieren. Statt +dessen werde ich versuchen die spezifischen Probleme freier Software zu +beschreiben. Wenn ein freies Software Projekt an die Wand gefahren wird, +dann ist es oft weil die Entwickler (oder die Projektleiter) nicht die +einzigartigen Probleme von Open Source Software zu würdigen wussten, +auch wenn sie durchaus auf die bekannteren Probleme der Closed-Source +Entwicklung vorbereitet waren.</para> <para>Einer der häufigsten Fehler sind unrealistische Erwartungen über die Vorteile von offenem Quellcode. Eine offene Lizenz garantiert weder, -dass eine Horde aktiver Entwickler urplötzlich anfangen werden, von sich -aus, Zeit in Ihr Projekt zu investieren, noch wird die Offenlegung die +dass eine Horde aktiver Entwickler urplötzlich anfangen, von sich aus, +Zeit in Ihr Projekt zu investieren, noch wird die Offenlegung die Krankheiten des Projekts automatisch heilen. Tatsächlich kann es sogar -genau das Gegenteil bewirken: Es kann eine ganze Reihe neuer Komplexität -hinzufügen, und kann auf kurzfristig <emphasis>mehr</emphasis> kosten -als es einfach im Betrieb zu behalten. Das Projekt zu öffnen, bedeutet -den Quellcode so um zu strukturieren, dass er für völlig Fremde -verständlich ist, eine Seite für Entwickler, sowie einen E-Mail Verteiler -einzurichten und oft auch zum erstem mal eine Dokumentation zu schreiben. -All das ist eine Menge Arbeit. Und <emphasis>falls</emphasis> +genau das Gegenteil bewirken: Es kann eine ganze Reihe neuer +Komplexitäten hinzufügen, und kurzfristig <emphasis>mehr</emphasis> +kosten als die Software einfach im Betrieb zu behalten. Das Projekt zu +öffnen, bedeutet den Quellcode so zu gestalten, dass er für völlig Fremde +verständlich ist, eine Seite für Entwickler aufzubauen, einen E-Mail +Verteiler einzurichten und oft auch zum erstem mal eine Dokumentation +zu schreiben. All das ist eine Menge Arbeit. Und <emphasis>falls</emphasis> interessierte Entwickler auftauchen, gibt es die zusätzliche Bürde, eine Zeit lang, ihre Fragen beantworten zu müssen, bevor man aus ihrer Anwesenheit einen Nutzen zieht. Entwickler Jamie Zawinski hatte folgendes @@ -93,7 +91,7 @@ <para><emphasis>Open Source funktioniert schon, aber es ist sicherlich kein Allheilmittel. Falls es ein warnende Lehre hier gibt, dann die, dass man ein sterbendes Projekt nicht einfach mit - dem magischen Elfenstaub des "Open Source" bestreuen kann und + dem magischen Elfenstaub des "Open Source" bestreuen kann, und danach alles wie von selbst läuft. Die Probleme sind nicht so einfach.</emphasis></para> @@ -107,52 +105,52 @@ Präsentation umfasst eine weite Reihe von Aufgaben, die sich alle um das Thema drehen, die Einstiegshürden niedriger zu legen. Das Projekt für Außenstehende einladend zu machen bedeutet, Anleitungen für Nutzer und -Entwickler zu schreiben, eine Webseite aufzubauen welche für +Entwickler zu schreiben, eine Webseite aufzubauen die für Neuankömmlinge informativ ist, möglichst viele der Kompilierungs- und Installationsvorgänge der Software zu automatisieren, usw. Viele -Entwickler behandeln diese Aufgaben leider so als wären sie nur von -zweitrangiger Bedeutung im Verhältnis zum eigentlichen Quellcode. Es -gibt hierfür ein paar Gründe. Erstens, kann es einem wie Fleißarbeit -vorkommen, denn die Vorteile sind zumeist nur für diejenigen sichtbar, -die noch am wenigsten mit dem Projekt zu tun haben und umgekehrt. -Schließlich brauchen solche die bereits mit dem Projekt vertraut sind -nicht unbedingt diese ganze Aufmachung. Sie wissen bereits wie man die -Software installiert, administriert und benutzt, schließlich haben sie -es ja auch geschrieben. Zweitens, sind die Fähigkeiten die Aufmachung -und Präsentation vernünftig zu machen andere, als solche die man -benötigt um Quellcode zu schreiben. Menschen neigen dazu sich auf das -was sie gut können zu konzentrieren, selbst wenn es für das Projekt -besser wäre ein wenig Zeit in etwas zu investieren, was ihnen weniger -liegt. <xref linkend="getting-started"/> behandelt Aufmachung und -Präsentation im Detail, und erklärt warum es entscheidend ist, dass -sie gleich von Anfang des Projekts an eine Priorität sein sollte.</para> +Entwickler behandeln diese Aufgaben leider so, als wären sie +nebensächlich zum eigentlichen Quellcode. Dafür gibt es ein paar Gründe. +Erstens, kann es einem wie Fleißarbeit vorkommen, denn es kommt meistens +nur denen zugute, die noch am wenigsten mit dem Projekt zu tun haben +und umgekehrt. Schließlich braucht jemand der bereits mit dem Projekt +vertraut ist, nicht unbedingt diese ganze Aufmachung. Wie man die +Software installiert, administriert und benutzt ist alles schon bekannt, +schließlich hat man es selbst geschrieben. Zweitens sind für +Aufgaben die sich um vernünftige Aufmachung und Präsentation drehen, +andere Fähigkeiten gefordert, als solche die man benötigt um Quellcode +zu schreiben. Menschen neigen dazu, sich auf ihre Stärken zu +konzentrieren, selbst wenn es für das Projekt besser wäre, ein wenig +Zeit in etwas zu investieren, was ihnen weniger liegt. +<xref linkend="getting-started"/> behandelt Aufmachung und +Präsentation im Detail, und erklärt warum es von Anfang an eine +Priorität sein sollte.</para> <para>Der nächste Trugschluss ist, dass bei freier Software wenig bis gar kein Projektmanagement erforderlich ist, bzw. umgekehrt, dass die selben Management Verfahren die für die Entwicklung im Betrieb benutzt werden, sich genau so gut auf eine Open Source Projekt anwenden lassen. Die Verwaltung ist bei einem Open Source Projekt, nicht immer besonders -offensichtlich, aber bei erfolgreichen Projekten gibt es sie, in irgend -einer Form im Hintergrund. Ein kleines Gedankenexperiment reicht um die -Gründe dafür zu zeigen. Ein Open Source Projekt besteht aus einem -zufällig zusammengewürfeltem Haufen von Programmierern—die an und -für sich schon eine notorisch eigensinnige Truppe sind—von denen +offensichtlich, im Hintergrund haben erfolgreiche Projekte sie aber, +in einer Form. Ein kleines Gedankenexperiment reicht um die Gründe +dafür zu zeigen. Ein Open Source Projekt besteht aus einem zufällig +zusammengewürfeltem Haufen Programmierer—die an und für sich +schon eine notorisch eigensinnige Truppe sind—von denen untereinander, wahrscheinlich keiner einem andere je begegnet ist, und von denen jeder u.U. unterschiedliche eigene persönliche Ziele verfolgt. Das Gedankenexperiment ist einfach, stellen Sie sich vor, was mit einer solchen Gruppe passieren würde, <emphasis>ohne</emphasis> eine -Verwaltung. Wenn kein Wunder geschieht, würden sie sehr schnell -außeinander gehen. Auch wenn wir es uns anders wünschen, läuft das -ganze nicht einfach von alleine. Die Verwaltung ist aber, wenn auch -ziemlich aktiv, meistens informell, subtil und unauffällig. Das einzige -was die Entwickler zusammenhält ist, dass sie mehr zusammen erreichen -können, als jeder für sich. Deshalb muss die Aufgabe einer Verwaltung -hauptsächlich darin bestehen, sie weiterhin daran glauben zu lassen, -indem sie Richtlinien für die Kommunikation festlegt, dafür sorgt, dass -brauchbare Entwickler nicht aufgrund persönlicher Eigenheiten an den -Rand gedrängt werden, und allgemein das Projekt als Ort zu gestalten, -an dem Entwickler zurückkehren wollen. Bestimmte Methoden das zu -erreichen, werden im Verlauf des Buchs behandelt.</para> +Verwaltung. Ohne ein Wunder, würden sie sehr schnell außeinander gehen. +Auch wenn wir es uns anders wünschen, läuft das ganze nicht einfach von +alleine. Die Verwaltung ist aber, wenn auch ziemlich aktiv, meistens +informell, subtil und unauffällig. Das einzige was die Entwickler +zusammenhält ist, dass sie mehr zusammen erreichen können, als jeder +alleine. Die Aufgabe einer Verwaltung besteht deshalb hauptsächlich +darin, dieses Gefühl aufrechtzuerhalten, indem sie Richtlinien für +die Kommunikation festlegt, brauchbare Entwickler davor schützt, +aufgrund persönlicher Eigenheiten an den Rand gedrängt zu werden, und +allgemein das Projekt als Ort zu gestalten, an dem Entwickler +zurückkehren wollen. Bestimmte Methoden das zu erreichen, werden im +Verlauf des Buchs behandelt.</para> <para>Zuletzt, gibt es noch die generelle Problemgruppe die man "Versagen der kulturellen Navigation" nennen könnte. Vor zehn Jahren, @@ -163,10 +161,10 @@ Meinungsverschiedenheiten und Parteigeist wie irgend eine geographisch gebundene Kultur—hat sie doch einen im Grunde genommen beständigen Kern. Die meisten erfolgreichen Open Source Projekte, -weisen alle oder zumindest einen großen Teil der Merkmale von diesem -Kern auf. Sie belohnen bestimmte Verhaltensmuster und bestrafen andere; -sie schaffen eine Atmosphäre, welche spontane Beteiligung ermutigt, -manchmal zu kosten zentraler Koordination; sie haben Konzepte von +zeigen alle, oder zumindest einen großen Teil der Merkmale von diesem +Kern. Sie belohnen bestimmte Verhaltensmuster und bestrafen andere; +sie schaffen eine Atmosphäre, die spontane Beteiligung fördert, +manchmal auf kosten zentraler Koordination; sie haben Konzepte von Unhöflichkeit und gutes Benehmen, die von den anderswo vorherrschenden erheblich abweichen können. Vielleicht am wichtigsten, sind die erfahrenen Teilnehmer die diese Konzepte meistens verinnerlicht haben, @@ -174,29 +172,29 @@ Nicht erfolgreiche Projekte weichen für gewöhnlich von diesen Kern wesentlich ab, wenn auch unabsichtlich, und haben oft keinen Konsens darüber, welches Benehmen als angemessen einzustufen ist. Das hat zur -folge, dass sobald Probleme auftreten, sich die Situation schnell +folge, dass sobald Probleme auftreten, die Situation schnell eskalieren kann, da den Teilnehmern ein etablierter Grundbestand -kultureller Reflexe fehlt, auf denen sie zurückgreifen können, um +kultureller Reflexe fehlt, worauf sie zurückgreifen können, um Meinungsverschiedenheiten zu klären.</para> <para>Dieses Buch ist ein praktischer Führer, keine anthropologische -Studie oder Historie. Grundkenntnisse über die Herkunft der Kultur der -freien Software sind dennoch, eine erforderliche Grundlage bei jedem -praktischen Ratschlag. Eine Person welche die Kultur versteht, kann -weit und breit in der Open Source Welt reisen, viele lokale Unterschiede -in den Gebräuchen und Dialekten begegnen und trotzdem in der Lage sein, -sich überall bequem und effektiv zu beteiligen. Im Gegensatz dazu, wird -eine Person ohne Verständnis für die Kultur, die Organisations- und -Beteiligungsvorgänge in einem Projekt als schwierig und voller -Überraschungen empfinden. Da die Anzahl der Menschen die freie Software -entwickeln immer noch stark im Anstieg ist, gibt es viele in der -letzten Kategorie—diese sind zum größten Teil vor kurzem -Eingewandert und das wird auch eine Weile lang so bleiben. Wenn Sie -meinen vielleicht eine von ihnen zu sein, gibt der nächste Abschnitt -einen Hintergrund für spätere Diskussionen, sowohl im Buch als auch im -Internet. (Wenn Sie andererseits bereits eine Weile lang mit Open Source -arbeiten, und u.U. bereits eine Menge seiner Geschichte kennen, können -Sie den nächsten Abschnitt getrost überspringen.)</para> +Studie oder Historie. Ein Hintergrund zur Kultur freier Software ist +dennoch, eine erforderliche Grundlage bei jedem praktischen Ratschlag. +Jemand der die Kultur versteht, kann weit und breit in der Open Source +Welt reisen, viele lokale Unterschiede in den Gebräuchen und Dialekten +begegnen und trotzdem in der Lage sein, sich überall bequem und +effektiv zu beteiligen. Im Gegensatz dazu, wird jemand ohne Verständnis +für die Kultur, die Organisations- und Beteiligungsvorgänge in einem +Projekt als schwierig und voller Überraschungen empfinden. Da die +Anzahl der Menschen die freie Software entwickeln immer noch stark im +Anstieg ist, gibt es viele in der letzten Kategorie—diese sind +zum größten Teil vor kurzem Eingewandert und das wird auch eine Weile +lang so bleiben. Wenn Sie meinen vielleicht eine von ihnen zu sein, +gibt der nächste Abschnitt einen Hintergrund für spätere Diskussionen, +sowohl im Buch als auch im Internet. (Wenn Sie andererseits bereits +eine Weile lang mit Open Source arbeiten, und u.U. bereits eine Menge +seiner Geschichte kennen, können Sie den nächsten Abschnitt getrost +überspringen.)</para> </simplesect> @@ -206,8 +204,8 @@ <para>Software wurde schon immer an Andere weitergegeben und miteinander geteilt. In den frühen Tagen der Computerindustrie, waren Hersteller der -Meinung, dass Wettbewerbsvorteile vor allem durch Innovationen in der -Hardware zu erreichen waren, und schenkten der Software als +Meinung, vor allem durch Innovationen in der Hardware +Wettbewerbsvorteile zu erreichen, und schenkten der Software als Vorteil gegenüber der Konkurrenz wenig Aufmerksamkeit. Viele Kunden dieser frühen Maschinen waren Wissenschaftler oder Techniker, die in der Lage waren, die Software die mit der Maschine selbst ausgeliefert wurde, _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
