taler-merchant-demos

when-free-software-isnt-practically-superior.html (11462B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/when-free-software-isnt-practically-superior.en.html" -->
 
 <!--#include virtual="/server/header.nl.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="essays aboutfs practice" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title> Vrije software is (praktisch gezien) niet altijd beter - GNU-project - Free
 Software Foundation</title>
 
 <!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
 <!--#include virtual="/server/banner.nl.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.nl.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.nl.html" -->
 <div class="article reduced-width">
 <h2> Vrije software is (praktisch gezien) niet altijd beter</h2>
 
 <address class="byline">
 door <a href="https://mako.cc/writing/">Benjamin Mako Hill</a></address>
 
 <p>In de missie van het <em>Open Source Initiative</em> staat: &ldquo;Open bron
 is een ontwikkelingsmodel voor software dat gebruik maakt van de kracht van
 onderlinge toetsing en transparantie van processen. De belofte van open bron
 is betere kwaliteit, hogere betrouwbaarheid, meer flexibiliteit, lagere
 kosten, en een einde aan vendor lock-in.&rdquo;</p>
 
 <p>Al meer dan een decennium pleit de Free Software Foundation tegen deze
 &ldquo;open bron&rdquo;-karakteristiek van de
 vrije-softwarebeweging. Voorstanders van vrije software hebben vooral tegen
 deze weergave gepleit omdat &ldquo;open bron&rdquo; expliciet oproept om
 onze kernboodschap van vrijheid te begraven, en het belang van onze beweging
 in het succes met de software die wij hebben gemaakt verdoezelt. We hebben
 beargumenteerd dat &ldquo;open bron&rdquo; fundamenteel slecht is, omdat het
 mensen ervan probeert te weerhouden over softwarevrijheid te praten. Maar er
 is een andere reden waarom we op moeten opletten voor de beeldvorming van
 open bron. Het fundamentele argument voor open bron, zoals aangehaald in de
 bovenstaande missieverklaring, is vaak onjuist.</p>
 
 <p>Hoewel het <em>Open Source Initiative</em> de suggestie wekt dat &ldquo;de
 belofte van open bron betere kwaliteit, hogere betrouwbaarheid en meer
 flexibiliteit&rdquo; is, wordt deze belofte niet altijd waar gemaakt. Hoewel
 we het niet vaak benadrukken, kan elke gebruiker van een beginnend
 vrije-software-project uitleggen dat vrije software niet altijd zo
 gemakkelijk is (praktisch gezien) als zijn private concurrenten. Vrije
 software is soms van lage kwaliteit. Het is soms onbetrouwbaar. Soms is het
 niet flexibel. Als mensen de argumenten van open bron serieus nemen, moeten
 ze uitleggen waarom open bron zich niet aan zijn &ldquo;belofte&rdquo;
 houdt, en zouden ze moeten concluderen dat private software een betere keuze
 is. Maar er is ook geen reden waarom we dat zouden moeten doen.</p>
 
 <p>Richard Stallman heeft het hierover in zijn artikel <a
 href="/philosophy/open-source-misses-the-point.html">waarom open bron de
 essentie niet begrijpt</a> waarin hij uitlegt: &ldquo;De grondgedachte
 achter open bron is dat wanneer gebruikers de broncode kunnen wijzigen en
 kopi&euml;ren, dit automatisch leidt tot krachtiger en betrouwbaarder
 software. Dit is echter niet gegarandeerd. Ontwikkelaars van private
 software zijn niet per definitie onbekwaam. Soms produceren ze een
 betrouwbaar en krachtig programma, ook al treedt het de vrijheid van
 gebruikers met voeten.&rdquo;</p>
 
 <p>Voor open bron is software van slechte kwaliteit een probleem dat moet
 worden uitgelegd, of een reden om de software in zijn geheel te
 vermijden. Voor vrije software is het een probleem waaraan gewerkt moet
 worden. Voor vrije-software-supporters zijn defecten en ontbrekende functies
 nooit een reden voor schaamte. Elk stuk vrije software dat de vrijheid van
 de gebruiker respecteert, heeft een inherent sterk voordeel ten opzichte van
 een niet-vrije concurrent. Zelfs als vrije software andere problemen heeft,
 geeft het nog altijd vrijheid.</p>
 
 <p>Natuurlijk moet elk stuk vrije software ergens beginnen. Bijvoorbeeld, een
 fonkelnieuw stuk software heeft waarschijnlijk minder mogelijkheden dan een
 bestaand niet-vrij programma. Projecten beginnen met veel bugs en hebben
 tijd nodig om te verbeteren. Waar open-bron-voorstanders wellicht menen dat
 een project nuttiger wordt met wat tijd en geluk, ziet de
 vrije-software-voorstander een vrije-software-project vanaf dag
 &eacute;&eacute;n als een belangrijke bijdrage. Elk stuk software die
 gebruikers zeggenschap over hun technologie geeft is een stap
 voorwaarts. Hogere kwaliteit in latere stadia is de kers op de taart.</p>
 
 <p>Het tweede feit, dat misschien belastender is, is dat het samenwerkende,
 gespreide ontwikkelproces met onderlinge toetsing dat de basis vormt van de
 open-bron-definitie weinig overeenkomsten vertoont met de praktijk van
 software-ontwikkeling bij de meerderheid van projecten met een vrije (of
 &ldquo;open bron&rdquo;) licentie.</p>
 
 <p>Verschillende wetenschappelijke onderzoeken over <a
 href="/software/repo-criteria.html"> vrije-software-hostingsites</a>
 SourceForge en <a href="https://sv.gnu.org">Savannah</a> hebben laten zien
 wat veel vrije-software-ontwikkelaars die code online hebben gezet uit de
 eerste hand weten. De meerderheid van de vrije-software-projecten is niet zo
 samenwerkend. De mediaan van het aantal bijdragers aan een
 vrije-software-project op SourceForge? E&eacute;n. Een enkele
 ontwikkelaar. Het 95e percentiel van deelnemersgrootte  voor
 SourceForge-projecten is slechts vijf bijdragers. Meer dan de helft van deze
 vrije-software-projecten&mdash;en zelfs de meeste projecten die meerdere
 succesvolle uitgaven hebben gedaan en vaak zijn gedownload, zijn het werk
 van een enkele ontwikkelaar met weinig hulp van buitenaf.</p>
 
 <p>Door de nadruk te leggen op de kracht van samenwerking en het
 &ldquo;gespreide proces met onderlinge toetsing&rdquo;, lijken
 open-bron-voorstanders weinig te kunnen zeggen over de vraag waarom je het
 grootste gedeelte van de vrije-software-projecten zou moeten gebruiken of
 eraan zou bijdragen. Omdat de beweerde samenwerkingsvoordelen niet mogelijk
 zijn zonder samenwerking, hebben de meeste vrije-software-projecten geen
 technisch voordeel ten opzichte van een private concurrent.</p>
 
 <p>Voor vrije-software-voorstanders is elk van deze projecten een belangrijk
 succes. Omdat elk stuk vrije software de vrijheid van gebruikers
 respecteert, menen voorstanders van softwarevrijheid dat elk stuk vrije
 software al een ethische voorsprong heeft op een private
 concurrent&mdash;zelfs eentje die meer functies heeft. Door vrijheid meer te
 benadrukken dan praktische voordelen is de roep om vrije software geworteld
 in de technische realiteit, op een manier waarop open bron dat vaak niet
 is. Als de vrije software beter is hebben we iets om te vieren. Als dat niet
 zo is hoeven we dat niet te beschouwen als kritiek op de roep om vrije
 software, laat staan als een dwingende reden tegen het gebruik van die
 software.</p>
 
 <p>Voorstanders van open bron moeten hun stelling bewijzen dat vrijelijk
 ontwikkelde software, eventueel na een tijd, beter zou moeten zijn dan
 private software. Vrije-software-voorstanders kunnen daarentegen vragen:
 &ldquo;Hoe kunnen we vrije software beter maken?&rdquo; In het licht van
 vrije software is software van hoge kwaliteit een middel en geen doel op
 zich. Vrije-software-ontwikkelaars zouden moeten streven naar functionele en
 flexibele software die gebruikers tot nut is. Maar dat is niet de enige
 manier om stappen te zetten richting een gemakkelijker en veel belangrijker
 doel: hun vrijheid respecteren en beschermen.</p>
 
 <p>Natuurlijk hoeven we het argument dat samenwerking een belangrijke rol kan
 spelen bij het maken van software van hoge kwaliteit, niet af te wijzen. Bij
 veel van de meest succesvolle vrije-software-projecten is die samenwerking
 duidelijk van belang geweest. De voordelen van samenwerking zijn iets om te
 begrijpen, ondersteunen en gebruiken, en dienen niet ter vervanging van
 ideologie.</p>
 </div>
 
 <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.nl.html" -->
 <div id="footer" role="contentinfo">
 <div class="unprintable">
 
 <p>Gelieve algemene vragen over FSF &amp; GNU te sturen naar <a
 href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Er zijn ook nog <a
 href="/contact/">andere manieren om in contact te komen</a> met de
 FSF. Foute links en andere correcties graag sturen aan <a
 href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</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 contributing translations of
         our web pages, see <a
         href="/server/standards/README.translations.html">Translations
         README</a>. -->
 We doen ons best om goede vertalingen te maken maar staan altijd open voor
 verbeteringen. Suggesties, op- en aanmerkingen sturen aan: <a
 href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
 <p>Zie <a href="/server/standards/README.translations.html"> Translations
 README</a> voor informatie over het onderhoud van vertalingen op deze
 website.</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>Deze pagina is uitgebracht onder een a <a rel="license"
 href="https://creativecommons.org/licenses/by-sa/3.0/us/deed.nl">Creative
 Commons Naamsvermelding-GeenAfgeleideWerken Verenigde Staten Licentie</a>.</p>
 
 <!--#include virtual="/server/bottom-notes.nl.html" -->
 <div class="translators-credits">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 <strong>Vertaling:</strong> <a
 href="//savannah.gnu.org/projects/www-nl">www-nl</a></div>
 
 <p class="unprintable"><!-- timestamp start -->
 Bijgewerkt:
 
 $Date: 2021/09/28 16:34:04 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>