diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/nl/when-free-software-isnt-practically-superior.html')
| -rw-r--r-- | talermerchantdemos/blog/articles/nl/when-free-software-isnt-practically-superior.html | 213 |
1 files changed, 213 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/nl/when-free-software-isnt-practically-superior.html b/talermerchantdemos/blog/articles/nl/when-free-software-isnt-practically-superior.html new file mode 100644 index 0000000..752fc69 --- /dev/null +++ b/talermerchantdemos/blog/articles/nl/when-free-software-isnt-practically-superior.html @@ -0,0 +1,213 @@ +<!--#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: “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.”</p> + +<p>Al meer dan een decennium pleit de Free Software Foundation tegen deze +“open bron”-karakteristiek van de +vrije-softwarebeweging. Voorstanders van vrije software hebben vooral tegen +deze weergave gepleit omdat “open bron” 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 “open bron” 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 “de +belofte van open bron betere kwaliteit, hogere betrouwbaarheid en meer +flexibiliteit” 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 “belofte” +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: “De grondgedachte +achter open bron is dat wanneer gebruikers de broncode kunnen wijzigen en +kopië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.”</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 +éé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 +“open bron”) 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é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—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 +“gespreide proces met onderlinge toetsing”, 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—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: +“Hoe kunnen we vrije software beter maken?” 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 & GNU te sturen naar <a +href="mailto:gnu@gnu.org"><gnu@gnu.org></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"><webmasters@gnu.org></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"> + + <web-translators@gnu.org></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"><web-translators@gnu.org></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 © 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> + |