path: root/talermerchantdemos/blog/articles/de/when-free-software-isnt-practically-superior.html

<!--#set var="ENGLISH_PAGE" value="/philosophy/when-free-software-isnt-practically-superior.en.html" -->

<!--#include virtual="/server/header.de.html" -->
<!-- Parent-Version: 1.79 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title> Wann Freie Software (aus praktischer Sicht) nicht besser ist - GNU-Projekt -
Free Software Foundation</title>

<!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
<!--#include virtual="/server/banner.de.html" -->
<h2> Wann Freie Software (aus praktischer Sicht) nicht besser ist</h2>

<p>
von <strong><a href="https://mako.cc/writing/">Benjamin Mako
Hill</a></strong></p>

<p>Das Leitbild der <span xml:lang="en" lang="en">Open Source Initiative</span>
(OSI) lautet: <cite title="https://opensource.org/about">„Open Source ist
eine Entwicklungsmethode für Software, die die Macht der verteilten
Peer-Review und Transparenz des Prozesses nutzt. Das Versprechen von Open
Source ist bessere Qualität, höhere Zuverlässigkeit, mehr Flexibilität,
geringere Kosten und ein Ende der rücksichtslosen
Anbieterabhängigkeit.“</cite></p>

<p>Seit mehr als einem Jahrzehnt spricht sich die Free Software Foundation
gegen diese „Open Source“-Charakterisierung der Freie-Software-Bewegung
aus. In erster Linie haben sich Freie-Software-Befürworter gegen dieses
<!--diesen Rahmen -->Schubladendenken ausgesprochen, weil „Open Source“ eine
explizite Bemühung ist unsere Kernbotschaft von Freiheit herunterzuspielen
und die Rolle unserer Bewegung in den Erfolg der von uns geschaffenen
Software zu verschleiern. Wir haben argumentiert, dass „Open Source“
grundlegend schlecht ist, weil sie davon abzuhalten versucht über
Softwarefreiheit zu sprechen. Aber es gibt noch einen anderen Grund, warum
wir dem Open-Source-Schublade gegenüber argwöhnisch sein sollten. Das
grundlegende Open-Source-Argument, wie im Leitbild oben zitiert, ist oft
falsch.</p>

<p>Obwohl die Open-Source-Initiative suggeriert, <cite
title="https://opensource.org/about"><q>Das Versprechen von Open Source ist
eine bessere Qualität, höhere Zuverlässigkeit, mehr Flexibilität
…</q></cite>, wird dieses Versprechen nicht immer realisiert. Obwohl wir
nicht oft auf die Tatsache aufmerksam machen, kann jeder Nutzer eines in
einem frühen Stadium befindlichen Freie-Software-Projekts dartun, dass Freie
Software nicht immer&#160;&#8209;&#160;aus rein praktischer
Hinsicht&#160;&#8209;&#160;so praktisch sei wie ihr proprietärer
Gegenpart. Freie Software ist manchmal von geringer Qualität. Sie ist
manchmal unzuverlässig. Manches mal unflexibel. Wenn man die Argumente
zugunsten von Open Source ernst nimmt, muss man erklären, warum Open Source
seinem „Versprechen“ nicht gefolgt ist und daraus schlussfolgern, dass
proprietäre Hilfsmittel eine bessere Wahl wären. Doch dafür gibt es keinen
Grund.</p>

<p>Richard Stallman erläutert in seinem Artikel <cite><a
href="/philosophy/open-source-misses-the-point">Warum Open Source das Ziel
Freie Software verfehlt</a></cite>: <em>„Der Gedanke von Open Source ist,
Benutzern das Ändern und Weiterverbreiten von Software zu erlauben, um sie
leistungsfähiger und zuverlässiger zu machen. Aber das ist nicht
garantiert. Entwickler proprietärer Software sind nicht notwendigerweise
inkompetent. Manchmal stellen sie ein Programm her, das leistungsfähig und
zuverlässig ist, obwohl es die Freiheit der Nutzer nicht respektiert.“</em></p>

<p>Für Open Source ist qualitativ schlechte Software ein zu erklärendes Problem
oder ein Grund die Software ganz zu meiden. Für Freie Software ist ein
Problem, dass daran <!--über einen bestimmten Zeitraum -->fortgesetzt
gearbeitet werden muss. Für Freie-Software-Befürworter sind Störungen und
fehlende Eigenschaften nie eine Schande. Jedes Stück Freie Software, das die
Freiheit der Nutzer respektiert, besitzt einen starken inhärenten Vorteil
gegenüber einem proprietären Mitbewerber, bei dem das nicht der Fall
ist. Selbst wenn andere Probleme gibt, hat Freie Software immer Freiheit.</p>

<p>Selbstverständlich muss an jedem Stück Freie Software an irgendeinem Punkt
angefangen werden. Ein brandneues Stück Software wird kaum beispielsweise
mehr können als ein ausgereiftes proprietäres Programm. Projekte beginnen
mit vielen Programmfehlern und werden im Laufe der Zeit immer
besser. Während Open-Source-Befürworter behaupten könnten, dass ein Projekt
im Laufe der Zeit und mit etwas Glück in puncto Nutzen wächst, stellen
Freie-Software-Projekte für einen Freie-Software-Befürworter vom ersten Tag
an einen wichtigen Beitrag dar. Jede Software, die Nutzern die Kontrolle
über ihre Technologie gibt, ist ein Schritt vorwärts. Verbesserte Qualität
während ein Projekt reift ist das Sahnehäubchen.</p>

<p>Eine zweite, vielleicht noch vernichtendere Tatsache ist, dass der
kooperative, verteilte Peer-Review-Entwicklungsprozess im Kern der
Open-Source-Definition mit der Praxis der Softwareentwicklung in der
überwiegenden Mehrzahl der Projekte unter freien (oder „Open-Source“-)
Lizenzen wenig Ähnlichkeit hat.</p>

<p>Mehrere wissenschaftliche Studien der <a
href="/software/repo-criteria">Freie-Software-Hosting</a>-Präsenzen <em><a
href="">SourceForge</a></em> und <em><a
href="//sv.gnu.org">Savannah</a></em> haben gezeigt, was viele
Freie-Software-Entwickler, die eine Codebasis online stellten, bereits aus
erster Hand wissen. Die bei weitem überwiegende Mehrheit der
Freie-Software-Projekte ist nicht besonders kooperativ. Die
durchschnittliche Zahl der Mitwirkenden an einem Freie-Software-Projekt auf
Sourceforge? Eins. Ein alleiniger Entwickler. SourceForge-Projekte um den
95-Prozentbereich haben nach Teilnehmergröße nur fünf Mitwirkende. Mehr als
die Hälfte dieser Freie-Software-Projekte&#160;&#8209;&#160;und sogar die
meisten Projekte, die mehrere erfolgreiche Freigaben veröffentlichten und
häufig heruntergeladen wurden&#160;&#8209;&#160;sind die Arbeit eines
einzelnen Entwicklers mit wenig Hilfe von außen.</p>

<p>Durch die Betonung der Macht kooperativer Entwicklung und „verteilten
Peer-Review“ scheinen Open-Source-Ansätze sehr wenig darüber auszusagen,
warum man die überwiegende Mehrheit der Freie-Software-Projekte nutzen oder
dazu beitragen sollte. Da der angebliche Nutzen der Zusammenarbeit nicht
realisierbar sind, wenn es keine Zusammenarbeit gibt, sind die überwiegende
Mehrheit freier Entwicklungsprojekte kein technischer Nutzen gegenüber einem
proprietären Mitbewerber.</p>

<p>Für Freie-Software-Befürworter werden diese Projekte jeweils als wichtige
Erfolge angesehen. Da jedes Stück Freie Software die Freiheit seiner Nutzer
respektiert, behaupten Befürworter von Softwarefreiheit, dass jedes Stück
Freie Software mit einem inhärenten ethischen Vorteil gegenüber proprietären
Wi­der­sa­chern beginnt&#160;&#8209;&#160;sogar noch einem mehr an
Eigenschaften. Durch Betonung von Freiheit über praktischen Vorteilen, ist
die Freie-Software-Befürwortung auf eine Weise in einer technischen
Sachhaltigkeit so verwurzelt, wie es „Open Source“ häufig nicht ist. Wenn
Freie Software besser ist, können wir diese Tatsache feiern. Wenn sie es
nicht ist, müssen wir sie nicht als eine vernichtende Rezension der
Freie-Software-Befürwortung oder gar als überzeugendes Argument gegen die
Nutzung der betreffenden Software behandeln.</p>

<p>Open-Source-Befürworter müssen ihre These verteidigen, dass frei entwickelte
Software besser sein sollte als proprietäre Software bzw. mit der Zeit
wird. Freie-Software-Unterstützer können stattdessen fragen, <em>„Wie können
wir Freie Software besser machen?“</em> Innerhalb eines
Freie-Software-Rahmens gibt es qualitativ hochwertige Software als Mittel
zum Selbstzweck, anstatt einem Ende selbst. Freie Software-Entwickler
sollten bestrebt sein, funktionelle, flexible Software zu entwickeln, die
ihren Nutzern auch dienlich ist. Doch dies ist nicht der einzige Weg zur
Lösung, welcher sowohl ein leichteres als auch viel wichtigeres Ziel ist:
Respektieren und Schützen ihrer Freiheit.</p>

<p>Natürlich müssen wir keine Behauptungen zurückweisen, dass Zusammenarbeit
eine wichtige Rolle bei der Schaffung qualitativ hochwertiger Software
spielen kann. In vielen der erfolgreichsten Freie-Software-Projekten wurde
es offenbar genau so gehandhabt. Der Nutzen von Zusammenarbeit ist (auch)
etwas zu verstehen, zu unterstützen und darauf hinzuarbeiten, anstatt etwas
als selbstverständlich zu betrachten, angesichts des Beweises derer, die
sich weigern sich der Ideologie anzupassen.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.de.html" -->
<div id="footer">
<div class="unprintable">

<p>Bitte senden Sie allgemeine Fragen zur FSF &amp; GNU an <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Sie können auch die <a
href="/contact/"><span xml:lang="en" lang="en">Free Software
Foundation</span> kontaktieren</a>. Ungültige Verweise und andere
Korrekturen oder Vorschläge können an <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a> gesendet
werden.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Bei der Übersetzung dieses Werkes wurde mit größter Sorgfalt
vorgegangen. Trotzdem können Fehler nicht völlig ausgeschlossen
werden. Sollten Sie Fehler bemerken oder Vorschläge, Kommentare oder Fragen
zu diesem Dokument haben, wenden Sie sich bitte an unser Übersetzungsteam <a
href="mailto:web-translators@gnu.org?cc=www-de-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Weitere Informationen über die Koordinierung und Einsendung von
Übersetzungen unserer Internetpräsenz finden Sie in der <a
href="/server/standards/README.translations">LIESMICH für Übersetzungen</a>.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1999-2011 Benjamin Mako Hill.</p>

<p>Dieses Werk ist lizenziert unter einer <a rel="license"
href="//creativecommons.org/licenses/by-sa/3.0/us/deed.de">Creative Commons
Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Vereinigte Staaten
von Amerika</a>-Lizenz.</p>

<!--#include virtual="/server/bottom-notes.de.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
<strong>Übersetzung:</strong> Jоегg Kоhпе <a
href="//savannah.gnu.org/projects/www-de">&lt;www-de&gt;</a>, 2017.</div>

<p class="unprintable"><!-- timestamp start -->
Letzte Änderung:

$Date: 2017/10/26 12:58:38 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>