Author: mbarkhau Date: Wed Sep 5 05:03:52 2007 New Revision: 1147 Log: Started review of ch04
Modified: trunk/de/ch04.xml Modified: trunk/de/ch04.xml ============================================================================== --- trunk/de/ch04.xml (original) +++ trunk/de/ch04.xml Wed Sep 5 05:03:52 2007 @@ -5,67 +5,66 @@ <simplesect> <para>Die erste Frage, die Leute über freie Software fragen ist für -gewöhnlich "Wie funktioniert es? Was hält ein Projekt am laufen? Wer +gewöhnlich, "Wie funktioniert es? Was hält ein Projekt am laufen? Wer trifft die Entscheidungen?" Ich bin immer unzufrieden mit den faden -Antworten über Meritokratie, der Geist der Zusammenarbeit, Code der -für sich selber spricht, usw. Tatsache ist, dass die Frage nicht so -leicht zu beantworten ist. Meritokratie, Zusammenarbeit und laufender -Code sind alle ein Teil davon, aber sie tragen wenig dazu bei, zu -erklären, wie Projekte wirklich auf einer täglichen basis laufen, und -sagen nichts darüber aus wie Konflikte gelöst werden.</para> - -<para>Diese Kapitel versucht die Gemeinsamen strukturellen Grundsteine -welche erfolgreiche Projekte aufzuzeigen. Mit "erfolgreich, meine ich -nicht nur im sinne technischer Qualität, sondern auch was die -betriebliche Gesundheit und Überlebensfähigkeit angeht. Die -betriebliche Gesundheit ist die andauernde Fähigkeit des Projekts neue -Code Beiträge und Entwickler aufzunehmen, sowie auf neue Bug Meldungen -reagieren zu können. Überlebensfähigkeit ist die Fähigkeit des -Projekts, unabhängig von irgend einem Beteiligten oder Sponsor -fortbestehen zu können—betrachten Sie es als die -Wahrscheinlichkeit, dass das Projekt weiter gehen würde selbst wenn -alle Gründungsmitglieder ihre Sachen packen würden und sich anderen -Sachen widmen würden. Technischer Erfolg ist nicht schwer zu erreichen, -aber ohne eine robusten Entwicklerbasis, kann ein Projekt vielleicht -nicht mit dem Wachstum welches anfänglicher Erfolg bringt, oder dem -Verlust charismatischer Individuen, zurechtkommen.</para> - -<para>Es gibt verschiedene Wege diesen Art Erfolg zu erreichen. Manche -beinhalten eine formale Struktur der Regierung, womit Debatten -aufgelöst werden, neue Entwickler eingeladen werden (manchmal auch -ausgeladen), neue Funktionen geplant werden, usw. Andere beinhalten -weniger formelle Strukturen, aber bewusstere Zurückhaltung, um eine -Atmosphäre der Fairness herzustellen, auf das sich Leute verlassen -können als eine so gut wie echte Regierungsform. Beide Wege führen -zum gleichen Ergebnis: Das Gefühl einer beständigen Institution, -welches von Gewohnheiten und Abläufen unterstützt werden, die alle -Beteiligten wohl verstehen. Diese Eigenschaften sind noch wichtiger -bei selbst organisierenden Systemen als bei zentral verwalteten, da -bei selbst organisierenden Systemen, jeder sich darüber im klaren ist, -das ein paar faule Äpfel die gesamte Obstschale verderben, zumindest -eine Zeit lang.</para> +Geschmack der Antworten über Meritokratie, der Geist der Zusammenarbeit, +Code der für sich selbst spricht, usw. Tatsache ist, dass die Frage +nicht so leicht zu beantworten ist. Meritokratie, Zusammenarbeit und +laufender Code gehören zwar alle dazu, tragen aber wenig einer +Erklärung bei, wie Projekte wirklich auf einer täglichen Basis ablaufen +und sagen nichts darüber aus wie Konflikte gelöst werden.</para> + +<para>Diese Kapitel versucht die Gemeinsamen strukturellen +Grundbausteine erfolgreicher Projekte aufzuzeigen. Mit "erfolgreich, +meine ich nicht nur im Sinne technischer Qualität, sondern auch die +betriebliche Gesundheit und Überlebensfähigkeit. Die betriebliche +Gesundheit ist die andauernde Fähigkeit des Projekts neue Code Beiträge +und Entwickler aufzunehmen, sowie auf neue Bug Meldungen reagieren zu +können. Überlebensfähigkeit ist die Fähigkeit des Projekts, unabhängig +von irgend einem Beteiligten oder Geldgeber fortbestehen zu +können—betrachten Sie es als die Wahrscheinlichkeit für das +Weiterleben eines Projekts, selbst wenn alle Gründungsmitglieder ihre +Sachen packen und sich etwas anderem widmen würden. Technischer Erfolg +ist nicht schwer zu erreichen, aber ohne eine solide +Entwicklergemeinschaft, kann ein Projekt vielleicht nicht mit dem +Wachstum des anfänglichen Erfolgs noch mit dem Verlust charismatischer +Individuen zurechtkommen.</para> + +<para>Es gibt verschiedene Wege solch einen Erfolg zu erreichen. Manche +benutzen eine formale Regierungsstruktur um Debatten zu lösen, neue +Entwickler einzuladen (oder manchmal auch auszuladen), neue Funktionen +zu planen, usw. Andere haben weniger formelle Strukturen, dafür aber +bewusste Zurückhaltung der Teilnehmer, um eine gerechte Atmosphäre +herzustellen, indem sich Leute auf diese so gut wie echte Regierungsform +verlassen können. Beide Wege führen zum gleichen Ziel: Das Gefühl einer +beständigen Institution, welches durch Gewohnheiten und Abläufen +unterstützt wird, die alle Beteiligten gut verstehen. Diese +Eigenschaften sind bei selbst organisierenden Systemen noch wichtiger +als bei solchen mit einer zentralen Verwaltung, da jeder sich darüber +im klaren ist, dass ein paar faule Äpfel die gesamte Obstschale +verderben können, zumindest eine Zeit lang.</para> <sect1 id="forkability"> -<title>Forkability</title> +<title>Die Gefahr eines Forks</title> -<para>Der Fork (de. Gabel im sinne von Aufspaltung) -Die unabdingbare Zutat, welche Entwickler in einem freien Software -Projekt zusammenbindet, und Sie Bereitwillig macht wenn Kompromisse -nötig einzugehen, ist die <firstterm>Forkbarkeit</firstterm> des Codes: -Die Möglichkeit von jedem, eine Kopie des Quellcodes zu nehmen und ein -konkurierendes Projekt anzufangen, bekannt als <firstterm>Fork -</firstterm>. Das paradoxe daran ist, dass die <emphasis>Möglichkeit -</emphasis> eines Forks in freien Software Projekten für gewöhnlich -ein viel größerer Antrieb ist, als wirkliche Forks welche sehr selten -sind. Da ein Fork schlecht für alle ist (aus Gründen, die in <xref -linkend="forks"/><phrase output="printed"> im Kapitel <xref -linkend="managing-volunteers"/></phrase> detailiert untersucht werden), -sind mehr Beteiligte dazu bereit Kompromisse einzugehen, wenn die -Gefahr eines Forks besteht.</para> +<para>Prinzipiell steht jedem Entwickler offen sich eine Kopie des +Quellcodes zu nehmen und einen +<firstterm>Fork</firstterm><footnote><para>de. Gabel im Sinne einer +Gabelung</para></footnote> anzufangen. Diese Zutat ist für freie +Software Projekte unabdingbar da sie Entwickler zusammenbindet und wenn +es nötig wird Bereit macht, Kompromisse einzugehen. Das paradoxe daran +ist, dass die <emphasis>Möglichkeit</emphasis> für einen Fork in einem +freien Software Projekte meistens ein viel größerer Antrieb ist, als ein +echter Fork, der nur sehr selten vorkommt. Da ein Fork schlecht für alle +ist (die Gründe dafür werden in +<xref linkend="forks"/><phrase output="printed"> im Kapitel +<xref linkend="managing-volunteers"/></phrase> detailiert untersucht), +sind mehr Beteiligte bereit Kompromisse einzugehen, wenn ein Fork +droht.</para> <para>Forks, oder vielmehr potentielle Forks, sind der Grund, dass es -keine wirklichen Diktatoren in freien Software Projekten gibt. Das mag -sich nach einer Überraschenden Behauptung anhören, wenn man bedenkt wie +keine wirklichen Diktatoren in freien Software Projekten gibt. Das liest +sich nach einer Überraschenden Behauptung, wenn man bedenkt wie gängig es ist das jemand ein "Diktator" oder "Tyrann" in einem beliebigen Open Source Projekt genannt wird. Diese Art der Tyrannei ist aber besonders, recht unterschiedlich von dem gewöhnlichen _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
