path: root/talermerchantdemos/blog/articles/nl/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.nl.html" -->
<!-- Parent-Version: 1.79 -->

<!-- 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" -->
<h2> Vrije software is (praktisch gezien) niet altijd beter</h2>

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

<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="http://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 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">
<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 submitting 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: 2017/01/14 14:58:43 $

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